One Little, Two Little, Three Little Interfaces

Several weeks ago, I promised a reader [EDIT: Read the comments here.] to discuss why I would think twice before adding a TaskSpace interface to a solution that already included an eRoom interface. Aside from the obvious that TaskSpace is a brand new interface and could most likely use service pack or two, I am always hesitant to provide too many interfaces into a solution. There are times for it, but it is important not to add them just because you can.

Interface Counting Fun

Users, when properly trained, users can readily handle switching between different user interfaces. They will gladly switch between Outlook, Word, Excel, and a browser no problem. They’ll go to one site to enter in their time, one to retrieve their benefit information, and still another one to reference corporate information. You can even replace interfaces and the users will adapt. The key is that they have to perceive each application or site as serving a separate purpose or job function.

Let’s say I have a collaboration application like SharePoint or eRoom. The users have workspaces for projects, groups, and other collaborative processes. They are happy, and so it IT. Now a requirement arises stating that the users need to scan some documents. I’d look into scanning them directly into the collaborative workspace and only give them a new interface to operate the scanner if absolutely necessary.

Now we add a little workflow to the mix. If it is an extension of one or more projects, just model it within the collaborative space. However, if it is addressing a new problem, or is a broader approach to problems previously modeled, then is the time to consider an additional interface.

A Enterprise of User Interfaces

Let’s talk about some Enterprise Applications. Let’s say you have a case management system built within Siebel. If a user is looking at a particular case and needs to look at a supporting document, they would much rather access it from within Siebel than have to open a second browser into an ECM system and look it up there. To solve this, you either bring the ECM into Siebel, Siebel into ECM, or both into a portal. I prefer the first but a portal can be useful for bringing a large number of applications together.

I have found that in general, it is best to keep the number of user interfaces to a minimum. That allows new functionality to be viewed as an enhancement and not as a new task. However, when you can clearly demonstrate that the new user interface solves or automates a new business problem, that is the time to seriously consider adding an additional user interface.

One would hope that no one user is using too many interfaces. If so, then it is time to either re-evaluate the Enterprise Architecture, or maybe the person’s job description.

4 thoughts on “One Little, Two Little, Three Little Interfaces

  1. Craig, I liked your entry, and most most entries in general. When I read his comment, I had to look twice. There wasn’t too much value to be gained due to the very topic, but I didn’t see it as political. This is something that most IT people understand more and more over time. I understand it and I’m sure you reached others that I missed.

    James suspect just wants something edgier from the vendor blogs. He is, after all, “From Incite comes Insight”. Maybe you should challenge James on what two sides of the discussion you seem to be straddling.


  2. Edgier is an interesting choice of words. How about instead asking for more transparency. For example, if Bex comments that ECM systems should store content and not users then Craig Randall could respond by first saying that he agrees with this position and/or counter as to why Bex is wrong.

    Craig could also state how much time he spends thinking about gaps in terms of ECM security (if any) and most importantly his thoughts on areas within the world of ECM where vendors really should work together to create standards.

    Politicians respond but never really answer the question asked…


Comments are closed.