Universal enterprise UX – Part 4 (Bringing it to life)

Fleshing-out our order processing scenario a little; Orders consists of Order parts (Line items) and these are for various Products. Products grouped into Categories. Enquiries can be progressed into Orders and Tasks are tracked by the application for various reasons e.g. Tracking cold calls, customer complaints etc. All key entities are allocated a Classification e.g. Geography. Customers are front-ended using the order processing system but are likely managed using something else. Similarly Tasks are front-ended but this will likely be managed by some workflow solution. That is it - a standard order processing solution.

Several instances call for a non-linear browsing approach, for example, the selection of Categories and Products where related items (not specifically searched upon by the user) may be seen and the selection may be seen in context. In many instances, the user will also want to search upon these objects (Categories and Products) directly i.e. without browsing.

The arrows show UX contextual flow only. For example, user interaction in the Browse/Next web-part will not automatically affect the Order browser however; the user can select a business operation such as “Add to order” to insert a Destination (or any other allowed object) into the Order browser (and the corresponding Order [Part] highlighted).

Each Type/Filter type of web-part will operate as a three-fold UX process. The user will choose the type of data to work with (Step 1) then apply a series of general filters to that selection (Step 2) and then browse the result set (list box) by use of the vertical scroll-bars and column sort functionality (Step 3).

Initial rendering of the Type/Filter web-part (Step 1) should either default to the filter view (Step 2) or the list view (Step 3). As such this web-part has just two modes – filter mode (Step 2) or list mode (Step 3). Three steps are shown above in order to articulate the UX process involved i.e. the Type has to be chosen first.

In this (modal) way, the model can affect a search by the following means – filtering, sorting and then browsing (from switching from the Type/Filter web-part to the connected Browse/Next web-part). For both UX and performance reasons, a more unstructured search function where, for example, all matches for a particular string are returned across all tables, columns and rows will not be selected. This type of unstructured search is more appropriate to content searching.

A Task is selected in the Task list and the matching Task is automatically selected in the Browse/Next web-part (Order web-part) below it (with the hierarchy also automatically expanded for browsing). The Next functionality will be grayed-out in this particular case, as there will only be one matching Task amongst the Orders.

We would mainly use the Type/Filter web-part as an entry-point to the browsing (what users generally really want to do). For example, if we know which State we want, we will use the Type/Filter web-part to select a Level of “State” then switch to the list view to find our particular state e.g. California. Once we have selected this, in the same manner as with the Task description above, we would switch to the Browse/Next web-part to drill-down into California to see the regions within that State and the Cities within the Regions (or in fact any hierarchical description we define below California; political/ethnic etc.).

Find functionality to the Type/Filter may be extended by the provision of two Filter/Value pairs, the first of which has previously enumerated values i.e. in a drop-down, the second of which displays different Filters (fields) to the first and allows a “wildcard” search via a text-box.

If the user wished to search for all Marketing Tasks for the New York office created for customer “Smith”, they would enter the following; Type = “Task”, Context = “Marketing”, Level = “”, Filter = “Office”, Value = “New York”, Filter = “Customer”, Value = “Smith”. There is a purposeful and direct parallel with the underlying table structure e.g. Type = Table, Context = Table Type, Level = Table Relationship, Filter = Field, Value = Value of Field.

No additional placement of Filter/Value pairs is possible with the model above. Also note that no Boolean operators are operative between the Filter/Value pairs. Of course more pairs/Boolean operators would extend functionality but would your users really use them?