|
The
growth of business to business integration (B2Bi), syndicated and
aggregated content, OEM branding of websites and application service
providers (ASPs) is creating a whole new challenge for user interface
designers. How do you design a usable interface for web content
which is designed merely as a component of something else?
Back
in January, we looked at the problem of aggregated content presented
through a single portal. We speculated that one possible way forward
was the clear separation of business logic from user interface.
Leaving the user interface in both it's function (interaction design
and code implementation) and it's form (graphic design) separate
allows the content provider to supply purely business function in
XML or using a remote method invocation system such as XML-RPC e.g.
SOAP. This scheme leaves the whole of the user interface task to
the integrator or aggregator. This is likely to lead to coherent,
unified designs but it presents a level of user interface work which
the aggregator is not prepared to, or cannot, undertake.
Several
industries are driving requirements where the supplier of the function,
has to, or wants to deliver a user interface on their components.
For example, a manufacturer who sells their products through OEM
channels may want to supplement their model range with an eCommerce
website. This effectively permits the end user to order on-line
through their preferred brand but the order actually comes directly
to the "no name" manufacturer. To facilitate such a design,
the look and feel of the website has to be configurable to fit with
the brand name vendors existing website. Each OEM vendor wants the
manufacturer's sub-site to look as if it is an integral part of
their own site, and that the end user cannot tell it apart from
their own site. In this case, delivering a user interface for the
sub-site component is a necessity as the manufacturer's channel
partners are not prepared to do it or have no ability to do it.
Another
example might be an application service provider who wants to deliver
certain services which can be integrated into a corporate website.
Take for example, an object modeling vendor which provides services
to produce and manage UML models through an application service
website. The UML tool is designed for integration into corporate
intranets so that staff at the corporate can share work on UML modeling
and have instant access to their project and history through a web
browser. The challenge for the tool manufacturer is to design a
browser based modeling tool, which has a user interface sufficiently
flexible that it can be integrated seemlessly into any corporate
intranet or web development environment. In this case, as with most
application services, the system requires a user interface because
it doesn't offer any real value without one. A modeling tool is
useless without a user interface.
There
are several real examples in use today. Real Estate sites often
aggregate and integrate content. For example, some sites aggregate
the whole of realtor.com,
such as Kansas
City Homes. Realtor.com in turn is integrating maps from a mapping
content provider.
The
New Challenge
These
examples present significant and new challenges for the designer.
How can you possibly design a coherent and usable system when you
have no idea how it is going to look to the end user?
First
of all, it becomes essential to separate out business logic from
user interface. The business function needs to be clearly defined,
fixed and separated out from the user interface. It needs to be
obvious to the web developers, responsible for integrating the final
site, where the boundaries lie and what they can change.
Secondly,
form and function of the user interface need to be clearly separated.
"Look" must be separate from "Feel". The "Look"
is essentially a graphic design rendering and the scope for changing
it is clearly greater than the scope for changing the "Feel"
which covers much of the function of the interface and how it integrates
with the business logic.
Thirdly,
layout must be flexible. Web designers have become used to the notion
that they never fully know how their design will look until they
see it in a browser. Renderings vary from browser to browser. Some
designs fair better than others. Some GUI developers have had exposure
to layout managers such as those used in Swing. The layout manager
seeks to adapt a GUI design to different screen and window sizes.
When GUI layout managers were first introduced, there was considerable
resistance amongst UI developers who often felt that the layout
manager couldn't do as good a job as they could with a fixed, pixel
oriented, design. Many early Swing programs did not make best use
of the flexibility of layout managers. In short, designers felt
that flexible layout produced a poorer design. In the web world
there have been those who shared that viewpoint. There are still
many top websites which render in a fixed width e.g. BBC
News.
A
few Guidelines
If
you are to design a site as a service or content for integration
or aggregation then you must allow for flexible size and layout.
Other
aspects of the Form of the design will change: the layout; the colours;
the fonts; the graphics. All of these need to be taken into consideration.
If
you design for integration into another site, do not use the <font>
tag. Better to stick with basic tags like <h4>,<p> and
so forth. Possibly consider using a class label on your tags and
providing a default stylesheet for your design. The integrator can
then modify this stylesheet to fit with their own site look. Particularly
don't use the size attribute for fonts. Allow the final integrator
to choose whether they wish to set font sizes or delegate size to
the client browser.
Your
component subsite must also work in varying colours. Try not to
set background or foreground colours. If you need colour, particularly
for tables or parts of your interface with business function e.g.
the modeling window is a UML application service, then parameterise
colour values using variables which the integrator can easily vary
to fit with their own site.
Be
careful with the use of graphics. Almost all graphics will need
to be replaced by the integrator as your defaults will not be suitable
for desired look or corporate colours or branding. Avoid use of
branded graphics. Your integrator or aggregator probably doesn't
want your brand on his pages. If you do use such graphics be sure
and parameterise their use to make them easy to replace.
For
example, throughout uidesign.net, the ui roundel is
used as a bullet point or visual stopper. If this content were to
be aggregated then that graphic would need to be replaced by the
aggregator. To make this easy, the graphic would need to be something
which can be easily replaced with the modification of a constant
variable definition.
It
is probably best to avoid the use of graphics for function. If you
implement an image map with functionality behind it, this may be
very difficult for the integrator to work with, as they may need
to replace your image but still map all the functionality.
Test
Results and Expectations
Another
big challenge comes from the need to test this "unfinished"
content. Obviously, a default or example rendering has to be developed
and it should certainly go through usability testing. The test results
can be used to make modifications and develop guidelines for usage
along with expectations for performance, training and online help.
However, the results can only ever offer a rough guide. Utimately
the integrator will need to do the testing themselves.
It
will become important for ui designers to manage the expectations
of the business people, managers and customers. This is a self-protection
mechanism.
Standards
and Guidelines
As
we see more and more work being done in this area, it will become
obvious that some standards and broad guidelines for application
services are required. Jakob Nielsen was hinting at this with his
recent piece proclaiming the end of web design. The challenge now
is to develop mechanisms which will allow for flexibility of form
and some flexibility of function, whilst delivering a coherent,
functional and usable aggregated service on the web.
Designers
need the flexibility to design. An end to web design is not a desirable
outcome.
However,
there does need to be some flexibility on both sides. There needs
to be acceptance that more standards for interaction design and
information architecture are required if web based application services
are to work. At the same time, there needs to be an acceptance on
the other side, that one of the great powers of the web IS the ability
to use it as a marketing and branding tool and to differentiate
with User Experience.
An
end to web design implies that we we must all wear the same grey
suits, bought from a guidelines compliant source, and that individuality
is bad.
This
website believes that an end to design represents a bad solution
to what is currently a big challenge. Cameron Barrett recently presented
his experiences, in an attempt to raise awareness of the challenges
and share his thoughts about solutions. If you don't want to see
an end to design, there needs to be a lot more material on this
new and difficult topic, published and shared. The ui design community
must strive to show that flexible form is still possible with aggregated
content and services.
|
