The Best Practices are just the basic “rules of the road” for any well-designed interaction: Design, Layout, Navigation, Screen Conventions, and Behavior. There are a bunch of ’em. They are the infrastructure of our basic design assumptions -so this is a vital reference document that I usually bring with me to any engagement.

Rules of the Road

There are only patterns, patterns on top of patterns, patterns that affect other patterns. Patterns hidden by patterns. Patterns within patterns. If you watch close, history does nothing but repeat itself. What we call chaos is just patterns we haven’t recognized. What we call random is just patterns we can’t decipher. What we can’t understand we call nonsense.” — Chuck Palahniuk

Best Practices is a document that covers huge area and addresses multiple overlapping issues. If we were to try to address all of the style attributes of every element of the website we would have a huge and unwieldy document. So we have broken the issues out into three main types of information:

Presentation-oriented

Some items describe specific screen elements and layout. (Layout & Screen Display, Windows).

Note: The Best Practices document rarely describes specific design attributes like color or font. The most granular presentation attributes are embedded in Cascading StyleSheets, which are defined in the CSS StyleGuide. As a general rule; a page file should not contain any HTML attributes.

Behavior-oriented

Other sections describe general behavior (s.a. Navigation, Choices, Screen-level Behaviors). These are site-wide behavioral attributes and “best practices”.

Task-oriented

Some sections describe the common tasks or “patterns”. (Search & Select, Edit a Form, Add & Delete, Reports, Customer Assistance). These are models for how a particular type of task is handled. They are closely affiliated with Use Cases.

Most pages consist of these fundamental semantic “meta-information” parts: Environment<MAIN>, Global topbar<NAV>, Title<HEADER>, Context, Content<SECTION>, Closure

 

Environment: Overall Screen Parameters

Default: 600 x 800 pixels
Pages are “chunked” (broken down) to display gracefully within that format.

Layout & Screen Display

Global topbar

  • Site Logo & Branding
  • Echo Personal Identity of Logged-in User (Name, Role, ID#)
  • [Today’s Date]
  • Login/Logout control (toggles, depending on status)
  • Menubar (top-level site navigation menus)

Page Title

Title text of a page is consistent with the button, link or menu that invoked it in the first place.

Context


Identifies what you’re working on (optional). Usually this is an individual Record or a specific Process.

Content

This Workspace is the main focus of the page. It is usually either:

  • A group or list of Records from which you choose (Search & Select a Record)
  • A “drilldown” to the details of an individual Record (Edit a Form)

The individual Record is usually presented as a “form”, which allows you to edit individual Fields of data.

If there is a substantial amount of Record data, the form may be parsed into several tabfolders, which allow you to deal with the information manageably.

Required data Fields are clearly identified as such.

Closure

This consistent page interface applies to an individual Record form. A List page is simply a navigation tool. The closure tools on a Record form allow you to resolve the Content (i.e.):

  • Complete the work
  • Move to next step
  • Abort the process
  • Return to the group List (in order to select another Record)

Search & Select

In most cases this is the first page of a Process. You can usually do several things: Search, View, Edit, Create & Delete a record.

The Searchbox at the top of the page contains the search tools.

  • Search Parameters
  • Search button

The Search Results are displayed beneath the Searchbox. it allows you to:

  • Select an Item (Edit)
  • Preview an Item
  • Delete an item
  • Create a New Item
  • Closure

Edit (Create) a Record

This type of page is used whether you Edit an existing Record or Create a New Record. The only difference is that you cannot edit the primary key (usually the “name”) of an existing record.

The Context area displays the attributes of the selected item as data. This is non-editable info that identifies the selected item (the context). It is presented at the top of the page.

The Editable Attribute Fields are the focal working area

The Validation & Closure buttons check the input data and initiate helpful feedback & guidance if there are errors.

 

These screenshots came from this case study in my portfolio: FISA / CityTime

Usage & Implementation

There’s (sort of) an accepted encyclopedia of Best Practices. They’re great techniques – but all of them don’t necessarily apply to every situation.  Do we adopt these trends unilaterally?

Some of those best practices can be broken down into “best of breed” (i.e. THAT technique works really well in THIS environment.) The issue – as ever – is context. If your client is trying to go up against a successful competitor with the same profile, then they’ll probably want to emulate the competitor’s best practices. We’ve all experienced that mandate from the client, “Make it like [our competitor] – but different.” (sigh, eyeroll)

On the one hand “Improved is good” – but also “Change is difficult” on general principle – no matter how good the new version is. Hope I’m not sounding like too much of a cranky old guy, but Inertia is Inescapable. It can be overcome, but it takes some doing.  Let’s also admit that improving an existing, well-accepted norm is a heavy lift.

Mind you, I’m not arguing against new forms, but feel that introducing a new way (especially of doing something that already ‘works okay’) carries a bigger load than just time&motion improvement. Lotsa ‘acceptance’ testing. Plus+ probably investment in ‘handholding the change’.

Nowadays easier-to-use is often in the form of you-don’t-need-to-think-any-more-silver-plattering data driven by ‘dark decision-making’.

Creating a whole new and different set of interaction metaphors & techniques means serious investment in terms of time & money for research and development, plus the gamble on user acceptance. I’d love to play in such an exploratory environment (who wouldn’t?) … But also, who’s got the money and the inclination to fund such an effort?

It can happen, tho: This was a wonderful challenge – the Enterprise Social Network

 

 

© The Communication Studio LLC

Advertisements