Exposing team members to end users means participating in field visits and listening in on interviews and usability tests that help uncover user’s goals and objectives.

For a project I recently worked on, I conducted field visits and interviews with a number of users and user groups. Reporting on the findings to stakeholders that had not participated in the research activity led to some conflicts and discussions at design and product development meetings since they weren’t as familiar with certain ways their product was being used. Not connecting with their end users has lead their design to become more complex by the addition of features and capabilities so it was great to see that this first step had been taken and an importance placed on user experience (UX).

Let’s compare that scenario to another project. For this project, a number of stakeholders actively participated in observing design concept walkthroughs and therefore, were much more educated in the subtleties and nuances of users’ interactions with the design. Seeing the problems users were running into led to insights behind their potential causes and gave everyone new ideas for a better solution. When everyone has a chance to come up with solutions, it helps the core design team become aware of other influences to the design, which may not have been considered or mentioned previously.

One way that we expose stakeholders to end users is to invite them to (silently) observe usability test sessions; whether in-house or remote. This allows them to become familiar with the users’ needs and wants so that conversations don’t become a battle in the meeting room later. If time zones or schedules don’t permit stakeholders to sit in live for the sessions, we record every one of them so that they can still expose their team members to the research activity at a time that’s more convenient.

Currently, we’ve also been involving our developers in projects that aren’t UX-only projects. Our developers have either been encouraged by our UX team members to become familiar with the design’s end users or often, the developers have put “more UX-exposure” onto their yearly review. When developers see how people are experiencing the design, they can think about the implications from a technology standpoint. It also gives them a chance to become more knowledgeable so that when something has been created and a roadblock occurs, they know of reasonable alternatives to use. This enables the whole team to work better together.

Involving these groups sends a clear message of the importance of UX and I’m excited to see how this leads to greater experiences for our end users!

Why Rubber Stamping?

Getting an application to work on the web, on the mobile, on the TV etc. is very expensive. So my reflex to bring my costs down could be to apply one design for all.

There is another more insidious reason and this is that sometimes we don't know what we know.  Simply put, there are things we're unconsciously competent about and this is one of them. We all know a web application doesn't go about performing the same task that a native mobile, or even a web mobile one would. Yet often when creating applications, the first thing I see people doing is trying to replicate the exact same task the same way. That's what I call being unconsciously competent about something - we intrinsically know the user model for the web is different from the mobile, yet we don't take that into account. It's like we keep forgetting to embrace the differences in the user model and the result is a software product that doesn't deliver on an experience that users will be expecting and ultimately it will not deliver on the business goals either. 

At a high level, two things I work hard at keeping front and center in design activities:  the mental model the user is in when using the said product, and the gaps the product is to address. 

Mental Models

An example of mental models to account for with users is how they are used to use the platform my product is to run on. The web metaphor of usage for a user is not the same as the mobile or desktop metaphor. So in the web we've gotten used to the back and forward button. Still it's very important to help the user find anchor points in my web application so that he's never lost, so bread crumbs are a visual indicator used sometimes to help with that. In mobile I still need to help orient the user, but I won't do it the same way because it's possible in the mobile application to imply a sequence from its visual language. Another expression for mental models is context of use. The two applications need to help orient the user, but because my user is in a different mental model imposed by the platforms, it means I must be aware of those differences to deliver a compelling user experience.

Mental models encompass a lot of things. It can be whether or not my user is standing up when using my app or sitting down; it will make for different expectations on the user's part. Rubber stamp design is not putting the user at the center of my design by being aware that their mental models are a critical aspect of the experience my software will deliver. 

Going Back to the Gap the Product is to Address

It's one aspect of my customer's overall business goals. My customers all want to make money, plain and simple, and more of it. How the software I'm working with is to go about meeting that goal is highly dependant on the gap the product is meant to address. The platforms on which the product is to run are only an ingredient of the overall business recipe. The web application might be the main use case. The mobile is there to supplement the experience when the full web experience is not available to my user. Mobile could also very well augment the experience of my main use case. 

The gap I'm designing to fix is another reason why rubber stamp design is no good. Settling for the same design on all platforms would not enrich the experience to capitalize on opportunities. 

Wrapping Up

Rubber stamp design doesn't work because it doesn't embrace the user models. It doesn't work because by not embracing the user models, I might not even fully cover the business gap I'm trying to address in the first place. In short, we all need to strive to become consciously competent about mental models our users are working under in conjunction with the business goals in order to create an experience that will encompass both. Only then do we deliver a product of great value to the users and the customer - a product of desire. 

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.

Leverage the “Search” Button

In addition to a “back” button, Android devices feature a hard “search” button. Be sure to eliminate any unnecessary soft search buttons and configure your app to leverage the built-in back button. Leverage the “Menu” Button and the “Long Press” Android menu options can be moved off-screen to a menu that is displayed when the hard button is clicked. Similarly, secondary options can be made accessible by doing a “long press” on a control. For example, long pressing a list item is one way to obtain the option to delete it.

Design the Selected State

When a control is selected, a visual representation of the controlled state is needed for designs that incorporate custom backgrounds. Buttons, for example, may need to change color when selected, so your design will need to specify the look and color of the specified state.

Use 9-patch PNGs

9-patch images allow Android controls to automatically resize images and display them properly on an Android device.

Set Controls to Density-Independent Pixel Sizes

If your Android UI is defined in pixels, the controls will be large on some screens and tiny on high-resolution screens. To remedy this, set your controls to density independent pixel sizes so that the physical size of the control is maintained on all screens.

By tailoring your iOS design to suit the Android platform, you can ensure your ported app looks and acts like an Android app — not simply an iPhone app running on an Android phone. What’s more, you will dramatically speed up development and release of the application by eliminating the complicated steps required to replicate the iOS experience on Android.

Summing It Up

Delivering value to app users who are interacting with dozens of different Android mobile devices is challenging and requires the collaboration of product management, design teams and developers. By leveraging Android design tools and understanding the differences between the iOS and Android platforms, you can quickly design and develop an Android app that is visually appealing, intuitive and easily adopted by Android users.

Talk With the Experts

User researchers trained in User-Centered Design techniques can help you to understand your prospective Android users and how they will be interacting with your app. We invite you consult with our accredited UCD researchers and Android experts who can work alongside you to develop a UI that will maximize the value of your design across the user base. At Macadamian, our experience and proven ability to design and develop groundbreaking mobile products make us the ultimate partner to support your Android application project.

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)

There are a couple of reasons functions can’t “take turns” sequentially designing and building a product:

1. The steps are not sequential. Designers need to test that a design is working over the course of development. Product Managers need to adapt requirements as they get updated competitive data.

2. Designers need room to be creative, and that means the ability to fail and iterate.

3. Part of success is releasing in time to capitalize on a market opportunity. Working in parallel with daily communication is much faster than sequentially. Here is a glimpse at how we’ve seen very successful teams manage this idea of mass parallelization and iteration.

Start With Back-End Development

Many developers are used to the idea of developing the UI first and then implementing back-end functionality progressively. This is normal—business stakeholders are visually inclined and have always put more emphasis on having the visible parts of an app built first for things like demos. How many managers do you know that see a UI with no back-end and assume the product must be almost complete, when in fact the back-end has barely been started?

Developers who are comfortable with the idea of starting on the back-end and making sure to have a robust data model while the designs are being fleshed out typically thrive in modern software environments. They recognize that well architected software has a clear divide between the front-end and back-end and starting with the back-end actually contributes to a solid architecture. What this means is that Product Managers need to work closely with the architect and developers early on to establish the data model based on product requirements. Follow the requirements advice we gave earlier, and you should be in good shape.

The other more unfortunate consequence is that from time to time, developers will be asked to develop the UI and then re-develop it when the design changes. A good software team leader will be sure to offer the right explanations and support, as this could otherwise be a morale killer for developers who see it as inefficient re-work. For the good of the product, it is better to continuously adapt a design than wait for it to be “locked” before starting development.

Continual Estimation

Once the Design and Development groups have developed trust and are communicating daily, they will often need to discuss time vs. design trade-offs. Many software developers are amazingly creative and can build almost any design—even an astoundingly complex one—but it’s always a question of time and budget. Since most designers don’t have the deep technical knowledge to know upfront which design elements will be costly and which won’t, successful development teams get into the habit of continually estimating the time required to develop the proposed designs and provide that information back to the team as the designs evolve.

Here is an example of this workflow:

1. The designer proposes an initial design concept.

2. A software developer estimates the rough time to achieve the design.

3. The developer highlights specific layouts or controls that will take time, especially if they risk threatening the timeline.

4. The developer gets back to design and product management with this information.

5. All three can discuss alternatives. If a particular design element is deemed critical to product success, the team can decide to leave it in scope despite its time and cost impact.

Does this constant negotiation-like process take a lot of time? It can, but it’s worth it. We have found two elements that can dramatically speed the continual estimation process:

1. Communication and trust. If these are present, design/development discussions quickly go from harsh negotiations to mutual support.

2. The developers’ ability to estimate quickly, which comes with practice and knowledge of the system. Estimates don’t have to be 100% accurate. In fact all that is really required is a ballpark estimate to flag any major complexities in the design.

Several years ago, Joel Spolsky recommended a process called Evidence-Based Scheduling—a way of using his company’s software so that developers could progressively learn to estimate quickly and effectively. While we have not used his tool, certainly the theory is one we ascribe to.

Buffer Time For Creative Failure

This is probably the hardest one to achieve with a senior management team that is not bought in to an integrated Agile design process. You need to allow for some buffer for designers to be wrong. Good designers are trying to solve problems much like the scientific process—they come up with a hypothesis, in this case a design, and try to prove it through prototyping and usability testing. Unless your product strategy is to be first to market at the expense of potential quality trade-offs, the product owner should actively plan for some “failure and re-work” time. Designers will need this to iterate designs. The additional time may not even push out the release schedule much, as developers can use this time to perform activities that are otherwise notorious for holding up a product release at the end—refactoring code and fixing last-minute bugs.

Key Takeaways

• Software team members need to effectively work in parallel, not sequentially.

   

• Developers working from the back-end will allow more time for designers to iterate the design.

   

• Developers should continually estimate the time impact of design changes and discuss it with the team.

   

• The product owner should buffer time for re-working the design and architecture, unless time-to-market is the key driver over quality.

Further Reading

• Introduction to Agile Usability. (Ambler)

   

• Four Ways to Review an Estimate with Limited Time and Expertise. (Macadamian)

Pre 1867:
As we were traveling we were reading about Argentina and the places we were visiting, the buildings etc. Then Manon stumbled on a very interesting piece of information. Argentina's rendez-vous with fame and glory: Frozen beef! It speaks to the power of innovation; it transformed people's lives and a country's future. For Argentina there was pre 1867 and after 1867. See Argentina has always had a great reputation for producing high quality beef. The problem they had was they could not sell it to anyone outside of their internal market. They had no way to ship the meat without it going bad before it made it to its destination.

Post 1867:
Well this date to Canadians is significant for different reasons, but for Argentinians it's the date when they figured out something very important. In 1867 they discovered a way to ship their beef frozen and keep it frozen long enough for the beef to make it to Europe and still be good to eat.

This innovation for Argentina was transformative. They figured how to freeze beef so they could export it and make huge money from that great resource they had. Thus was born the expression 'rich like an Argentinian'.

Where is my 'frozen beef' in my industry?
It is so simple when you think about it. I have a supply and there is a market for it but I just can't get it there. Then one guy puts two and two together and a country is transformed. Back in the day, frozen beef existed. Still the process needed to improve significantly so that significant breakthrough could be achieved with the beef supply.

Back in the day, the big innovation was what now looks like a fairly simple thing and we all know it wasn't. And still the point I want to make is how incremental this whole innovation was - frozen goods existed, boats transporting industry existed, beef existed ... still how very significant keeping beef frozen for a little longer turned out to be.

The take away for me is this incremental innovation is all around us in our businesses. It starts with a hitch, it starts with a gap, it starts with a pain, and next thing you know you might just have an Aspirin like impact.

The ingredients are here. We need to experiment. We need to continuously mix and remix! So where is the frozen beef moment in your business?

In my last blog post I discussed HTML frameworks that simplify the use of HTML5. I’m now going to dig a bit deeper and talk about four helpful tools – some that exist and some that are still in development – that will help developers in their day-to-day work within those frameworks.

1. New Client-Side Validation Tools:

Client-side validation is probably one of my least favourite things about development. Luckily, it’s getting a whole lot easier with HTML5. When developing forms on the web that handle e-mail addresses, URLs or other user inputs, you usually need to write a lot of validation scripts to ensure that those entries are valid. These scripts can be pretty tedious to create and can’t always be ported from one project to another.

Luckily, HTML5 uses input elements that eliminate the need to write complicated validation scripts for common forms. These elements can automatically detect whether the user has inputted a valid entry.

For example, if you want to have a field that can only accept regular expressions, you can use an input pattern attribute to automatically generate the appropriate field:

In this case, the field will only accept regular expression entries. If the user does not input one, as in the above example, the box automatically turns red and displays the message “Please match the requested format.” The same type of input can be used for other common form elements like e-mail addresses and URLs as seen here:

One of my favourite uses of these input patterns is for required fields. Normally you’d have to place an asterisk beside the box to indicate that it’s a required field, and the user might only realize that they haven’t filled it out once they try to submit the form. With HTML5, you can use an “input required” element. If the user leaves it empty, it will highlight it in red and indicate that it must be filled before submitting the form.

All of these HTML5 input elements make it very easy to create forms quickly and painlessly.

2. FlexBox

Another great HTML5 innovation is FlexBox. It’s a very flexible jQuery plugin that can be used as a replacement for HTML textboxes and dropdowns. It’s useful for when you have to design web page layouts like the one below that can adapt to a variety of screen sizes.

Normally, you’d need to use a lot of messy floats and clears to accomplish that, but FlexBox lets you do it with one simple line of code:

<div style=“display: -webkit-flexbox”>

By adding this code and inputting your normal content, you can create a web layout that will display properly on a wide range of devices.

FlexBox is also very…flexible! You can assign a lot of different options for rows, columns, wrapped text, ordering and alignment – both horizontal and vertical. That’s nice because it’s traditionally been really tough to get vertical alignment right.

The last bullet in the above diagram is one of my favourite aspects of FlexBox. If you’re setting the width and height of a FlexBox, you can assign it a positive value, a negative value and the preferred width. It will make your element the preferred width if it can, and it will use the positive value to accommodate any extra space left over and margin it accordingly. If the element doesn’t fit, it will use the negative value to align it according to your wishes (left justified, right justified, etc.)

You can learn more about FlexBox and download it on its website: http://flexbox.codeplex.com/

3. Web Intents

HTML5 also features “web intents” which are just like Android intents – they’ll find the appropriate activity or tool needed for a particular operation. So, if your app requires someone to input an image, for example, you could create an intent that would recognize the user’s social networks and ask if they would like to use an image from Facebook, Twitter, Google+, etc.

Web intents are still at an early stage so I don’t know of a version that you can play with in a browser, but I’m sure that will change within the next 12 months. I expect these to become very, very popular!

4. Web Components & Scoped Styles

Two of the most powerful upcoming HTML5 tools (in my opinion) are Web Components and Scoped Stylesheets. I could probably write entire blog posts on each of these, so I’ll just give you a taste of what they will make possible. Web Components will dramatically simplify the process of creating and re-using widgets through the use of templates, decorators, custom elements and shadow DOMs. You can find some very detailed explanations of all of these aspects here: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html

Scoped Stylesheets will allow you to create widgets that don’t break the rest of a web page. In short, you can restrict certain style rules to only apply to one section of a particular page – allowing you to cleanly incorporate content from third party sites, for example. You can read a good description and example here: http://updates.html5rocks.com/2012/03/A-New-Experimental-Feature-style-scoped

Staying Up to Date on HTML5

As you can see, there’s lots to know and learn about HTML5. In my next post, I’ll show you where you can go to learn more about HTML5 and stay up to date on all of the new tips, tools and tricks.

Background

This all began when we got a sneak peak at BlackBerry 10 a while back, saw some of the concepts like flow and connect, and realized what was possible using Cascades with a minimal amount of code. We got excited and decided to create a demo that embodied those concepts in an Enterprise context. We wanted people to rethink how they might go about building a really rich enterprise app in BB10.

The App

Imagine you are the owner of a sports apparel company and its NBA play-off time. Like any business, your biggest problem is predictability. As the owner you want to see data analytics and visualizations that will help you make inventory purchasing decisions, such as how many team jerseys to buy. Of course you can’t predict what is going to happen in the playoffs, so you want to see data showing you things like who’s playing well so you can make a more informed purchasing decision.

This app is a combination of Cascades and OpenGL. On the left hand side of this screen shot is a giant Cascades control. It allows you to rotate around through the different NBA teams.

For the data source, we captured ½ million tweets over 2 weeks from Twitter for the different NBA play-off teams, in an attempt to get a sense for which team was generating the most interest among fans.

We then rendered the data in OpenGL as a screen graph, which shows which team has the most buzz. As you tab through the app, you can see the starting line- ups of the Mavericks and Thunder as well as who has the most play-time in minutes per game.

As you tab through the app, you can see the starting line- ups of the Mavericks and Thunder as well as who has the most play-time in minutes per game.

In this screen shot, you can see that the app also shows which players have the most rebounds per game.

Both of these charts are drawn in Open GL but all of the rest is done in Cascades. The text and buttons are in Cascades, and OpenGL is dropped in on top. Basically, we’ve seamlessly rendered OpenGL in between all the rest of the controls.

The Code

There are 3 parts to the code for the controls we created: an OpenGL thread, 3 different GL renderers (each responsible for drawing one of the graphs), and a custom control that implements straight from the Cascades CustomControl class. Once we had these three parts, we attached the OpenGL thread to the CustomControl using an invisible ForeignWindow and gave our OpenGL thread a reference to the correct renderer.

To use the control, we import the control by name and then just drop it in a QML document like any other Cascades control. The rest of the app is written in straight Cascades. The scene graph is built up by the Cascades engine and the control will integrate seamlessly into your app. It’s as easy as that.

If you’d like a better look at the code, we’ve put it up in open source under Cascades samples.

Image by Getty Images via @daylife

• Facebook is becoming a vision of what the consumer operating system is,

• Social media is an acceleration,

• Internet of things concept.

I think as a product designer and creator there is something to be said about the points Marc Benioff is making. To create the enterprise software of tomorrow, the biggest trend these days to be aware of is the 'consumerization' of the enterprise.  This is driving the need for better design back into the enterprise. Through better design, a better user experience will encompass what works from the consumer side of things and the new interaction metaphors the consumer is driving. 

Image via CrunchBase"Facebook is becoming a vision of what the consumer operating system is"

Not to put words in his mouth, but he really is saying Facebook is the model of interaction and use cases that our customers' customer expects to see now. The users of our enterprise software now are growing up in an FB world - not a Frederic Boulanger world, but a Facebook one! Facebook for all its good and bad is setting the bar on how things get done. Whether it's how information is discovered and shared, or how we interact with it, Facebook is the only game in town. 

To create the interactions of tomorrow in our business software, we have to be taking into account the new expectations of the users regarding the interactions and the experience they unknowingly have. They are the Facebook models of interactions.

"Social media is an acceleration"

Image by Laughing Squid via FlickrEnterprise software is about enabling quicker decisions for an organization. Information discovery is a big part of social media. The information architecture of the products of tomorrow are set to use some of the social networks concepts because they accelerate propagation of information that is likely to matter with you. There is a perfect match in principle for social and enterprise through 'acceleration of decisions'.

"Mobile, Social and cloud'" vs "Internet of things"

I'm mashing two things I heard yesterday here. Arab Spring was supported by 'Mobile, Social and cloud', this is why we saw Thank you Facebook and Thank you Twitter all over the place in Cairo and other cities in the Middle East. Additionally, in the not so distant future there are going to be many more devices than we can think of right now. 

The model to have in our heads is - if 'it' consumes energy it will be connected to the internet. This means all sorts of things will be helping us make decisions on data received from the cloud wherever we are and with the ability to share those experiences and engage. 

Example: I'm driving my car and it slips on a patch of ice; my car will then push that information up into the cloud and all cars following me will be notified of that patch of ice and will help their driver not get into an accident. 

The Mobile, Social and cloud and the internet of things, will further accelerate the enterprise. Adapting more quickly, avoiding obstacles and making more decisions are a direct benefit for those who embrace it. It's only starting - buckle up.

Wrapping Up

Our new software products in the enterprise have much to gain to internalize the models of social networks. The models are there and well understood by the users, so less training and more engagement are highly likely. The impact is already seen and known in the consumer space; information propagation through social network is fast and no enterprise out there wants to go slow.  Decision making and adapting to an ever changing landscape are optimal with social network. 

So a couple of questions for your next release to embark on the enterprise social software:

Do not be afraid. Plenty of familiar guidelines and work experience from other industries can be drawn on to support design work for the healthcare industry.

Some of the same considerations for designing mobile apps for the general population exist for clinicians as well. For example,

• Should the app be web, native, or hybrid?
• How will the app function so that expectations are met regarding existing UI guidelines?
• How will the app be used? What goals should be met?
• How will the app fit into the users context of use?
• What is the platform and device to be used?

There are additional considerations for this sector as well and these should not be skimmed over quickly. For example,

• What type of data will the app display? Loads of data can be collected from a patient and it needs to be displayed in a useful and usable fashion for the clinician. Consider taking advantage of data visualization techniques to display patient information especially for providing trending information. This helps clinicians improve the quality of care through better patient tracking and decision support (Adaptiv 2011).

   

• Healthcare encompasses people of all ages, mental capacities, physical attributes, skills and knowledge, etc. so who will use your app? An app that clinicians touch may also be targeted for their patients so check out Barb’s blog on “Sometimes, it’s not About the User” or our newly published whitepaper “How to Create Engaging Patient Software”.
• What other applications or devices will your app talk to? Don’t assume your app is the only tool in the toolbox. An integrated approach to healthcare is key to its success and the success of the mobile app. A solution requires a holistic approach that is capable with integrating with heterogeneous systems or applications (Raja 2011).
• Will security and compliance affect your app? If so, it is essential that you check out and adopt healthcare compliances and regulations that govern the healthcare sector (e.g. HIPAA, HITECH, ITRF Regulation, PRCI/PHI Compliances, etc.)

Not that it should affect how fabulous your app is at the end of the day or how much hard work has been done in user research and design, but keep in mind that your app may be one that healthcare consumers will be told to use instead of choose to use.

Acknowledging these considerations is integral as it allows the healthcare app’s UX team to provide the most optimal end user experience.

We just got back from BlackBerry World, and I was simply floored by what I saw. We're a longstanding RIM partner, so we've been getting sneak peaks of BlackBerry 10, and we were impressed with what we're seeing, and what we're able to create with their new Cascades framework (more on that later). But I wasn't prepared for what we saw in the BlackBerry World Keynote.

Incredible User Experience

The new User Experience of BlackBerry 10 is simply amazing. RIM is really sweating the fine details of the new UI. The transitions are organic and gorgeous. Apple caught everyone unawares when they released iOS, and it's in the fine details like transitions and scrolling where other platforms like Android don't measure up - they simply don't feel as realistic and natural as iOS. The UX and software teams at RIM are clearly making sure that the finer details of the platform feel as good as, and in some cases better than, iOS. I think developers, and the industry, will be really surprised with what you'll be able to do with BB10 and the new Cascades UI framework. Here's a link to the part of the keynote where they show off the new UX - see for yourself, and hang on through the keyboard and camera demo: http://www.youtube.com/watch?feature=player_detailpage&v=OfHLjlogDS8#t=1208s

Innovation in the keyboard

The new touch keyboard on BB10 is really wild. There hasn't been a whole lot of innovation in the keyboard on mobile devices, and the new BB10 keyboard will take predictive typing to a whole other level. First, the performance looks really solid. Performance is a constant annoyance on other mobile platforms, where your thumbs can get ahead of the keyboard, and it's looking like the RIM team is focused on making the typing experience one of the best in the industry, just as it was with the first wave of BlackBerry devices. More importantly, the new swipe gestures are sheer genius. As it learns which words you use most often, it starts to make suggestions, and you simply swipe upwards to create entire sentences with just a few gestures.

Flow, Connect, Extend

RIM is playing to their strengths, and capitalizing on the weaknesses of other platforms. One of the weaknesses of iOS is that each app is it's own island. On BlackBerry 10, data will flow between apps, and the integration between apps will be far more seamless. There will also be a focus on Connecting with social media and other systems, and the fact that BlackBerry 10 is based on QNX will make it easier for BlackBerry to Extend beyond the glass and interface with the many devices in the rest of your life, like your car, which, chances are, runs on QNX.

Developers, Developers, Developers

To borrow a famous Steve Ballmer quote, it's about "Developers, Developers, Developers". RIM is paying a lot of attention to developer tools in BlackBerry 10, and it shows. Look at what we were able to do, with an Alpha no less, in under 2 weeks. http://www.youtube.com/watch?v=3nX_AploVC8  We believe that the future of enterprise mobility lie in apps like these - micro apps that are small, simple, but provide immense value to the enterprise user. Things like data visualization apps that provide windows of insight and help enterprise users make day-to-day decisions while mobile. 

A winning strategy

I'm really impressed by RIM's cohesive strategy, and their intense focus on making BlackBerry 10 a great platform. At BlackBerry World, it felt like every fibre of RIM was focused on making BB10 a remarkable platform. I think RIM is going to exceed expectations with BlackBerry 10. You heard it here first.

The smartphone experience is continuity and engagement 
The mobile pervasiveness is marching on. From keynotes to demonstrations, the pattern emerging for brands and winning products is becoming clearer and clearer. The mobile is with you all the time and it's a great weapon to connect the dots of what is going on in your life - it's a continuity engine. The next thing it does very well is engage the user in context where no engagement was possible before - get ready to experience the world like no man has experienced it before! 

The ecosystems battle royale 
Is there really a battle there between iOS, Android, Windows Phone and soon BB10. At the show, Android was the big gorilla and iOS was the big elephant nowhere to be seen. The contenders, Microsoft and RIM, need to cook something special up to make themselves contenders again. Carriers have been neglected by Apple and Google. We can expect to see Microsoft and RIM play that card strongly.  By showing more love to the carriers and helping them become relevant again, they provide the carriers with a huge incentive to move RIM and MS products in front of customers. 

Cars + Connectivity is the new mobile
The car a 100 years ago was the first mobility play. Ford believes the combination of car + telecom is the new mobile. For a car company to be one of the keynote they must really believe that story. The middle class in emerging countries wants their own car and the freedom that comes with it. To Ford this has huge repercussions on the environment and city traffic, parking etc. that only the connected cars can address. We saw the RIM Porsche, the MS Sync Ford car, and the connected home concept integrating the car into the overall picture. Today is about entertainment, but already cars on our roads have more than 1million lines of code embedded in them so we will be getting a lot more than entertainment soon. 

Healthcare is a two headed beast depending on where  you live

The problems we have to address in the developed world are very different from those we have to address in the emerging world. The developed world is about efficiencies to reduce the costs. The emerging world is about access to the services for the population. During the talks it became clear that it's not the same innovation that is required to save people's lives depending on where you live. The realities of the emerging world are just very different than ours. As a vendor of solutions in the health space, insight based solutions design is essential for success.  

 

It's a world of BigData more than ever

It's the voluntary data we provide the applications on our phone, it's the phone collecting information for us, it's all the sensors that are also collecting data about us and it's the machine to machine data we're starting to see. The opportunity is making sense of the data in the moment. It's building the intelligence to factor in the context and combining it with past data to make predictions, and then presenting the information so that decisions can be made in the moment.

 

1b smartphones, 7b people on the planet - it's only getting started 

This is a quote from Eric Schmidt during his keynote. I highly encourage you to view it ( Eric Schmidt's MWC keynote on YouTube ). It puts things in perspective as far as how far along the mobile revolution really is. Lots of people during the conference, including Eric Schmidt, called for cheap smartphones. The word on the street is we're about 18months away from a $120 smartphone. Carriers in emerging markets are calling for $70 smartphones in order to gain serious penetration. Huge challenges remain for accessibility, and one huge opportunity.

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

Sencha Code

The code used for Ext JS and Sencha Touch is very similar and easy to recognize. Check out these code examples to see what I mean: http://docs.sencha.com/touch/2-0/#!/guide/first_app http://docs.sencha.com/ext-js/4-0/#!/guide/getting_started After working with it, it won’t take long for you to look at a piece of code and tell whether or not it’s Sencha.

2. jQuery

While jQuery is technically a framework, it isn’t as big or “framework-y” as Sencha. It’s more of a UI library that simplifies HTML document traversing, event handling, animating, and Ajax interactions. 

Use jQuery whenever you need to do something cool with your UI around menus like transitions, slideshows or fancy menus. Here’s an example of a simple drop-down menu created in jQuery: http://javascript-array.com/scripts/jquery_simple_drop_down_menu/

Unlike Sencha, jQuery isn’t used to manage models or controllers and it isn’t an all-encompassing framework that tells you how to do everything. Instead, it’s a very plugin-oriented solution that you can use as much (or as little) as you need.  

Because of its plugin nature, jQuery plays very nicely with other frameworks so it’s safe to use with Ext JS 4 and Sencha Touch. What you don’t want to do, though, is mix two mobile frameworks. jQuery has a mobile version called jQuery Mobile that is good for mobile development unless you’re using a mobile framework like Sencha Touch. jQuery Mobile and Sencha Touch have conflicting functionality and will give you a ton of headaches if you try to combine them. 

To confuse things, there’s a product out there called jqMobi which is actually different from jQuery Mobile but performs many of the same functions. I’ve never used it personally, but it can also be used for mobile HTML5 app development.  

Lastly, you may have heard of an old version called jQuery Touch. I would not recommend this as it was one of the very first solutions for mobile app development and is quite old and obsolete.  

3. Backbone 

Backbone.js is an MVC library like Sencha, but it doesn’t include widgets for creating fancy UI elements. What it does give you is a lot of really neat model control and excellent documentation. It pairs well with jQuery and jQuery Mobile because you can use their plugins to develop UI elements while taking advantage of the MVC elements present in Backbone.  

Here is a nice example of a checklist created with Backbone: http://documentcloud.github.com/backbone/examples/todos/index.html 

While it’s very similar to Sencha, I find the documentation and explanations provided by Backbone to be more helpful than those created by Sencha. While they are both large frameworks, Backbone’s documentation is much more readable and not as overwhelming as Sencha’s. 

4. Cordova

You probably haven’t heard of Cordova because up until a few weeks ago it was called PhoneGap. Keep that in mind if you go looking for Cordova tutorials because you may need to look for both Cordova and PhoneGap resources until people standardize on the new name.

Unlike Sencha, jQuery and Backbone, Cordova isn’t a JavaScript library. All of the other frameworks I’ve talked about are written in JavaScript but Cordova isn’t entirely JavaScript – it’s more of a bridge between JavaScript and native device APIs.

What I like about Cordova is that it works with any mobile framework. You can use it with JavaScript, Sencha Touch, JQuery, Backbone and JQuery Mobile – pretty much anything. In fact, it’s good to combine them to maximize functionality and give yourself a powerful framework. Using multiple frameworks with Cordova won’t make it easier to work with, but it can save you from having to develop a lot of functionality yourself.

HTML5 Innovations

In my next post, I’ll dig deeper into some of my favourite things about HTML5 and show how you can use particular code innovations to save development time. Stay tuned!

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.

Leverage the “Search” Button
In addition to a “back” button, Android devices feature a hard “search” button. Be sure to eliminate any unnecessary soft search buttons and configure your app to leverage the built-in back button.

Leverage the “Menu” Button and the “Long Press”
Android menu options can be moved off-screen to a menu that is displayed when the hard button is clicked. Similarly, secondary options can be made accessible by doing a “long press” on a control. For example, long pressing a list item is one way to obtain the option to delete it.

Design the Selected State
When a control is selected, a visual representation of the controlled state is needed for designs that incorporate custom backgrounds. Buttons, for example, may need to change color when selected, so your design will need to specify the look and color of the specified state.

Use 9-patch PNGs
9-patch images allow Android controls to automatically resize images and display them properly on an Android device.

Set Controls to Density-Independent Pixel Sizes
If your Android UI is defined in pixels, the controls will be large on some screens and tiny on high-resolution screens. To remedy this, set your controls to density independent pixel sizes so that the physical size of the control is maintained on all screens.

By tailoring your iOS design to suit the Android platform, you can ensure your ported app looks and acts like an Android app — not simply an iPhone app running on an Android phone. What’s more, you will dramatically speed up development and release of the application by eliminating the complicated steps required to replicate the iOS experience on Android.

Summing It Up

Delivering value to app users who are interacting with dozens of different Android mobile devices is challenging and requires the collaboration of product management, design teams and developers. By leveraging Android design tools and understanding the differences between the iOS and Android platforms, you can quickly design and develop an Android app that is visually appealing, intuitive and easily adopted by Android users.

Talk With the Experts

User researchers trained in User-Centered Design techniques can help you to understand your prospective Android users and how they will be interacting with your app. We invite you consult with our accredited UCD researchers and Android experts who can work alongside you to develop a UI that will maximize the value of your design across the user base. At Macadamian, our experience and proven ability to design and develop groundbreaking mobile products make us the ultimate partner to support your Android application project.

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)

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

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

• 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)

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.

What about a business analyst, software architect, design researcher, or interaction designer? What are they responsible for? Ask and you get a stunning number of different answers. The fact that every company expects different things from different roles is not, in and of itself, a major barrier to product success. What does affect success is when team members aren’t clear on their role within the team, their co-worker’s roles, and their responsibilities to one another.

First, Understand Each Other’s Goals and Motivations...

“That jerk! He just doesn’t understand what we need to do here.” While this may express a common frustration between functional groups, Steven Covey, author of 7 Habits of Highly Effective People, famously said: “Seek First to understand, then be understood”. In a nutshell, to work as a team, all groups must understand each other’s goals, motivations and priorities.

The following generally hold true from company to company:

Product management is responsible for the overall success of the product in the market. This can be tied to product revenue, or simply getting a product out the door that satisfies a particular set of business requirements.

Designers are looking to design the best possible experience for the user. This group is measured on design success and, to some degree, product success in the market.

Developers are measured on speed and quality. They need to deliver on time and on-budget and their code needs to be bug free (which only adds to the on-time problem, since bug-free code takes time).

Understanding these main differences is key. Developers aren’t pushing back on feature requests because they’re stubborn, but because they’re responsible for maintaining timeline and quality. A designer doesn’t look to change the design “yet again” because he gets a giddy thrill each time he pushes out the timeline—it’s because he needs to make sure that users will love the product.

To ensure your teams understand each other, consider investing in basic training around each others’ disciplines. There are a growing number of experienced consultancies that offer half or day-long seminars for product teams on this very subject.

Focus on The Gray Areas

Since product managers are ultimately responsible for the success of a product in the market, we recommend they take the lead on clarifying roles and responsibilities throughout the team, ensuring team members are each put into a position where they are maximizing their strengths.

For example, though product managers often take on the development of personas as well as requirements and workflow definition, these are all specialties of trained design researchers. Effective delegation of these tactics to the design researcher will free up more time for strategic business-level product planning.

What about the design? Who has the final say? In our experience, there needs to be a lead designer who takes feedback from the team and uses his or her experience and judgment to make the best design decision for the good of the product. This doesn’t mean the designer “takes over” product management, which is the last thing we’d recommend. It also does not mean the designer should ignore technical considerations. Instead, the lead designer should “own” final design decisions in the same way that your chief architect or lead developer likely has the last say on challenging architecture decisions.

And what if a particular feature will impact the timeline? Who decides if it is in or out of scope? We’ve often seen this call made by the development team, but ultimately we believe this is a product management call. The product management team should decide whether to ship late with a fuller scope, or earlier with a limited scope.

To ensure all team members are clear on their respective roles, we recommend writing out a list of these responsibilities. Before the project begins, determine who the team will count on for each deliverable so you can avoid arguments down the road and committee decisions that ultimately slow down the process and hurt product success.

Ultimately, what’s truly important to the organization is revealed at the top. Organizations serious about delivering acclaimed products in the market often invest in a VP of Product Management who is separate from the Marketing department.

A more recent trend is the addition of a VP of User Experience (like myself). This VP ensures emphasis is placed on the user’s overall perception of the product during use. The best way of growing business is through referrals from satisfied users.

If you are a GM or CEO reading this post, who is on your management team? Does it reflect the priorities you have for software product success?

Key Takeaways

• Product Managers, Designers and Developers are evaluated differently on product success.
• Each function needs to understand the others’ motivations through communication and training. • Agree upfront on roles and responsibilities of each function within the product context.
• Focusing primarily on the gray areas where there is overlap (product management / design researcher, interaction designer/software architect, etc.).

Further Reading

• Did you bring a knife to a gun fight? Three reasons your UI design investment isn’t paying off. (Macadamian)

   

• Living in an Agile World—Product Management when Development Goes Agile. (Johnson)

   

• This post is part of a larger whitepaper: How to Get Amazing Software Out the Door Fast

Here is my new model:

• layer 0 - hardware is relevant again - no more only beige boxes with a different brand sticker. The innovation on phone hardware is very real and happening with hardware and sensors integration.
• layer 1 - this is the platform - one heck of a battle is brewing at that level and competition is going to get more fierce.
• layer 2 – the services – caught in between layer 1 and layer 2 because some will be coming from the platform, and others will be from the outside, independent services. This is the new kid on the block for me, I didn’t realize it could play such a big role as to have its own layer.
• layer 3 - the app layer –  lots of innovation happening making everyone’s head spin already, and it’s only starting. Connectivity and BigData working hand in hand is bound to yield a lot more to make our lives better.

From where I sit – here is what I see – 
No ones owns the full stack and it’s really a good thing. Competition is good. I think the battle for the platforms and ecosystems is only starting with MS entry and to some extent RIM’s unclear way forward. It’s going to get ugly. The platforms are after my data; they want to lock me down. The applications are after my data too - do they want to know me to ultimately sell me more stuff. Owning the data and collecting analytics about me rhymes with loads of cash for those guys. An independent service layer is a really good thing, as long as there are many providers of services.

• Think dropbox getting bigger and offering more than file sharing, like they are tipping their toe in with the mobile photo upload sync released recently. I hope this will force the hands of Google, MS, and Apple, just like apps developers to integrate dropbox like they would integrate Flickr.
• It’s a source of innovation; more services can be created that will collect specific data from the ever growing list of sensors we are using.
• It also had the drawback that it’s now one more place where data is going to be collected about us.

Overall, the independent services layer is good because it creates alternatives at a critical point in the stack. It gives power to the mobile user, me, to choose where my data should go. It also makes it more difficult for one vendor to own the whole stack, and have way too much power over what advertising and suggestions I’m being pushed to through my mobile behaviors.

Android UI Controls

Android provides a number of standard UI controls that enable a rich user experience. Designers and developers should thoroughly understand these controls because they are faster to implement and ensure good performance. By implementing standard controls, you can eliminate the need to test, revise and improve custom controls. Creating a “clean” custom control from scratch can take a significant amount of design and development time. Google, however, has already thought about these interactions and developed standard controls to properly address them.

Android users expect standard controls. Through their interactions with other Android apps, users become accustomed to Android’s standard controls. Deviating can confuse and frustrate users, making them less likely to want to use your app.

Activities

Android applications are composed of “activities” which are unique, focused actions a user can take. Because it can be difficult or time consuming to scroll, zoom in, or click links on a small screen, it is recommended that an app display only one activity per screen. While a screen can expose multiple tasks, it should help the user complete just one activity at a time.

User Interactions

When a user first downloads your application, he will make snap judgments on the usability and intuitiveness of the application within the first few minutes of use. So it’s crucial to balance the creativity of your app with the standard Android user interactions These include:

• Hard buttons: including Back, Menu, Home and Search buttons. Soft buttons that duplicate these features will only confuse or frustrate Android users.
• Long press elements: Items of a list can be long pressed to open a context menu that provides secondary information.

Layouts

Android UI screens are frequently resized, both on the fly via pinch and zoom as well as at startup when Android adjusts the size of the UI to fit the screen. In order to make the most of the screen size and handle this resizing gracefully, Android provides a number of screen layout options. First, Android developers must specify whether each screen should follow a linear layout (the most common) which manages controls in a horizontal or vertical fashion, or a relative layout which manages controls in relation to one another. A relative layout defines the position of controls by their relationship to other components on the same screen.

Android also offers specific layout properties to control the way in which screen elements are displayed across Android devices and during use:

• Weight: allows the developer to determine how free space is divided on the screen.

   

• Gravity: the term used for control alignment (right, bottom, top, or left) on an Android device.

   

• Density independence: Your application achieves “density independence” when it preserves the physical size (from the user’s point of view) of user interface elements displayed on screens with different densities. Without density independence, a UI element (such as a button) will appear larger on a low-density screen and smaller on a high-density screen.

So who specifies all of these properties? In our experience, best practice is to have the designer document the layout and resize behavior of each screen to the development team via a series of wireframes, if not a full style guide. The designer should then stay in close communication with the development team as the developers work to determine the right combination of Android layout properties to realize the design.

Screen Size

A common misconception is that an Android app should be designed to support only a specific set of Android devices. In reality, Android offers you tools needed to develop a visually impressive interface that supports the full range of devices and screen sizes on the market.

To help you accommodate the range of Android screen sizes, Android recommends designing four versions of the application UI:

• A small version for screens under 3”. • A normal version to accommodate 3” to 4.5” screens.

   

• A large version for viewing on 4.5” to 10” screens.

   

• An extra large version for devices with screens larger than 10” (tablet).

It’s not strictly necessary to create a design for all four versions – in some cases; one “normal” and one 'extra-large' version may suffice.

Fragments

A smart phone should only display one activity per screen due to its small screen size. Tablet devices, however, offer additional screen real estate and are often used in a similar setting as a desktop or notebook, meaning the application could show more information at once on the screen. Using an Android construct called fragments, designers and developers can merge portions of the UI onto one large screen or split them into individual screens for use on small screens. This can help to reduce the number of interactions a user must perform on a device with a large screen and eliminate wasted space.

If you anticipate your app will someday be used on a tablet device, we strongly recommend you incorporate fragments into your design. By designing custom, reusable fragments for each screen activity at the beginning of the project, you can eliminate the need to create an entirely new layout for a tablet device.

Intents

Android applications typically borrow from other applications already on the device. Using intents you can simplify both the programming requirements for your app and offer simpler, less cluttered screens.

If your app needs to perform a function beyond its core abilities such as opening a photo, looking up a contact, etc., the team should investigate whether a tool that can perform that function already exists in the OS or in a popular third-party app. If so, you can leverage that functionality using intents.

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)