Universal enterprise UX – Part 2 (Core Web-parts)

The first post on this topic generated several requests for a UX design of the concept and some suggestions that it simply would not be implementable. Following posts on this topic will attempt to deliver at least a high level design so this question can be debated. We will use specific terms e.g. web-part but the design will be generic and not tied to any particular portal technology. We will also use the scenario of a standard order processing system to bring it to life but it could just as well be any application.

Each portal page will comprise a maximum of one large area (web-part) for the display and update of data (the Display/Update web-part). This will present data/allow updates (if the user has the requisite authority etc.). A page could be comprised of several other web-parts (without a Display/Update web-part) but it will never have more than one Display/Update web-part as the scope of the page would then be too confusing for the user. Optionally, this web-part will invoke actions; for example, “New customer entry” or “Add contact to enquiry”. As such it may be described as a “big, dumb” area of the page in that it has no filter, selection (of types) or browsing capability. It exists for displaying and updating data – CRUD operations.

The Display/Update web-part must then be controlled (and contextualized) through other web-parts e.g. filtering, selection (of types) and browsing. These functions may be combined in several different ways to create the web-parts described in the earlier post.

Data with a rich-hierarchy such as Products lend themselves to a browse metaphor and data which is mainly sequential such as Tasks lend themselves to a list metaphor. Our model will implement these as such. There are also a couple other ancillary functions; namely Next (for moving through peers in a hierarchy) and Filtering (for selecting what is in the list) functionality respectively.

Now that we have defined the core functions, several options for combining them into web-parts are possible:

The “Next” functionality simply finds the first match and allows the user to “hop” through matches to whatever filters are set in the Type/Filter web-part.



1) Multiple Filter web-parts. Easier for multiple developers to code, for example; they can each be given a web-part describing a “type” of information e.g. Developer X is responsible for creating a web-part to select “Geography” and Developer Y is responsible for building a web-part to identify a “Category” for successive editing. Issues with code-reuse, consistency and the amount of screen real-estate required.
2) Combined Type and Filter web-parts. Here, the same web-part is used to display all types of data, for example; a drop-down will allow the selection of “Classification” as a type and the user would use filter functionality to select whether “Geography” or “Category” would be displayed in the same web-part as a list. The user would then choose one at a time to display or update in the Display/Update web-part. The user will use the filter capability in the controlling Type/Filter web-part to select the first in the list of matches and then use the Next button to move through matches.
3) Separate Type and Filter web-parts. As above, but the type functionality in the drop-down is taken out of the controlling web-part and placed into a dedicated Type web-part. The issue here is that it may be confusing for the user in that they have to know which web-part is actually controlling the Display/Update web-part i.e. Type or Filter.
4) Combined Type/Filter and Browse/Next web-parts. As with Option 2 but the additional Browse web-part functionality is also included. This option has the advantage of being very flexible in terms of user interaction. It suffers however from a compromise around consistency i.e. The Type/Filter/Browse web-part is used for all controlling functionality (even for those areas that do not need it or it could be potentially confusing e.g. Task list) or we selectively use it for areas that may benefit from browsing either by a list or a hierarchy e.g. Classification.

Option 2 is selected for our model as it is a combination of usability and judicious screen utilization and affords a consistent UX. It also does not result in extraneous functionality being deployed e.g. around the Task example described above.

Our model now has three core web-parts; Display/Update, Browse/Next and Type/Filter. Together, these will enable us to build most applications. They are effectively UX classes; used to build the physical web-parts of the application e.g. both a Product browser and an Order browser can be made from (differently configured) Browse/Next web-parts.