General User Interface Design Guidelines for usable HTML mockups

Bookmark Blog Post

	del.icio.us
	Digg
	DZone
	Furl
	Reddit

Praveen Coca's Blog | April 22, 2008   3:44 PM | Comments (2)

Background

Most application architectures focus heavily on tiers other than Presentation tier and usually devote a cursory reference or effort to the presentation tier. Even most of the SOA (Service Oriented Architecture) exercises leave out the presentation tier and focus heavily on the services layer. Whatever little architecture/design focus, that is devoted to the presentation tier, just skims the surface and reiterates MVC is the way to go and focuses mainly on the server side components of the presentation tier and totally misses out on addressing those architecture/design aspects on the presentation tier that take advantage of the rapid changes and technologies advances in browser side technologies. Well an argument can be made that it may fall outside the domain of architecture or even design, since it is more of an implementation detail and better left to the developers who actually implement the presentation tier. I leave it to the purists to figure out the domain these aspects belong to. Some Webtier application frameworks do address certain design aspects of presentation tier: Spring Web MVC, Tapestry, JSF and its derivatives to name a few. It is good that technologies like Web2.0, Portals, federation, REST etc extend the scope of SOA to a new level and demand adequate attention to presentation layer services.

The other motive behind this blog of mine on this topic is that most organizations hire design firms to create a brand experience and rich user experience. While these design firms excel in the user experience on the browser end, most are not necessarily conversant with and are not required to be knowledgeable in other tiers of the application, they are putting a face to. It behooves upon the application architects and designers to define a clear set of guidelines for the format, structure and technologies to be used in the artifacts delivered, since most of these involve the html markup, JavaScript, CSS, flash etc., lest it may result in a set of artifacts that are not easily adaptable for use by the application and may require a complete rewrite.

The Essence

The following are a set of guidelines I gathered over a period of time executing several Web Applications, that came in handy for me in such scenarios. These are just suggestions and not rules and surely can be customized to individual application needs. Since Portal solutions are my area of interest and expertise, I tailored these to typical portal applications, but the guidelines are applicable to any modern web application in general. Just replace the words Portal and Portlets with WebApp and Page Fragment (akin to a DIV section within the body of a page) respectively, you should be good to go.

A typical WebApplication/portal consists of four main areas

• Header
• Footer
• Navigation Menus
• Content(collection of information islands)

An example of a typical web page is shown below

• Once the UI design is complete, the location/layout of these four areas should be fairly static for the duration of the User interaction on the website.

• The content area can be viewed as a collection of independent islands of information, known as portlets, which either surface content or application functionality.

• The portlets are arranged in a grid of columns and rows (using simple HTML tables). As in a HTML table, the cells can span multiple rows and columns as well. However it is recommended that the content area layouts remain static at runtime within the page. The same layouts and advanced behavior can also be achieved through creative use of DIV layers and CSS positioning.

• Clicking on a hyperlink/button within a portlet in effect is conceptually equivalent to zooming into that area of content or application functionality. The portlet can then be optionally maximized to cover the entire content area for the duration of interaction with the portlet of interest and restored back to normal state once the interaction is complete. Typically the content and functionality displayed within a portlet should represent a single business process, functional flow, or content subject domain. The view within the portlet may change but the functional or contextual focus should remain the same.

An example of a maximized portlet/detail page

• Portlet titles (if applicable) and content within the content area are typically relevant to a particular context which is currently being viewed. Ex: Products. Services, Case Studies, Articles, FAQs etc. Often these contexts will constitute the Main Menu titles for navigation links for the portal.

• The Main Menu navigation allows the user to switch between different contexts within the portal. However sometimes the hyperlinks within a particular context may require the user to be sent to a different context.

• Some level of nesting within context areas is often desirable to organize the information, particularly if information categories or processes are large or complex. However, too much nesting can lead to navigational challenges for both technical implementation as well as user experience design.

• Some portal frameworks provide automatic menu creation (navigation) for simple nesting of context areas. However, if custom navigation is desired as in the case of deep nesting or for other reasons, then custom code needs to be implemented for menu functionality and to switch between contexts accordingly.

• Strive to minimize the number of page layouts, navigation steps, and switching contexts within the portal, as more complex interaction models require additional learning/discovery time for users of portals or any web application in general, as well as more development time.

• Minimize the inter-dependency between portlets, unless there is an easy visual way of depicting such dependency and a business need to group multiple portlets and make them behave as a single cohesive set of components exists.

• If the portlets involve several steps of a functional flow which typically involves traversing the steps in a sequence, minimize/avoid situations where the user needs to jump from the middle of a stepped sequence to the middle of another stepped sequence. Careful analysis or design decisions need to be taken, in situations where such a jump is warranted.

• Use well structured HTML for easy repurposing of HTML mockup during actual implementation.

• Use consistent naming convention for identifying DOM elements in the HTML markup.

• Organize any JavaScript into files that can be included in the HTML files. Group JavaScript functions for related functionality in a single file. Minimize use of inline JavaScript.

• Minimize use of inline stylesheets and organize styles into linkable stylesheet-CSS files.

• Avoid using absolute positioning and use relative positioning to have a predictable behavior across browsers. If absolute positioning is absolutely needed make sure it is used as an offset from a relative positioned enclosing element and the absolute positioned element is updated whenever the enclosing relative positioned element resizes or moves.

• When creating HTML mockup assume that the body content will be used as a fragment and not as a complete page, so it is paramount that the content is well structured, commented and use demarcation using div tags where possible. Keep in mind that the HTML mockup created during UI design will be broken down into fragments and the fragments may become part of different portlets. Any JavaScript functionality used in a fragment should limit itself to the DOM elements within the fragment and should not assume or refer to elements outside that fragment.

• Use consistent naming convention and unique IDs for forms, form elements, scripts, and stylesheets to avoid naming conflicts with multiple forms and elements in the final aggregated HTML generated by the portal.

Conclusion

This list may just cover the aspects I could think of based on my observations of common scenarios. I am sure there may be other aspects that I may have overlooked which may be relevant to the scenario at hand.

Comments

• Hi Peter,

  Thanks for the feedback.

  By that statement, I didn't mean that one cannot choose/create/design/customize different layouts, instead I meant that once a user is presented with a layout in the current session of user interaction the layout should remain fairly static for the remainder of the session, unless the user changes/customizes his preferences to see a different layout.

  Taking a concrete example of the Dev2Dev home page, where I have a three COLUMN (15%-70%-15%) layout and I am used to expecting quick links to Products and Resources in the left column, Events and News in the right column and the main content in the center. While I am interacting with site, if my home layout, all of a sudden changes to a three ROW layout, it would be disconcerting from user experience standpoint.

  Similarly if I explicity choose my preferred layout to be two column(70%-30%, if such option is made available, ex: thru visitor tools in case of WLP), it should remain that way for the rest of my interactions with the site, automatically switching to any other layout unexpectedly would throw me off my usual user experience and as a User I would have one more usage scenario to learn and live with. Hope this clears out the obscurity in my statement. Thanks Praveen

  Posted by: pcoca on April 23, 2008 at 5:07 AM

• Hi Praveen - Great write up. The path from static page design to a fully dynamic portal is not as easy as it should be. I think there are good guidelines to help that along.

  Some questions about this statement:

  Once the UI design is complete, the location/layout of these four areas should be fairly static for the duration of the User interaction on the website.

  With WLP and the adoption of Ajax/RIA technologies, customers are increasingly wanting to allow user customization of the portal. Call it a Web 2.0 thing or not, but drag and drop of portlets is becoming a common request. With WLP 10.2, we provided REST APIs to make this possible, and the Dynamic Visitor Tool (DVT) sample out of the box shows how.

  Back to your statement - fixing the layout does not mesh with the idea of user customization. Can you explain more where you were coming from with that statement? Would having a dynamic layout break your design in some way?

  Cheers - PJL

  Posted by: plaird on April 22, 2008 at 9:11 PM