We had our class meeting for the firs time in 3 weeks, it was very productive since it produced many action items. Overall I would say the project is it a bit of a hump so I’m focusing my attention on the development of the User Interface so we have something to call our product. This starts with the home page, it was decided at the meeting that this would be integrated with the content frames and reclassified as the user interface.
So my concept for the page viewer will substitute for the home page, this of course meant it required some polishing.
This first revision my goals were:
- Relative sizing – based on screen resolution
- Actual content in the ‘pages’ frames
- Naming concept
- Mild animation polishing
- Swipe functionality
Relative Sizing:
The one minor setback is the lack of an iPad, the best solution to this problem is of course development with a relative content display in mind. Meaning the use of percentages over explicit sizing of elements. With the page view specifically this created a minor issue which was solved with the use of JavaScript. The first issue with relative sizing was the width of #article-wrapper, the reason this could not be solved with modifying CSS/HTML is the page construction concept, in which the wrapper is meant to extend past the end of the page. (See article viewer concept) This meant when i set the width of any child within #article-wrapper based on a % it would go by the width of this div which by design will be wider than the page. To solve this issue I simply used window.innerWidth which is a built in JavaScript function, this solution has worked flawlessly especially since the user will be unable to move the iPad. All I did was went in and refactored all referenced to X% and changed it to pageWidth*0.x+’px’. This solution works however it might be a good idea to seek an alternative when we get more into the project. So this problem was solved and everything with regard to displaying relative to the window; while it might seem like a solution to a problem that wouldn’t exist if we had iPads I believe this kind of development will yield a better end product, if this web application can be ported to other devices it has the potential to be more beneficial.
Actual Content:
So if you had to opportunity to look at the initial proof of concept for the page viewer you would notice that the text inside the ‘page’ or ‘article’ divs would wrap when the size got smaller. This was obviously a proof of concept and for the final concept we would prefer having some nice content in these areas. The goal to accomplishing this was to use a nested div inside of the previous divs that would hold the real content and have no animations directly called on them. I named these the ‘.article-preview’ and what nesting these means is that the content would not be modified with regard to sizing, that it would always maintain its ‘actual width’ which in relative terms was 59% of the page. This was accomplished using the same technique in the previous section, using pageWidth. This worked as there was already a proof of concept in article viewer.
Naming Concept:
If you looked at the initial concept the pages were just there, and it was assumed that each page was based on the navigation title. I didn’t think this was enough as some users might not want to use the navigation and instead use swipe navigation which will be cover in another section. So, my goal was to create a relatively appealing naming concept that would be visible to users who may ignore or fail to notice the navigation. So this concept was basic CSS3 and HTML which rotated the text, here is a screenshot (I also added icons to show the potential this had.)
The only useful thing this offer is that the text can be dynamic.
Animation Polishing:
I was really just modifying the animation concept to also modify the height and top margin, you can see outcome in the image above.
Swipe Functionality:
This was pretty easy, especially after making the article viewer concept, I used the .live() function with the virutal events ‘swiperight’ and ‘swipeleft’. This made for a really cool effect, the only issue I ran into was updating the current article according to the navigation, all I had to do with this is the inverse of what I did with the clicking on the navigation. I took the current article index, removed the classes ‘ui-btn-active ui-state-persist’ and then incremented the curArticle respectively (++ for swipe left, and — for swipe right) then added classes ‘ui-btn-active ui-state-persist’ on the new curArticle. I also had to create a check for the last article and first article, which was pretty simple, if it was the first or last I would not execute the animation depending on what was swiped.
Overall this step from concept to potential production idea wasn’t overly challenging because I utilized a lot of the lessons learned during the article viewer concept development. I am somewhat pleased with the result, however I feel the input of others would yield a better product. The biggest take away from this updating is that applying lessons learned in previous programs seriously save you time, from idea to completion this took only 2-3 solid man hours.
This concludes my V 0.0 to V 0.2 update for the page viewer (there was a 0.1, I just like even numbers so I made changed); Until next time.
-Joe
From the blog itsJoe's Blog » cs-wsu by itsjoeyoung and used with permission of the author. All other rights reserved by the author.
