Macadamian Blog

Insights from Mobile World Congress - The Only List You Need!

As you know, I attended Mobile World Congress 2012 back in February.  Here are some insights I took away from the conference!

HTML5 Frameworks you Need to Know About

The following is information we learned from Dan Menard (dan-menard.com ) when he gave us an internal presentation on HTML5. This is the first in a five part series.

We’re big fans of HTML5 at Macadamian.

Not only does it offer powerful new features and support the latest multimedia, it can speed and enhance development – especially for mobile apps. I’ve found that there are four excellent HTML5 frameworks that can simplify the process of using HTML5 and reduce cross-platform and cross-browser issues. These are:

1. Sencha & Sencha Touch

Sencha is a company that has created some solid web app frameworks. Its frameworks can help you to build HTML5 apps that look and feel “native” and run on any device. Sencha makes big frameworks that include both UI and controller/mode components, and you can use it to write a full MVC (model-view-controller) app.

Sencha for the Desktop

One of its more popular desktop frameworks is Ext JS 4. On modern browsers, Ext JS 4 uses HTML5 features and it defaults back to alternatives on older browsers. Basically, it helps you to build an app that harnesses the power of the web regardless of the browser the end customer might use.

Ext JS 4 also allows you to include nice drag-and-drop functionality into your desktop app. Play around with this live example to see the end result: http://dev.sencha.com/deploy/ext-4.0.1/examples/desktop/desktop.html

I can’t stress enough, though, that Ext JS 4 is for desktop use only – don’t try to run it on a mobile app unless you want it to be unbearably slow. For mobile apps, you should use Sencha Touch.

Sencha Touch for Mobile

As its name implies, Sencha Touch 2 is designed specifically for devices with touch screens – namely mobile devices. It gives you the ability to create the most common and expected mobile experiences such as scrolling and bouncing, and it lets you create header elements and back elements quickly and easily. 

Sencha Touch is especially nice if you’re working on an iOS project because its output looks and feels a lot like what you’d see in a typical iOS app. Here are some live examples of what it can do: http://dev.sencha.com/deploy/touch/examples/production/index.html

Do Your Homework Before Porting an iOS app to Android

With the rise of Android’s popularity, product managers with an existing iPhone or iPad product are under pressure to port it to Android. While porting from iOS to Android is certainly possible, we have found teams almost always underestimate the amount of effort required.

Porting an iOS app is not a trivial matter because there are a number of Android elements not present in iOS, and vice versa. When the product manager or designer tries to preserve as much of the iOS design as possible, developers frequently devote a great deal of time replicating the iOS controls and workflow because they do not exist on Android. The result is a product that releases late, and ultimately alienates Android users who have become accustomed to Android-specific interactions. For those who are planning to port an application from iOS to Android (or are already knee-deep in this surprisingly challenging endeavour), we’ve put together a list of recommendations.

Re-use Data Organization and Grouping of Controls

The data organization and grouping of controls into screens can be reused from an iOS product in a direct mapping. The relative control placement does not need to change, although it is typical to move the “tab” control from the bottom to the top of the screen.

Use Native Android Controls

Android controls are much easier (and less costly) to implement than custom controls so they should be used wherever possible. Google, like other UI toolkit makers, spent more effort on its UI controls than most app developers can afford. This makes it difficult or impossible to replicate many iPhone interactions on the Android platform.

For example, “lists” on the iPhone can be pulled down to reveal a search control. While this can be easily replicated on an iPhone app, implementing the same behavior on an Android app, and making the transition smooth, would require a significant investment.

Eliminate the “Back” Button
Android devices feature a back button in their physical design. A “soft” back button (such as the one found in iOS apps) could confuse the user or unnecessarily clutter the UI, so it should be eliminated.

An After Webinar Surprise

Last week I presented a webinar User Experience Design within the Seven Phase Product Lifecycle with Brian Lawley, CEO and Founder of 280 Group, and sponsored by AIPMM.

During the webinar we talked about how Product managers are in a great position to enforce and evangelize for user experience as a critical part of a cross-disciplinary product development process – a process that will yield the best results. The webinar was well attended and we had a great Q and A at the end with the participants.

After it was over Benjamin S. Norris, sent me this sketch he created of the event. He really managed to capture many of my key takeaways in such a quick-read, attractive format!

Thank you so much Benjamin, this is really fantastic.

Brian and I will be holding another webinar with AIPMM on Tuesday, May 15th at 2:00. Registration links will be available soon.

Further Reading
If User experience design and how it can help product management is a topic you’re interested in, you may enjoy this whitepaper: UxD: Helping Product Manager’s Sleep at Night

The Right Amount of Upfront Planning

The first generation of software planning processes were termed “Waterfall” and were severely derided over the past decade for being heavy, time consuming and wasteful. The second generation of processes took on various forms of “Agile”, where many teams abandoned upfront planning and jumped right into short sprints or iterations.

What we’re seeing now is the emergence of a third generation involving just the right amount of upfront planning in something called “Sprint Zero”, a term borrowed from the Scrum methodology. What you focus on and what you accomplish in your sprint zero will have a tremendous impact on the success or failure of the overall product.

Requirements Upfront

No matter how agile development is, you’ll never build a successful product if the work being done isn’t aligned to the company strategy and market needs. What level of product requirement detail is needed upfront and how should those requirements be expressed? This is a big topic and already well-covered by Steve Johnson in “Writing the Marketing Requirements Document”.

We highly agree with his recommendation to use personas, not only because it is a way of communicating context that would otherwise be challenging to express in a bulleted list of functional descriptions (“The software shall perform…”), but also because personas are a key tool used by designers.

The Design Blueprint

It is clear that you need to establish the basic skeleton of your design from the outset, as it will shape the entire product in each subsequent sprint. This requires some upfront planning.

In his paper “Introduction to Agile Usability,” Scott Ambler recommends having at a minimum:

• An overall organization for the parts of the UI that fit with the structure of user tasks.
• A common scheme for navigation among all parts.
• A visual and interaction scheme that provides a consistent look-and-feel to support user tasks.

We call these information architecture, primary workflows and basic interaction structure, but it matters less what you call them, and more that you do them. In sprint zero, the software architect defines the high-level structure of the system so that the software developers have just enough information to start developing in parallel. Similarly, the lead designer needs to define a UI blueprint that includes just enough of the main UI framework and guidelines that multiple team members can work in parallel with confidence that their individual pieces taken together will form a consistent user experience.

Communication Tools and Artifacts

One of the biggest hurdles that product teams face is understanding what each functional group will be producing, and what they need from each other to do their best work. In a way, designers, developers, and researchers all speak different languages. While a design concept is good at communicating a sense of what something might be, it’s far from being in a language that developers will be able to use to implement.

Just think for example of a concept car—“It’s the automobile for the new generation, completely integrated with social networks and mobile technologies while being completely simplistic in its operation. The car you feel safe that your teenager can drive and enjoy.” Interesting concept; could you build it? At the same time, engineers need to understand how best to communicate technical constraints without snuffing out the design process.

Ambler recommends using modeling tools and artifacts that reflect agile practices and are familiar to designers and the product owner. XP teams, for example, prefer to work with index cards and user stories. AUP teams prefer whiteboard sketches. All of these mediums are used regularly by design professionals.

Everyone Needs to Understand Technology

Contrary to the idea that only developers need to worry about the underlying details of the software technology, we posit that the entire team—product management, design, analysts, QA, architects and developers—need to have a firm grasp of the technology that the software product will be based on. Consider the Android mobile platform as an example—Android users have become accustomed to the look and feel of popular Android applications developed by Google and its partners. These were developed using Android-specific design constructs like activities, fragments and intents that determine how the application behaves.

Using these constructs is vital in developing an application quickly! Developing custom designs that don’t leverage these default Android constructs can take up to ten times longer and still not have the right look and feel at the end of the day. What’s more, understanding these constructs will ensure the whole team is again speaking the same language. For example, Android developers use the term gravity, which is a close equivalent of the term control alignment on other platforms.

The Android example aside, we’ve found this to be true for any of the numerous modern technologies that are proliferating, from iOS to Silverlight to Google Web Toolkit. If the designer knows how to use the native controls, the development will be much faster than if the designer or product owner ask for custom controls, and the team will be speaking the same language. To ensure product success, ensure that the entire team has a thorough understanding of the platform, its feature and its constraints.

Key Takeaways 

• Plan to have the right information defined and agreed in a short initial project phase (“sprint zero”).
• Use personas to explain the intent and context behind product requirements quickly.
• Create a design blueprint with basic information architecture, primary workflows and interaction structure.
• Agree on communication tools like index cards or user stories.
• Ensure all team members have an understanding of the technology platform and its constraints.

Further Reading

• Usage-centered engineering for web applications.” (Constantine & Lockwood)
• Your First Android Release — It Could Go Really Well or Really, Really Badly.” (Macadamian)
• This post is part of a larger whitepaper: How to Get Amazing Software Out the Door Fast