The New Face of the Interface
I've seen an interesting new class of user interfaces emerge in products lately. Microsoft's CRM, for instance, uses a ribbon interface, and Aplicor's UI employs a tile-like metaphor. This UI makes it easy to go from job to job and enables a user to pursue business processes that cross interdepartmental boundaries.
I saw an interesting CRM user interface the other day, and while I don't usually write about something as basic as the UI, I was drawn to this one. Actually, I've been very interested in a new class of UI emerging lately; something we haven't thought about in a long time is re-emerging, possibly as a differentiator, so perhaps this is timely.
The last significant UI paradigm before window interfaces was the green screen, the IBM 3270 terminal that displayed information as plain text and worked through punching function keys or tabbing to fields -- you remember? For the new user, the metaphor was pure amoeba -- poke it with a function key and see how it reacted. It took a while to get the hang of it all, and each application could have different standards. The 3270 always looked like something with feathers because it had so many post-it notes attached. The graphical user interface, or GUI, replaced green screens, and I don't need to say much more. We've been living in a windowed world ever since.
The Role-Based UI
Now, the original upgrade from 3270 to GUI was significant because it changed the way we worked by imposing a set of standards. Green screens typically dumped a file into your lap, which was easy because all the data was stored together in a file rather than in relational tables. GUIs to me go hand in hand with relational databases -- perhaps not exactly, but metaphorically. They delivered less data that you didn't want by selecting it from a RDBMS.
Since we got the graphical user interface (GUI), we've been tinkering around the edges with client-server, browsers, thick and thin clients, but we've usually displayed a single-screen equivalent to the application, with buttons to click if we wanted to do something different to the data. Buttons seem to be the heirs to the function key, and different locations on screens have different names for a button. At the top of the screen the persistent buttons are called "tabs," and when they appear elsewhere they might simply be "buttons" or "checkboxes" etc.
But all that might be changing with some out-of-the-box thinking from some vendors. Recently, I saw Microsoft's CRM UI, which has a "ribbon" containing the functions appropriate to the job you are involved in. The big idea for the ribbon is that its contents change as you change activities. So a salesperson would have a set of functions appropriate to selling but the sales manager might have a super set of those tools plus some management functions or the ability to see all of the deals his or her team is working on. If needed, both users have access to other Microsoft applications like accounting functions.
This role-based UI is a great idea, and I expect Microsoft enables users to change the functions in the ribbon as they need to. It's a nice idea. I like it because it gives more flexibility to the user to do a job as the user thinks it needs doing. Perhaps that leads to job satisfaction, or at least less frustration, and those are good things.
Another new UI comes from Aplicor, an emerging company from Boca Raton, Fla., that has a suite of front- and back-office functions that I find interesting. The Aplicor UI supports flexibility, but in a different way than the Microsoft ribbon. Aplicor supports a standards-based UI that is easy to figure out but it also enables multiple applications to be live at the same time, which supports a more natural ability to enable the user to sequence work.
The Aplicor UI (wish it had a name) uses a tiled workspace metaphor. In it, multiple applications -- even third-party applications -- can be active at once, and the user can simply mouse from one to the next and back. The tiles, or "panels" as they are called, fill up the workspace, but the user can opt for full-screen viewing of any application. It reminds me of a tabbed interface but without the need to remember which tab to go to -- all the active applications are open in front of the user, but not scattered around the screen in separate windows. Of course, Aplicor still supports tabs, but I think users will naturally gravitate to the new metaphor quickly.
I am not a big fan of multitasking because research has shown that it's an illusion. No one really multitasks; they just move between jobs very quickly. This UI makes it easy to go from job to job, and if not exactly multitasking, it does enable a user to pursue business processes that cross interdepartmental boundaries.
For instance, a salesperson might want to check credit on a prospect before closing a deal or making a sales call. That's a very easy thing to do in two separate windows, but the Aplicor UI makes it a bit easier with the tiled UI. Similarly, the rep could open a panel on a social networking site for use while prospecting. There are many possibilities.
As we look down the road to next-generation CRM with analytics and social technologies embedded, other ideas like unified communications and more robust portals will, I think, come forward, and a UI like this might be very useful. It's a small thing, really, but the potential impact could be big.