Learning by Shipping

Back in the pre-web days, acquiring software was difficult and expensive.  Learning a given program (app) was difficult and time consuming.  Within this context there was an amazing amount of innovation.  At least in part, these constraints also contributed to the oft-cited (though not well-defined) concept of bloatware.  Even these constraints do not seem particularly true on today’s modern mobile platforms, we are starting to see a rise in app bloat.  It is early and with enough self-policing and through the power of reviews/ratings we might collectively avoid bloatware on our mobile devices.

Product managers have a big responsibility to develop feature lists/themes that make products easier to use, more functional, and better overall–with very finite resources.  Focusing these efforts in ways that deliberately deprioritize what could lead to bloatware is an opportunity to break from past industry cycles and do a better job for modern mobile platforms.  There are many forms of bloat across user experience, performance, resource usage and more.  This post looks at some forms of UX bloat.

This post was motivated by a conversation with a developer considering building an “all in one” app to manage many aspects of the system and files.  This interesting post by Benedict Evans, http://ben-evans.com/benedictevans/2013/9/21/atomisation-and-bundling about unbundling capability and Chris Dixon’s thoughtful post on “the internet is for snacking” http://cdixon.org/2013/09/14/the-internet-is-for-snacking/ serve as excellent motivators.

History

The first apps people used on PCs tended to be anchor apps–that is a given individual would use one app all day, every day.  This might have been a word processor or a spreadsheet, commonly.  These apps were fairly significant investments to acquire and to gain proficiency.

There was plenty of competition in these anchor apps.  This resulted in an explosion in features as apps competed for category leadership.  Software Digest used to evaluate all the entries in a category with lists of hundreds of features in a checklist format, for example.  This is all innovation goodness modulo whether any given individual valued any given feature. By and large, the ability for a single (difficult to acquire and gain proficiency) product to do so many things for so many people was what determined the top products in any given category.  

Two other forms of innovation would also take place as a direct result of this anchor status and need to continue to maintain such status.

First, the fact that people would be in an app all day created an incentive for an ISV to “pull into” the app any supporting functionality so the person would not need to leave the app (and enter the wild world of the OS or another app that might be completely different).  This led to an expansion of functionality like file management, for example.  This situation also led to a broad amount of duplication of OS capabilities from data access to security and even managing external devices such as printers or storage.

As you can imagine, over time the amount of duplication was significant and the divergence of mechanisms to perform common tasks across different apps and the OS itself became obvious and troublesome.  As people use more and more programs this began to strain the overall system and experience in terms of resources and cognitive load.

Second, because software was so hard to use in the early days of these new apps and paradigms there was a great deal of innovation in user experience.  Evolving from command line to keyboard shortcuts to graphical interface.  Then within the graphical interface from menus to toolbars to palettes to context menus and more.  Even within one phase such as early GUI there were many styles of controls and affordances.  At each innovation junction the new, presumably easier mechanism was added to the overall user experience.

At an extreme level this just created complete redundancy in various mechanisms. When toolbars were introduced there was a raging debate over whether a toolbar button should always be redundant with a menu command or never be redundant with a menu command.  Similarly, the same debate held for context menus (also called shortcut menus, which tells you where that landed).  Note a raging debate means that well-meaning people had opposing viewpoints that each asserted were completely true, each unable to definitively prove any point of view. I recall some of the earliest instrumented studies (special versions of apps that packaged up telemetry that could later be downloaded from a PC enlisted in the study) that showed before/after the addition of redundant toolbar buttons, keyboard shortcuts, and shortcut menus.  Each time a new affordance was added the existing usage patterns were split again–in other words every new way to access a command was used frequently by some set of people.  This provided a great deal of validation for redundancy as a feature.  It should be noted that the whole system surrounding a release of a new mechanism further validated the redundant approach–reviews, marketing, newsgroups, enthusiasts, as well as telemetry showed ample support for the added ways of doing tasks.

As you can imagine, over time the UX became arguably bloated and decidedly redundant.  Ironically, for complex apps this made it even more difficult to add new features since each brand new feature needed to have several entry points and this toolbars, palettes, menus, keyboard shortcuts, and more were rather overloaded.  Command location became an issue.  The development of the Office ribbon (see JensenH’s blog for tons of great history – http://blogs.msdn.com/b/jensenh/) started from the principle of flattening the command hierarchy and removing redundant access to commands in order to solve this real-estate problem.

By the time modern mobile apps came on the scene it was starting to look like we would have a new world of much simpler and more streamlined tools.  

Mobile apps and the potential for bloat

Mobile app platforms would seem to have the foundation upon which to prevent bloat from taking place if you consider the two drivers of bloat previously discussed. Certainly one could argue that the inherent nature of the platforms intend for apps to be focused in purpose.

First, apps are easy to get and not so expensive.  If you have an app that takes photos and you want to do some photo editing, there are a plethora of available photo editing apps.  If you want to later tag or manage photos, there are specialized apps that do just that.  While there are many choices, the web provides a great way to search for and locate apps and the reviews and ratings provide a ton more guidance than ever before to help you make a choice.  The relative safety, security, and isolation of apps reduces the risk of trial.

Second, because the new mobile platforms operate at a higher level of abstraction the time to learn and app is substantially reduced.  Where classic apps might feel like you’re debugging a document, new apps building on higher level concepts get more done with fewer gestures, sometimes in a more focused domain (compare old style photo editing to instagram filters, for example).  Again the safety afforded the platforms makes it possible to try things out and undo operations (or even whole apps) as well.  State of the art software engineering means even destructive operations almost universally provide for undo/redo semantics (something missing from the early days).

Given these two realities, one might hope that modern mobile apps are on a path to stay streamlined.

While there is a ton of great work and the modern focus on design and simplicity abounds in many apps, it is also fair to say that common design patterns are arising that represent the seeds of bloat.  Yet the platforms provide capabilities today that can be used effectively by ISVs to put people in control of their apps to avoid redundancy.  Are these being used enough?  That isn’t clear.

One example that comes to mind is the share to verb that is commonly used.  Many apps can be both the source and sink of sharing.

For example, a mail program might be able to attach a photo from within the program.  Or the photo viewer might be able to mail a photo.

It seems routine then that there should be an “attach” verb within the mail program along with the share verb from the photo viewer.  On most platforms this is the case at least with third party mail programs as well.  This seems fast, convenient, efficient.

As you play this out over time the the mail program starts to need more than attach of a photo but potentially lists of data types and objects.  As we move away from files or as mobile platforms emphasize security the ability for one app to enumerate data created by another makes this challenging and thus the OS/apps need to implement namespaces or brokers.

The other side of this, share to, becomes an exceedingly long list of potential share targets.  It becomes another place for ISVs to work to gain visibility.  Some platforms allow ISVs to install multiple share targets per app and so apps show up more than once.  On Android there is even a third party app that is quite popular that enables you the ability to offer to manage this list of share targets.  Windows provides this natively and apps can only install as a single share to target to avoid this “spamming”.

As an app creator, the question is really how critical it is to provide circular access to your data types?  Can you allow the system to provide the right level of access and allow people to use the native paradigms for sharing?  This isn’t always possible and the limitations (and controls) can make this impossible, so this is also a call to OS vendors to think through this “cycle” more completely.

In the meantime, limited screen real estate is being dedicated to commands redundant with the OS and OS capabilities might be overloaded with capabilities available elsewhere.

A second example comes from cross-platform app development.  This isn’t new and many early GUI apps had this same goal (cross-platform or cross-OS version).  When you need to be cross-platform you tend to create your own mechanisms for things that might be available in the platform.  This leads to inconsistencies or redundancies, which in turn make it difficult for people to use the models inherent in the platform.

In other words, your single-app view centered around making your app easier by putting everything in the context of your app drives the feature “weight” of your app up and the complexity of the overall system up as well.  This creates a situation where everyone is acting in the interest of their app, but in a world of people using many different apps the overall experience degrades.

Whether we’re talking about user/password management, notifications, sounds, permissions/rights, and more the question for you as an ISV is whether your convenience or ease of access, or desire to do things once and work across platforms is making things locally easier at the expense of the overall platform or not?

Considering innovation

Every development team deals with finite resources and a business need to get the most bang for the buck.  The most critical need for any app is to provide innovative new features in the specific domain of the app–if you’re a photo editing app then providing more editing capabilities seems more innovative than being able to also grab a picture from the camera directly (this is sort of a canonical example of redundancy–do many folks start in the editor when taking a picture, yet almost all the editors enable this because it is not a lot of extra code).

Thinking hard about what you’re using your finite resources to deliver is a job of product management.  Prioritizing domain additions over redundancy and bloat can really help to focus.  One might also look to reviewers (in the App Stores or outside reviewers) to consider redundancy as not always more convenient but somewhat of potential challenge down the road.

Ironically, just as with the GUI era it is enthusiasts who can often drive features of apps.  Enthusiasts love shortcuts and connections along with pulling functionality into their favorite apps.  You can see this in reviews and comments on apps.  Enthusiasts also tend to have the skills and global view of the platforms to navigate the redundancy without getting lost.  So this could also be a case of making sure not to listen too closely to the most engaged…and that’s always tricky.

Designers and product managers looking to measure the innovation across the set of features chosen for a release might consider a few things that don’t necessarily count as innovation for apps on modern mobile platforms:

• Adding more access points to previously existing commands.  Commands should have one access point, especially on small screen devices.  Multiple access points means that over time you’ll be creating a screen real estate challenge and at some point some people will want everything everywhere, which won’t be possible.
• Making it possible to invoke a command from both inside-out and outside-in.  When it comes to connecting apps with each other or apps to data, consider the most fluid and normal path and optimize for that–is it going from data to app or from app to data, is your app usually the source or the sink?  It is almost never the case that your app or app data is always the starting point and the finishing point for an operation.  Again, filling out this matrix leads to a level of bloat and redundancy across the system and a lack of predictability for customers.
• Duplicating functionality that exists elsewhere for convenience.  It is tempting to pull in commonly changed settings or verbs into your app as a point of efficiency.  The challenge with this is where does it end?  What do you do if something is not longer as common as it once was or if the OS dramatically changes the way some functionality is accessed.  Whenever possible, rely on the native platform mechanisms even when trying to be cross-platform.
• Thinking your app is an anchor so it needs to provide access to everything from within your app.  Everyone building an app wants their app to be the one used all the time. No one builds an app thinking they are an edge case.  This drives apps to have more and more capability that might not be central to the raison d’être for your app.  In the modern mobile world, small tools dominate and the platforms are optimized for swiftly moving between tools.  Think about how to build your app to be part of an overall orchestra of apps.  You might even consider breaking up your app if the tasks themselves are discrete rather than overloading one app.
• Reminding yourself it is your app, but the person’s device.  “Taking over” the device as though your app is the only thing people will use isn’t being fair to people.  Just because the OS might let you add entry points or gain visibility does not mean you should take advantage of every opportunity.

These all might be interesting features and many might be low cost ways to lengthen the change log.  The question for product managers is whether this was the best use of resources today and whether it builds the experience foundation for your app that scales down the road?

Where do you want your innovation energy to go–your domain or potential bloat?

–Steven Sinofsky