The debated example

In the comments of the aforementioned article, many of us started rewriting the following example if...else block.

const wow = arg => {

  if(arg === "dog"){
    return "LOVELY";
  } else if(arg === "cat"){
    return "CUTE";
  } else {
    return ("gimme an animal");
  }
}

wow("cat");  
//-> "CUTE"

While the example was fine for demonstrating the author's point (we picked it apart anyway because we'll rip apart everything but our paychecks), it does present a few opportunities for improvement.

Else if, else if, else if

The first issue is that whenever a new condition is needed, a new else if clause must be added. So if you wanted to say "AWESOME" in response to "pony", you'd need to adjust the code as follows:

const wow = arg => {

  if(arg === "dog"){
    return "LOVELY";
  } else if(arg === "cat"){
    return "CUTE";
  } else if(arg === "pony"){
    return "AWESOME";
  } else {
    return ("gimme an animal");
  }
}

wow("pony");  
//-> "AWESOME"

This would be repeated for every new animal and makes for very brittle, difficult to test, code.

The conditionals

Rather than using so many if...else if blocks, one could rewrite the function with conditional statements. Here is a comment from the linked article demonstrating this approach:

const wow = arg => (  
  (arg === "dog" && "LOVELY") ||
  (arg === "cat" && "CUTE") ||
  "gimme an animal"
);

wow("cat");  

There are no if statements present, but you are still left with the original maintenance issue. That is, you'd need to add an additional condition for each new animal.

The Data Map

One way to eliminate this growing set of else if statements is to store your relationships in a map. Consider the following:

const animals = {  
  dog: "LOVELY",
  cat: "CUTE",
  pony: "AWESOME",
};

const wow = arg => {  
  return animals.hasOwnProperty(arg) && animals[arg] || "gimme an animal";
};

wow("pony");  
//-> "AWESOME"

Here, we've replaced the if...else statement with a lookup in a data map. With this, we have drastically simplified the wow function and we no longer need to modify it when a new animal comes along.

Before continuing, I'd like to point out that removing if statements is not the point here. The point is to make your code less brittle and easier to maintain. The latest iteration of this example could just as well have been written as follows:

const animals = {  
  dog: "LOVELY",
  cat: "CUTE",
  pony: "AWESOME",
};

const wow = arg => {  
  if(animals.hasOwnProperty(arg)){ //WTF if, who invited you?
    return animals[arg];
  }
  return "gimme an animal";
};

wow("pony");  
//-> "AWESOME"

Going further...

You might look at the above and declare "But I still have to change the code! What's the difference?" I wouldn't fault you for that. So in this section, I will do a bit of restructuring in order to drive the point home.

First, let's abstract out the data.

//file: data.js

let animals;

//Let's pretend this is really being loaded from the database
//Let's also pretend the load is synchronous so we don't have
//get into a discussion of async/await or the Promise api
const loadAnimals = () => {  
  animals = {
    dog: "LOVELY",
    cat: "CUTE",
    pony: "AWESOME",
  };
};

const getAnimals = () => {  
  if(!animals) loadAnimals();
  return animals;
};

export default getAnimals;  

In this module, we are faking a database. The public getAnimals method will return the data from our datasource. Remember, the entire animals structure lives in the database, so modifications to it would happen there rather than in this file. For the sake of this discussion, let's pretend that data.js is the database.

Next, we implement our wow module.

//file: wow.js

import getAnimals from 'data';

const wow = name => {  
  const animals = getAnimals();
  return animals.hasOwnProperty(name) && animals[name] || "I'm sorry Dave, I'm afraid I can't do that";
};

export default wow;  

Notice here we import the data module and use it to grab the animals structure. Then, just as before, we either return the greeting (if one is present) or the silly string if no animal is found that matches the specified name.

The important point is that even if the set of animals changes or the greeting for each animal changes, this module does not need to be modified. That makes it much more maintainable since modifying or adding animals becomes an issue of data entry rather than a coding change. Your unit tests are greatly simplified because you need not test a branch per animal. In fact, you'd get 100% code coverage in this unit with just the following two tests.

• should accept a name and return a greeting for the specified animal.
• should return I'm sorry Dave, I'm afraid I can't do that if no animal matches; because all error messages should sound like a computer that sounds like a human trying to sound like a computer that sounds human.

Finally, you'd import and use this module from somewhere (here we'll just use index.js).

//file: index.js

import wow from 'wow';

wow('pony'); //-> AWESOME  
wow('horse') //-> gimme an animal  

Conclusion

Look, I'm not here to tell anyone how to code. I don't believe there is anything fundamentally wrong with using if statements. I absolutely don't believe in absolutes. I'm sure that last sentence harmed the same cat Schrödinger locked in that box. Did he ever answer to PETA for his actions?

Anyway, based on the needs of your project and your ability to convince the coding zealots you work with to turn a blind eye, you can likely get away with stringing a few if...else if...else statements together and shipping it. However, there are alternatives that will enhance the stability and testability of your code. This article points to the tip of that particular iceberg. If there is interest, I'll look into writing more about this and exploring some other popular patterns that can help. If not, just tell me to go to that place where that guy's cat was half of the time. Hell. I'm talking about hell.

Introduction

Early in 2013, I took on a client in need of help with a mobile solution that was currently in production. There was a long, growing, list of bugs and feature requests that needed some attention. After an initial set of "quick win" bug fixes, a closer examination of the application showed that all of the complaints and most of the bugs revolved around a user experience in need of improvement. In this article, I'll talk about a few of the things we focused on to begin turning things around for the users of this mobile application.

Background

Before getting into the solution, lets take a quick look at the original versions and review some of the issues.

This client, a SaaS company, built a work order processing system used by technicians to keep track of, and perform maintenance tasks on energy-related hardware in buildings. For example, a Dishwasher in the 3rd Floor Kitchen may need its drive chain inspected on a monthly basis. This work order would automatically be scheduled and routed to the appropriate technician. From there, the work order can be managed by the technician from his/her mobile device.

Initial Stack

Because of the need to run on both iOS and Android, the initial version was implemented as a hybrid application using Apache Cordova and jQuery Mobile. Plugins from both communities were used to handle things like scrolling, barcode scanning, etc. All things being equal, this stack works well for many applications.

Top Issues

Unfortunately, there were some design/implementation choices as well as some business requirements that negated some of the benefits of this particular hybrid approach. At the top of issues list were the following:

1. Scrolling was unreliable on many Android devices.
2. Overall performance suffered due to the chatty nature of the app and the need to keep re-rendering screens in order to keep the DOM's size to a minimum.
3. There was not a consistent theme to the UI due to the mix of plugins used to resolve some requirements.
4. Planned features, while possible with the current stack, were proving to be more and more time consuming to implement.

There were lots of other, more specific, bugs and feature requests, but most of the complaints were related in one way or another to these issues. With enough time and some very clever tricks/hacks, the first three items in that list could be reasonably resolved. The fourth item, however, would always be a challenge.

Constraints and Requirements

As with all projects, there are always constraints within which we must work. In this particular case, the following constraints and requirements were imposed for reasons beyond the scope of this article:

1. The App must remain "familiar". While some retraining was expected, the overall "feel" of the app must be similar to the current implementation.
2. Increase overall performance with a focus on resolving issues with scrolling, screen rendering and data reloading.
3. Keep users informed of their work orders. The key here was to do this in a timely and convenient manner.
4. Create a path to easily implement a growing list of features.
5. While the backend services could be tweaked, a major overhaul was out of scope.

One additional thing to keep in mind is that this app, while available in the App/Play stores, is not targeted towards everyday users. Rather, it is meant to be used by service technicians working in properties that use the specific SaaS solution provided by this client.

Solution

For the solution, we decided to focus on the following 7 ways to improve the app's overall UX:

1. Convert to a Near Native app
2. Reduce Chattiness
3. Build a consistent UI
4. Take advantage of the "glance"
5. Scroll less; Search/Filter/Sort more
6. Smarter Push Notifications
7. Let analytics drive each iteration

Let's take a look at each of these.

Convert to Near Native

Since issue #4 above had such a negative affect on the overall future of the app (which included any solutions to the previous issues), we decided to start there. The most radical change to the app was to move it from Hybrid to Near Native. While this was an expensive proposition, in this case, it would have been more expensive to continue down the original path.

We used Appcelerator's Titanium to build the new app so that we could take advantage of its impressive cross-platform features. This gave the app an instant performance boost across both iOS and Android. It also set us up to easily tackle the remaining core issues.

Converting to native can improve your {#}UX.

What the user got here was a much more responsive and fluid application that felt like it belonged on their device; no uncanny valley issues here.

Reduce Chattiness

A major cause of frustration and performance issues in the app were the repeated server calls for the same or similar data. Normally, these repeated calls are made because they represent an "easy path" solution to a common problem. For example, say you have a list of orders in one view which transitions to an order detail view when an item in the list is selected. If the user is allowed to make changes to the details, it is often easier to simply refresh the entire list from the server in order to reflect that change back to the list.

Obviously this is not ideal and there are lots of solutions to this problem. We chose to use the observer patternThe Observer Pattern provides a mechanism for changes to be automatically reflected to all observers of a particular record.. Naturally, the modifications themselves are still sent to the server. However, there is no longer a need for the app to request all records just to update the list screen.

We were also able to take advantage of the fact that most of the work order related data is "owned" by a technician once accepted. This allowed us to maximize the offline use of the data until it is transitioned to a state that requires public access once again. Much of the supporting data (assets, locations, etc) changed infrequently enough to be used in an offline state upwards of 95% of the time.

For the user, this meant extremely performant screen renders and transitions. It also created a much better experience for those who worked in areas with limited connectivity.

Boost your {#}Mobile {#}UX by adding offline capabilities to your {#}app.

Build a consistent UI

Another area we found to be a source of confusion was the lack of a unified design language across the entire UI. Sometimes the culprit was the collection of plugins used the build out certain screens. In other cases, some views seemed to have been designed and developed with very little knowledge of the design language used in others. This created a somewhat chaotic experience for the user.

Agile's natural allowance for rapid and frequent course corrections gave us the ability to quickly iterate through the UI design until the right design language presented itself. We simply started with the home view (one of the most used views in the app) and implemented a new design. As we included additional views, the previous set of views would be iterated upon if the current view required some design language changes.

A consistent {#}UI increases your {#}mobile {#}app's {#}UX.

What users would experience here were views that got out of the way; leaving them to focus on their current context rather than having to understand how to interact with a particular view.

Take advantage of the "glance"

While working on UI consistency, we also worked on removing as much clutter as possible. For lists, we reduced the amount of information in each row so that there was just enough for the user to identify the item being presented. This gave the user more rows to choose from while making each row more understandable in less time.

The above image is an example of the request list from both versions of the app. In addition to showing twice as many requests in the native version, we made an additional 3 of the 4 most important bits of information glance-able ("status" already stood out in the original app).

For this and all views, we worked on streamlining the presented data. We focused on answering the following two questions in order to determine what to display, when to display it, and how it should be presented:

1. Is this item absolutely needed on this view?
2. If so, can we (and should we) present it with a visual clue rather than purely as text?

{#}UX Tip: Stop forcing users to “read” your {#}Mobile {#}UI.

This resulted in a UI where late items or high priority items could be quickly identified with a glance; as opposed to having the user "read" everything.

Scroll less; Search/Filter/Sort more

Scrolling through hundreds or thousands of records has never been the best way to find something. Imagine a reference book written as one very long page. Finding something in the "M" section would be tedious. We've moved away from this practice with most things. Books provide a table of contents and an index, tapes have taken a back seat to direct access media, etc.

The "Scrollable UI," however, has remained as one of the primary ways of presenting long lists. They are relatively easy to develop, but present usability issues for our customers.

While we didn't removed them completely from the app, we limited them to somewhere between 50 and 200 records depending on the data being listed. We then augmented those lists with full text searches, filters and sorters. The idea was to guide users towards looking up their data and managing the results rather than "flicking" through a very long dataset. We also provided cross-referenced data to further reduce scrolling. For example, a user viewing a piece of equipment in a building can go directly to the work orders for that asset with the tap of a button.

For a better {#}mobile {#}UX, Scroll less; Filter/Search/Sort more.

So far, this has worked out nicely. Users are usually able to get within 10-20 records of their desired item. Since these particular users tend to be familiar with the data, many of them are specific enough in their searches to produce results that are one or two records long.

Using native components made the lists (and everything else) extremely fast by default. With these augmentations however, users get to their data in even less time.

Smarter Push Notifications

Because of their time-sensitive nature, users need to be informed when a new work order has been assigned to them. In the initial version of the app, Comet was used to push alerts to the user's device. This was problematic because it would only work while the app was front and center.

One of the quick wins came from adding Push Notifications. However, due to some technical issues with the early app, these notifications were very basic and did nothing more than launch the app when activated.

Focus on {#}UX when implementing {#}Push {#}Notifications.

In the redesign, we focused on smarter use of Push Notifications so that data is preloaded before alerting the user in many cases. The user is taken directly to the appropriate view when reacting to a notification rather than simply being dropped onto the home screen.

Naturally, Push Notifications provide a great way to keep users engaged. However, properly designed notifications can go a long way to improving the overall user experience as well.

Let analytics drive each iteration

We took some risks by implementing some of the solutions above. In some cases, we changed how the user interacted with the app (as with our list modifications). At the end of the day, there is no absolute way of knowing how well these changes will be received before the app has been delivered. What we can do however, is track what happens after delivery.

Improve your {#}mobile {#}UX via repeated analytics-based adjustments.

Because we used an agile process with a plan to release often, we can rely on analytics to let us know what we got right and what needs adjusting. What better way is there to increase user experience than having the users themselves tell you? So we track everything we can think of and we use this data as part of the planning process for the next release. We then repeat the process after that.

Conclusion

With all of this, a framework has been put in place that is flexible enough to accommodate future requirements. More importantly, the overall process for the continued development was change to one that focuses first on the user's experience. The reception has been great. The app is not perfect, but there has been a notable turnaround in how the users interact with it and how they feel about that interaction. To quote one user:

The most recent update is head and shoulders above the previous versions...Lots of small quality of life fixes...No doubt big improvement.

What say you? Have you used any of the above tips in the past? How do you keep UX at the forefront while building your apps? Sound off in the comments below.

Introduction

Over the years, there has been a war raging between two mobile camps. In one camp, you have the "Native or Bust" population. On the other side of the fence are the "HTML5 Rocks" guys. As with all things, the best answer tends to be a needs-based compromise between extremes. When discussing this with colleagues, one question almost always comes up. "When should I use a hybrid vs a native solution?" In my #ThinkMobile presentation, I discussed the advantages and disadvantages of these two app types. Additionally, I gave an overview of the 5 "app types""App" is used loosely here to include both traditional and mobile web. found in today's market.

There are 5 types of mobile apps. Successful developers must know when and why to use each.

So what are the 5 types of mobile applications and when is each appropriate? Let's get into it.

Traditional Web

First up is the traditional website. A traditional website isn't mobile, is it? There was a time when it wasn't. Before 2007, standard websites were almost completely incompatible with mobile devices. Sure there were a few browsers that sort of rendered a version of basic websites, but the experience was horrible. When Apple introduced the iPhone in 2007, it made the traditional web a first class citizen of the mobile world. The new experience was not perfect (no Flash, for example), but it was almost as good as the desktop experience for the first time.

The good news here is that you probably already have one of these. If you don't, they are relatively easy to build. The bad news is that, compared to the other solutions discussed in this post, traditional websites offer the worst user experience. "Pinch to zoom" seemed like a brilliant concept at the time, but it quickly becomes a pain when browsing the internet. Additionally, these sites were likely not built with mobile in mind, so there are lots of missed opportunities when it comes to using the device to fully engage your users.

Traditional websites offer the worst user experience of all mobile solutions.

So when should you use this approach? In short, you shouldn't. I'm not saying you should never build a traditional website again; just that you should not consider it to be your "mobile" presence.

Mobile Web

Traditional websites, while easy, are lacking when it comes to mobile user experience. One of the quickest fixes for this is to convert your site to a mobile web site. In fact, if you're going to redesign your site for mobile, you should make it a responsive website (so that it presents the best experience for both mobile and desktop).

Despite the fact that traditional websites, for the most part, render fine on mobile, the mobile web is really the most basic solution you should consider when developing your mobile strategy. The advantages here are that it's just as easy to develop as a traditional website, but presents a far better user experience. You also get to target the widest possible audience since the vast majority (if not all) smartphones will support it. You can take advantage of many mobile device features to fully engage your users. There is even support for offline functionality that you can use if needed.

The main disadvantage of the mobile web is that you are at the mercy of the browser.

On the other hand, your main disadvantage is that you are at the mercy of the browser and unfortunately, not all browsers are equal. If you've been a developer long enough, you'll remember the browser wars on the desktop. Things might not be that bad anymore, but there are still quite a few inconsistencies to deal with.

Go with a mobile web solution when:

• you are looking for the least expensive way to target the widest audience.
• you wish to avoid dealing with the various app stores.
• you must support e-commerce and don't wish to share your profits with today's mobile platform vendors.
• you do not have very strict Data at Rest security concernsData at Rest is an IT term referring to inactive data which is stored physically in any digital form (e.g. databases, data warehouses, spreadsheets, archives, tapes, off-site backups, mobile devices etc.)..
• you are not concerned with having your code in the open.

If none of the above apply to you, perhaps you need a hybrid or native solution.

Hybrid Apps

Until now, the mobile solutions discussed above are not what the general public would consider a mobile app. There is nothing to install with those other solutions and not much you can do with them if you need deeper access to the mobile device.

This changes with Hybrid apps. These are generally web applications, wrapped inside of a mobile app. The mobile app wrapper itself uses a web viewer (basically a scaled down version of a browser) to display the web pages. Naturally, your web pages are developed with the same technologies you'd use for both the traditional and mobile web; namely, CSS, HTML and JavaScript.

With hybrid applications, you get all of the advantages of the mobile web and many of the benefits of having an actual app. While you are still at the mercy of the browser for rendering and overall performance, you now have the power to dive into the device's API for additional functionality.

Be aware of the uncanny valley when building hybrid apps.

The downside of the hybrid approach typically centers around the UI and performance. Since you are not using native controls, you have to create your own (or use a packaged set). Many of the packages today tend to have a strong bias to a single platform. While you can target many platforms, your apps tend to look like they were written for one platform only. For example, both Sencha Touch and jQuery Mobile defaults to an iOS-centric look. The same app running on Android or Windows Phone seem like they've been ported over, rather than written for these platforms. Additionally, the components tend to leave your app in the uncanny valleyThe uncanny valley is a hypothesis in the field of human aesthetics which holds that when human features look and move almost, but not exactly, like natural human beings, it causes a response of revulsion among some human observers.See Martin Fowler's post for information on the uncanny valley as it relates to hybrid mobile apps. There are many hacks that developers have come up with to get over the performance hurdle. Some work; some create more maintenance issues than they are worth.

A hybrid solution is right for you if

• your target users are spread out over most of today's mobile platforms.
• you want to leverage the various platform-established stores for distribution, payments and in-App commerce.
• you need more access to device APIs than is afforded by the mobile web solution.
• you have Data at Rest security requirements.
• you don't have very high performance requirements.

Need even more power? A native solution may be your best bet.

Native

Native apps give you access to everything there is for a given platform. These are typically the best performing mobile solutions available today. When going over this particular option with my clients, I break it down into two categories; Native and Near Native. Let's take a look at each one.

Native Apps

Again, native apps give you access to everything under the hood of your chosen platform. These apps are written in the language specified by the platform (Objective-C or Swift for iOS, for example). While 3rd party libraries are often used, no part of a truly native mobile application is written in a language that is foreign to the platform except in one situation. There are times when you need to display a webpage in your app. The content of that webpage might be extended functionality written in HTML, CSS and JavaScript. In fact, it is this very approach that is used by the hybrid solution discussed above.

Consider a native mobile solution when performance and security are paramount.

Performance, security, API access, native look and feel are all enhanced with native solutions. Almost everything is better. The downside comes into view when you need to target multiple platforms. You often can't reuse code, so this can be an expensive proposition for some situations.

You should consider a native solution when

• you have a critical need in the area of performance and/or security.
• you need access to the full range of device APIs for your selected platform (or at least much more access than is typically available for hybrid solutions).
• your UI's platform fit is crucial to your success.
• you are only targeting a single platform.

Near Native Apps

Often, the requirements for a mobile app include those of a native solution plus the need to target multiple platforms. This is where the near native solution can be a perfect fit. Near native apps have their business logic core written in a language other than that which is provided by the platform. In this regard, they are similar to hybrid apps. However, the UI and almost every other aspects of the app makes full use of native components and APIs.

Apps developed with Appcelerator's Titanium are great examples of this. They are written primarily in JavaScript, but make use of all native components. The end result is an app that can be targeted to multiple platforms but run natively on each. This means your app looks and behaves as though it was built specifically for the platform it is running on.

Near Native Mobile Apps: All the benefits of being native, plus the ability to go cross-platform.

The big win here includes almost all of the full native advantages plus the cost reduction resulting from a very high percentage of code reuse across platforms. For this, you sacrifice a small amount of performance in some cases. You also may not always have access to 100% of the native APIs. This last part is mitigated by the fact that you can usually extend these solutions to include anything that is not included in your chosen near native framework.

A near native solution is a good fit when

• you have a critical need in the area of performance and/or security.
• you need access to the full range of device APIs for your selected platform (or at least much more access than is typically available for hybrid solutions).
• your UI's platform fit is crucial to your success.
• you are targeting multiple platforms.

Conclusion

So there you have it. When it comes to having a presence in the mobile space, there are really 5 basic solutions. Though Apple and its iPhone made traditional websites much more usable on a mobile device, the user experience is severely lacking compared to the other solutions.

When working with clients, I tend to start the evaluation process with the near native solution front and center. This is because it offers what I believe to be the best compromise when considering API access, cross-platform requirements, performance and security. From there, I work with them to move toward a Hybrid approach or full native depending on their needs. I mostly hold off on recommending a mobile web solution unless there is a specific need to avoid distribution via a platform's store.

What's your approach? Do you have other reasons for picking one solution over the other? Let us know about them in the comments.

Quick Review

As a review, I wanted to list some of the take-aways from this presentation.

The Platform Myth

There is no one "best" platform. Rather, what you need to look for here are the platforms that best meet your needs. The reccomendation is to find out which platforms are used by your target audience and do a cost-based analysis for each group.

As an example, a couple of years ago, a client requested a cross-platform app that would run on both Android and iOS. Upon completion, they wanted some advice on adding BlackBerry to the list of supported platforms. After taking a closer look at the users they were targeting, we came to realize that less than 3% were active BlackBerry users. Waying this against the cost of supporting the additional platform drove them to decide to allocate their funds elsewhere.

The Native vs Hybrid Debate

As with selecting a platform, you pick what's best for your situation here. If you absoluetly must support the widest range of platforms, a hybrid app may be the best choice. However, you'll need to carefully consider whether you will need lots of features that are best served by a native approach.

Don't be afraid to consider a mix here. By that I mean, it's ok to go with a native or near native solution for the platforms that are used by the vast majority of your users. You would then follow that up with a hybrid (or mobile web) solution that provides reduced functionality for the other platforms. You would be increasing your development and support costs with this approach, but it could pan out to be worth it for certain situations.

Get more details on the 5 mobile solution options in this post.

Build Something and Be Agile

The main thing to keep in mind here is that at some point, you need to start building your solution. You are free to choose your development methodology, but agile offers one very important advantage: the ability to make rapid and frequent course corrections.

So, start building something now and stay flexible. You won't be able to reuse your code if you have to move from one language to the next (moving from Javascript to Objective-C for example), but there are lots of design concepts and server code that should cross the technology bounderies.

Is mobile even necessary?

No one article can answer this question for you. What you should know, however, is that mobile is growing; it's growing at a rapid pace. According to one report, the segment of mobile users that open apps at least 60 times per day (called Mobile Addicts) has grown by 123% between 2013 and 2014. In fact, mobile adoption has seen a 259% increase since 2010. Even if this doesn't seem relevant to your current situation, there is a high probability that it will be in the very near future as companies continue to consider their mobile strategy.

Attend our Think Mobile presentation at the Technologists of Color July Meetup. We will take a general look at the mobile space and point out some of the things that must be considered in order to have a successful mobile presence.

Need directions?

Presentations slides now available.