Macadamian Blog

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

Stunning Design &  Products using Android Tools

Too often, designers and developers work as two separate teams. Designers try to express what the product should look like via Photoshop mock-ups, and developers may or may not carry out their vision due to a number of factors that could include:

• Whether the designer communicated the design effectively.
• Whether the designer is available over the course of implementation for questions.
• Whether the design can be realistically implemented.

Android provides tools that effectively bridge the gap between design and development. If your team is not using these tools — designers using them as input and developers as output — you are subjecting your project to risks! To ensure your app’s interface looks as good as your designer’s Photoshop concept designs, your team will need to leverage the following Android tools and features:

9-patch Tool

Android supports 9-patch PNG images, which can specify the area that should be stretched when it is re-sized. These PNG files will scale properly for all screen sizes and contained text, making them ideal for most control backgrounds. For example, a single 9-patch PNG can be used for all buttons of your app in all languages. Certain developers may be able to create these resources, but very few are artists, so it makes sense to have your visual designers create these images. While 9-patch images take longer to create than regular imagery, they can greatly reduce overall app development time by eliminating the need to create custom imagery for a variety of screen sizes.

ShapeDrawable Objects

ShapeDrawable objects are a programming construct that developers can use to create basic shapes and manage their presence on the screen. ShapeDrawable objects give your interface a “slick” look by preventing the banding effect that occurs with re-scaled PNGs.

To use ShapeDrawable images, designers provide the start and stop color of the gradient and its angle. With this information, developers will be able to ensure shapes are drawn correctly and dynamically.

Alternate Resources

9-patch PNGs and ShapeDrawable objects should be used as often as possible to ensure buttons and backgrounds scale smoothly across screen sizes. In cases where they can’t be used, designers should provide alternate design resources such as standard PNG images for various Android screen densities. As with screen sizes, designers and developers only need to handle four main screen densities:

• Low: around 120 dpi
• Medium: around 160 dpi
• Large: around 240 dpi
• Extra Large: around 320 dpi

The Android OS can rescale images, but the image quality will not be as high as when designed in Photoshop. Providing four PNGs of each image that accommodate the screen densities listed above will allow imagery to look crisp on all devices.

By designing for the most popular screen densities and leveraging Android specific tools such as ShapeDrawable objects and the 9-patch tool, developers and designers can ensure the stunning visual mock-ups developed during the design phase of the project are translated quickly and accurately to the app’s final design.

Takeaways

Android offers specific UI controls, activities, interactions, layout and resize options, as well as special constructs like fragments and intents. While on the surface these appear to be things that the design team needs to work with, we contend that the entire team must be immersed in Android to coordinate design, workflow and execution into a single, intuitive application — one that grabs users’ attentions and draws them in to the real value of your product.

Further Reading

For more information on designing and developing for Android. Read my whitepaper Your First Android Release, It Can Go Really Well (Or Really, Really, Badly)

Mobile Applications Creation – What To Care About?

I was at Mobile World Congress 2012 back in February and it triggered a quite few thoughts. While there were many that I had, some are more appropriate for this blog than others. So what is it that matters in the mobile space and where is it that innovation needs to take place?

Marketers are taking over – I know it’s tough to swallow. We’re collecting data, we're following our users like never before, we’re always with them either with a pocket mobile or with a smart wristband as examples. This is a dream come true for marketers - they can now create a much stronger link with their brand and with social use the social connections to influence a whole slew of people I know for FREE through my social network. Marketing budgets will explode!

Here are the places that scream opportunity to me.

Experience:  It transcends all layers and goes beyond (see my post Mobile – Reframing My Model ). No one really owns all the pieces and it’s a big challenge. The experience equation is: Hardware + Software + Services + Applications. As Peter Chou, CEO of HTC puts it, "the experience has to be Simple, Human and Crafted". In other words, easy to use, compelling through an emotional connection ie. working for people and lastly stylish and sophisticated. All of the above has to be with the mindset that continuity matters to users.

As an application designer and creator, the big picture is critical to me. I need to get out there to observe and engage my users. I need to get out there to engage the service providers and integrate them seamlessly in the continuum of the experience of my application. I have to understand the context where I take over from the current task and where I hand off, and do it seamlessly.

Ecosystem:  Competition is good and it always pays off in the end for the users. At the same time, I’m afraid of the barriers the platform vendors are putting up across ecosystems. There is room for a #3 and maybe a #4. For Nokia, as per Elop, they want to build a platform that answers the ‘where’ question ALL the time (see my post Nokia’s Mobile Strategy @ Mobile World Congress ). I like the odds of Windows Phone, and for RIM there are still a few tricks they can play that could change the trend.

Ultimately though how many of us will have a full blown Apple house and work, or Windows, or Google. I really like the odds of dropbox like services that are going to help me cross the chasm between all the players. I see opportunity in more services like dropbox to glue the ecosystems together.

Big Data:  The monetization model has changed forever even if a few apps companies are making a killing. The money is in data and leveraging users' involvement and participation in some ways. Dennis Crowley of Foursquare opened with "everywhere you see a map there should be a foursquare dot on it".

This is how to build the barriers of entry - the more data I have and the smarter I can be about it, the better the experience I deliver will be. The power in analytics is the ability it gives me to get good at putting a context around what is going on in the user universe and deliver that second to none experience.