The evolution of the UI

Since the beginning of the personal computing era, we have seen different types of user interfaces. These interfaces were defined by technology. The mobile/cloud age brings us another type of user interface.

The user interfaces were:

• Text-mode programs
• Character-based graphic programs
• True GUI programs
• Web programs

Text-mode programs were the earliest of programs, run on the earliest of hardware. Sometimes run on printing terminals (Teletypes or DECwriters), they had to present output in linear form -- the hardware operated linearly, one character after another. When we weren't investigating problems with hardware, or struggling to software, we dreamed about better displays. (We had seen them in the movies, after all.)

Character-based graphic programs used the capabilities of the "more advanced" hardware such as smart terminals and even the IBM PC. We could draw screens with entry fields -- still in character mode, mind you -- and use different colors to highlight things. The best-known programs from this era would be Wordstar, WordPerfect, Visicalc, and Lotus 1-2-3.

True GUI programs came about with IBM's OS/2, Atari's GEM, and Microsoft's Windows. These were the programs that we wanted! Individual windows that could be moved and resized, fine control of the graphics, and lots of colors! Of course, such programs were only possible with the hardware and software to support them. The GUI programs needed hefty processors and powerful languages for event-driven programming.

The web started in life as a humble method of viewing (and linking) documents. It grew quickly, and web programming surpassed the simple task of documents. It went on to give us applications such as brochures, shopping sites, and eventually e-mail and word processing.

But a funny thing happened on the way to the web. We kept looking back at GUI programs. We wanted web programs to behave like desktop PC programs.

Looking back was unusual. In the transition from text-mode programs to character-based graphics, we looked forward. A few programs, usually compilers and other low-output programs, stayed in text-mode, but everything else moved to character-based graphics.

In the transition from character-based graphics to GUI, we also looked forward. We knew that the GUI was a better form of the interface. No one (well, with the exception of perhaps a few ornery folks) wanted to stay with the character-based UI.

But with the transition from desktop applications and their GUI to the web and its user interface, there was quite a lot of looking back. People invested time and money in building web applications that looked and acted like GUI programs. Microsoft went to great lengths to enable developers to build apps that ran on the web just as they had run on the desktop.

The web UI never came into its own. And it never will.

The mobile/cloud era has arrived. Smartphones, tablets, cloud processing are all available to us. Lots of folks are looking at this new creature. And it seems that lots of people are asking themselves: "How can we build mobile/cloud apps that look and behave like GUI apps?"

I believe that this is the wrong question.

The GUI was a bigger, better incarnation of the character-based UI. Anything the former could do, the latter could do. And prettier. It was a nice, simple progression.

Improvements rarely follow nice simple progressions. Changes in technology are chaotic, with people thinking all sorts of new ideas in all sorts of places. The web is not a bigger, better PC and its user interface was not a bigger, better desktop GUI. Mobile/cloud computing is not a bigger, better web, and its interface is not a bigger, better web interface. The interface for mobile/cloud shares many aspects with the web UI, and some aspects with the desktop GUI, but they have their unique advantages.

To be successful,  identify the differences and leverage them in your organization.

Limits to growth

The shift from desktop and web applications to mobile applications entails many changes. There are changes in technology, new services and capabilities, and integration of apps and the sharing of data. Yet one change that has seen little discussion is the limits of an app's size.

Desktop applications could be as large as we wanted (and sometimes were larger than we wanted). It was easy to add a control to a dialog, or even to add a whole new dialog full of controls. A desktop application could start small and grow, and grow, and grow. After a short time, it was large. And after a little more time, it was "an unmanageable monstrosity".

The desktop PC technology supported this kind of growth. Desktop screens were large, and got larger over time. (Both in terms of absolute dimensions and pixel count.) The Windows UI philosophy allowed for (and encouraged) the use of dialogs to present information used less frequently that the information in the main window. Thus, application settings could be tucked away and kept out of sight, and users could go about their business without distractions.

But the world of mobile apps is different. I see three constraints on the size of apps.

First is the screen. Mobile apps must run on devices with smaller screens. Cell phones and tablets have screens that are smaller than desktop PC monitors, in both absolute dimensions and in pixel count. One cannot simply transfer a desktop UI to the mobile world; the screen is too small to display everything.

Second is the philosophy of app UI. Mobile apps show a few key pieces of information; desktop apps present dozens of fields and can use multiple dialogs to show more information. Dialogs and settings, encouraged in desktop applications, are discouraged in mobile apps. One cannot simply port a desktop application to the mobile world; the technique of hiding information is dialogs works poorly.

Third is the turnover in technology. Mobile apps are generally client-server apps with heavy processing on servers and minimal presentation on clients. The mobile app platforms change frequently, with new versions of cell phones and new types of devices (tablets and Windows 8 Metro devices). While there is some upward compatibility within product lines (apps from the iPhone will run on the iPad) there is a fair amount of work to make an app run on multiple platforms (such as porting an app from iPhone to Android or Windows 8). Desktop applications had a long, steady technology set for their UI; mobile apps have a technology set that changes quickly.

This third constraint interests me. The frequent changes in mobile devices and their operating systems means that app developers have incentive to update and revise their applications frequently. Certainly one can write an app for the earliest platforms such as iOS 1.0, but then you lose later functions. And the rise of competing platforms (Android, Windows 8) means new development efforts or you lose those shares of the market.

I expect that technology for mobile devices will continue to evolve at its rapid pace. (As some might say, this rapid pace is "the new normal" for mobile development.)

If mobile devices and operating systems continue to change, then apps will have to change with them. If the changes to devices and operating systems are large (say, voice recognition and gesture detection) then apps will need significant changes.

These kinds of changes will limit the size of a mobile app. One cannot start with a small app and let it grow, and grow, and grow as we did with desktop PC applications. Every so often we have to re-design the app, re-think our basic assumptions, and re-build it. Mobile apps will remain small because will be constantly re-writing them.

 I recognize that I am building a house of cards here, with various assumptions depending on previous assumptions. So I give you fair warning that I may be wrong. But let's follow this line of thinking just a little further.

If mobile apps must remain small (the user interface portion at least), and mobile apps become dominant (not perhaps unreasonable), then any programs that a business uses (word processing, spreadsheets, e-mail, etc.) will have to be small. The world of apps will consist of small UI programs and large server back-ends. (Although I have given little thought to the changes for server technology and applications. But let's assume that they can be large apps in a stable environment.)

If business use the dominant form of computing (mobile apps) and those apps must be small, then business processes must change to use information in small, app-sized chunks. We cannot expect the large, complex data entry applications from the desktop to move to mobile computing, and we cannot expect the business processes that use large, complex data structures to run on mobile devices.

Therefore, business processes must change, to simplify their data needs. They may split data into smaller pieces, with coordinated apps each handling small parts of a larger dataset. Cooperative apps will allow for work to be distributed to multiple workers. Instead of a loan officer that reviews the entire loan, a bank may have several loan analysts performing smaller tasks such as credit history analysis, loan risk, interest rate analysis, and such.

These business changes will shift work from expert-based work to process-based work. Instead of highly trained individuals who know the entire process, a business can use specialists that combine their efforts as needed for each case or business event.

That's quite a change, for a mobile device.

Icon rot

A number of folks have observed that commonly used icons in applications are no longer sensible.

Their observations are true: pictures of floppy discs are lost on the latest generation of computer users. ("What's a floppy disc?")

The implicit assertion is that we need a new set of icons to represent common functions such as "save" and "search". I disagree with this.

Let me state that I do agree with the assertion that the icons no longer make sense. The notions of floppy discs, radio buttons, paper calendars, and cassette tapes are not relevant to an entire generation of computer owners.

I disagree with the notion that we need a replacement set of icons.

I think that we can get by without icons -- for certain functions. Most prominent are the "save" and "save as" functions.

Classic desktop applications needed the idea of "saving data". They were designed to load data into non-permanent memory, allow the user to modify it, and they allow the user to either save the changed version or abandon the changes and revert to the original version.

Web applications and phone apps are designed differently. We have moved away from the "modify and save" design. Web applications and phone apps save data by default. They don't offer the user of "save or do not save". Saving is automatic. (The better phone apps allow the user to revert to earlier versions.)

I see few icons in web applications, and very few in phone apps. The few icons I see are usually singletons, such as the "send tweet" icon in Twitter apps. Instead of icons, I see buttons (or tap areas) with words. The Facebook app has tap areas with the words "status", "photo", and "post". The Google Gmail app has a tap area with an envelope with a wavy arrow, but to be honest I would be more comfortable with the word "send".

Windows set a number of standards for application design and provided the commonly used icons for those operations. Web and phone apps do not follow those standards, and do not need those common icons.

Rather than a set of standard icons (and therefore a set of standard operations) for all apps, look for app-specific operations. Web apps and phone apps will provide the operations that they need, the operations that make sense. They will not attempt to mold an app into a standard model; they will let the app be itself.

With no common set of functions, there is no need for a common set of icons. Indeed, icons will cause more confusion than they save, since custom icons are not universally understood. Look for more words, and fewer icons.

Microsoft Office becomes hip because Facebook did

The new Microsoft Office 2010 edition has a number of improvements, ranging from animations on the opening splash screen to collaborative capabilities. Microsoft Outlook has a special feature, one that I have not seen in the other products of the suite.

Microsoft Outlook has a social networking feel to it, with incoming e-mails showing avatars of the sender and their immediate network. That's a neat trick, since few people in our office have the latest version of MS Office, and therefore have had no opportunity to set up a social network. (And to be honest, the avatars are all generic "shadow" avatars.)

But this is a change to look like a social network without actually being one.

It turns out that you as the user don't define your social network in MS Outlook -- the software uses the organization's network defined in the Active Directory server. People are members of departments (or groups, or branches, or whatever) and MS Outlook relies on this structure. Which means that the social network image of MS Outlook is just that: an image. It's not my social network (where I can friend and unfriend people), it is the company's definition of a social network: the people in my assigned organizational unit.

It looks cool, until you realize what's happening. Is this an attempt at making a staid (dare one say "quaint") interface more hip? is it a way to make MS Outlook more acceptable to the generation that was raised on Fascebook? Perhaps.

Hipness aside, this change demonstrates that Microsoft felt compelled to change Outlook. Perhaps the change was driven by the collaboration capabilities, but I feel that Microsoft is attempting to compete with Facebook. Which means that Facebook is driving the design of software, not Microsoft.