Building Really Elegant Web Portals, Part 1

This is part one of a two-part article.  Part two is here.


This article discusses principles for building really elegant web portals. More precisely, it’s about how to build portals in a really elegant way. Even though I use a particular development stack for the example implementation, the principles can apply generally to other platforms as well.

Web-based applications and interfaces have become very popular.  Even certain kinds of equipment, like routers, generally implement a web-based GUI.  In the telecom community, sites that allow subscribers to access and manage their services are often referred to as "portals".  There are a lot of approaches to designing a portal site, and a lot of potential pitfalls that could be avoided with the right approach.

A Design Pattern for Portals

Usually, when a portal has to be built, people go looking around for a framework to use, or they use the one they already know.  There are some pretty good frameworks out there, but in my experience I've found most of them to be too unwieldy, bloated, complicated, slow and error-prone for my taste.  They seem to get in the way more than helping.

Instead of a framework, what I propose is a design pattern.  For lack of a better phrase I call it the Widget Pattern.  There's already a lot of information about design patterns, when to use them, and the pros and cons of custom development versus one-size-fits-all frameworks, so I won't get into that.  The Widget Pattern is really simple, and it's been used with great success in lots of other areas besides portal design using other names  -- its just not seen quite so often in web applications.

The core of the idea is to provide a collection of widgets that a relatively non-technical person can utilize to customize or build a portal using just basic HTML and CSS skills.  It also attempts to separate functionality from content and presentation, putting them into separate areas so individuals with different roles can take responsibility for their area of expertise.  In this part, we'll look at those roles and responsibilities and the problems that the Widget Pattern is trying to solve.

It's really important to recognize the different roles people play when it comes to portal development, and to let them all do their role without stepping on each others toes.  The developers should really focus on functionality.  Then the marketing folks can really focus on the layout, messaging and workflow.  The graphic designer can really focus on getting the visuals right.  But a lot of frameworks sort of lump everything together, forcing you to go through a big learning curve before you can make even small changes to the site.

Everyone's a Designer

Web sites are a lot like wardrobes. Whoever assumes responsibility for a web site immediately wants dress it up differently.  Our taste in fashion is as unique and individual as the way we look, and can be a form of self expression.  In a similar way, the urge to reconstruct the visual components of a website appeals to our individual aesthetic sense, and promises to be noticed!

Interfaces are highly visual, so they’re really easy to latch onto, put on powerpoint slides and debate.  Since everyone has a different idea of what looks good, it makes a never-ending source of meeting-fodder.  Interface planning can become a magnet for interminable design-by-committee projects - often with bad results.

Portal design tends to generate intense pride of ownership. Everyone attaches self-worth to their own creative endeavors, from their fashion choices to their work deliverables.  Whenever I have to design a portal or web application, I feel a pleasant rush of creative responsibility.  After all, we know that artists are not supposed to be questioned on their creative work, but given uninhibited artistic license! This sense of freedom and responsibility can be very appealing, and nobody is really immune from it.  This is the “Everyone’s a Designer” syndrome.

Unfortunately the “Everyone's a Designer” syndrome leads to a lot of bad user interfaces. Web technologies make it easy for people to unleash their inner artist, but just because you can doesn’t mean you should. I call this the “Not Everyone Should Be Allowed to Wear Spandex” principle.

The Immediacy of Interfaces

User interfaces get an immediate reaction because they're the first thing you see about a system - the point of entry.  The importance of first impressions means a lot of thought and effort to go into the presentation.  This is typically the domain of marketing specialists and graphic designers, but developers are the ones who have to implement the functionality. This can lead to difficulties, since marketing folks generally don’t understand the constraints of web development platforms, and developers generally don’t understand the difference between mauve and chartreuse, or comprehend how anyone could obsess for two weeks over the precise wording of a single paragraph. The situation can get bad if the developer has to repeatedly re-implement the fickle, frivolous whims of a marketing team that can’t make up their minds and has no appreciation for the amount of work their “minor changes” require.  Or if the marketing person keeps getting road-blocks thrown up by a developer who claims "you can't do that" for "technical reasons" that "you wouldn't understand".

Avoiding Entanglements

Design review meetings can quickly degenerate into debates on aesthetics and battles of opinion. Programming skills are not particularly well-suited to this environment, and the developer caught in the middle has a hard job ahead. This brings us to the next principle: Avoiding Entanglements.

At all costs, developers should avoid getting embroiled in debates about aesthetics, text content, layout and any other aspect that are likely to be scrutinized by marketing, branding and product level management types. For developers these things can be a phenomenal time-waster. Instead, developers should try to adopt a framework that puts power into the hands of branding / marketing folks to take ownership of as much of the presentation as possible, or at the very least make it extremely trivial to make ongoing changes to the static design.

A really elegant framework will turn a rebranding exercise into hours - instead of weeks - of effort, and from a job requiring major programming skills into one requiring only a modest familiarity with web design. This way, developers can extricate themselves from the entanglements of aesthetic debates and focus instead on functionality, while marketing and branding specialists can have a great deal of flexibility in the design and presentation of material.

Content vs. Functionality

An oft-quoted maxim of web development is “content vs. presentation”, harking back to the days when stylistic details like fonts and colors were embedded into the markup tags of text on web pages. Designers were admonished to separate content from presentation by using cascading style sheets to supply the stylistic details in a way that could be more easily swapped for alternate styles.

But the notion of separating content from presentation can be carried further. Although “presentation” typically means things like fonts, colors, layout and background images, and “content” typically means text, whenever a marketing team is hammering out the wording of a particular paragraph, the phrase in question can begin to seem a lot like a matter of presentation. Or when they're coming up with different scenarios about what should appear on the screen after clicking the “submit” button, even the workflow can be seen as a presentation concern.  Again, a really elegant portal framework will enable such decisions to be implemented and modified by the non-technical folks themselves... perhaps with a little hand-holding, but without requiring any real custom programming effort.

To enable such a level of flexibility requires more than a separation of content and presentation, it requires separation of content and functionality. This is the next principle, the Principle of Content versus Functionality.  It allows the developer to focus on what the portal should do, while the branding experts focus on what it should say and how it should look.

Offload Everything

For the developer, an elegant approach to designing a portal offloads as much of the responsibility for visual and interactive decisions to other people as possible. It's the Offload Everything Principle.  That includes not only the things typically found in a stylesheet, but as much of the static content and layout as possible, too. A really elegant design should even permit changes to the “workflow” (the series of pages a user must navigate while completing a particular task) without sacrificing simplicity and a small footprint. The dynamic parts of the interface that require programming knowledge to implement should be so well encapsulated that they can be reorganized to fit the client’s unique requirements, like a collection of “widgets” that supply bits of dynamic content and functionality, and can be relocated, re-skinned and reconfigured without any special programming expertise.

Next in Part 2
As a developer, I always like to get the technical details first, and read about the justification for the design later, so I've approached this backwards by offering lots of context first.  However in the next part we'll get into the technical details of the design pattern itself.  Here is part 2.