Tim Johnsen Intelligent Design for Mobile Readers Abstract...............................................................................................................................2 1. Introduction ....................................................................................................................2 1.1 History ...............................................................................................................2 1.

2 The State of Mobile............................................................................................2 1.3 The Mobile Reader.............................................................................................4 2. Intelligent Design for Mobile ........................................................................................5 2.1 Controls ..............................................................................................................5 2.1.1 System Software Controls...............................................................................6 2.1.2 System Hardware Controls ...........................................................................10 2.1.3 Dynamic Controls .........................................................................................12 2.2 Web Views .......................................................................................................14 2.2.1 Web View Layout Issues ...............................................................................14 2.2.2 Web View Speed Issues ................................................................................17 2.2.3 Web Apps ......................................................................................................18 2.3 Caching.............................................................................................................19 2.3.1 State Saving...................................................................................................19 2.3.2 Caching of Content .......................................................................................20 2.3.3 Over-Caching ................................................................................................21 2.3.4 Gracefully Handling Lost Connectivity ........................................................22 2.4 Content Layout ................................................................................................22 2.4.1 Displaying Large Content .............................................................................23 2.4.2 Content and Control Layout .........................................................................24 2.4.3 Differences in Form Factors .........................................................................25 3. Demonstration: NGadget ............................................................................................26 3.1 Controls ............................................................................................................26 3.2 Web Views and Content Layout .......................................................................29 3.3 Caching.............................................................................................................33 4. Conclusion ....................................................................................................................34 References .........................................................................................................................36

Abstract In the modern world of redundant and excessive smartphone apps, design and user experience play a crucial role in adoption of mobile software. This thesis outlines some effective strategies for producing top-notch user experiences for mobile, as well as a creative project implementing all of these principles. The creative project is mobile news reading app for the iOS focused on a delightful user interface. Contents include effective use of system and hardware controls, use of the web in native mobile apps, content caching, and layout for different form-factors. 1. Introduction 1.1 History The advent of the personal computers in the 70s and 80s revolutionized the way that the average person sees computing. Before personal computers, computers were portrayed as temperamental, monolithic boxes occupying whole rooms that could only be operated by people with PhDs. The Apple Lisa, Machintosh, and Microsofts Windows 3.x all sporting GUIs really brought computers to the people in ways never before imagined. The internet, again, did the same thing with networking. Overnight, networking went from being portrayed as complex technology keeping government nukes in order into something people did at home for leisure and as a serious business tool. These two technologies are solely responsible for the information age, but they are not without their follies. With the creation of a hot, new, consumer-facing product the producers of such a product are rarely prepared or even know how to develop effective user interfaces for that product. Alan Cooper in his acclaimed work The Inmates Are Running the Asylum (2004) states The newness of the computer software industry is well known, but our very youth conspires to make us a very nonintrospective industry. We are too busy assimilating new technologies to reflect on the misconceptions surrounding the older ones. Consequently, the software industry resounds with myths and misunderstandings that go quite unquestioned., this was the case then and it still is with modern tech today. 1.2 The State of Mobile Through the past 30 years there has been a movement in mobile from a set of discreet, single-purpose devices to mobile platforms. Mobile strategist and co-Founder of CloudFour.com, Jason Grigsby, was quoted saying "Mobile is the most Borg-like

technology ever; it vacuums up adjacent consumer electronics categories" (Grigsby, 2010), this is very much the case. These discreet devices include MP3 players, gaming devices, eReaders, GPS devices, digital cameras, and cell phones, all of which now exist inside of modern smartphone operating systems. The power that comes with having platforms on mobile devices is similar to that of the advent of PC and web platforms: everything starts being built on top of them. Much like the revolutionary personal computer and web platforms, the mobile platforms come with a variety of design issues. Mobile platforms as we know them today have only been around for the past 5 years, and design for these platforms is still very new to many companies just entering the mobile space. Modern smartphones, with the advent of the iPhone in 2007, the first devices shipping with Android in 2008, Palms (and now HPs) webOS platform in 2009, and the final shipment of Windows Phone 7 in 2010 all represent significant efforts to thrust substantial and long-lasting mobile platforms into the future. The trouble with mobile applications, similar to the trouble with the advent of personal computers before them, is that the way that people interact with mobile devices is very different that the ways in which they interact with prior technologies. Mobile devices are much more personal and integrated into their users lives, with only short quanta of interaction time, limited screen real estate, and often limited connectivity. They are truly dynamic devices following their users humbly wherever they go. A lot of third party app developers enjoy throwing out the rule book and designing for flair, but there are precautions that should be taken in doing this. Regardless of how a mobile designer wants mobile software to look, they need to stick to the paradigms provided in order for a user new to a program to understand it. First impressions mean everything in the mobile space, and people are exceedingly shallow. There is a world of competitive apps out there for users to choose from, and the discovery, installation, trial, and removal process has been boiled down to mere minutes. This causes effective user interaction design to become of vital importance for users of mobile devices, much more so than a large feature set. If the friction a user endures in an app is high, it can be dumped and replaced at will. Because of this, actions must be taken within the new mobile space in order to effectively design mobile software so that it is not only useful but also immersive and pleasurable to use. Because of the unique and personal nature of mobile computing combined with its on-the-go utility, it is crucial to to reflect on the misconceptions and myths and misunderstandings that go quite unquestioned that Cooper describes in design for mobile software and to make some declarations about smart design in the space.

1.3 The Mobile Reader One of the greatest advantages provided by the modern smartphone and tablet, as well as the eBook reader before it is the ability to enable leisurely reading of user-tailored content. Reading is increasingly becoming interactive and less read-only. Mobile reading software is putting on-demand, personalized content in the hands of readers and changing how, when, and where people consume that content. The days of waking up and reading the newspaper at the breakfast table are rapidly changing, and mobile readers enable users to have much more selection in the content they desire in their news. Social networks like Digg, StumbleUpon, and Reddit are perpetuating this as a norm, and many other social networks like Twitter and Facebook can act as content-sharing networks between friends. Revolutionary news readers like Pulse Mobile and FlipBoard represent the bleeding-edge of mobile-optimized content layout for such networks.

Figure 1: Flipboard for iPad, a new mobile reader breeding the advantages of print and the web together

One of these online reading services, Read It Later, recently published a post titled Is Mobile Affecting When We Read? (2011) outlining the difference between reading on a mobile device and on a computer, the evidence shows that theres a massive shift from reading when content is available to reading when its convenient for a user. They claim that a majority of this reading is done in ...whitespace time. Whitespace is the time between A and B. Its the time on the subway or bus. Its the time standing in line. Its a spare moment..

Figure 2: A comparison between the peak reading times for conventional internet users (left) and for consumption on the iPhone (right). Source: Is Mobile Affecting When We Read?, 2011

This radical shift in the way people are consuming content is responsible for a demand in changing the way that content is presented. A recent study of 500 college students, prolific users of new-media readers, turned up overwhelming demand for mobile-specific features in the software they were using to consume news. Demand for location-based services, mobile-specific content layout for ease-of-reading, and syncing of bookmarks across a regiment of devices were all notable mentions. The close of the study describes the perceived issue with modern mobile news The history of the Internet and news media reveals that most publishers and broadcasters neglected to treat the Web as a new and unique medium early on. (Kiesow, 2010). These issues were not present in classical mediums, but changing technology demands a change in the user experience for that technology. Read It Later reiterates this in the closing of their study: As better mobile experiences become more accessible to more readers, this movement will continue to grow. Readers want to consume content in a comfortable place, on their own time and mobile devices are making it possible for readers to take control once more. (Is Mobile Affecting When We Read?, 2011). Because there has been such a large motion towards reading on mobile devices much of the research in this thesis will focus on how to improve mobile reading. A lot of modern mobile readers, just as any other apps out there, contain design flaws. Things like content caching for loss of connectivity and quick response, static controls obscuring the desired content, and prolific use of web views when a better content layout would better suit the form factor are just a few of these. There will additionally be an implementation of a mobile reader highlighting how these manifested design choices do improve the consumer reading process. 2. Intelligent Design for Mobile 2.1 Controls

Controls are everywhere in user interfaces, theyre the standard way that a user interacts with their software. Such controls include software controls provided by an apps parent OS, and the hardware controls provided by the hardware manufacturer. While some of these controls arent all that different than their prior desktop and web counterparts, a different perspective should be taken about their use in mobile. One of the Three Golden Rules for interface development is make the user interface consistent, with the benefit ...that users can transfer their knowledge and learning to a new program if it is consistent with other programs they already use. (Mandel, 1997). Utilizing common software and hardware controls that a user is already familiar with is the best way to achieve this golden rule. 2.1.1 System Software Controls The developers of mobile operating systems and the manufacturers of mobile hardware very seriously invest in the controls and control paradigms that they deploy in their end product. From the behaviour of scrolling lists and table down to the simplest shading or distance between controls, everything has been thought-out by a devices creator to make the user experience elegant and seamless. That being said, those who create mobile operating systems and hardware desire to push-on their design patterns to third-party developers in hopes of further making a user comfortable. Microsoft states in its design guidelines that it ...highly recommends that Windows Phone 7 developers adopt the Metro design style for their applications. ... Although requirements and implementations will vary from application to application, utilizing Metro styled elements will create a more consistent and fluid overall UI experience for users. (UI Design and Interaction Guide for Windows Phone 7, 2010). Apple similarly states Consistency in the interface allows people to transfer their knowledge and skills from one application to another. A consistent application is not a slavish copy of other applications. Rather, it is an application that takes advantage of the standards and paradigms people are comfortable with. in its iOS Human Interface Guidelines. Some examples of these standard software controls that users are constantly exposed to are the iPhone navigation bar and the Windows Phone 7 app bar. The iPhone navigation bar, in any navigation-based application such as iPod, Settings, or Photos, sits at the top of the screen. There is commonly a left-justified back button, a title, and an optional right-justified action button. These three buttons are common for any navigation interface in the iOS, empowering a user to direct their flow wherever they are in an app. The Windows Phone 7 app bar, similar to a toolbar, runs along the bottom of the screen. It can contain up to 4 commonly-used actions listed as icons as well as an ellipsis for more actions. When this ellipsis is tapped it reveals less-commonly used actions in full
6 6

text to resolve any user confusion. This bar looks the same everywhere in the OS and should be instantly recognizable and useful to Windows Phone 7 users.

Figure 3: The iOS Navigation Bar (left), Windows Phone 7 App Bar closed (center), and open (right). Source: http://www.anandtech.com/Show/Index/3982? cPage=5&all=False&sort=0&page=3&slug=windows-phone-7-review

An example of poor use of software controls is Microsofts Bing app for the iPhone. Bing for iPhone exists on a platform foreign to Microsoft, and while the app is quite functional, its designers made some fundamental mistakes in engineering the controls for the user interface. The back controls in the app are consistently placed on the bottom left-hand corner of the screen, not in the top left-hand corner as iOS users have come to expect from a native app. To make this even worse, upon entering an certain views, the actions of the back button become quite ambiguous. For example, when viewing an image and then zooming in repeatedly, the back button stops acting as a return to search results button and starts acting as a zoom out button. It is impossible to visually determine how far zoomed in an image is, so a user attempting to zoom out or return to the prior screen has no clear way to back out to the exact degree they require. Similarly when viewing a web page, the back button goes back through a visited web history and only returns to the query results when exhausting that history.

Figure 4: Ambiguous controls in Bing for the iPhone. In image viewing (left) pressing back could zoom out or return to the previous menu, in web page viewing (right) pressing back could return to the previous page or to the list of query results. Back button is in the bottom right as in the browser, not in the top left as with native iPhone Apps.

This design choice might have been made on the classic misconception that less is more, however in the case of other popular iOS apps, having nested, contextual back controls is quite acceptable and understandable to users. The Twitter for iPhone app has two distinguishable back controls upon viewing a web page, and it is instantly apparent which control is responsible for which action because the two different buttons resemble the ones used everywhere else in the iOS.

Figure 5: Twitter for iPhone effectively shows how two different back buttons can be distinguishable and useful for users by playing off of the controls in the rest of the OS

Alan Cooper describes the term cognitive friction as ...the resistance encountered by a human intellect when it engages with a complex system of rules that change as the problem changes. (Cooper, 2004). One solution to reducing cognitive friction in mobile software, as with other software, is to stick with the controls that users are familiar with. This doesnt mean that all mobile software should look identical and tasteless, or that the developers of smartphone platforms mandate that all software strictly conform to their ideals, but simply that controls should act the way users expect. The following two examples demonstrate this idea. The iPhone app Calvetica by Mysterious Trousers, LLC puts a very different face on mobile calendar software. The app itself is very stylistically different from the norms of the iOS, with straight black on white and copious, frivolous animations. The app is very modern looking and minimalistic, the look really draws users and the app has received great reviews. Although the app looks nothing like the gamut of apps for the iPhone, the one thing that it does preserve from the iOS design guidelines is the placement, look, and actions of controls. The standard navigation bar including title and pointed back button along the top is still ever-present, the standard toolbar is included along the bottom for frequently-used actions, and the tables look and act as they do for other apps. Simply stated, regardless of the edgy look of the app, it still acts exactly as users expect from other apps. FlipBoard for iPad similarly puts an edgy, print-like look on social media with lots of special animations, however its homescreen acts like that of the iPad homescreen and the page flip actions it has are similar to that of iBooks.

Figure 6: Pictures of Calvetica for the iPhone (left) and FlipBoard for the iPad (right) illustrating that even with an unconventional look, controls can still be intuitive

2.1.2 System Hardware Controls With the advent of mobile platforms rather than simple feature phones the creators of phone operating systems have much more of a say in how the hardware for a device should be designed than in the past. Much like desktop computers, there are competing paradigms about how exactly this should be done. Some OS developers manufacture their own hardware, and others release their software for dedicated hardware manufacturers to use. Apple with the iOS, RIMM with the BlackBerry OS, and HP Palm with webOS are all examples of the first paradigm -- they are the sole producers of their own hardware and they strictly enforce their design guidelines throughout both hardware and software. This allows them to produce a consistent experience as they see fit for all users out there. Microsofts Windows Phone 7 and Google Android, on the other hand, only produce OSes and allow other manufacturers to utilize them. Windows Phone 7 has a strict set of design regulations for its hardware (UI Design and Interaction Guide for Windows Phone 7, 2010), enforcing consistency for both developers and end-users of the platform regardless of hardware choice, but Android does not.

Figure 7: Hardware controls on various mobile devices. From left to right: The Nexus S running Android, The iPhone 4 running iOS 4.0, the HTC HD7 running Windows Phone 7, and the Palm Pre Plus running webOS.

The hardware controls on a particular device or platform, just as with the software controls, should be treated with great importance in the design of user-friendly software. Hardware and software should act in symphony when done correctly, presenting an intuitive experience. Dedicated hardware is there to promote common user actions with common expectations for results, and the software controls allow for more dynamic interactions. Examples of poor use of hardware can be found in the SoundCloud and Square client apps for Android. Pressing the hardware search button in SoundCloud has no effect, whereas almost everywhere else in Googles search-centric OS pressing the search will always open a query field. Each and every screen in Square for Android has a software back button in the top left-hand corner la iOS, but this is unnecessary and redundant on Android devices because of the hardware back button.

10

10

Figure 8: Square for Android (left) running with redundant software and hardware back buttons, and SoundCloud for Android (right) which treats the hardware search button as a no-op and instead forces a user to press the software search button.

Another example of a bad harmony between the prior mentioned software controls and hardware controls is the reply button in Twitter for Android. The reply software button appears directly above the back hardware button in some devices, and although the two controls have vastly different purposes, they look identical.

Figure 9: The hardware back button on the Google Nexus One running Twitter for Android with the common reply button. These two buttons, one software and one hardware, look almost identical however their actions are very different.

The hardware controls built into devices should be treated with extreme caution. Having a back button not go back, a menu button not pop up a menu, or a gesture not act as it normally does is instantly going to up the cognitive friction a user experiences when using software. One user interface design blog aptly states ...[there] should be no Back

11

or Close buttons at all within the user interface. Again, we give you a back button for free. So use that extra space to keep your app clean and simple. (Astort, January 17, 2011). Where software controls have some leeway in use, hardware controls are the only things that are truly set in stone, and having them act out-of-the-ordinary should be avoided. 2.1.3 Dynamic Controls A lot of apps written for mobile devices statically show a status bar and two toolbars presenting users with all the functionality necessary to make the app useful. These toolbars are of great use, but their lies a problem in that infrequently used controls can block out what a user is trying to focus on, in the case of readers, text. The standard height of these toolbars in the iOS is 44 pixels, the standard height of the status bar is 20 pixels, and the total screen height is 480 pixels in portrait or 320 pixels in landscape. This means that 22.5% of the onscreen content is obscured in portrait and 33.75% of the content is obscured in landscape 100% of the time.

Figure 10: Illustration of the degree to which toolbars and status bars obscure and distract users away from content

Wasting a fifth or a third of the space on every sheet of paper in a book would be an unacceptable waste, but because it costs nothing extra to use this space up on a digital screen the appeal of saving it isnt readily apparent to the casual developer. Alan Cooper sides with many users on this fact in stating that ...it really gets tiresome to find my way so often obscured by interaction artifacts... (2004). Fortunately, there has been a solution invented for this: dynamic controls. The iBooks app for the iOS is a perfect example of this, all the controls are translucent and fade away completely after a few seconds. If a user ever wants the controls to return, they do whats logical, tap once and they all show again. The app is still functional and it
12

12

doesnt get in the the way of whats important to the user, the reason he or she is there in the app, the content, in this case text and images. Android hides controls a user wont necessarily use under the standard hardware menu button, relieving clutter from the user interface. webOS, similarly to the iOS, has controls that roll off of the top of the bottom of the screen and return on a single tap.

Figure 11: iBooks for the iPhone (left) illustrating dynamically hiding controls, Tweetdeck for Android (center), and Photos on webOS (right) illustrating dynamically hiding controls

A popular recent example of dynamic controls that has taken the mobile world by storm is pull-to-refresh. This control originated with an iOS app named Tweetie, now Twitter for iPhone, written by a man named Loren Brichter. The genius behind this control is that it is completely hidden from the user unless absolutely needed, but the way the action behind it is performed is totally intuitive. Brichter said in an interview about Tweetie 2 that Tweetie 2 simply took this idea from Tweetie 1, that reloading was simply loading newer, and loading newer put new messages at the top of the list and activated the action based on a finger motion that you were already doing. Why make the user stop scrolling, lift their finger, then tap a button? Why not have them continue the gesture that they are already in the process of making? When I want to see newer stuff, I scroll up. So I made scrolling itself the gesture. (Kaufman, 2009). Previous attempts at hiding refresh controls included adding refresh controls at the top and bottom of lists, adding shake-to-refresh, and having purely static refresh buttons present on a user interface. Placing the the control just out of sight and having it
13

manipulated by an action users naturally perform when trying to reach it is truly a brilliant design in dynamic mobile controls. This concept has been adopted by a huge amount of Apps, include Pulse news reader, Facebook, and Foursquare for the iOS as well as Twitter for Android. Intelligently hiding and showing controls when reasonable while allowing a user to focus on the task at hand should be taken into consideration when developing for mobile. Alan Cooper sums up this matter stating When an interaction designer has done a particularly good job, the designer will be quite unaware of the designers presence. ...no matter how cool your interface is, less of it would be better. (2004). The goal of developing mobile software should be to create controls so natural that they sort of melt into their environment. 2.2 Web Views A majority of modern mobile platforms provide to developers what are called web views. Web views provide a windowed space in which web pages will be displayed, and they act just as the browser on the device would act with content from the internet. These views are of great use and allow for an app to display online content without rough application switching or reinventing the HTML-parsing and rendering wheel. There are some pitfalls associated with web view use though, their use should be auxiliary to an app and not the substance of the app itself. 2.2.1 Web View Layout Issues Web views are meant to be used to add a small slice of web content to mobile software. Theyre often used for the secure OAuth authorization or for displaying content linked to by users in social networks. The feel of a web view is similar to that of a mobile browser, pinch-to-zoom manipulation, latency, and layouts abnormal for mobile are all commonplace with dealing with web views, but these are not commonplace in dealing with native applications to a device. Native apps should be built to take advantage of every nook and cranny of their parent operating system, and simply utilizing a web view cannot do streamlined content justice. Because mobile web browsers are responsible for rendering and usefullydisplaying desktop-class content, the designers of web views designed some common gestures allowing users to still see this content rendered to true form, these gestures include zooming and panning. Many web pages take on a so-called F-shaped format, and its been shown that doing so increases a users ability to rapidly comprehend the body of a page (Nielsen, 2006).
14

14

Figure 12: Pictures demonstrating the common F-shaped layout of web pages (left), the difference in display ratios for mobile and desktops (center), and a typical desktop web page viewed on such a device (right). Source: Nielsen, 2006.

This F-shaped format is great for a landscape 4:3, 16:9, or 16:10 display, but on a mobile device with a commonly portrait 2:3 or 3:5 screen, the prolific usage of the F-pattern requires a tremendous amount of manual panning from left to right in order to view all of the content available. A Windows Phone 7 design blog states that Conventional web pages are rarely optimized to be viewed on phones. , Thats why pinch and zoom is enabled when we browse those web on phones. The ability to enlarge web content is a behavior we expect when we use a mobile browser, however when we interact with a mobile app that expectation is no longer true. So, take caution when embedding web content in your application. (Astort, January 13, 2011) This adds significant discontinuities to the reading process of a user and requires a lot of work where none would be required if the care to lay out content were taken. Instead taking the care to resize content so that it dynamically fits a given devices screen width and intelligently adjusts to different orientations presents easily readable content and takes the burden of panning off of the user. Another issue with web views is the way in which they render. Typically when rendering a webpage, first the HTML body complete with text and formatting is loaded and displayed to the user, then each of the image and video resources are loaded one-byone and snapped into the web view as they complete individually. If a user begins reading content in a web view that isnt 100% complete and all of a sudden an in-line image resource is completed, all of the text content is shifted downward causing a user to lose

15

his or her place. This is common in a lot of reader apps that depend solely on web views for content display, to name a few Engadget, Pulse, Flud, and The New York Times.

Figure 13: Example of images snapping in to web views (left), example of poor web view content layout as a result of lost connectivity (center), example of poor web view content layout (right).

A potential solution to this is to not present content until it is completely downloaded. David Gruber on The Daily, a new iPad magazing, said about this The point of native apps is to provide a better experience than websites can offer. Watching a splash screen rotate a Loading spinner for 80 seconds isnt it. (Gruber, 2011). Another, better solution would be to display the textual content of a web page immediately as its downloaded but pre-allocate spaces for images in the content and simply fill them in as the assets load, this way the user can read their content as its available but not deal with visible snappy image loading. Web views, even when loaded with correctly formatted text, may not be capable of loading in artwork at a resolution suitable for mobile devices. With the introduction of the iPhone 4 and the pixel-doubled Retina Display, Apple made low-resolution artwork on its platform stick out like a sore thumb. Because they provide the tools to develop for their platform, there is a straightforward way to change an app to load in artwork of a proper resolution at run time. Web views, however, still load in the same resolution artwork because theyre not based on a technology that may change resolution. A pixel in a web page is the same on a desktop and a mobile device, and so the artwork using the Retina Display is pixel-doubled up to a size where its visible to users. Android took a similar turn with their platform adjusting from 320 x 480 to 480 x 800 (WVGA), both changing pixel density and the ratio of width-to-height. Section 2.1.1 discussed how its beneficial to stick with the software controls provided by a platform. A lot of web based application attempt to mimic the software controls provided by an OS, this usually ends with a mish-mash of web controls that act abnormally masked as standard controls. Just as with native, web apps should stay true to
16 16

their platform, standard web controls should be used with the actions one would expect in a web page. Imitation controls will confuse users when they dont act as they should. The Netflix for iPhone app is written completely in HTML5 and Javascript, but it is available through the native App Store. Scrolling, something that should be a very fluid action and something that the iOS pulls off very well, is very not well suited to the web. It requires precise calculations and mimicry of the physics associated with scrolling in the real world, and the scrolling that Netflix employs in its app feels very strange compared with that of the rest of the OS. There are additionally pixel-doubled buttons that show up because of the inability for web views to scale their images like native apps do. Problems like these make a native app feel cheaper. 2.2.2 Web View Speed Issues Because web views present content being rendered by a HTML-rendering engine and not a devices native view hierarchy system, there is a lower bound placed on the speed at which web content can be loaded when compared to native apps. This bound is introduced because the code of each and every page that appears must be downloaded, parsed, and interpreted. With a native, compiled app these bounds dont exist because the layout information is locally and readily available, usually on disk or in the memory, and the layout engine is as fast as possible because it utilized the rendering system of the OS itself. Studies were performed by Microsoft and Google on the importance of such latency to users, and the results showed that there were significant penalties for slow pages. The results of Microsofts study turned up that Progressive rendering can have huge performance and user satisfaction gains. (Forrest, 2009). A social networking app, for example, has to load the details of a particular user when presenting their page, but the fields and blank spaces could progressively rendered while downloads are occurring. On a web page the whole page has to be loaded in, so there is latency in even loading these blank spaces and a decrease in the apparent responsiveness of the app. Operating system-managed web views are limited in caching capability. When web views in the iOS are unloaded the whole of their content vanishes as well, the only aspect of the web views session that can be saved is the last URL visited. This means that when a user restarts an App theyll have to wait for the whole page to download again. This can get very frustrating in readers where the content offset is lost and the text, images, and other attributes of the page could easily be stored in a database and recalled immediately upon app launch without the need for internet connectivity. This further cramps usability when connectivity is lost. If a user attempt to load a web page without connectivity the result will be an error and a blank page. The ability to cache the content

17

of the page is crucial for reading no matter what a users conditions are, and web views cannot answer the call here. Caching of content is discussed more in section 2.3. 2.2.3 Web Apps The flip-side of this coin, of course, is that web apps can be written once and deployed everywhere. This is a valid argument and has saved tremendous time in the development of cross-platform products. If a developer plans to make a web app, the whole app should reside within the browser, and if they decide to make a native app almost everything in that app should be native to the device. Blurring of the line between these two often leads to an inconsistent user interface. A good example of the blurring of this line is in the native Kindle apps for the iOS, Android, and Windows Phone 7. Kindle has been hailed as one of the top eReaders out there with clients for nearly every popular platform, however there is a rift in the buying experience for these native clients. Each of these clients has a great, native reading experience, but the moment a users want to search for new content or make a purchase theyre forced into the browser and a mobileoptimized website. The user login information is lost in the process, so the login process must be repeated and then after buying online the user must manually redirect themselves back to the native app and refresh their content. If the process were made all native or all web-based then this redirection and redundancy in use could be avoided.

Figure 14: The fractured Kindle for iPhone experience, where the reader implementation is native (left) and the store implementation is in the browser (right). The user is responsible for all switching and redundant login.

For the sake of consistency, if an app is native it should be as native as possible, and if an app is a web app it should be as online as possible. All of the switching between the two causes latency, discontinuities is experience, and reason for an app to appear clunky. Cutting corners on behalf of the develop is not beneficial to the consumer.
18

18

2.3 Caching Caching in the simplest form means storing things locally so they dont need to be fetched repeatedly and are accessible faster. Modern mobile devices have very limited resources when it comes to disk space, memory, and connectivity, and often resources must be unloaded in order to maintain a balance in the tasks a device is running. One of the goals a mobile developer should have is to make this constant loading, reloading, and unloading of assets completely invisible to the user and make their app seem like it has limitless resources. A way of doing this is caching everything about an app, both the content and the various states within it, so that costly memory warnings or downloads can be avoided at all costs. Without caching, an app will perform repeated and redundant work consuming more resources than necessary, when the original point of unloading was to save resources in the first place. 2.3.1 State Saving One of Theo Mandels three golden rules for user interface design is to Reduce users memory load (Mandel, 1997). A critical part of reducing the users memory load is being able to have a consistent state between sessions of app use. Apps are used in sporadic and short sessions, and if a user had to re-enter their credentials or re-navigate to a particular piece of the interface that they frequent this rule is violated and the users time is wasted. Because of this there is the need for state-saving within an app, specifically saving state between closing and launching so that a user doesn't lost his or her place much like bookmarking a book in-between reading sessions. Because of the limitations of modern mobile hardware, the app life cycle is very volatile. While theres been a movement from having mobile devices be unable to multitask to devices which are able to fully multitask over the past 5 years, the memory and processing capability of mobile devices often limits the number of processes that can be going on concurrently. As a result of this, there exists a queue of apps running in the background, and in the event of low-memory conditions the ... the system purges applications that have not been used recently (Apple Inc., 2010). Before multiasking devices and operating systems were common place, the programmatic saving of state of a users actions was required, but because apps can still be arbitrarily terminated this need is still very present because it can never be determined when an app will stop. Every mobile operating system has a so-called execution model or life cycle, and these each dictate how app are responsible for responding to incoming calls, notifications, being quit by a user, or being terminated by the OS. It is the responsibility of the developer to ensure that the user experience of an App, no matter what has

19

occurred since the time it was last quit, springs back to life quickly right where a user left it. The MSDN Library for Windows Phone 7 development says ...the application is responsible for restoring the state of the user interface on the page so that it appears the same as it did when the user navigated away, giving the user a seamless experience as if the application had remained running. (Microsoft Developer Network, 2011). A good methodology of storing a users state is to have each screen visible to a user pair with a small bit of information about the state of that view. Upon termination, an is given a few seconds by the OS to perform cleanup, and it is during this short period of time that the tokens from each of the open views should be saved. Upon app launch these tokens can be reinstalled into the views that were in place before app closure. Below is an illustration of a generalized app life cycle in tandem with these actions.

Figure 15: Generalized app life cycle on mobile devices, illustrating the measures to be taken to save state.

While the iOS provides no stock provisions for performing this resurrection, both Android (Google Inc., 2010) and Windows Phone 7 (Microsoft Developer Network, 2011) do. There are additionally a number of third-party options available for adding this into an application, such as the Facebook Three20 project (Hewitt, 2009). Apps that do this well may not even need to run in the background, freeing up resources for others to share. 2.3.2 Caching of Content Resiliency and quick launch are essential to mobile devices because of the quickuse behavior mentioned before. The iOS Application Programming Guide says about this that The strength of iOS-based devices is their immediacy. A typical user pulls an iPhone or iPad out of a pocket or bag, uses it for a few seconds or minutes, and then puts it away. (Apple Inc., 2010). A key component to this is for content to be internally organized such that it is quickly accessible for on-demand applications without the redundancy of re-fetching from the web. A recent ACM paper on mobile caching states
20

20

that To relax the network requirements imposed by multimedia traffic, caching has been deployed as a solution. Essentially it brings the content closer to the user so that the strict requirements presented above, are imposed to small parts of the network only (near-user premises). (Edwards & Kara, 2003). Images and textual content are primarily what reading material is comprised of, and both can be stored once downloaded to permit quick and offline access. Caching of these assets can be done much in a similar fashion to caching of any other data. SQLite databases are available on a majority of platforms as a low-level cache and there is always volatile space that can be used in a devices memory for storage of small elements of data. Performing fetch requests on a SQLite database has a significant performance penalty over fetching from RAM, but a SQLite database can store much, much more content over time.

Figure 16: Various cache levels that can be employed in the caching of content for apps.

This follows from the idea that in order to minimize latency in an application, highlatency operations should be performed as infrequently as possible (ideally once), and low-latency operation should be performed as often as possible when trying to access an asset. Care should be taken to perform downloads and caching concurrently with user interactions and to push it into the background as much as possible in order to avoid poor responsiveness. Recently, an iPad-only magazine named The Daily was release, and it has been slandered for taking an enormous amount of a users time to download daily content: Im not saying The Daily needs to magically make an entire new issue download to an iPad in 10 seconds or less. Im saying they need to engineer the app so that it can start showing something interesting in 10 seconds or less and then keep downloading the rest of the issue, piece by piece, in the background (Gruber, 2011). 2.3.3 Over-Caching Just as leaks in executing code can be costly can put stresses on the memory of a mobile app, over-caching of content can cause serious long-term problems for the long term memory on a mobile device. Over-caching, or the retention of assets unnecessarily, can cause these problems in one of two ways:
21

1. Fetching assets that ordinarily take little time will grow to be a very slow task, noticeable to users 2. The size of the cache will grow large enough to put pressure on the storage of a device, catching the users attention Each of these statements mention the user becoming aware of your cache. In the event of either of these something that is meant to be only internally visible and for the benefit of the user will become externally noticeable and a burden to the user. This should be avoided at all costs because the user should be unable to manipulate or manage the internal cache of an app, and asking a user to uninstall and reinstall is unacceptable. A good means of avoiding over-caching of content it to have periodic, redundant cache audits or dumps in an app. Such audits could take a moment to inspect each asset cached to determine whether or not it is still of use to the app, and if not, jettison this asset. Dumps are a bit simpler, simply removing all assets periodically. Providing relationships between different assets could be valuable in auditing as well because the relationships could trace routes of objects to dump. For example, if a news article had several images attached to it, when the article was dumped the images could all be mapped to and dumped as well, removing the work of performing an audit over all images. 2.3.4 Gracefully Handling Lost Connectivity Content caches are helpful in making an app quick and efficient, but where they really become helpful is in the event that connectivity is lost altogether. This is because The user ideally should be affected as least as possible by the network changes, delays or any short term disconnection. The amount of time required for the handover to complete, depends on a number of factors such as the network congestion, the clients ability to respond to the change, (Edwards & Kara, 2003). In the event that an a device loses connectivity, some apps will crash or fail to present any content at all. A good backup plan to have it to store at least some content that should be readable or useful while offline, for mobile news readers this could include content such as recent or bookmarked content. 2.4 Content Layout The way that content can be laid out from mobile app to mobile app can vary wildly with the type of content and the content provider, but there are some basic
22

22

concepts in place that mobile OS developers have put in place to ease such content layout. In order to provide a good window into content, in order to remove the need to use web views as a backbone to mobile reading, and in order to remove the obstruction of controls, the way in which content is laid out needs to be considered. 2.4.1 Displaying Large Content Content is not necessarily designed for the medium on which it will be presented, normally when an author is writing he or she is not thinking Will this be below the page break? what screen ratio am I writing for. The loose coupling between content and the medium in which that content is presented opens a rift of methodologies for presenting content that is larger than the screen. It is important to lay out this content as the writer, the device manufacturer, and most importantly the user desire. In a recent New York Times interview with the developer of a prominent Wikipedia app, he explained, A small window into a huge space is horrible, he said. It makes for a great demo, but its very frustrating to use. (Markoff, 2008).The conventional means of presenting such content is with scrolling, scrolling has been around since computers began as the logical means of presenting content larger than the viewing space. Scrolling is a simple and logical action that is known to many users across the web and mobile devices, but scrolling doesnt necessarily do justice to the content itself and still places the user partially in change of their viewing experience. There is a recent development in mobile technology that creates pagination, or emulated pages in content on a page. This simulates the printed media unlike scrolling on the web. Mike McCue, the CEO of FlipBoard which is a product aiming to wed print and social media into a beautiful user experience, in recent interview expressed his thoughts on scrolling and pagination: What pagination does is it allows for designers to build beautiful content because they know what the dimensions of that content are going to be. You know, if you were a publisher that really valued the photographs in your publication you would never want half of your photo visible to your user at any one time. (Boehret, 2010). Pagination allows for beautiful and pixel-perfect content layout. Keeping this in mind, scrolling is a very important means of navigation. Its very hard to shoe-horn arbitrary web content into a paginated view like FlipBoard does, and scrolling permits a users ability to scan, which a lot them are prone to do (Nielsen, 1997). Paging can even be restrictive on content that users will want to scan for information. Alan Cooper commented on a desktop program that used paging as a form of navigation that content was ...funneled through the pop-ups in numerical order, allowed only a few sentences at a time. It was a hideous paradox: the computer was actually more restrictive
23

than the book. (2004). The proper way to attack the issue of whether to page or not to page is to look at the content being displayed. If the content takes the natural form of having breaks or is very long and requires milestones for a reader, paging is the optimal method to use. If the content is primarily textual, not logically breakable into pages, and meant to be skimmed, browsing with a scrolling pane is preferable. Designing content for a particular paradigm works for content producers here, but if the developer is not producing his or her content then it is important to be aware of the best way to present it for an elegant user interface. 2.4.2 Content and Control Layout Because of the narrow screens available on mobile devices, it is important to avoid the F-layout described earlier (Nielsen, 2006) to ease the reading and viewing experiences for users. One mobile devices there is the concept of laying out content linearly down a page to significantly increase a users ability to comprehend and use software quickly, because looking from left to right across a page requires similar action physically panning from left to right with touches. One design website of this stated that linear layouts ...require half as many visual fixations than left or right aligned labels. Top aligned labels also allow users to move down the form in one visual direction, instead of two visual directions with left and right aligned labels. (Anthony, 2010). Textual content is particularly well laid out in a single, linear column for reading on mobile, whereas on the web multiple columns with loads of navigation controls and titles are acceptable. Special consideration should also be taken in the volume of controls used in a mobile user interface because of the limited screen real estate. Having limited space to place controls on should not, however, hinder a users ability to use an app or require more work to get to an action, this goes against a users best wishes. Alan Cooper says on this that When I say less interface, I dont mean less functionality -- although that can sometimes be the case. I mean that the user doesnt have to interact with the program any more than is absolutely necessary to get any particular task accomplished. (2004). The trick is finding a balance in the right functionality and how prominently you display certain actions. An interview with an app developer in the New York Times recently weighed in on this stating The small screen forces you to be even more ruthless and focus on usability almost like a haiku, said Barney Pell, Powersets founder and chief executive. Thats what happens with design for the small screen. You have to think about what the most important thing the user is doing is. (Markoff, 2008). any of the technologies in place to help alleviate the clutter of controls were discussed prior in the

24

24

section on controls. These include use of hardware controls, contextual menus, and dynamically hiding controls. 2.4.3 Differences in Form Factors Much more recently than the development of the major smart phone platforms is the development of tablets and tablet platforms. Tablets date back to the 90s running versions of Windows, but the recent resurgence of the tablet for factor was led by the charge of the iPad, a spinoff of the iPhone. Android is now coming to bat with its version 3.0 named Honeycomb, Palm recently announced that webOS 3.0 will be available for its first entry into the tablet market with the TouchPad (Hewlett Packard, 2011) and Microsoft is seriously re-provisioning Windows to be both touch-friendly and run smoothly on lighter hardware (Microsoft, 2011). The tablet market is growing almost as rapidly as the smart phone market just before it, and while some of the hardware such as ARM processors and multiple-touch input is common with smart phones there are differences in the ways that the UI should be architected. Columns of content can be treated differently on the tablet for factor. Whereas on the handheld devices, each screen is treated as a sort of column, cascading from one to another, the screen real estate on tablets allows for mutliple such UIs to be shown at once. A common example of this can be found in the email clients for the iPad, TouchPad.

Figure 17: Multiple columns of content can be manipulated by a user at once in the tablet form factor, illustrated in the mail clients for the iPad (left) and HP TouchPad (right). Sources: http://www.tipb.com/ images/stories/2010/09/ios_42_ipad_mail_unified_inbox.png, http://common6.ziffdavisinternet.com/ util_get_image/24/0,1425,i=248272&sz=1,00.jpg

These designs clearly show multiple parent and child columns going from left to right, where on a smaller device each of these columns would be an interface in itself.

25

Another difference between form factors lies in the way that controls can be laid out. The tablet form factor is large enough to provide a user with many more controls than just a navigation bar and a title bar, however this space should not be abused to dump more functionality than is necessary on a user. Autorotation, or the ability for an app to dynamically rotate its user interface, is present in the whole gamut of mobile devices today. Because mobile smartphones and PDAs are predominantly handheld a lot of mobile developers stick to the basic, portrait orientation on that form factor. Tablets are designed completely differently, and are meant to be held in whatever orientation is most useful and comfortable to a user. Because of this, it is necessary to support multiple interface orientations in the tablet form factor, and to not hinder or change the functionality a users sees in different orientations. 3. Demonstration: NGadget

As the creative project aspect of this thesis, an implementation embodying many of the qualities describing good mobile and mobile reader design was developed. This app is a reader for the popular tech blog Engadget that Ive named NGadget, and it aims to smooth out many of the rough user interface experiences that can be encountered in the numerous other apps one can use to read Engadget. 3.1 Controls One thing that is immediately noticeable to the user is the fresh, minimalistic, and modern look of NGadget. Controls are all black, white, and gray, with many square edges. This look was inspired by the Windows Phone 7 Metro UI, FlipBoard for iPad, and Calvetica for the iPhone. These controls do not have to look or feel of other native iOS applications, however the important steps that have been taken are in how the controls act and are placed using cues from the rest of the operating system.

26

26

Figure 18: The NGadget back button compared with a system back button (left), action sheet (center), and action button compared with a system action button (right). All have styling unlike the iOS but all resemble and act exactly as they should

Despite not having a visible status bar, tapping in the status bar area has the action that is consistently used throughout the rest of the iOS: it scrolls the current view to the top. The top bar acts just as in any other iOS App, with a left-aligned, pointed back button to the left that always returns a user to the previous screen. There are so-called action sheets used within the app that dont have the look of standard iOS apps, but they act in exactly the same way, sliding up to present options and sliding away when finished. The action button, even though it fits the theme of the app, still resembles the standard action button of the iOS. NGadget is constantly fighting the urge to have controls on the screen at all. The main headlines view shows only headlines, no status bar, no title bar, and no toolbars. The images associated with headlines arent obscured by their titles, but are layered one on top of the other allowing for a really beautiful browsing experience. The user, when viewing this screen, has only their headlines to focus on. Pull-to-refresh was implemented expressly so that refresh controls could be hidden in this view but would be immediately recognizable to users.

27

Figure 19: The NGadget headlines view (left), and pull to refresh implementation (right).

The photo and article viewers both act exactly the same as the iOSs photos and iBooks apps with dynamically hiding controls. These control hide themselves within 3 seconds of inactivity or if a user starts to manipulate content, and immediately show if the user taps the screen once. Pinch-to-zoom, double-tap to zoom, panning, swiping from one image in a gallery to another, and the dynamic controls all resemble the stock photo actions, event though the look may not. This allows a user to be instantly familiar with how these viewers will work, but keep the consistent NGadget look.

28

28

Figure 20: Dynamic controls shown (top left) and hidden (top right) in the NGadget photo/gallery viewer. Dynamic controls shown (bottom left) and hidden (bottom right) in the NGadget article viewer.

There are additionally unobtrusive gestures put in place to enhance functionality for power-users but can be ignored if a user is unaware of them. Two-finger swiping up or down scrolls all the way to the top or the bottom, swiping to the right always pop to the previous view, and swiping to the left from the headlines view shows a users bookmarks. These gestures are all invisible but they can enrich the experience for a user that discovers them and further remove the need to depend on buttons and other controls for navigation. 3.2 Web Views and Content Layout NGadget, similarly to its treatment of disruptive controls, avoids using web views as much as possible. The headlines, articles, images, and galleries in NGadget are all shown with very customized, form-factor specific views written exclusively for the app. This affords NGadget the opportunity to do some things that the web version of Engadget is unable to. Where the mobile Engadget site shows a few, low-resolution thumbnails and requires a user to follow a link to view a gallery, and doesnt present any way at all to view images in a high resolution, NGadget takes full advantage of the data at hand to present images in a delighful way. Tapping on an image shows it in full, desktop resolution in a viewer that is recognizable to users as discussed in the prior section. Galleries are displayed with in-line scroll views, allowing a user to browse the full contents of a gallery without waiting on a new web view to load up or even navigating

29

away from the article. This really serves the place the user in control rule of UI design that Mandel talks about.

Figure 21: Gallery viewers in the native Engadet app (left), mobile Engadget website (center), and NGadget (right). Only NGadget takes advantage of native capabilities and shows a full, in-line gallery viewer.

Use of this custom content view allows for caching of a users state within each article across sessions, something that is programatically impossible to set in the iPhones UIWebView. Full caching of the text body of the article becomes possible as well, although this is also doable with HTML pages. The way that the custom article viewer lays out content also relieves the problems associated with content loading in after a user has started reading by snapping down the text content to make room for the images. The content layout engine pre-allocates space for images, galleries, and videos to provide a consistently-sized viewing experience.

30

30

Figure 22: Loaded web view assets snapping down content once loaded (top), and NGadgets layout engine allocating space for assets up front to alleviate snapping (bottom).

In pursuit of showing a user the optimal experience for whichever link they decide to navigate to, NGadget has an engine that detects the content type of future links and decides in which view to present them. The three content viewers this applies to are web views, articles, and galleries, each of which have their own special layout and can all link from one to another. Any hyperlink tapped on in NGadget goes through this engine, whereas in the Engadget app a special article viewer is shown for the first page, but tapping any link outside of that launches a foreign web viewer.

31

Figure 23: The linking scheme between different content views in NGadget

So, if a user taps on a link in an article viewer that isnt an Engadget page, a webview is loaded. If a user is in a web view and taps on a link that can be laid out as an Engadget article, the custom article viewer is loaded. If a link is tapped that directs to a gallery, instead of showing a webpage with the gallery, the gallery viewer is loaded. It all kind of just works, linking into and out of the view that appropriate for the user, doing work for them to make the experience better rather than relying on web views as a backbone. NGadget is a universal iOS application, meaning that there is a single binary that runs on both the handheld and tablet form factor. The tablet form factor intelligently scales from the handheld one, not simply stretching the interface but repopulating it in a way that is useful but not daunting. The headlines screen, for example, shows a 3x4 grid of headlines rather than a blown-up 2x3 grid like the handheld version. Where the article viewer on the handheld version has dynamic controls that hide and show with user taps, the tablet form factor constantly shows a navigation bar along the top because the space of this bar is insignificant on a larger display. In a future release, there are additionally plans to implement a 2-columnar article viewer for the iPad version which would show images and galleries along the left column and text in the right column to more effectively use the space and break the handheld linear layout.

32

32

Figure 24: From left to right, the NGadget headlines view, the article viewer with static navigation bar, and the future, multi-column layout for the tablet version of NGadget.

3.3 Caching One of the goals in designing NGadget was to have minimize app launch time even in non-multitasking environments. The stock Engadget App, even when multitasking, displays a launch screen and loads for several seconds, and in the event its terminated in the background states are completely unsaved, dumping the burden of navigating back to the last visited article on the user. NGadget saves the a small kernel of the state of each view open on each app close, and instantiates the views all again on launch just as discussed in section 2.3.1. NGadget has a robust internal caching scheme that allows it to dynamically retain exactly the content desired by a user (i.e. recents, bookmarks, and galleries and images related to articles). Internally, there is a database present with three different entities, these are as follows:
The article entity stores the relevant metadata such as title, date, author, and

thumbnail, as well as the entire contents of an article. The image entity retains the image and URL corresponding to that image online The gallery entity retain the title of a gallery and the list of URLs corresponding to its images These three entities are related in such a way as to make purging of unnecessary content very easy. Every time an image, gallery, or article is visited, it is serialized and cached into one of these entities. Galleries and images, once loaded, are linked to the articles to which they belong so that in the event that an article must be purged its corresponding assets can also be removed.
33

Figure 25: Representation of the internal schema of the NGadget long-term cache

Every 6 hours on a refresh an audit is performed to remove old content. At every audit, every article is examined. If an article is deemed too old (beyond the 40 newest headlines), and it is not bookmarked by a user then it is removed. Upon removal, all linked images and galleries are also removed, freeing up disk space for future content. The 6-hour gap makes it so that this time-intensive process is not repeated frequently, disrupting the user, and so that recently visited content is still available for users to view. In addition to these long-term disk caches, there is a cache present in RAM for images for quick and easy access. This cache is highly volatile because images can begin to take up a significant amount of memory when loaded in succession, like in a gallery. The image cache in memory is dumped on app termination and on all memory warning, usually freeing many megabytes of memory. 4. Conclusion Developers should work tirelessly to make their user experience seamless, delightful, and easy-to-use, this means not taking shortcuts or forcing users to work any harder than they need to in order to get their job done. The idea of user friendliness has been around since desktop computing and long before, but adapting it to mobile provides new challenges in the limitations and uniquely personal position that they take. Its a sort of paradox that, while these mobile devices are supposed to suit and grow into their users lives filling every need, theyre far less powerful and consistent then their preceding counterparts. There are an enormous number of measures that developers can take to fulfill their end-users needs gracefully, however ensuring that system software and hardware controls are understandable and not overused, and that content is laid out in a linear and space-efficient way are methods of overcoming usability issues. Caching of

34

34

content and state as well as not relying on the web for major parts of user experiences significantly improve the ability to combat lost connectivity, latency, and device limitation issues. Each of these qualities is quite implementable, as shown in the creative project element of this thesis. Though some of these features are often implemented in existing mobile software, their sum is greater than the parts, and implementing all of these features makes for an app that users will truly appreciate.

35

References Anthony. (2010, September 1). Why Users Fill Out Forms Faster with Top Aligned Labels. UX Movement. Retrieved from http://uxmovement.com/forms/faster-withtop-aligned-labels

Apple Inc. (2011, January 3). iOS Human Interface Guidelines. Retrieved from http:// developer.apple.com/library/ios/#documentation/userexperience/conceptual/ mobilehig/RevisionHistory.html#//apple_ref/doc/uid/TP40006556-CH2-SW1

Apple Inc. (2010, November 15). The Application Runtime Environment: Fast Launch, Short Use. Retrieved from http://developer.apple.com/library/ios/#documentation/ iphone/conceptual/iphoneosprogrammingguide/RuntimeEnvironment/ RuntimeEnvironment.html

Astort, A. (2011, January 17). 7 of 10 - Place your buttons well Floating buttons, home buttons, and back buttons Oh my!. The Windows Phone Developer Blog. Retrieved from http://windowsteamblog.com/windows_phone/b/wpdev/archive/ 2011/01/17/7-of-10-place-your-buttons-well-floating-buttons-home-buttons-andback-buttons-oh-my.aspx

Astort, A. (2011, January 13). 6 of 10 - Embedding web content should be done with extreme caution. The Windows Phone Developer Blog. Retrieved from http://
36 36

windowsteamblog.com/windows_phone/b/wpdev/archive/2011/01/13/6-of-10embedding-web-content-should-be-done-with-extreme-caution.aspx? utm_source=twitterfeed&utm_medium=twitter

Boehret, K. (2010, December 21). Dive Into Mobile Video: Flipboard Chief Mike McCue. The Wall Street Journal. Retrieved from http://online.wsj.com/video/ dive-into-mobile-video-flipboard-chief-mike-mccue/ 69A0F362-6363-4BD7-9D9A-D5F43AEAB3E7.html?mod=WSJ_article_related

Cooper, A. (2004). The Inmates are Running the Asylum. Sams Publishing.

Edwards, C., H. Kara. (2003). A Caching Architecture for Content Delivery to Mobile Devices. Proceedings of the 29th EUROMICRO Conference. 2003.

Forrest, B. (2009, June 23). Bing and Google Agree: Slow Pages Lose Users. OReilly Radar. Retrieved from: http://radar.oreilly.com/2009/06/bing-and-google-agreeslow-pag.html

Google Inc. (2011, February 3). Application Fundamentals: Activity lifecycle. Android Developers. Retrieved from http://developer.android.com/guide/topics/ fundamentals.html#actlife

37

Grigsby, J. (2010, October 8). Twitter / Jason Grigsby. Retrieved from https://twitter.com/ #!/bgalbs/status/26775337425

Gruber, J. (2011, February 4). The Daily Wait. Daring Fireball. Retrieved from http:// daringfireball.net/2011/02/the_daily_wait

Hewitt, J. (2009, March 23). The Three20 Project. Retrieved from http://joehewitt.com/ post/the-three20-project/

Hewlett Packard. (2011, February 9). HP TouchPad Brings webOS to the Big Screen. [Press release]. Retrieved from http://www.hp.com/hpinfo/newsroom/press/ 2011/110209xc.html

Kaufman, J. (2009, July). Tweetie reloaded: an interview with Loren Brichter. Retrieved from http://unraveled.com/archives/2009/11/tweetie-interview-loren-brichter

Kiesow, D. (2010, August 5). Mobile Study: Make news more convenient for readers. Retrieved from http://www.poynter.org/latest-news/media-lab/mobile-media/ 104794/mobile-study-make-news-more-convenient-for-readers/

Markoff, J. (2008, July 13). On a Small Screen, Just the Salient Stuff. The New York Times.

38

38

Mandel, T. (1997). The Elements of User Interface Design. John Wiley & Sons.

Microsoft. (2011, January 5). Microsoft Announces Support of System on a Chip Architectures From Intel, AMD, and ARM for Next Version of Windows. [Press release]. Retreived from http://www.microsoft.com/presspass/press/2011/ jan11/01-05SOCsupport.mspx

Microsoft Press. (2010, July). UI Design and Interaction Guide for Windows Phone 7. Retrieved from http://go.microsoft.com/fwlink/?LinkID=183218

Microsoft Developer Network. (2011, January 28). How to: Preserve and Restore Page State for Windows Phone. Retrieved from http://msdn.microsoft.com/en-us/ library/ff967548(VS.92).aspx

Nielsen, J. (1997, October 1). How Users Read on the Web. Retrieved from http:// www.useit.com/alertbox/9710a.html

Nielsen, J. (2006, April 17). F-Shaped Pattern For Reading Web Content. Retrieved from http://www.useit.com/alertbox/reading_pattern.html

39

Read It Later (2011, January 12). Is Mobile Affecting When We Read?. Retrieved from http://readitlaterlist.com/blog/2011/01/is-mobile-affecting-when-we-read/

40

40