Strategy 4. Separate Verbs from Nouns

Using the output from strategies the Core Strategies ( Part 2 ) make lists of verbs and nouns. Make lists of verbs and nouns from both the primary 5 to 10 and the secondary lists. You can subset the verbs and nouns if you deem it appropriate. This may help to obviate groupings or narrow the list of the most important. There are various subsetting strategies

4.(a) Subset by strategy

You could subset by strategy, i.e., if the verb or noun came from strategy 1, 2 or 3 then place it in a subset accordingly.

4.(b) Subset by general classification

You can subset nouns by Archetype such as Role Player within the system (probably from strategy 1), important moment in time (instance) or period of time (interval) ,e.g., sale (instance in time) and warranty period (period of time), things, e.g., Shipment of Good, and descriptions, e.g., Dispatch Note (typically Forms and other paperwork)

4.(c) Subset verbs into "performed by" User Role

You can subset verbs by the User Role which performs the action, e.g., "sell" performed by Salesman, "dispatch" performed by warehouse clerk.

This suggests that "sell" and "dispatch" appear in separate groups.

4.(d) Subset verbs by the noun they operate upon

Subsetting verbs into groups according to what they operate on can also be useful, e.g., "sell goods", "dispatch goods". Both verbs operate on "goods" so group them together.

For Goods, this suggests that "sell" and "dispatch" appear together.

From Strategies 4.(c) and 4.(d) two design alternatives are emerging. We have learned that if we build a User Role centric design then we probably want to present actions like "sell" and "dispatch" to different Users in different places and at different times. We have also learned that if we build an Object centric design then we probably want to present actions such as "sell" and "dispatch" together.

At this early stage neither design is right or wrong. As a major architect of the system, you, as UI Designer, will have a good idea what your target is. If for example, you were targetting an Object Oriented UI and OS such as OS2 Workplace Shell then you might want to steer the design towards the Object Centric classification. If you are targetting a User Centric design for, say, a handheld device or specific point of use system to be used in a warehouse by a warehouse clerk then you may wish to pursue the User Centric classification instead. I prefer to preserve all alternatives as they may prove useful later.

Strategy 5. Identify Groups of Data

Knowing what data to group together and understanding why you are grouping it together can be a very powerful aid to design and ultimate usability. Naturally, artifacts/things within the system can be described by a number of attributes and you would expect to find views displaying these attributes together. This is the intuitive and obvious idea for data grouping. If we were to formalise it as a strategy then, we would have :

5. (a) Group Data by Attributes of a single artifact/thing/object

For each of the nouns derived in Strategy 4, examine and list the attributes. Group these attributes together for display, e.g.,

This is hardly worthy of mention as a strategy and is in any event a part of both the requirements analysis and object modelling. It can almost be assumed that results from strategy 5.(a) are a requirement, at the very least for data input.

Data is often transcribed from Forms, thus it is convenient for data entry to group the attributes of single objects together. It may also make sense for many data reading occassions too.

How can we group data, so that it is more useful to the User? How can it help the User get the job done? In other words, how can we make the data groupings help with the User Goals?

5. (b) Analyse Data Grouping by minor Tasks and User Role

The key tasks defined in Strategy 2 are probably too high level or involved to be of use to us here. Why? Key tasks for a business often involve a number of people working collaboratively on a number of smaller tasks. We are looking for smaller tasks, probably from the secondary list. These may have emerged in the verb & noun analysis in Strategy 4. Look for simple and commonly occurring verbs such as "create"/ "new"/ "add" and "search" / "find". Identify tasks such as

• Create a new Customer record in the database
• Find a Customer and Contact them by telephone

For each of these minor tasks identified categorise by User Role and examine the User Goal, then analyse what data is required to achieve the task.

For "Create a new Customer record in the database", the User Role is probably, Salesman. What we need to do is examine what the salesman needs to capture as data. The goal is to be able to capture sufficient data in order that we can uniquely identify the customer and commence a long term business relationship. Answer the Questions "What do I need to know in order to accept a new customer/applicant?"

There may be a minimum set of mandatory attributes which produce a list, something like

• Name
• Post code
• Address
• Telephone Number
• ID Number (probably Registration Number)
• ID type(probably Company Registration)

Followed by a number of preferred optional attributes like

• Business Sector
• Annual Budget
• Preferred Language
• Referred by

It makes sense to take this data and put it together on a single panel. To group according to the User Goal - satisfy the Task to be undertaken by the User Role.

At this point many System Analysts will be horrified. These attributes come from several Objects - they are spread across the Object Model. My answer to that is "So what?" The goal of systems analysis and object modelling is different. The goal is amongst many things to provide an optimal mechanism for storing the data whilst maintaing data encapsulation and separating responsibilities to facilitate system maintenance. The goal of the UI Designer is different. Help the User to get the job done in the fastest possible way, with minimum cognitive load.

Now look at the second example. We need to answer the question, "What do I need to know in order to contact that customer?" In this case the group of data is even smaller.

• Name
• Telephone Number
• Language Spoken

It makes sense to group this data together. This small grouping may be a useful component on its own. It may also be re-usable. It may be the best solution for the earlier example to put this second grouping as a sub-group within the first.

5. (c) Group Data by need at time of use

Often different pieces of information are needed together at the same time. From the tasks broken out by User Role, look for instances that where several pieces of data are needed together or several tasks happen together.

For example, Find Customer Information and Contact Customer are two tasks which tend to happen together. It makes sense to group data together to enable these two tasks to be completed together.

Puting Data Groups into a re-usable panel component is a good practice for UI Development. Re-using the panel where appropriate in the design is good practice. It promotes consistency and reduces the amount of UI Code which has to be developed.

Strategy 6. Identify Collection of Items

Seek to identify Whole - Part relationships within the domain, perhaps suggested from the list of nouns from Strategy 4. Look for a noun which suggests a collection, e.g. Catalogue and then look for the nouns which make up the collection, e.g. Goods. A collection of different types of Goods is a Catalogue. This relationship implies containment and containment implies a container, e.g. a list box or table. A list of the Collections in the system will give you a starting point for exploring shapes for the UI presentation.

Identify inter-related collected items. This implies that you have a tree or graph structure. You may or may not need a named collection.

For example, DDD Co. may be carrying a range of special offers from a vendor. A bundling deal. Buy these 3 items together at a big discount. Our Product Catalogue may display the bundle as a separate item, but we still want to see the breakdown of the individual items. This implies that we have a tree structure, e.g.,

Catalog

Product Grouping e.g. Lawnmowers

• Product e.g. Qualcast Promotion Set
  • Qualcast 2000 mower
  • Qualcast 2001 strimmer
  • Qualcast Lawn Rake

In the example given, we still need the container, the Catalogue. The tree structure is merely one set of items amongst many.

If collections emerge with names which you haven't heard before i.e. new Nouns, then go back and revisit Strategies 1 to 5 adding in the additional Nouns.

6.(a) Categorize collections by User Role

Identify the User Roles which interact with each collection.

Identify the User Roles which interact with items within the collection.

Are they the same or different?

From a User Centric perspective, do we need to treat Collections and Items differently or similarly?

This may imply that certain Users can only see the collection, or certain Users can only see the parts, e.g. a Warehouse Clerk may only be interested in Goods but a Sales Person will be interested in the Catalogue and the Goods.

6.(b) Categorize collections by Verbs

Identify the verbs ( tasks/actions ) which operate on each collection.

Identify the verbs which operate on the items within the collection.

Are they the same or different?

From a tasks/actions perspective ( Object Centric perspective ), do we treat the collection and its items differently or similarly?

If similarly, this may imply that the collection and its parts have the same menu items, navigations or action buttons. If differently, then not.

6.(c) Categorize collections by interaction with other artifacts/things/objects

From the list of nouns, identify other artifacts/things which interact or relate to the collection and its items.

Identify the things which interact or relate to the collection.

Identify the things which interact or relate to the items.

Are they the same or different?

Do we need to treat the collection and its contents, similarly or differently?

The answer to this question will affect navigation and shape of UI. This gives us a clue as to what other data may be required on screen or easily reached when the collection or its items are on screen. This is a key indicator as to where the space constraint problems are going to occur in the system. When an item or collection is highlighted from this strategy, more attention will need to be paid to it. Extra work will need to be done with the Users to analyse and drill out the exact requirement.

6. (d) Do we need a named collection?

Examine whether all the items you are considering for the collection relate to each other or not. In the Catalogue example, there are many independent items, whilst only a few have inter-relations. When this is the case, do we need the collection as an explicit User Interface artifact, i.e. a Catalogue, in the User Interface?

In this example, Yes. In fact, the Catalog could be a Product which can be ordered i.e. it is also a thing.

When all the contained items are related such as the DDD Co. Organisation Structure, do we still need a container? For building the UI, you will. A window, panel or other UI Widget, but as an explicitly named artifact? The answer will lie in the Domain language.

For example, if we have a feature Display the Organisation Chart, then this implies the collection is named.

So, the answer is Yes. You can use "Organisation Chart" as a named collection in the UI.

However, if the feature were worded, Display the List of Employees with Superiors and Sub-ordinates, then that implies that the container doesn't have a name.

The answer is No. Using the term "Organisation Chart" or "Organisation Structure" is meaningless in this example. Simply use the terms, "Employees" instead.

6. (e) Challenge the size of the collection

Sample the possible sizes of the collection. For example, when the Salesperson is taking an Order for a collection of Items, how many Orders have more than one item?

If the number is very small then we may be able to optimise the design. It will certainly change the shape.

When there are a large percentage of collections with only one item, try to assess a reasonable maximum size. It doesn't make sense to provide a table with space for 10 entries when 6 is the likely maximum, and 1 is the most common.

6. (f) Identify Collections with behaviour across the items

Items in the collection share the same relationship with the container and behaviour is common across the collection. Go back to the output from Strategies 2 and 4 and look for tasks which relate to the collection e.g. Total the Order Value. Nouns from Strategy 4.(a) categorised as Moments or Intervals of Time ( e.g. Sale, Order ) or Nouns from Strategy 2 related to tasks, are the most likely candidates.

Where there is behaviour relating the items in a collection to the collection itself, we are likely to require a different visual shape or layout, to when there is not.

Example: Totalling an Order. It makes sense to list the items in the Order in a table and display the totals at the bottom. Where there is no such relationship, say the collection of Addresses for the Customer, then a table is not perhaps the most appropriate choice.

A Collection identified by this strategy may over-ride any influence from Strategy 6 (e), i.e. due to the requirement to total an order, a table component will be required and it will need to have a reasonable size, even if many orders only contain 1 item.

If it is likely that most orders only have 1 item, or a very few items, we may be tempted to optimise the design, perhaps displaying only a single item. However, the suggestion from 6 (f) would imply that we need a table (or similar shape) regardless or quantity and sufficient space for a reasonable maximum must be set aside.

Strategy 7. Identify Object Histories

From the list of nouns, identify those which involve the storing of a history ( a collection over time ) e.g. Customer Address. An Address is a noun in the system. A customer may move house but for whatever reason we are required to store the history of their residence. This is a collection over time.

7.(a) Categorize histories by User Role

Identify User Roles which interact with the "current" object in the history.

Identify User Roles which interact with the previous objects in the history.

Are they the same or different?

From a User Centric perspective, do we have to treat the current object differently or similarly to the whole history of objects?

Example: A Sales Person may be interested in the history of a Customers residence, so might an Accounts Clerk, but the Warehouse Clerk would only be interested in the current Address. That is where the goods will be dispatched.

7.(b) Categorize histories by Verbs

Identify tasks or actions performed on the Object history from amongst the verbs list.

Identify verbs which act on the "current" object. Identify verbs which act on the "previous" objects in the history.

Are they similar or different?

From an Object Centric perspective, do we need to treat the current object differently or similarly from the whole history?

Example:, we might "dispatch" to the current address, but we would never "dispatch" to a previous address. This kind of partitioning helps to improve usability by reducing choice. A Warehouse Clerk can never make a dispatch error, if he can only select "current" address for the customer.

7.(c) Categorize histories by interaction with other artifacts/things/objects

Identify other artifacts/things from the nouns list.

Identify nouns which interact or relate with the object history, e.g. Address and Property Description.

Identify nouns which relate to or interact with the "current" object.

Identify nouns which relate to or interact with the "previous" objects in the history.

Are they the same or different?

Do we need to treat the "current" object differently or similarly to the whole history?

The answer to this question will affect the shape of the UI and will indentify navigation options which must be offered from the "current" object and from the "previous" objects.

Example: for a given customer we may need to see the Current Salesman responsible for the account, we may also need to see the history of Salesmen who have looked after the account. In this example the results for "current" and "history" are the same.

Strategy 8. Look for comparative analysis requirements

Sometimes we have a requirement to capture data as input but the output (reader) requirement isn't to show the data as such but to derive some other data. For example, we may capture the financial accounts for an organisation. The data is figures such as Net Profit After Tax for each business year. However, there will be occasions where the reader is actually interested in the change over time. Perhaps, the User has questions like, "Is the business doing better, or what is the rate of improvement?"

Data which has this type of comparative analysis requirement will almost certainly have been identified by Strategies 6 & 7. You cannot compare data without first having a collection or capturing a history!

8. (a) Categorise by comparison across objects

Using the output from Strategy 6, look for items in collections where Users need to compare data.

For example, from the Product Catalogue there may be several similar and competing products. The salesman needs to be able to communicate to the User what the alternatives are and describe the differences, e.g. "The Flymo has an 8Litre grass box, against 6Litres on the Qualcast".

8. (b) Categorise by comparison over time

Using the output from Strategy 7, look for items that need to be compared over time.

Spend time to identify the real requirement. Ask questions like, "Do you need to see the before and after values, or the change in value?" "Do you need to see both?"

Find out if it is acceptable to highlight that a change has occurred whilst not showing either the change amount or the previous value. This is a good space saver but will only work under certain circumstances.

8. (c) Categorise comparative data requirements by User Role

For the output from Strategies 8 (a) and 8 (b), list them against User Roles identified in Strategy 1.

Are they the same or different?

Do we have the potential for different views for different User Roles?

Example: from 8(a) - Comparison of Objects

Example: from 8(b) - Comparison over time

Assuming that the UI Design is being done at an early stage in the software development lifecycle, it is possible to use the UI Design process to develop a list of key features for a system. Features are key to system design and object modelling particularly when using Peter Coad's techniques [ Coad 99 ] referenced many times in the Coad Letter http://www.oi.com.

The output of stratgies 1 through 8 can be used to produce such a feature list. Features should be listed in short sentences, such as

• The Salesman makes the sale to the customer
• The Salesman makes the sale of the goods

These simple sentences can be broken down into 4 parts: the nominative; the verb; the accusative; the dative. Or if you prefer: the first party; the action; the second party; and the third party.

The later strategies will give you finer grained features, such as

• compute the change in turnover ( from strategy 8 )
• total the value of an order ( from strategy 6 )
• total the value of business from a customer ( from strategy 7 )

Note that in these finer grained features, the System is the first party in the sentence. How did this come about? We are getting business logic features when we want to examine User Interaction. The simple truth is that the system derived values are of interest to the viewer. These values don't need to be input but viewing them makes the User task easier. They help the user to get the job done. Some of these requirements will have been explicitly stated in the requirements document, e.g. total the value of an order. Some of these will not, for example, compute the change in turnover.

Use this list of features as input to your Object Modelling, particularly when it comes to analysing interaction or developing Scenario Views ( Coad Methodology) and a Feature Driven Development Process as described in the forthcoming book by Coad, Lefevre, De Luca, Yourdon Press, Prentice Hall, 1999. (title to be announced later)

It is easy to relate the feature sentences to the earlier analysis in strategies 4 through 8.

• the nominative / first party - is a User Role
• the verb - is an action or task
• the accusative / 2nd party - is an artifact or object
• the dative / 3rd party - is an artifact or object

It is further possible to make some predictions about the Object Model analysis

• the nominative / first party - is a Role Player
• the verb - is a method on a class
• the accusative / 2nd Party - is the data output for the method
• the dative / 3rd party - is the class or the data input for the method