Task-Oriented vs. Object-Oriented GUI


I’m reading the excellent resource Sun Web Application Guidelines . I’ve been looking for this kind of resource for years! Love it! In section 5.5, they offer a great suggestion for transitioning an Object-Oriented GUI into a more Task-Oriented GUI. I’ve been interested in this topic for a few years, and I’d like to summarize my thoughts. Keep in mind, I’m not a usability or GUI expert. I’m just a….well, you know the title of my blog…time for a new acronym.

New acronymn:

RAJP – [raj-pee] Regular Average Java Programmer.

As a RAJP, I’m not concerned with breaking new ground or anything, I just want my users to be happy. So here are my thoughts.

[EDIT:  Alas, Sun is no more, and I cannot found this outstanding document anywhere] The difference between Task-Oriented GUI (let’s call it TOG) and Object-Oriented GUI (let’s call it OOG) can be understood by this nifty diagram from Section 5.5 of Sun Web Application Guideline.

An OOG application requires knowledge of the information hierarchy of the system. When you’re navigating an OOG app, you’re navigating the various objects that make up the system (Procurements, Budgets, Purchases Orders, etc.). You kind of have to be a subject matter expert to be successful with an OOG app.

A TOG application relates directly to the tasks that make up your job (Procure Goods, Manage Budget, Make Purchase, etc.). The issue here is that if you have a lot of different kinds of information to manage, then a task list could be overwhelming. Say each domain has an average of five different tasks and you have ten different domains. That’s fifty tasks!

So we break our tasks into groups by domain. But wait! Domains are really a part of the information hierarchy. So we’ve organized our tasks by object domain. In my experience, regular average users think in terms of tasks AND objects. Enter the Common Tasks Page!

“To make existing OO applications into real task-oriented products would take a rebuild from the ground up, based on data from a thorough task analysis of prospective users. However, until products can be rebuilt, a good way to help the user of existing products is to provide a list of tasks and a set of wizards or other means to help perform those tasks. The list of the most common tasks is presented in what is called the Common Tasks page.

The design for the Common Tasks page should be different from other pages in the application (for visual uniqueness and identifiability). The goal is to provide users with quick access to tasks that are supported by key product features. When there are more than a few tasks, the page is divided into sections where functional groups of tasks are separated from each other. For example, functional groups might include configuration and troubleshooting.” – from Section 5.5 of Sun Web Application Guideline

Here’s a super diagram from Sun to illustrate a Common Tasks Page

fig1_9.png

Note that the Navigation Tree on the left is OOG but the Common Tasks Page is TOG.

I REALLY like this design and will be using it in my prototype regardless of which tools we choose.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s