So you have an existing piece of PC software or even a website and you want to port it to a modern app. Sounds easy, right? Not so fast, Tex. The mobile experience is a unique one and it requires you as an app developer or designer to practice restraint in how you port that web or traditional desktop app over. In this post (the third in a series) we will discuss some of the things you need to think about if you are bringing web or desktop software assets to the mobile form factor, whether that be the tablet (i.e.: Windows Store app) or a smartphone app.
Throughout this blog post series so far (Part 1 is here and Part 2 is here; this is Part 3) we have discussed the concept of Consistency of Experience. In a nutshell, it basically means that if you have an app and you intend to port it to a different screen form factor (or different platform for that matter), the wrong thing to do is copy the entire UI from the original form factor to the new one. You should be focused on bringing the right UI to the form factor while maintaining a consistent experience across those two apps. So, if you have an existing desktop app or website that you are converting into a Windows Store app or Windows Phone app, you need to consider the idea of UI Refactoring.
UI refactoring is the process of taking an existing user interface and studying how it is used in context of its current form and how users would interact with the UI in a different form factor. I have already stated that the constant in this process is the experience. The spirit and personality of the app in question should remain intact after porting it to another form factor or platform, even though the UI should very likely look different. When thinking about UI refactoring, there are a few things you should be considering through the process:
To better illustrate each of these points, I will use a mocked-up example as a “virtual” case study for some of the things you should consider in a refactoring exercise.
Yes, I’m pulling the Contoso card out (if you don’t know what I’m talking about, Contoso is a fictitious company name that is often seen in Microsoft demos). Let’s imagine that the premier stock site today is Contoso Stocks and that it is a website for investors to use to create portfolios of stocks to buy and trade. It’s a fully-featured stock site and has many subscribers. Users must log into the site to access their portfolios and once signed in they can do a number of things including:
Below is a screenshot of a page on our mocked-up Contoso Stocks site:
Ignoring the fact that this is likely the ugliest site in the history of consumer stock trading, let’s review the UI in terms of information. The reason why this is key is because the refactoring process is driven by the information you want to get across to the user on the target form factor and how that user will make use of the information. In terms of this screenshot you can see (in broad terms) the following use case scenarios:
That’s a pretty busy screen! Having a busy screen is not necessarily a UI sin, however – again it depends on the scenario and the expectation that a user may have in how to use the software. A good example of this would be a call center application. Typically, call center applications that are used by telephone customer service agents are very busy as it allows the agent to fill in information to a wide variety of fields in a minimal number of clicks. In that kind of scenario, the goal is to minimize clicks and maximize tab use to flip through textbox fields. In this context, a call center agent is able to tab through fields and type information into them very quickly with the intent of minimizing the time an agent is spending with a customer (often, call center performance metrics are measured in average time on a customer telephone call). If you search the web you can find many examples of screens that are extremely busy yet are quite adept at getting the job done.
With all that said, however, that does not mean that your new app version of the Contoso Stock site should be that busy. Remember that your target user is the typical day trader, someone who comes and goes frequently to do one specific thing (like make a quick stock trade) and then gets back to his or her day job. With this in mind, let’s do an exercise in determining the right way to think about building a Windows Store app version of this site.
Windows Store apps are unique in their look and feel, making use of Microsoft’s Modern UI. While many people can now recognize and identify our Modern UI, one of the best kept secrets about this new UI paradigm is that its purpose is to evolve apps to have truly great information architecture (or information design). The intent of a Windows Store app is to make it as easy as possible to make a decision from the information presented in from of him or her.
With that in mind, let’s brainstorm a way to make the page from the Contoso Stocks website pictured above into an appropriate UI for a Windows Store app. The first step is to review the scenarios supported on the website page (which we listed above). For a Windows Store app, the number of scenarios that this web page supports seems to be a little much, particularly with the intent in providing the user with useful information quickly. As a result, let’s make the decision to break up the number of scenarios supported by this one web page into several screens for the Windows Store app.
Here is a reasonable breakup of information (each major bullet point would be a section of a Windows Store app):
Here is an example of a rough layout for what the My Portfolio view of the Windows Store app might look like (in full transparency I borrowed some of the assets on the screen from the Bing Finance app, which is a great example of a very good Windows Store app experience):
You can see how the information is clean, not busy and allows the user to understand the health of the portfolio at a glance. You can also see how a separate scenario (transaction history for the portfolio) can be accessed by simply scrolling to the right yet still part of the same screen. You can also see how the app bar at the bottom of the screen (visible only if the user swipes the screen from the bottom or right-clicks on the screen with a mouse) adds extra functionality to the screen without getting in the way of the information.
I also want to bring up another tip that you might have noticed in the new scenario listings above. The Search screen and Account Settings screens aren’t actually screens in the traditional sense for this example – they utilize components of the Windows 8 platform called charms (in this case, the search charm for the Stock Search screen and the Settings Charm for the Account Settings screen). this is an example of how the Windows Store app makes great use of the built-in features of Windows 8 and conforms to the standard UI guidelines for building Windows Store apps.
Great examples of how this is done in the Bing Finance app are shown below:
In the image to the left, note how the Bing Finance app has implemented the search charm to contextually add search to the app without having to create a “search screen” for the app itself.
When a user wants to search for a stock inside the app, he/she simply swipes from the right of the screen (or presses WINDOWS+C or moves the mouse to the top right of the screen), selects the magnifying glass (i.e.: search) from the charms bar that appears and voila – contextual search capability for the app via native OS integration in Windows 8.
If you are interested in learning more about implementing contextual search capabilities for your Windows Store app, you should start here. Likewise, if you are intent in using account settings integration via the charms bar in your app (which you should if you have app settings to share with the user), you should start here.
So now that I’ve shown you an example of how to refactor one screen to fit the form factor of a Windows Store app, let’s take a look at how a Windows Phone app experience for Contoso Stocks would like like. First, we need to refactor screens to the smartphone form factor to create an effective information design for the user.
As you can see, the screens are somewhat similar yet the implementations are different as referenced in the example images below (using the Sketchflow technology for rapid prototyping). Basically, by using a Pivot Control for Windows Phone (not found in Windows 8 which used grid controls as a rough equivalent), you can separate information according to scenario for each screen.
In these 3 screens (Portfolio, Stock Detail and Buy/Sell Stock, respectively), you can see that multiple scenarios are managed through the Pivot control. The app bar on the portfolio screen shows a search button that is used to search for stocks. So, as you can see, the UI has been refactored not only for a smartphone screen but also making use of the Windows Phone features to make the experience enjoyable and effective.
While we have only scratched the surface on the subject of UI Refactoring, you can clearly see how powerful the process is in turning an app or website into an effective Windows Store app or Windows Phone app by thinking through the various use cases/scenarios and understanding (and leveraging) the unique native features of the platform.