Topic : Mobile

24
Jul 10

RIApalooza 3: A Look at the Future of RIAs

Every time I get a glimpse of the future of web and app development, I can’t help but believe the best has yet to come. I got that feeling again yesterday at RIApalooza 3 in Chicago, an insightful yearly conference that aims to advance the development of Rich Internet Applications.

Speakers included the always engaging Chris Bernard, a Microsoft User Experience Evangelist, who delivered the keynote on the future of RIAs. The big take away for me, besides Chris’ great “7 things I learned from John Hughes” segment, was the idea that to better understand and grow in the RIA space you have “go where you are uncomfortable”. His message was essentially this: if you are a Flash developer, explorer HTML5; if you are an Flex developer, explore Silverlight. Chris urged designers and developers to not let our focus on an particular development platform define us as technologists, lest we become the buggy whip makers in the next web technology revolution.

Other speakers included consultant Michael Labriola, who spoke on the major striations of internationalizing and localizing a product. Micheal’s examples were in Adobe Flex, but his lessons apply to whatever development platform you use. He examined several layers in terms of effort and return on investment to demonstrate what can be accomplished quickly, what takes up-front planning, and what fine-tuning work truly makes an application localized. If you are building for a global audience, the tips he provided were golden.

Another great talk came from Adobe’s Renaun Erickson, who demonstrated how Flex 4 could be used to build mobile apps that scale across many devices with different Pixel Per Inch screen densities without having to code device-specific apps. This is valuable if you developed an Android app with the Droid X in mind and want it display correctly in another handset with a different PPI density. This flexible development approach is also useful when handsets from the same manufacturer have different PPI densities, such as iPhone 3GS and iPhone 4. But he advised that when you think about porting an iPhone app to the iPad, it may be time to look at a separate app that takes advantages of the iPad’s much larger surface.

All in all a great day of insightful talks from some really smart people. Not a bad way to end the week.

13
Jul 10

App Store Flow on iPhone Could Be Streamlined

Normally I love the iTunes App Store, but not so much today. I was trying to add Kayak’s travel app to my new iPhone and found the experience to be full of unnecessary and redundant tapping.

This was my screen flow:

  1. Launched the App Store
  2. Clicked Search
  3. Typed “kayak” and clicked the Search button
  4. Tapped Kayak’s app on the list screen
  5. Clicked the Free button
  6. Clicked the Install button
  7. Received a prompt for my password
  8. Entered my password and click the OK button
  9. Received a message asking me to confirm I wanted to download the app since Apple had detected this was a new device
  10. Clicked the Continue button
  11. Received a prompt for my password
  12. Entered my password and click the OK button
  13. Got directed to billing page with a request to confirm all information (since this was the first time using this device)
  14. Entered credit card security code without making any other changes and clicked the Done button
  15. Returned to the Kayak screen
  16. Clicked the Free button
  17. Clicked the Install button
  18. Done

Did I really need to enter my password twice? The App Store should be smart enough to know I just entered a password when sending me to the billing information page. Normally I don’t mind having to authenticate when accessing billing information, but not when I just did it a moment ago and am finger tapping an iPhone.

Another redundant step was requiring me to tap the Free and Install buttons a second time after going through the setup screens. At that point I had gone through 36 taps, so I think I clearly expressed my desire to download the app (“Really, I do want it!”, I thought). The App Store should have just started the download.

A last unneeded step was asking me to update my payment information to download a free app. My guess is that was done to get my iPhone ready for seamless purchasing in the future, but that’s a business goal of Apple’s, not a user goal of mine. I just wanted to download a free app. Ask me to confirm my billing information when it’s really needed.

My entire Kayak download took 38 taps. Eliminating the second password prompt and the last two buttons would have cut it to 26, a 31% reduction in taps. That’s a lot in a mobile experience. Dropping the credit card setup for a free app would have removed four more taps. Luke Wroblewski stated it best in Web Form Design, don’t ask for data you don’t need to complete the user’s task at hand.

As I said before, I love the App Store. But its download flow needs some streamlining, especially in the mobile context. I’m surprised Apple missed this aspect of the store’s design given its usual laser-focus on all the small details. As Charles Eames said: “The details are not the details. They make the design.”

2
Apr 10

iPad Prototyping Tool

Teehan+Lax, the awesome team that brought us the iPhone GUI prototyping PSD, has stepped up again with their iPad GUI PSD.

I used their iPhone GUI PSD about a year ago in an HCI graduate class project and was able to create some very polished comps that our project team used for medium-fidelity prototype testing once we glued the printouts of the app to iPhone shaped foamcore cutouts. I won’t be standing in line Saturday waiting for an iPad, but I know where I’ll be turning if the opportunity comes along for an iPad design project. Enjoy!

iPad GUI PSD

iPad GUI PSD

17
Mar 10

New Mobile Features for United and Target

United Airlines and Target last week both introduced new mobile features for smartphones, becoming the latest national brands to try and increase customer loyalty with time and money saving mobile features.

With United Mobile Check-in you can have your boarding pass sent to your mobile device via email for some itineraries. No printing is needed. According to United’s website, once you receive your boarding pass, you can scan the barcode on the screen at airport security checkpoints and at the gate during boarding.

The service is currently limited to eight airports: Chicago O’Hare, Dallas – Fort Worth, Denver, Las Vegas, Los Angeles, New York LaGuardia, San Francisco and Washington Dulles. United said they plan to expand the service to other airports. If there is a seat change, upgrade or change in departure gate, your boarding pass can be refreshed to display the new information.

Target meanwhile introduced mobile coupons last week.

Target claims it is the first major retailer to send scannable coupons to cell phones, although there have been other coupon sites offering mobile coupons in the last year, including Cellfire, Coupon Sherpa and Yowza.

To enroll in Target’s mobile coupon program, you can register at Target.com or text the word “COUPONS” to 827438.

The service sends text messages with links to a Web page that features various coupons. CNET reported that the program works with any phone that has a mobile browser and data plan for Internet use.

Target reportedly will replenish coupons as they expire, and the coupons are good at any Target store but not at Target.com.

JCPenney announced last year it was partnering with Cellfire to pilot a scannable mobile coupons program at 16 stores in the Houston area.

The timing of the mobile coupon offerings takes advantage of growing use of mobile devices to access the internet. Industry publication Internet Retailer reported earlier this year that online coupon redemption increased 360% in 2009 over the previous year, indicating consumers’ appetite for discounts is exploding just as more people are embracing the mobile internet for shopping.

Target Mobile Coupon Signup

Target Mobile Coupon Signup

Target Coupon Confirmation

Target Coupon Confirmation

United Mobile Check-in

United Mobile Check-in

31
Jan 10

iPad Misses on Several Key Points

The world got its first look at the long awaited iPad from Apple this week. And after digging into it bit I think I can wait a little longer to actually get one, though, as Apple has missed some key functionality.

iPad Home Screen

A few of the key features Apple missed are:

No camera: Video chat is impossible without a built in iSight camera. With the hardware as large as it is there is no reason not to have a camera, and one better than the 2.5 megapixel on the iPhone.

No multitasking: There’s no reason a more powerful processor couldn’t have been included so that Mac OS X could be supported. And that’s another miss in itself.

No Mac OS X: Limiting the iPad to the iPhone OS removes a lot of key functionality for mobile users. Unless someone is planning to use Google Docs and other cloud-based apps there is a lot you can’t do with Apple’s “magical” new machine. Business travelers and many other users will find themselves having to carry an iPad and laptop.

Battery not removable: The 10-hour life of the battery is a big improvement over iPhone, but for the cost of the iPad it should come with a removable battery so a heavy user could charge it and swap in a backup.

Lack of clarity on GPS: It’s not clear if the iPad has a dedicated GPS chip or if that will be available on all models. The tech specs indicate Assisted GPS will be used, but not a dedicated GPS chip like one would find on a Garmin. It’s hard to believe Apple wouldn’t match the quality of location-based services available to the 3GS so I suspect this is more of a marketing or semantic problem than a technical limitation of the iPad.

While the iPad is a big advance in multitouch technology and will provide a great mobile web surfing experience, it does not offer enough functionality to replace the laptop, which is what many people were expecting. This is likely a business decision by Apple to not cannibalize the market for their Macbooks. The iPad may have strong appeal to BlackBerry users who want some of the iPhone experience without having to give up their Berry. Only time will tell if Apple made the right calls in limiting what iPad can do.

26
Oct 09

Convert: Great Mobile App Using Iterative Design

If you ever needed an example of the power of iterative design you need look no further than what the designers of the Convert app for iPhone did with their amazing mobile app.

The tap tap tap team posted a video a while back that plays like a time lapse video of all the iterations the design team went through. It’s amazing to see all the choices they team went through, discarding many and making others integral to the app (see the video below from YouTube).

[youtube=http://www.youtube.com/watch?v=oDSrZ5Nv1dI]

The recognition by the design team that iteration is a key part of the design process is a testament to the value of the UCD process. This app, which is well worth the 99 cents just for the exposure to the interface, is useful, elegant, and, perhaps most importantly, fun to use. But it should be, it’s the product of continual refinement of a great idea.

17
Sep 09

Chicago Metra Redesign Could Better Support Mobile Use and Accessibility

Chicago’s suburban mass transit agency recently launched a new website design that could better support a few important audiences among its riders — people using mobile devices and users of adaptive technologies.

The new Metra website offers some long-needed enhancements, such as online ticket sales, finally accepting credit cards for ticket purchases, and email alerts for service delays and disruptions. But a feature that every transportation agency should offer, a smartphone friendly website, was not part of the relaunch.

By comparison the San Francisco Bay area public transit system (BART) offers riders numerous mobile options including support for the iPhone, Blackberry, Android, SMS, and even open access to BART schedule data for third-party app developers.

BART Homepage

BART Homepage

BART Search Screen

BART Search Screen

BART System Map

BART System Map

Metra Search Screen

Metra Search Screen

On the BART site, a visitor using an iPhone sees the normal homepage in Safari with an additional link in red text prompting the user to visit the BART mobile site. The link is hidden for people using regular web browsers. This leads users to a simple screen of seven text links from which the person can get to the BART search screen. While it’s better than what Metra does (or doesn’t do), it should just take you to the mobile site since that is what most mobile users likely want and then provide a link back to the regular site for people who end up there by mistake.

BART also provides a fairly easy to read system map for iPhone users. The Metra map for just one route is useless on the iPhone since it was designed for regular browsers and includes shading for municipal areas, lakes, and forest preserves. All important things to know when your train is unexpectedly stopped on the way home from work and you have to make a change to your travel arrangements. You’ll have to view the site in a regular browser to see the map in detail.

Even if you enlarged the portion of the screen with the start and destination station select menus, the results page is impossible to work with on a two-inch screen.

In yet another omission for users of alternative means of browsing, the accessibility features of the new Metra site leave a lot to be desired. The only skip navigation takes a user from the top of the page to the center content column. On the homepage this skips all the repetitive main header and utility header links but also takes you past the site search, search by route, and search by address or zip code utilities. The skip navigation on the BART site takes you to the Quick Planner, which resides in the left most column like on the Metra site.

Metra also dropped the footer link to web accessibility information that the previous site had and makes no mention of web accessibility on its system accessibility page. BART in contrast provides information on web accessibility as well as contact information for its website manager.

To be fair, both sites do make use of HTML label tags and standards compliant coding, which should improve the experience for users of adaptive technologies. Yet both sites also lack support for accesskeys.

The BART site is not perfect, as no site is. The homepage link for the system map takes you a page with one link that reads “View System Map” and includes a disclaimer saying some mobile browsers won’t be able to display the map. So an iPhone, BlackBerry, or Android user has to go through two pages to get to the map.

Metra’s new site is definitely a step in the right direction after years of a lackluster presence, but ignoring mobile users and the limited accessibility features are a huge disservice to the people who pay its bills everyday. More time spent walking through real use scenarios with a diverse set of users could have prevented much of this.

27
Aug 09

New York Times iPhone App Update Botches Navigation

The recent update to the New York Times iPhone app does its users a real disservice with some disastrous changes to the app’s navigation.

The main flaw in Version 2.2 is the removal the navigation bar and tab bar from the screen once the user scrolls down into the body of the story. In the first image below, the app is seen with all navigation when a story first loads. You just have to scroll down a small amount and the navigation and tab bars disappear, as seen in the second image.

Navigation in Place

Navigation in Place

Navigation Hidden

Navigation Hidden

Full Screen Ad

Full Screen Ad

What? I want my Back button back. Imagine scrolling halfway down into a long story and deciding you want to to the previous screen. There is no way to get back to the headline screen except to the scroll to the top or bottom of the story, which causes the navigation to reappear.

When the tab bar at the bottom disappears it hides the button to email someone a link to the story, the font size controls, and the Save story button.

In the previous version, the navigation and tab bars were always present along with the horizontal ad at the bottom.

The user experience is better in the AP Mobile app, which never removes navigation from the screen.

It may have been that the NY Times designers wanted to offer users a larger area of the screen for reading, but for someone like me who pogo sticks in and out of stories sometimes, this is a major annoyance.

A smaller issue is a full screen ad that comes up when the main screen gets its latest update of headlines, as seen in the third image. While this is intrusive, it’s also somewhat understandable since the battered traditional news media needs to find a new business model that goes beyond just giving their content away for nothing. Because I value the quality of the Times reporting and writing, and it’s free, I don’t mind clicking the Close Ad button and moving on. At least the app’s designers had the good sense to only show one full screen ad per session, which makes the intrusion minimal. Since this is the first news app I’ve seen using full screen ads it will be interesting to see if other apps start doing this.

While I can live with the ads, the change to the navigation scheme is unbelievably bad design. I’m hoping Version 2.3 is coming soon to fix this mess.

5
Jun 09

HCI 440: Usability Engineering

Just finished the final session of my usability engineering course at DePaul, a course that provided a lot of insight into the UCD process and the compromises you make on a working project.

Overview: The main focus of the course was to design a mobile phone application over an 11-week period. To simulate some of the pressures and challenges of a real world situation, we had to work in teams and deliver each successive phase of the project (research, requirements, designs, prototypes) weekly. The final deliverables were a presentation of our business case and the market problem we solved along with completed Photoshop mockups of the three primary use cases.

Research: After deciding on the application we wanted to design (an iPhone app for fashion accessories), we conducted market research using a combination of online surveying and interviewing. We surveyed nearly 50 people who matched our intended target demographic and interviewed 10 people during a one-week period. As so often happens, we learned we made incorrect assumptions about what the target user wanted and missed some features they considered important to the application.

Requirements: After completing our research we developed a set of user goals and the necessary supporting functionality based on what we learned about the target consumers. Due to time constraints we had to skip development of traditional use cases and diagrams, and instead utilized a matrix that traced functionality back to user goals. We then developed the requirements to deliver those functions.

Prototype One: This was one of the most interesting and fun parts of the course. Several of our peer teams were developing prototype applications in Flash or HTML for testing on laptops. We chose a different route. Using the iPhone prototyping tool from Teehan+Lax we mocked up our prototype in Photoshop. We then printed the PSDs and glued them to foamcore cutouts to make interacting with the prototype a more tactile experience. While we lost some of the interactivity some our peer groups had, we gained an advantage by having test participants (drawn from the class) actually hold and touch our app. We gained useful insights by watching them respond to color, contrast, and visual cues while actually holding the prototype and viewing it from a realistic distance (though I admit we could not accurately mimic screen brightness and other settings that affect users in the real world). While one of us moderated the tests another played the role of the phone and handed out new screens in response to participants’ actions. In two hours we were able to test five people going through three main use scenarios while capturing our observations on recording forms. We followed each test by asking the participant to respond to five statements about their experience, which we asked them to rate using the Likert scale.

Evaluation: We analyzed the usability issues encountered in several ways. We looked at the frequency of the issue, the impact to the user’s ability to complete a task, and the criticality of the feature of the app where the issue occurred to overall business goals (in our case conversion).

Frequency was recorded as a simple count of the number of times an issue occurred. Impact to task completion was measured as high, medium, and low, with numeric values of 3, 2, and 1 respectively. Criticality also was measured as high, medium, and low, with numeric values of 3, 2, and 1 respectively. Criticality level was set by using the requirements matrix to see how the feature traced backed to user goals.

For example, the failure of two users to see a Buy Now button would be rated as Frequency=2, Impact to Task Completion=High, Criticality=High. This would be calculated as 2 x 3 x 3 = 18. This allowed us to prioritize the issues based on what fixes would have the biggest improvements to the app. In a business project, of course, time and cost would have been other dimensions to consider and some high ranking fixes might have been descoped due to time constraints.

Prototype Two: Based on the Evaluation phase we focused on enhancements to the search interface. Adjustments were made to search results interaction widgets and results list displays. Sorting by price/brand was originally deemed as out of scope but was added based on user feedback. People wanted ways to narrow results quickly, and price and brand seemed most natural to most participants. The refined prototype was part of final deliverable package.

Presentation: Our final presentation was organized around several key areas—user expectations for mobile applications based on the current products available, market need for the product we developed, business opportunities in satisfying those needs, and the iPhone application we designed to realize those opportunities. This exercise allowed us demonstrate that what we designed would be accepted by the market and could be profitable. In addition to our app we developed an affiliate program model that would partner with online fashion retailers to provide revenue to us for referred purchases.

This was a great learning experience because while the primary focus was designing an application following the UCD process it also challenged us to be concerned with satisfying business goals. A useful skill when your design work has to actually float the business.

Note: Screen designs and greater details were not shared because we are considering working with the university’s business school incubator to pursue a commercial application.

18
May 09

More Fun With Paper Prototypes

Testing an iPhone app prototype in class this week was a breeze thanks to some fast paper prototyping. We developed our prototype using the PSD iPhone UI tool available from Teehan+Lax. To give the prototype a bit more of a real feel, we glued color prints to foam core backing to provide a tactile quality not available in pure paper prototypes. While some of our classmates created slick Flash files that could provide fuller interactivity via a web browser, we felt we learned more by giving the test participants something they could hold in their hand. It was fascinating to watch them swipe up and down while telling us how they would scroll through a list of search results in our mobile shopping app. We also learned a lot about what they found confusing when they scanned the mobile “device” and had difficultly with certain parts of the interface. We would have lost that if they were looking at a laptop-based prototype since it sat farther from them than the mobile would in hand. The participants also seemed more engaged by the tactile aspects of touching and holding. After two hours and five tests, we had a lot of insights for the next revision, and all without writing a single line of code.