Blog about presentations

Yesterday Laurence talked about the challenges that a multitude of interfaces can present a solution builder, specifically in the context of ECM, and today Billy added his thoughts.
While both posts seem to be focused more on visual interfaces (UI) than
non-visual interfaces, the concerns raised apply to interfaces in
general.

Here are my thoughts:

• I very much agree that it’s more a matter of should than can.
  Is the new UI or user experience relevant to my business? Does a new
  experience enable the retirement of any other experiences? Does a new
  experience lower training costs (e.g. is it more intuitive to my users)?
• At some level, all user experiences from a vendor should be
  consistent. However, one must also consider where ultimate experience
  control resides. For example, I see at least two major categories of
  users where ECM applications are concerned: (1) those who prefer a
  standalone experience, typically within their web browser of choice,
  and (2) those who prefer that the vendor provide an integrated
  experience within the primary applications serving the business’s
  knowledge work (e.g. Office applications, a third party portal, etc.).
• I agree with Laurence: UI should serve the task at hand; not the
  other way around. You have a job to accomplish and the provided
  experience should clarify and simplify that job–even anticipate next
  steps, etc.
• How a business is run and wants to be run will determine whether or
  not a solution has one or more graphical/visual aspects. Knowledge work
  is becoming more specialized; so, each user experience should be
  tailored specifically to the particular link in the value chain it
  serves. Some have called this approach “purpose-built applications” or
  “task-centric experiences.” At the same time, there are horizontal
  (cross-cutting) concerns with visual needs, too (e.g. CIO dashboards,
  BAM, management consoles for admins, etc.).

When you provide presentation tier code as part of your
solution–”whole cloth UI’s” as Billy calls them, you should acknowledge
that users can be a fickle bunch (read: today’s Lexus experience will
become a Yugo eventually–it’s a matter of when, not if).

So you should have a well-factored architecture that separates
business logic and services, which serve all your UI’s, from
application logic and services, which serve a particular UI (e.g.
web-based, Office-based, etc.). Doing so, should produce a “thin
veneer” for a presentation layer, which is easier to evolve or replace.
Again, the UI serves the task at hand; over time, a new UI may serve the task better.
Source: www.craigrandall.net