Learning by Shipping

products, development, management…

Posts Tagged ‘design

Designing for exponential trends of 2014

GrowthRather than predict anything that will suddenly appear at the end of 2014, this post offers some trends that are likely to double by some measure this next year.

This will turn out to be an exponential year in many technologies and what seems far-fetched could very easily be trends that are doubling in relatively short periods of time. We humans generally have a tough time modeling things doubling (why so many companies and products did not figure out how to embrace Moore’s law or the rise of mobile).

To fully embrace exponential change means looking at the assumptions in product development and considering how optimizations for the near term might prove to be futile when facing significant change. Within each trend, design or product choices are offered that might be worth considering in light of the trend.

  • Low-cost/high-function devices. The seemingly endless march of the exponential Moore’s law will continue but include more than compute. Devices will put transistors to work for sensors, rich graphics, and discrete processors. These devices will continue to drop precipitously in price to what seem today like ridiculous levels such as we’ve seen at discount super stores this holiday shopping season in the US. If automobiles are any indication, we should not assume low price is equivalent to low quality for the long-term, as manufacturing becomes more capable of delivering quality at low price. The desire to aspire an even higher level of quality will remain for many and continue to support many price points and volumes. At the same time, the usage patterns across price points will vary dramatically and we will continue to see exponential growth in-depth usage as we have this holiday season with high-value devices. This makes for a fairly dramatic split and leaves a lot open to interpretation when it comes to market share in devices. Design: First, it is worth considering target customers with more granularity when looking at share, as the pure number of devices might not determine how much your service will get used, at least in the near term. Second, don’t expect differences in capability across price points to last very long as the pace of pulling capabilities from higher price points to lower will be relentless.
  • Cloud productivity. Cloud (SaaS) productivity tools will routinely see exponential growth in active users. Tools that enable continuous productivity will rapidly expand beyond tech early adopters as viral effects of collaboration kick in. Products such as Asana, Quip, Paper, Mixpanel, Lucidchart, Haikudeck or others will see viral expansion kick-in. Established tools such as Evernote, Box, Dropbox, WhatsApp, and more with high active usage will see major increases in cross-organization work as they grow to become essential tools for whole organizations. Design: Don’t assume traditional productivity tools and assume new employees, vendors, and recent grads will default to cloud-first productivity.
  • Cloud first becomes cloud-only. Enterprise software in 2013 was a dialog about on-premises or cloud. In 2014, the call for on-premises will rapidly shift to a footnote in the evolution of cloud. The capabilities of cloud-based services will have grown to such a degree, particularly in terms of collaboration and sharing, that they will dwarf anything that can be done within the confines of a single enterprise. Enterprises will look at the exponential growth in scale of multi-tenant systems and see these as assets that cannot be duplicated by even the largest enterprises. Design: Don’t distract with attempting to architect or committing to on-premises.
  • WWAN communication tools. WWAN/4G messaging will come to dominate in usage by direct or integrated tools (WhatsApp, WeChat, iMessage, and more) relative to email and SMS. Email will increasingly be viewed as “fax” and SMS will be used for “official” communications and “form letters” as person to person begins to use much richer and more expressive (fun) tools. This shift contributes to the ability to switch to data-only larger screen devices. Design: Skip email notifications, rely on SMS only when critical (security and verification), and assume heterogeneity for messaging choices. Expect to see more tools building in messaging capabilities with context scoped to the app.
  • Cross-platform challenge. This is the year that cross-platform development for the major modern platforms will become increasingly challenging and products will need to be developed with this in mind. It will become increasingly unwieldy to develop for both iOS and Android and natively integrate effectively and competitively with the platform. Visual changes and integration functionality will be such that “cross-platform layers” might appear to be a good choice today only to prove to be short-lived and obstacles to rapid and competitive development. New apps that are cross-platform “today” will see increasing gaps between releases on each platform and will see functionality not quite “right” for platforms. Ultimately, developers will need to pick their lead platforms or have substantial code bases across platforms and face the challenge of keeping functionality in sync. Design: Avoid attempting to abstract platforms as these are moving targets, and assume dual-platform is nearly 2X the work of a single platform for any amount of user experience and platform integration.
  • Small screen/big screen divergence. With increasing use of cloud productivity, more products will arrive that are designed exclusively for larger screen devices. Platform creators will increasingly face challenges of maintaining the identical user experience for “phones” and for phablets and larger. Larger screen tablets will be more able to work with keyboard accessories that will further drive a desire for apps tuned along these lines along with changes to underlying platforms to more fully leverage more screen real estate. The converse will be that scenarios around larger screen tablets will shift away from apps designed for small screen phones–thus resetting the way apps are counted and valued. Design: Productivity scenarios should be considering committing to large screen design and leave room for potential of keyboard or other input peripherals.
  • Urban living is digital living. With demographic shifts in urban living and new influx of urban residents, we will see a rapid rise in digital-only lives. Mobile platforms will be part of nearly every purchase or transaction. Anything requiring reservations, tickets, physical resources, delivery, or scheduling will only win the hearts and minds of the new urban if available via mobile. While today it seems inconvenient if one needs to resort to “analog” to use a service, 2014 is a year in which every service has a choice and those that don’t exist in a mobile world won’t be picked. Design: Consumer products and services will only exist if they can be acquired via mobile.
  • Sharing becomes normal. With the resources available for sharing exceeding those available in traditional ways, 2014 will be the year in which sharing becomes normal and preferred for assets that are infrequently used and/or expensive. Government and corporate structures will be re-evaluated relative to sharing from autos to office space and more. Budget pressures, rapid increase in software capabilities, and environmental impact all contribute to this change. Design: Can your business share resources? What are you using that could be shared? Is the asset you sell or rent something that runs the risk of aggregation and sharing by a new entry?
  • Phablets are normal. Today’s phablets seem like a tweener or oddity to some–between a large phone and a small tablet. In practice the desire to have one device serve as both your legacy phone (voice and SMS) as well as your main “goto” device for productivity and communication will become increasingly important. The reduction in the need for legacy communication will fuel the need to pivot closer to a larger screen all the time. Improvements in voice input and collaboration tools will make this scenario even more practical. In the short-term, the ability to pair a larger screen tablet with your phone-sized device for voice or SMS may arise in an effort to always use one device, and similarly smaller tablets will be able to assume phone functionality. Design: Don’t ignore the potential of this screen size combined with full connectivity as the single device, particularly in mobile first markets where this form has early traction.
  • Storage quotas go away. While for most any uses today this is true in practice, 2014 will be a year in which any individual will see alternatives for unlimited cloud storage. Email, files, photos, applications, mobile backup and more will be embedded in the price of devices or services with additional capabilities beyond gigabytes. Design: Design for disk space usage in the cloud as you do on a mobile client, which is to say worry much more about battery life and user experience than saving a megabyte.

Amara’s Law states “we tend to overestimate the effect of a technology in the short run and underestimate the effect in the long run”. We will see 2014 not as one year of progress, but as the culmination of the past 15 years of development of the consumer internet as “it all comes together” with incredibly rapid adoption of products and technologies that at once become more affordable, more ubiquitous, and more necessary for our work and personal lives.

It looks like 2014 is shaping up to be the long-term of 2000 that we might have underestimated.

Stay tuned and Happy New Year!

–Steven

Written by Steven Sinofsky

December 17, 2013 at 7:00 am

Posted in posts

Tagged with , , , ,

10 Observations from Tokyo’s CE scene

YodobashiI love visiting Tokyo and have been lucky enough to visit dozens of times over many years.  The consumer electronics industry has certainly had ups and downs recently, but a constant has been the leading edge consumer and business adoption of new technologies.  From PCs in the workplace to broadband at home and smartphones (a subject of many humorous team meetings back pre-bubble when I clearly didn’t get it and was content with the magic of my BB 850!) Japan has always had a leading adoption curve even when not necessarily producing the products used globally.

This visit was about visiting the University of Tokyo and meeting with some entrepreneurs.  That, however, doesn’t stop me from spending time observing what CE is being used in the workplace, on the subway, and most importantly for sale in the big stores such as Yodobashi, Bic, and Labi and of course the traditional stalls at Akihabara.  The rapid adoption, market size, and proximity to Korea and China often mean many of the products seen are not yet widely available in the US/Europe or are just making their way over.  There’s a good chance what is emphasized in the (really) big retail space is often a leading indicator for what will show up at CES in January.

If you’re not familiar with Yodobashi, here’s the flagship store in Akihabara — over 250,000 sq ft and visited by 10’s of millions of people every year.  I was once fortunate enough to visit the underground operations center, and as a kid who grew up in Orlando it sure feels a lot like the secret underground tunnels of the Magic Kingdom

With that in mind here are 10 observations (all on a single page).  This is not statistical in any way, just what caught my eye.

  • Ishikawa Oku lab.  The main focus of the trip was to visit University of Tokyo.  Included in that was a wonderful visit with Professor Ishikawa-san and his lab which conducts research on exploring parallel, high-speed, and real-time operations for sensory information processing. What is so amazing about this work is that it has been going on for 20 years starting with very small and very slow digital sensors and now with Moore’s law applied to image capture along with parallel processing amazing things are possible such as can be seen in some of these Youtube videos (with > 5 million views), see  http://www.youtube.com/ishikawalab.  More about the lab http://www.k2.t.u-tokyo.ac.jp/index-e.html.

Prof Ishikawa

  • 4K Displays.  Upon stepping off the escalator on the video floor, one is confronted with massive numbers of massive 4K displays. Every manufacturer has displays and touts 4K resolution along with their requisite tricks at upscaling.  The prices are still relatively high but the selection is much broader than readily seen in the US.  Last year 4K was new at CES and it seems reasonable to suspect that the show floor will be all 4K.  As a footnote relative to last year, 3D was downplayed significantly.  In addition, there are numerous 4K cameras on sale now, more so than the US.

4K

  • Digital still.  The Fuji X and Leica rangefinder digital cameras are getting a lot of floorspace and it was not uncommon to see tourists snapping photos (for example in Meiji Garden).  The point and shoot displays feature far fewer models with an emphasis on attributes that differentiate them from phones such as waterproof or ruggedized.  There’s an element of nostalgia, in Japan in particular, driving a renewed popularity in this form factor.
  • Nikon Df.  This is a “new” DSLR with the same sensor as the D-800/D4 that is packaged in a retro form factor.  The Nikon Df is definitely only for collectors but there was a lot of excitement for the availability on November 21.  It further emphasized the nostalgia elements of photography as the form factor has so dramatically shifted to mobile phones.
  • Apple presence in store.  The Apple presence in the main stores was almost overwhelming.  Much of the first floor and the strategic main entry of Yodobashi were occupied by the Apple store-within-a-store.  There were large crowds and as you often see with fans of products, they are shopping the very products they own and are holding in their hands.  There has always been a fairly consistent appreciation of the Apple design aesthetic and overall quality of hardware but the widespread usage did not seem to follow.  To be balanced, one would have to take note of the substantial presence of the Nexus 5 in the stores, which was substantially and well-visited.
  • PCs. The size of the PC display area, relative to mobile and iOS accessories, definitely increased over the past 7 months since I last visited. There were quite a large number of All-In-One designs (which have always been popular in Japan, yet somehow could never quite leap across the Pacific until Windows 8).  There were a lot of very new Ultrabooks running Haswell chips from all the major vendors in the US, Japan, and China.  Surface was prominently displayed.
  • iPhone popularity.  There was a ubiquity of the iPhone that is new.  Android had gained a very strong foothold over the national brands that came with the transition to nationwide LTE.  Last year there was a large Android footprint through Samsung handsets that was fairly visible on display and in use.  While the Android footprint is clearly there, the very fast rise of iPhone, particularly the easily spotted iPhone 5s was impressive.  The vast expanse of iPhone accessories for sale nearly everywhere supports the opportunity.  A driver for this is that the leading carrier (DoCoMo) is now an iPhone supplier.  Returning from town, I saw this article speaking to the rise of iOS in Japan recently, iPhone 5S/C made up 76% of new smartphone sales in Japan this October.
  • Samsung Galaxy J.  Aside from the Nexus 5, the Android phone being pushed quite a bit was the Samsung Galaxy J.  This is a model only in Asia right now.  It was quite nice.  It sports an ID more iPhone-like (squared edges), available in 5c-like colors, along with the latest QC processor, 5″ HD display, and so on.  It is still not running Kitkat of course.  For me in the store, it felt better than a Galaxy S.  Given the intricacies of the US market, I don’t know if we’ll see this one any time soon. The Galaxy Note can be seen “in the wild” quite often and there seems to be quite a lot of interest based on what devices on display people would stop and interact with.

Galaxy J

  • Tablets.  Tablets were omnipresent.  They were signage in stores, menus in restaurants, in use on the subway, and in use at every place where people were sitting down and eating/drinking/talking.  While in the US we are used to asking “where are all the Android tablets”, I saw a lot of 7″ Android tablets in use in all of those places.  One wouldn’t expect the low-priced import models to be visible but there are many Japan OEMs selling Android tablets that could be spotted.  I also saw quite a few iPad Minis in use, particularly among students on the trains.
  • Digital video.  As with compact digital cameras, there was a rather extreme reduction in the number of dedicated video recorders.  That said, GoPro cameras had a lot of retail space and accessories were well placed.  For example, there were GoPros connected to all sorts of gear/showing off all sorts of accessories at Tokyu Hand (the world’s most amazing store, imho).  Professional HD and UHD cameras are on display in stores which is cool to see, for example Red and Arri.  One of the neatest uses of video which is available stateside but I had not seen is the Sony DEV-50 binoculars/camera.  It is pricey (USD$2000) but also pretty cool if you’ve got the need for it.  They have reasonable sensors, support 3D, and more.  The only challenge is stability which make sense given the equivalent focal length, but there is image stabilization which helps quite a bit in most circumstances.

There were many other exciting and interesting products one could see in this most wired and gadget friendly city.  One always is on the lookout for that unique gift this holiday season, so I found my stocking-stuffer.  Below you can see a very effective EMF shielding baseball hat (note, only 90% effective).  As a backup stocking-stuffer, all gloves purchased in Japan appear to be designed with resistive touch screens in mind :-)

Hat (front)

Hat (back)  Gloves

–Steven Sinofsky

PS: Here’s me with some super fun students in a class on Entrepreneurship and Innovation at the University of Tokyo.

Classroom @ University of Tokyo

Written by Steven Sinofsky

November 29, 2013 at 4:00 pm

Posted in posts

Tagged with , , , ,

On the exploitation of APIs

Not a stepLinkedIn engineer Martin Kleppmann wrote a wonderful post detailing the magical and thoughtful engineering behind the new LinkedIn Intro iOS app.  I was literally verklepmpt reading the post–thinking about all those nights trying different things until he (and the team) ultimately achieved what he set out to do, what his management hoped he would do, and what folks at LinkedIn felt would be great for LinkedIn customers.

The internet has done what the internet does which is to unleash indignation upon Martin, LinkedIn, and thus the cycle begins. The post was updated with caveats and disclaimers.  It is now riding atop of techmeme.  Privacy.  Security. etc.

Whether those concerns are legitimate or not (after all this is a massive public company based on the trust of a network), the reality is this app points out a longstanding architectural challenge in API design.  The rise of modern operating systems (iOS, Android, Windows RT, and more) have inherent advantages over the PC-era operating systems (OS X, Windows, Linux) when it comes to maintaining the integrity as designed of the system overall. Yet we’re not done innovating around this challenge.

History

I remember my very first exploit.  I figured out how to use a disk sector editor on CP/M and modified the operating system to remove the file delete command, ERA.  I managed to do this by just nulling out the “ERA” string in what appeared to me to be the command table.  I was so proud of myself I (attempted) to show my father my success.

The folks that put the command table there were just solving a problem.  It was not an API to CP/M, or was it?  The sector editor was really a tool for recovering information from defective floppies, or was it?  My goal was to make a floppy with WordStar on it that I could give to my father to use but would be safe from him accidentally deleting a file.  My intention was good.  I used information and tools available to me in ways that the system architects clearly did not intend.  I stood on the top step of a ladder.  I used a screwdriver as a pry bar.  I used a wrench as a hammer.

The history of the PC architecture is filled with examples of APIs exposed for one purpose put to use for another purpose.  In fact, the power of the PC platform is a result of inventors bringing technology to market with one purpose in mind and then seeing it get used for other purposes.  Whether hardware or software, unintended uses of extensibility have come to define the flexibility, utility, and durability of the PC architecture.  There are so many examples: the first terminate and stay resident programs in MS-DOS, the Z80 softcard for the Apple ][, drawing low voltage power from USB to power a coffee warmer, all the way to that most favorite shell extension in Windows or OS X extension that adds that missing feature from Finder.

These are easily described and high-level uses of extensibility.  Your everyday computing experience is literally filled with uses of underlying extensibility that were not foreseen by the original designers. In fact, I would go as far as to say that if computers and software were only allowed to do things that the original designers intended, computing would be particularly boring.

Yet it would also be free of viruses, malware, DLL hell, system rot, and TV commercials promising to make your PC faster.

Take for example, the role of extensibility in email, Outlook even in particular.  The original design for Outlook had a wonderful API that enabled one to create an add-in that would automate routine tasks in Outlook.  You could for example have a program that would automatically send out a notification email to the appropriate contacts based on some action you would take.  You could also receive useful email attachments that could streamline tasks just by opening them (for example, before we all had a PDF reader it was very common to receive an executable that when opened would self-extract a document along with a viewer).  These became a huge part of the value of the platform and an important part of the utility of the PC in the workplace at the time.

Then one day in 1999 we all (literally) received email from our friend Melissa.  This was a virus that spread by using these same APIs for an obviously terrible usage.  What this code did was nothing different than all those add-ins did, but it did it at Internet scale to everyone in an unsuspecting way.

Thus was born the age of “consent” on PCs.  When you think about all those messages you see today (“use your location”, “change your default”, “access your address book”) you see the direct descendants of Melissa. A follow on virus professed broad love for all of us, I LOVE YOU.  From that came the (perceived) draconian steps of simply disabling much of the extensibility/utility described above.

What else could be done?  A ladder is always going to have a top step–some people will step on it.  The vast majority will get work done and be fine.

From my perspective, it doesn’t matter how one perceives something on a spectrum from good to “bad”–the challenge is APIs get used for many different things and developers are always going to push the limits of what they do.  LinkedIn Intro is not a virus.  It is not a tool to invade your privacy.  It is simply a clever (ne hack) that uses existing extensibility in new ways.  There’s no defense against this.  The system was not poorly designed.  Even though there was no intent to do what Intro did when those services were designed, there is simply no way to prevent clever uses anymore than you can prevent me from using my screwdriver as a pry bar.

Modern example

I wanted to offer a modern example that for me sums up the exploitation of APIs and also how challenging this problem is.

On Android an app can add one or more sharing targets.  In fact Android APIs were even improved to make it easier in release after release and now it is simply a declarative step of a couple of lines of XML and some code.

As a result, many Play apps add several share targets.  I installed a printing app that added 4 different ways to share (Share link, share to Chrome, share email, share over Bluetooth).  All of these seemed perfectly legitimate and I’m sure the designers thought they were just making their product easier to use.  Obviously, I must want to use the functionality since I went to the Play store, downloaded it and everything.  I bet the folks that designed this are quite proud of how many taps they saved for these key scenarios.

After 20 apps, my share list is crazy.  Of course sharing with twitter is now a lot of scrolling because the list is alphabetical.  Lucky for me the Messages app bubbles up the most recent target to a shortcut in the action bar.  But that seems a bit like a kludge.

Then along comes Andmade Share.  It is another Play app that lets me customize the share list and remove things.  Phew.  Except now I am the manager of a sharing list and every time I install an app I have to go and “fix” my share target list.

Ironically, the Andmade app uses almost precisely the same extensibility to manage the sharing list as is used to pollute it.  So hypothetically restricting/disabling the ability of apps to add share targets also prevents this utility from working.

The system could also be much more rigorous about what can be added.  For example, apps could only add a single share target (Windows 8) or the OS could just not allow apps to add more (essentially iOS).  But 99% of uses are legitimate.  All are harmless.  So even in “modern” times with modern software, the API surface area can be exploited and lead to a degraded user experience even if that experience degrades in a relatively benign way.

Anyone that ever complained about startup programs or shell extensions is just seeing the results of developers using extensibility.  Whether it is used or abused is a matter of perspective.  Whether is degrades the overall system is dependent on many factors and also on perspective (since every benefit has a potential cost, if you benefit from a feature then you’re ok with the cost).

Reality

There will be calls to remove the app from the app store. Sure that can be done. Steps will be taken to close off extensibility mechanisms that got used in ways far off the intended usage patterns. There will be cost and unintended side effects of those actions. Realistically, what was done by LinkedIn (or a myriad of examples) was done with the best of intentions (and a lot of hard work).  Realistically, what was done was exploiting the extensibility of the system in a way never considered by the designers (or most users).

This leads to 5 realities of system design:

  1. Everything is an API.  Every bit of a system is an API.  From the layout of files, to the places settings are stored, to actual published APIs, everything in a system as it is released serves as an interface to people who want to extend, customize, or modify your work. Services don’t escape this because APIs are in a cloud behind REST APIs.  For example, reverse engineering packets or scraping HTML is no different — the HTML used by a site can come to be relied on essentially as an API.  The Windows registry is just a place to store stuff–the fact that people went in and modified it outside the intended parameters is what caused problems, not the existence of a place to store stuff.  Cookies?  Just a mechanism.

  2. APIs can’t tell you the full intent.  APIs are simply tools.  The documentation and examples show you the mainstream or an intended use of an API.  But they don’t tell you all the intended uses or even the limits of using an API.  As a platform provider, falling back on documentation is fairly impossible considering both the history of software platforms (and most of the success of a platform coming from people using it in a creative ways) and the reality that no one could read all the documentation that would have to explain all the uses of a single API when there are literally tens of thousands of extensibility points (plus all the undocumented ones, see #1).

  3. Once discovered, any clever use of an API will be replicated by many actors for good or not.  Once one developer finds a way to get something done by working through the clever mechanism of extensibility, if there’s value to it then others will follow. If one share target is good, then having 5 must be 5 times better.  The system through some means will ultimately need to find a way to control the very way extensibility or APIs are used.  Whether this is through policy or code is a matter of choice. We haven’t seen the last “Intro” at least until some action is taken for iOS.

  4. Platform providers carry the burden of maintaining APIs over time.  Since the vast majority of actors are doing valuable things you maintain an API or extensibility point–that’s what constitutes a platform promise.  Some of your APIs are “undocumented” but end up being conventions or just happenstance.  When you produce a platform, try as hard as you want to define what is the official platform and what isn’t but your implied promise is ultimately to maintain the integrity of everything overall.

  5. Using extensibility will produce good and bad results, but what is good and bad will depend highly on the context.  It might seem easy to judge something broadly on the internet as good or bad.  In reality, downloading an app and opt-ing in.  What should you really warn about and how?  To me this seems remarkably difficult.  I am not sure we’re in a better place because every action on my modern device has a potential warning message or a choice from a very long list I need to manage.

We’re not there yet collectively as an industry on balancing the extensibility of platforms and the desire for safety, security, performance, predictability, and more.  Modern platforms are a huge step in a better direction.

Let’s be careful collectively about how we move forward when faced with a pattern we’re all familiar with.

–Steven

28-10-13 Fixed a couple of typos.

Written by Steven Sinofsky

October 25, 2013 at 9:30 am

Posted in posts

Tagged with , ,

Avoiding mobile app bloat

Nemo BloatrBack 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

Written by Steven Sinofsky

September 24, 2013 at 6:00 pm

Posted in posts

Tagged with ,

Designing for scale and the tyranny of choice

with 16 comments

Movie still from American Graffiti showing fancy hot rod carA post by Alex Limi, of Mozilla, Checkboxes that kill your product, is a fascinating read for anyone in the position to choose or implement the feature set of a software project.  What is fascinating is of course the transparency and admission of the complexity of a modern software product.  Along with this is a bit of a realization that those making the choices in a product are in some ways the cause of the challenge.  Things are not quite so simple but are also not so difficult.

Simple

By now we are all familiar with the notion that the best designs are the simplest and most focused designs.  Personified by Apple and in particular the words of Steve Jobs, so much of what makes good products is distilling them down to their essence.  So much of what makes a good product line is only shipping the best products, the smallest set of products.  So much has been written, including even in Smithsonian Magazine, about the love of simplicity that inspired and is expressed in the design language of Apple’s products based on a long history of design.

It is exceedingly difficult to argue against a simply designed product…so long as it does what you want or when it does more than competitive products.

In fact it is so difficult to argue against simplicity that this post won’t even attempt to.  Let’s state emphatically that software should always do only what you need it to do, with the fewest number of steps, and least potential for errors due to complex choices and options.

On the other hand, good luck with that.

Anyone can look at any software product (or web site or hardware product) and remove things, decide things are not valuable to “anyone” or simply find a new way to prioritize, sort, or display functionality, content, capability.  That’s really easy for anyone who can use a product to do.  It is laudable when designers look back at their own products and reflect on the choices and rationale behind what, even with the best intentions, became undesired complexity, or paperclips.

The easiest type of simplicity is the kind that you place on a product after it is complete, hindsight is rather good when it comes to evaluating simplicity.  This is simplicity by editing.  You look at a product and point out the complexity and assume that it is there because someone made some poor assumptions, could not decide, didn’t understand customers, or a whole host of other reasons.

In fact, many choices in products that result in complexity are there because of deliberate choices with a known cost.  Having options and checkboxes costs code and code costs time in development in testing.  Adding buttons, hinges, or ports is expensive in materials, weight, or even battery life.  Yet designers add these anyway.  While data is not a substitute for strategy, looking at usage data and seeing that nearly every bit of surface area is executed, validates these choices (one could go through Limi’s post and reverse engineer the rationale and point to the reasons for baggage).

It is enormously difficult in practice to design something with simplicity in mind and express that in a product.  It is an order of magnitude more difficult than that to maintain that over time as you hope for your asset to remain competitive and state of the art.

Difficult

Software is a unique product in that the cost of complexity is rarely carried by the customer.  The marginal cost for more code is effectively zero.  While you can have lots of options, you can also effectively hide them all and not present them front and center.  While you can have extra code, it is entirely possible to keep it out of the execution path if you do the work.  While you can inherit the combinatorics of a complex test matrix, you can use data and equivalence classing to make good engineering assumptions about what will really matter.  Because of these mitigations, software is especially difficult to design simply and maintain in a simple state even if you accomplish a simple design once.

Here are seven reasons why simplicity in software design is incredibly difficult:

  • New feature: enable/disable.  You add a new feature to your product but are worried about the acceptance of the feature.  Perhaps because your new feature is an incredibly innovative, but different, way to do something everyone does or perhaps because your new feature is based on a technology that you know has limits, you decide to add the checkbox.  The easy thing to do is to just add a “do you want to use this” or the first time you see the feature in action you offer up an option to “keep doing this”.  Of course you also have to maintain a place to undo that choice or offer it again. Play this out over the next release and evolution of the feature and you can see where this leads.
  • New feature: can’t decide. You add a new feature and it clearly has a modality where some people think it should go left and others think it should go right (or scroll up or down, for example).  So of course the easy thing to do is just add an option to allow people to choose.  Play this out over time and imagine what happens if you decide to add a new way or you enhance one of left or right and you can see the combinatorics exploding right before your eyes.
  • New way of doing something: enable compatibility.  You add a new way to do something to your product as it evolves.  Just to be safe you think it would be best to also have the old way of doing something stick around so you add back that option—of course software makes this easy because you just leave the old code around.  But it isn’t so easy because you’re also adding new features that rely on the new foundation, so do you add those twice? Play this out as the new way of doing something evolves and people start to ask to evolve the old thing as well and the tyranny of options gets to you quickly.
  • Remove feature: re-enable. As your product evolves you realize that a feature is no longer valid, useful, or comes at too high a cost (in complexity, data center operations, etc.) to maintain so you decide to remove it.  Just to be safe you think it is a good idea (or customers require it to be a good idea) to leave in an option to re-enable that old feature.  No big deal.  Of course it is important to do this because telemetry shows that some people used the feature (no feature is used by zero people).  Play this out and you have to ask yourself if you can ever really remove a feature, even if there is a material cost to the overall system for it to be there.
  • Environmental choice: customize.  Your product is used in a wide variety of environments from consumer to enterprise, desktop to mobile, managed to unmanaged, private network to internet, first time to experienced people, developers or end-users, and so on.  The remarkable thing about software is the ability to dynamically adjust itself to a different usage style with the simple addition of some code and customization.  The depth and breadth of this customization potential makes for a remarkably sticky and useful product so adding these customizations seems like a significant asset.  Play this out over time and the combinatorics can overwhelm even the largest of IT administrators or test managers.  Even if you do the work to design the use of these customizations so they are simple, the ability to evolve your designs over time with these constraints itself becomes a constraint—one that is likely highly valued by a set of customers.
  • Personality: customize.  You design a product with a personality that reflects the design language across every aspect of the product from user interface, documentation, packaging, web site, branding and logos, and more.  Yet no matter what you do, a modern product should also reflect the personality of the owner or human using it.  You see no problem offering some set of options for this (setting some background or color choices), but of course over time as your product evolves there is a constant demand for more of these.  At some extremes you have requests to re-skin the entire product and yet no matter what you try to do it might never be enough customization. Play this out over time and you face challenges in evolving your own personality as it needs to incorporate customizations that might not make sense anymore.  Personality starts to look a lot like features with code not just data.
  • Competitive: just in case. The above design choices reflect complexity added during the development of the product.  It is also possible to make choices that do not arise out of your own choices, but out of choices that come from responding to the market.  Your main competitor takes a different approach to something you offer and markets the heck out of it.  You get a lot of pressure to offer the feature that same way.  The natural reaction is to put in a quick checkbox that renders some element of the UI your way as well as competitor’s way.  You battle it out, but rest assured you have the objection-handler in place so sales and marketing don’t stress.  Play this out and you can see how these quick checkboxes turn into features you have to design around over time.

Of course we all have our favorite illustrations of each of these.  You can imagine these at a very gross level or even at a very fine level.  The specifics don’t really matter because each of us can see immediately when we’re hitting up against a choice like this.  Play the design choice out over the evolution of the product/feature and see where it goes.

It is important to see that at the time these are not dumb motivations.  These are all legitimate product design approaches and tradeoffs.  Another way people see simple is that while you’re designing it you know how it will definitely not appeal to a set of customers.  You can take a bet on convincing people or you can be a bit safer.  Product development is uncertain and only hindsight is 20/20.  For every successful product that is simple, there are a lot of simplicity approaches that did not pan out over time. Minimal can be simple, or just a minimal number of customers.

What can you do?

Evolution

Software is definitely in a new era.  The era of excess configurability or even infinite customization is behind us.  The desire for secure, robust, long battery life along with incredible innovations in hardware that bring so many peripherals on board means that designers can finally look at the full package of software+hardware through a different lens.

If you draw an analogy to the evolution of the automobile, then one might see where the software world is today.  And because we see software and hardware inextricably connected today, let’s say that this applies to the entire package of the device in your hand or bag.

In the golden era, as some would say, of automobiles it was the height of hip to know the insides of your car.  A fun after school project for a guy in high school would be to head home, pop the hood on the Chevy, and tune the engine.  Extra money earned on the side would go to custom parts, tools, and tweaking your wheels.  You expressed yourself through your car.

Then along came the innovations in quality and reliability from car makers in the 80’s.  They saw a different approach.

When I was 16 my father took me to look at cars.  We stopped by the dealer and during the pitch he asked the salesman to pop open the hood. I am sure the look on my face was priceless.  I had literally no idea what to look for or what to see.  Turns out my father didn’t either.  Electronic fuel injection, power steering, and a whole host of other things had replaced the analog cars he knew and loved (and currently drove).  Times had changed.

I have not looked under the hood of a car since.  My expectation of a car is that it just works.  I don’t open the hood.  I don’t service it myself.  I don’t replace parts myself.  I can adjust the seats, set the radio presets, and put an Om sticker on the back.  I want the car’s design to express my personality, but I don’t want to spend my time and energy worrying if I broke the car doing so.  Technology has advanced to the point where popping the hood on a car is no longer a hobby.  The reliability of being able to drive a 2002 Prius for over 100,000 miles without worrying comes with fewer options and customizations, but I got a car that cost less to operate, took less time as an owner to maintain, and was safer in every way.  Sold.

Today’s sealed Ultrabooks and tablets, app stores, and even signed drivers represent this evolution.  Parts that done wear out, peripherals that you don’t need to tune or adjust at the software level, thin, light, robust, reliable.  Sold.

Approach – Point of View

How can you approach this in the products you design? As you can imagine there is a balance.  The balance is between your point of view and making sure you truly meet customer needs.

A point of view has to be one of the best tools of design  A point of view is the reason for being, the essence, the very nature of a product.  In a world where just about every product (but not all) is made of similar ingredients and solve problems that can kind-of, sort-of be solved in other ways, what distinguishes one product from another is a unique point of view that is followed through in the design.

A point of view says who the product is for and why.  A point of view says the benefits of a product.  A point of view says why this product is better, faster, and differentiated in the marketplace.

A point of view also guides you in deciding how to be simple.  Simplicity comes from adhering to your point of view.  If you have a clear point of view then simplicity follows from that.  Is something consistent with your point of view?  If so then it sounds like a candidate.  If not, then why are you considering it?  Is your point of view changing (it can, but be careful)?

But we don’t all have the luxury of declaring a point of view and sticking to it.  You can share your point of view with customers, or potential customers.  You can articulate your point of view to the market.  You can also adapt and change.  The market also adapts and changes.

That’s why product development is so exciting and interesting.  The answers are not so simple and the journey is complex, even if the goal is product simplicity.

–Steven

PS: Interested in a Harvard Business teaching case study on this topic, then perhaps check out http://www.hbs.edu/faculty/Pages/item.aspx?num=34113 (Microsoft Office 2007).  This is a paid link for which I receive no compensation.

Written by Steven Sinofsky

March 19, 2013 at 11:30 am

Posted in posts

Tagged with , ,

%d bloggers like this: