|
|
|
The key to understanding why modeling UML in color is so powerful is to understand the 4 basic building blocks on which it is based - the Archetypes. Webster's defines Archetype as
A model from which all things of the same kind more or less follow
You could also think of an Archetype as a kind of template for a class, though template has awkward connotations for C++ developers.
Developing from his earlier work, [Coad 97-2] Coad proposes the use of 4 Archetypes. Each Archetype is then assigned a color and those colors are shown on the Object Model. Color introduces a graphic design technique called Layering. It sets the model into 4 layers and instantly allows the viewer to divide the diagram into those 4 visual layers. This reveals a lot about the content and behaviour in the model, at a glance.
As you work with and learn more about the use of Archetypes, you will find that the color also allows you to visually check your design as you progress. You will see that colors fit together in familiar patterns when your analysis is correct. When you don't see those familiar patterns, then you start to look for what is missing. The use of color really does help you build better models faster. It simply doesn't look right (the colors aren't mixed in the correct pattern) until you've got it right!
2.1 Archetypes
|
Fig 1. Basic Archetypes and their colors
|
The 4 Archetypes are Role Player (yellow), Moment/Interval (pink), Person/Place/Thing (green) and Catalog-like Description (blue). The colors conveniently map onto four colors for 3M Post-IT notes. Use of these sticky notes allows you to model in color even when you are working on paper or on a wall with a facilitated group.
2.1.1 Moment/Interval (pink)
You may find it easiest when doing the analysis to first look for the Moment/Interval classes. As you will see, Moment/Intervals are important to businesses and important to User Interface design. A Moment/Interval represents any thing which must be tracked for business or legal reasons and happens at an instant in time or over a period of time. Examples are:-
A Sale, the act of ringing-up the till, closing the deal, making the sale - an instant in time
A Warranty, a guarantee of repair or service - a period of time
A Reservation, a guarantee of a seat or room, made at an instant in time but held for a period of time.
The key thing is to recognise that you have one of these two, a moment in time or a period of time and don't worry about whether it is one or the other. Either way, its a pink class.
2.1.2 Role Player (yellow)
Almost as easy to spot during analysis are the Role Players. Beware Role Players are not job descriptions. Try to think more about what actions are performed by the people, places or things in the system and at what time and for what purpose. Then look at the role that was played when performing the action. For example:-
A Bank can have lots of customers. Customer is a role for a Person or Organisation. However, Customer is not very granular. There are lots of types of Customer. A Customer can play several roles e.g. Applicant, Depositor, Borrower, Investor.
2.1.3 Person/Place/Thing (green)
A simplistic view may be to say that this represents all the tangible nouns in the problem domain. Look for any individuals, organisations, places, locations and finally all the items and artifacts involved in doing business. In a hotel, it could be Rooms. In a hospital, it could be Beds. In a bank, it could be Accounts, Application Forms, Cash Balances.
2.1.4 Description (blue)
A collection of blues describing versions of a similar thing is a catalog. Catalogs are what Descriptions are all about. In an airline system you may have a description of a plane, "Boeing 747-400". That is one object of the Plane Description class. If you schedule a flight for a plane fitting that description, then you would have a Plane (green) which would have a Plane Description (blue) of "Boeing 747-400". The actual Plane (green) would then have precise detail such as the actual plane registration number, a serial number, a number of hours flown. Detail which only attaches to it, whilst its blue description class holds all the detail which describe it and all it siblings - other Boeing 747-400s.
2.2 Archetypal Behaviour
Identifying archetypes goes beyond simply helping us identify the necessary classes in a model. Each Archetype has a set of expected behaviour (methods and attributes) which can be predicted based on its archetype. This expected behaviour based on archetype is what makes color modeling so powerful. The colors on the analysis or domain model, show us clearly how many classes of each type are involved and what behaviour we can expect. From that we can list the business benefit that the model can deliver. The features available. Features which will manifest themselves in the User Interface, if we choose to put them there.
2.2.1 Pink - Moment/Interval Behaviour
A pink moment/interval knows its date (or interval), its number, its total, its status and its priority. It should have methods such as totalSaleValue(), isComplete(), isUrgentDelivery().
2.2.2 Yellow - Role Player Behaviour
Role Player classes allow us to assess performance e.g. Counter Clerk Role would have a method, assessPerformance(), a Checkout Operator Role would have a method, salesMadeInPeriod(), and averageSalesOverPeriod(), assessAccuracy(), assessSpeed(). Yellow roles can also be asked about availability to play that role. For example, an Airport currently performing a Military Role may not be available for a Passenger Role.
2.2.3 Green - Person/Place/Thing Roles Behaviour
These can assess their own performance, hold values or fetch values based on description e.g. Price. It will also hold a status, perhaps availability and manage the interaction between its description and the Moment/Intervals and Role Players who may need to query it.
2.2.4 Blue - Catalog-like Description Behaviour
Descriptions can perform tasks such as totalling availability for stock control, e.g. totalUnitsAvailable(), or they can totalUnitsManufactured(). They could then assess these totals over periods of time and provide reports of business value.
In my white paper, User Interface Analysis [Anderson 99], I introduced a number of analysis strategies for identifying what is important within a system for UI Design purposes. Those strategies were designed to be used directly with potential system users to design a User Interface and perhaps help with the system specification process. Here I take a different approach and specifically look at strategies for developing a UI Design based solely on a UML Color model built on Coad's Archetypes. In other words, no need to do separate analysis for the Problem Domain and the User Interface and no need (arguably) for a User Interface Design expert.
Naturally, there ought to be an overlap in analysis between the User Interface and the Problem Domain. The User Interface must ultimately represent what is built in the Problem Domain section of a system. Archetypes help to make obvious the important parts of a system and it should come as no surprise that what is important must be important in both the User Interface and the Problem Domain.
3.1 A Web Style Interface UI Shape
UI Shape is a term which I introduced to describe the screen layout and Navigation choices available to the User. Why shape? It is analagous to developing an Object Model. An Object Model has a series of classes and those are related to together. That relationship structure produces a design shape or pattern. With the User Interface, we must define a number of screens and the navigation or relationship between each one. As a screen or panel can be represented by a class, we therefore have a number of classes and the relationships between them. Sounds very similar to an Object Model. Hence UI Shape or Navigation Model as its also known.
There have been a number of names for application environments on the web. Terms like "browser metaphor" and "webtop" have been used. My personal prefence is the later "webtop" [Sun 97] as detailed in the White Paper for the design of the Hot Java Views web environment by Frank Ludolph et al, at Sun. Variants on this basic shape have appeared from Lotus with eSuite, IBM at their own website, and at many other web sites.
The basic premise is that menus are not used except for context sensitive functionality and that the main application is contained within a 2 dimensional screen layout of buttons or selectors. The first level of selectors is arranged on the LHS side of the screen in a column. This was chosen as vertical space is usually at a premium in web applications which spend a lot of time presenting documents which tend to be longer than they are wide. Thus a column of space is available at the side of the screen. The second level of choices is provided as a toolbar of buttons or selectors across the screen and is context sensitive for the chosen 1st level.
Screen space dictates that a maximum of around 10 selectors at each level is a reasonable maximum. This conveniently fits with the notion that good menus offer a number of 7 +/- 2 choices, so as not to overload the User with too many to choose from.
I therefore called this UI Shape or Navigation model "Chessboard Layout" [Anderson 99-2] because it offers approximately 8 x 8 screens which can be navigated a-modally.
|
Fig 2. The Chessboard Layout Navigation Model
[ Each LHS button represents a navigation selection. For each selection there is a row of subordinate selections horizontally across the top. The currently selected top choice is shown in inverted color.]
|
Note: Some recent studies have shown that a larger number of menu or navigation choices is better than exceeding 3 levels deep. So as a general rule, when more options are required, it is better to increase the number of selections beyond 10, at the top and 2nd levels rather than create a deep hierarchy.
I believe that this would work best when the choices are stacked vertically at the side of the screen. Trying to cram too much across a screen horizontally can look graphically messy and it is harder to predict how wide the target client screen will be. Longer lists of choices have been popular with some website designs recently and it seems to work acceptably well.
3.2 Populating the initial shape
So, we selected the basic shape that we aspire to achieve but, how do we decide on the navigational choices? How do we know that we are making good choices and helping to design a usable system which helps Users to complete a task or achieve a goal?
Deciding on the correct options for each of the navigation buttons and providing the correct context sensitive function is a process that I call Populating the Navigation Model. This is analagous to adding the references to an object model and then adding the methods and attributes.
First of all, take a look at strategies for selecting the navigational choices and developing the Navigation Model.
|
Fig 3. An example of a fully populated Chessboard Layout.
3.3 User Task Analysis
Tasks and Role Players are closely related. The act of performing a task involves an individual, organisation, place or thing (green) in some kind of role play. Hence, the task of approving a loan involves an individual in the role of Approver (yellow). Hence, it makes sense to develop Task Analysis for the each Role Player in the system. Identify all the (yellow) Role Player classes in the model. Identify those which are representing Party (green), or sub-classes such as Individual (green) and Organisation (green). For each of these Role Players work with real players of those roles and develop a list of Tasks and document them. This is the User Task Analysis. For the Approver Role Player (yellow), you ought to come up with a task analysis which looks like this.
Task - Approve a Loan
- Select a Loan Application from the in-tray
- Read the application
- Read the covering letter
- Consider the lending proposal (lines and limits)
- Consider the security offered
- Consider customer account conduct
- Consider the customers ability to repay
- Approve or reject the application
- Write Comments
Now let us consider how we might put that task into the User Interface. First off we could look at a Task Centric approach i.e. we are trying to make the completion of User Tasks easier. With the goal of making the system fast and easy to use.
3.4 Strategy: A top level choice for each step in a Task
From the example above, we have analysed the task down into a series of sub-tasks or steps. We could simply provide a menu choice for each step. Is this particularly helpful? If the only system users are Approvers then it may be. They can pick at a glance which step they want to perform. However, this solution won't scale very far. As soon as we have more than a two or three tasks in the system, it will be unwieldy. If we introduced other Role Players then it immediately look ridiculous. A Marketer for example, doesn't need or want to see the Approver sub-tasks.
|
Fig 4. Chessboard Layout populated for a single task.
[ The second level choices reflect actions which can be taken rather than data which can be selected]
3.5 Strategy: A top level choice for each Task
We can reduce the granularity of our Task Centric approach. Offer each Task at the top level. Well, this approach will work if the number of Tasks in the whole system is small. Certainly up to 10 Tasks, you simply put a Task on each button. If you have a few more then you can use a 2 dimensional array of buttons and that would allow up to 20 Tasks. Though two rows of 10 buttons can be hard to accomodate. A more reasonable maximum would be 16, a vertical row of 8 and a horizontal row of 8.
|
Fig 5. Chessboard Layout populated based on tasks.
[ The second level choices reflect the steps involved in performing the task.]
3.6 Strategy: A top level choice for each Role
When the number of tasks becomes unwieldy then there must be a large number of tasks per Role or a very large number of Roles. Perhaps we can simplify the complexity by grouping tasks by Role. Provide a top level choice for each Role and then the second level choice provides the tasks. Like the diagram here.
|
Fig 6. Chessboard Layout populated with Role Players
[ The 2nd level choice highlights the tasks available for that role player ]
|
It could be that each Role only has one or two tasks but Roles actually combine into Job Roles, so splitting by Role isn't very useful.
It is also very likely that Users won't recognise the roles that they play explicitly and thus this population strategy leads to a problematic and non-intuitive design.
3.7 Roles are not Job Descriptions or Job Roles
|
Fig 7 A simple model for a Job assignment
[ This design removes role players. Ommission of Role Players is permissable if the design doesn't warrant the flexibility that they add.]
Fig 8 A more complex model for Job assignment
[ This design introduces a role player for both the Party and the Place which interact with the Job Assignment Moment/Interval (pink) ]
3.8 Strategy: A top level choice for each Job Role
Assuming that the Role Players are well understood and can be allocated and combined or composed to create each Job Role then a User may easily recognise a top level choice which defines their job role. All the tasks for the Roles played by that Job Role can then be flattened into a 2nd level choice. For example, the Marketer Role combines, Prospector, Lender, Deposit Taker, Investment Seller.
|
Fig 9 Chessboard Layout populated by Job Role
[ Job roles collect Role Players. The tasks for the entire collection of role players is used for the 2nd level]
|
This makes for an easily recognisable UI. Users can identify with their own job role but is the UI a good design? What if one Job Role is very close to another. Say for example we have a Junior Marketing Role which only composes two of the Marketer Roles such as Depositor Taker and Prospector. Do we provide a separate top level choice for that User or do we dynamically modify the more all-encompassing Marketer Role and make some choices unavailable?
If we take the first option then we risk being too granular and may potentially, significantly increase the development effort by adding a lot of extra view classes for what are simply small variants in Job Specification. That could be a lot of extra work. The alternative is not ideal either. The interface will need to dynamically compose its functionality and that functionality will change from one user to the next. As the User gets promotions the interface will change to reflect that. This could be disconcerting and mean additional training as people are promoted and perhaps additional resistance to system acceptance. What if System Admin people are tardy in their operation and forget to update the User account? The User is locked out of functionality that they need to see and use.
Is there a better way which allows us to combine screens for these closely related Job Roles and maximise the re-use amongst the User the different types of User?
3.9 Strategy: A top level choice for Person/Place/Things with a large number of Role Players
It is reasonable to assume that a Person, Place or Thing (green) which holds a large collection or references to Role Players must be important within the system. The fact that it has these Role Players (yellow) shows that it is playing a part in the operation of the system. The more Role Players, the more parts being played and the more important that Person, Place or Thing must be to the overall business goals for the system.
Look across the model for large areas of yellow classes, attached to a single green, then use the name of that green as a top level UI Model choice.
|
Fig 10. Chessboard Layout populated with Person/Place/Thing
|
As we will see later, the naming of the navigation choices for this strategy can be problematic.
3.10 Strategy: A top level choice for each Moment/Interval
What if we move to a system which highlights the Moment/Intervals (pink) classes at the highest level of the UI? In other words, we make an assumption that the Users know what they do for a living. They already know which Roles they are playing and what they do in that role i.e. which Party/Place/Things (green) that they are interacting with. So rather than let them identify the Role Being played / the Action performed, we allow them to identify what they play the role with. What would that give us?
Moment/Intervals (pink) tend to be connected to at least two Role Players and perhaps more. The Moment/Intervals can also be connected to others related closely in the business process and perhaps indistinguishable at the User level. If for example we promote LoanApplication to the top level. What would that buy us?
Well a Customer (green) using his Applicant Role (yellow) has Loan Applications (pink). That collection of applications over time is useful. The current / most recent application is the one of key interest. What other Roles are involved? A Marketer Role (yellow) from a Branch Manager (job specification) who is an Individual (green) who is a System User (yellow) will be proposing the loan. The act of proposing falls to the Submitter (yellow) of Approval Request (pink). The Submitter and the Marketer are the same person (usually). The fourth Role Player interested in the Loan Application is the Approver (yellow) who might be a Regional Manager (job specification) but represented by an Individual (green).
|
Fig 11. Chessboard Layout populated with Moment/Intervals
[ The second level is populated with Moment/Interval Details collected or referenced by the top level MI]
|
Grouping by Moment/Interval gives us a neater way of presenting the top level of the interface. It scales better than Tasks or User Roles. There are likely to be less of them that need to be highlighted within the system. Why? Not all the Moment/Intervals (pink) need to go at the top level of the interface! So how do we tell them apart? Moment/Intervals represent a broad grouping of transactions and business events [Ruble 97] which need tracking for business or legal purposes. We can break that broad grouping down.
The first breakdown that we can look at is Moment/Intervals which cross the business boundary against those that do not.
By its very name, it is obvious that Moment/Interval (pink) classes encompass a number of ideas and types of object. There are Moments in time as well as Periods of Time. There exist, however, several other ways of examining and classifying Moment/Intervals.
A subset within the general grouping is Transactions. A transaction in a business sense is anything which happens which we record for business purposes such as a Sale, a Booking, a Payment.
Another subset is the Business Decision. A Business Decision records a certain action or choice such as an Approval. Requests, Offers, Acknowledgements, Statements, Minutes and many other business events are all broadly similar.
For User Interface interaction design, these Business Events are interesting and are worthy of study with a view to highlighting them in the design.
4.1 DoingBusiness - boundary crossing events
A number of Moment/Intervals in the system will be there to represent the process of doing business. In these cases the pink class is capturing a business transaction which crosses beyond the boundary of the business. Its a transaction between the business and the customer. The model shape for a business boundary crossing transaction would look something like this.
|
Fig 12. Model of a business boundary crossing event.
[ The Party class is shown twice for visual effect, demonstrating that two Party Objects are involved]
|
How could you identify Moment/Intervals which represent boundary crossing events?
Perhaps if only one Party (green) connected through a Role Player (yellow) to the Transaction (pink) also has a System User Role and the other Role Player (yellow) doesn't? Well that would certainly work but what about other workers in the firm who don't have access to the system. Could they be involved in a business event with a Customer? Probably!
So let's consider that only one of the Parties (green) in the Business Event(pink) has a Employee Role Player (yellow)? Well that is a lot better! It catches all the cases where the employee isn't a system user but is it completely accurate? What about the case where an Employee is also the Customer? When a Bank Employee applies for a Loan? In that case the Party Object (green) with the Applicant Role (yellow) would also have an Employee Role (yellow). So we need a more robust definition.
Actually, the only robust method is to set a definition for your Role Players with the Model. Classify each Role Player as being "within" the business or "outwith" the business. In our System we would have Lender, Approver, Marketer, System User all classified as within the business. The Customer, Applicant, Borrower, Depositor would all be classified as outwith the business.
4.2 Business Decisions - internal business events
There is a second set of interesting business events. Those which occur within the business and are essential to the facilitation of doing business. These are vital business decisions, or records involved in coming to a decision. In some ways they are more important for the User Interface than the actual business transactions. Why should this be so?
It depends on the focus of the system!
If you are building an internal use "intranet" system, then the system is there to make the process of doing business smoother. The internal business events are almost certainly of more interest to us when designing the navigation choices.
If, on the other hand, you are designing a direct trading application for use on the web, where the User is the Customer and the system facilitates eTrading then we are more likely to be interested in the boundary crossing transactions. For a moment let's consider the internal business decisions.
Without a decision, it would be impossible to actually do business. The Business Transaction cannot be processed without the internal Business Decisions happening first. A chain of Business Decisions Moment Intervals or interactions with a Business Decision Moment/Interval represent the business workflow to facilitate a task, or action. Making tasks or actions easier to complete is the job of a good User Interface design.
A model shape for a Business Decision might look something like this.
|
Fig 13. A Model Shape for a Business Decision
[ Approval Request (pink), clearly showing the Business Transaction - Loan Application (pink) , which is affected by the decision ]
|
In this example, an internal business decision is required in order to facilitate the business transaction of processing a Loan Application. That business decision is an Approval Request and is represented on the model by an Approval Request Moment/Interval (pink).
A business decision or non-boundary crossing event (pink) is recognised by its Role Players (yellow) which are classified as being within the business. A Business Decision Moment/Interval (pink) will generally have a connection to a boundary crossing Business Transaction Moment/Interval (pink).
4.3 Role Player Description
If you wanted to automate the detection of classification of Role Players, so that you could question a transaction at runtime. You might introduce a Role Player Description class as shown in Fig 14. It would hold information such as whether a certain Role Player is considered as within or outwith the business.
|
Fig 14. Role Players referencing a Role Player Description
|
So, if choose to populate our Chessboard Layout with Moment/Intervals, which ones do we pick? Fig. 13 shows us that often one Moment/Interval relates to another very closely. For the purposes of the User Interface, it may not be useful to show both or to split them explicitly, even though splitting makes sense in the problem domain analysis model.
5.1 Improved Customer Service
If the prime goal of the system is improved customer service through improved and informed response to customer calls - a call center query application for example, then we must provide fast and efficient access to the boundary crossing MIs. We must put Boundary Crossing MIs at the highest level of the Interface in order to respond to a customer query. For example,
A customer calls and asks "has my loan been approved yet?"
Operator: Can I take your name sir?
Customer: [replies]
Operator instigates a Search operation on the Customer Name. A number of results come up.
Operator: Can I have your date of birth for confirmation please?
Customer: [replies]
Operator selects the appropriate name from the results and then presses the top level navigation choice "Loan Applications".
Giving a prominence to Boundary Crossing MIs highlights the fact that the goal of the system is to improve the business processes which cross the boundary of the business. The processes where the business is interacting with Role Players outwith the business.
As pointed out in 4.2, this is also true of direct eCommerce applications where the Role Player from outwith the business - the customer - is actually using the application.
5.2 Improved Business Processes
If the goal of the system is to speed up internal processes, then the customer and the external business events are secondary. In other words, the process is most important, each individual external business event or transaction is irrelevant, they are processed like units on a production line. The key here is to provide a simple solution for those performing the process tasks. We need to highlight the non-boundary crossing MIs which facilitate a boundary crossing one. For example, Approval Requests.
|
Fig 15. Chessboard layout with Business Event Moment/Intervals as first choice
|
By making the internal events available at a higher level we help system Users to access them. A Bank Regional Manager may have a query, "Show me all the Approval Requests for me today?". Puting Appoval Requests at the top level of navigation solves this problem. A filter for today, this week, this month can be provided within it.
Why not put select User at the top level? This implies select "Myself" at the highest level, or select "an other User" at the highest level then select "Approval Requests". Hmmm. Well that might be flexible too! It allows us to view the Approval Request for any User. However, how often would a User wish to do this, compared to viewing there own list? Not often. It makes more sense to show them their own view by default, then allow secondary navigation to others lists.
Does promotion of Approval Request to the highest level make sense for other users?
Lets take a look at some other Job Roles and the roles that they play e.g. Marketer. Do they need to see Approval Requests? Yes, of course, they have a Submitter Role.
So far we have looked at possible top level data navigation choices and strategies for selecting them from the UML in Color Model. They example layouts have hinted at possible 2nd level navigation choices but we haven't examined how to go about identifying and choosing the additional detail for the UI Model.
6.1 Strategy: Populate a Moment/Interval with Moment/Interval Details
When a Business Transaction or Business Event happens there are always a number of details which must be recorded. These may take the form of "snapshots" of otherwise on-going activities or records. For example in a Loan Application, we may be including a copy of the Financial Statements for the Applicant. At the time of the Application, they will be the latest Financial Statements. However, if we go back say 1 year later to view the application, there may already be a new set of latest Financial Statements. Ideally, we need to see the set which were current at the time of the Application. So we must make a "snapshot" of the Financial Statements. In general, Moment/Intervals (pink) will collect a number of "snapshots" of relevant information which contribute to the conclusion of the Business Transaction, Business Event or Decision.
|
Fig 16. Model Shape showing a generic pattern for Moment/Interval Details
|
A Loan Application will collect the details of the Facilities offered. These are specific instances of Loan Products from the available Catalog. The model shape in Fig 16. accomodates this. However, as we have seen before, the shape would need to be enhanced to accomodate additional details for Financial Statements, Account Conduct, Securities Offered and Covering Letter. Consider again the layout from earlier and see how the second level of navigation is derived from the Moment/Interval Details
|
Fig 17. Loan Application with its details as a 2nd level navigation choice
|
If we take a look at a UML Model which represents this part of the system, we can see quickly where the UI Model detail is coming from.
|
Fig 18. A detailed model showing the Loan Application and its Moment/Interval Details
|
The second level navigation choices across the top of the screen are populated with data from the Moment/Interval Details (pink) from the model. A grouping technique has been used to place Income Statement and Assets & Liabilities together into a more task and goal oriented Repayment Ability. Note that the Repayment Ability is not needed as a container class on the UML Model, it would simply be needless embelishment.
6.3 Strategy: Populate a Person/Place/Thing with its collected details
|
Fig 19. Party showing some of the details it must collect or reference
|
Examine the selected Party/Place/Thing (green) which was selected as a top level choice. It will probably be collecting together a number of other green classes which often are given meaning by the association e.g. an Employment Detail is meaningless unless it has an association to an Individual. Then it becomes the Employment Detail for that Individual.
So populate the 2nd level with those additional details. Note the first of the second level choices is simply called details. That is reserved for the details of the main 1st level class. The attributes of Party and the appropriate sub-class such as Individual would be placed under this choice i.e. Customer.Details will show the attributes from the Party and Individual or Organisation classes (as appropriate). The remaining 2nd level choices navigate to views of attributes from the other associated or collected classes.
|
Fig 20. A UI Model showing Party with its 2nd level navigation choices
|
However, using the Party/Place/Thing (green) class name on the UI may not be a good choice. It may not have real meaning to the Users. The naming may be unintuitive. There is another problem too. The other green classes which are being collected or associated by our Party may be there to facilitate one or more Roles which the Party class can play. We may need to name our navigation by one of the roles played e.g. Customer, or we may actually need to change the top level choice to a suitable Role Player. This may actually help to make the user interface more task or goal centric.
6.4 Strategy: Break a Party into two key role players - one outside the business boundary, the other inside
In this example, we show the Roles (yellow) that Party (green) can play, grouped into those inside the business boundary and those outside. We then populate the 2nd level UI Model navigations with collected details which relate from the Party (green) to the Role being played (yellow).
|
Fig 21. Party with some of its Role Players
LHS shows roles outwith the business boundary, RHS shows those within the business boundary
|
So in this example it makes some sense to choose the Customer Role Player (yellow) to represent those outwith the business boundary and the Employee Role Player (yellow) to represent those within the business boundary. So we promote those Role Player names to our first level navigation choice, and the 2nd level choices continue to be selected from the green classes but only those which relate to the appropriate role being played.
|
Fig 22. A UI Model showing Customer Role with its 2nd level navigation choices
6.5 Strategy: Populate a Person/Place/Thing with its Role Players
We can take the previous strategy a step further and consider that we can break a Party/Place/Thing (green) or its key Role Players (yellow) down into the subordinate Role Players as the 2nd level navigation choices. Populating those second level screens or views with data which is only relevant to the appropriate role being played.
If we consider the Party (green) and its Role Players (yellow) that we have just examined in figure 21. We could propose an alternative 2nd level of navigational choice based on Roles.
|
Fig 23. A UI Model showing Customer Role with Role Players as 2nd level navigation choices
|
However, the Role Player names are perhaps not the best choice. In order to derive the best naming, we must look beyond the Role Player to the Moment/Interval (pink). For example, the Applicant Role makes Loan Applications (pink). When we want to know the history of an Applicant, it is the Application details that we need to recall. So here we see the Moment/Intervals (pink) which we have previously suggested can be top level choices, being used as a 2nd level choice via the Role Player with which they are associated.
The Party example from Fig 20. works best when broken into key Role Players as seen in Fig 22. Taking Customer Role as an example, if we break it into its subordinate Role Players we get a design like this.
|
Fig 24. A UI Model showing Customer Role with Moment/Intervals from Role Players as 2nd level navigation choices
|
What about Places or Things (green), can they be treated similarly to Party?
It will depend whether there is a requirement to build significant User Interface views around Places or Things (green). However, there is no reason why they could not be treated similarly.
In earlier examples, we used the explicit class Bank Branch, however it is unlikely that Bank Branch would exist. It is more likely to be modelled like this.
|
Fig 25. A simple Organisation Unit Model with a description class
|
These Organisational Units can play Roles too. Fig 24. gives a highly detailed breakdown of a Bank Branch and its Roles. It would really depend on the system requirements whether such a detailed breakdown and delegation of responsibilities would ever be necessary in the UML Model, however, it is shown as an example.
|
Fig 26. A Bank Branch and its Roles
|
Roles like these could lead to a design which provides navigation choices based on each role. The Advertising Role is hard to express in a name, so I have opted for Advertising Board which expresses the use of the Foreign Exchange Rate Board in the window as an Advertising mechanism.
|
Fig 27. A UI Model for Organisation Unit with 2nd level options based on Roles played.
|
If you look at each of the UI Model Shapes which have been presented for each of the many shape populating strategies, you may notice that any one strategy fails to produce a really satisfactory choice. Perhaps there are too few options at the top level or too many. Perhaps, the second level options aren't ideal.
Remember the initial suggestion for Chessboard Layout - try to achieve a layout of approximately 8 first level choices and 8 second level choices for each first level choice! You can do this regardless of the strategy you like best, by mixing-in results from other strategies. The key is to ensure that you don't overlap.
If say we decide on Business Transactions for the top level. We may get three or four examples from out list of Moment/Intervals (pink). We can add to this top level list by selecting from the important Party/Place/Things (green) or their chief Role Players (yellow). We can also select from other important Moment/Intervals (pink) such as Business Events.
We may end up with a layout such as this.
|
Fig 28. A fully populated Chessboard Layout for our system
|
The choice of which elements warrant selection for top and 2nd level navigation on our Chessboard, is highly dependant on the system specification and the goals for the system.
In the example presented we have assumed that we are building a Retail Banking System with the goal of improving customer service whilst improving performance of the day-to-day tasks involved in Retail Banking. The focus of the design has been on Party/Place/Things (green) which interact with the business through a multitude of Role Players (yellow) and those business boundary crossing Business Transaction Moment/Intervals (pink) which record the day-to-day business of the bank.
In a different domain, or with a similar system that had different goals then we may make different choices.
I have sought to present a mechanism for working from a complex problem domain, UML in Color model and delivering an outline UI Model shape. This will never be more than an outline. It provides the structure for the main views and navigation choices in the system. It is not a full UI Design. Further work will be needed to add in the detail into each view. The data to be displayed and the actions and choices available at each stage.
Basic mechanisms such as "create"/ or "new", "find or "search" are also missing. It is intended that these are grafted onto the basic shape that we have developed as a second stage process.
What has been presented here is a number of strategies for getting to grips with a large and complex domain problem and mapping that problem as simply as possible onto User Interface which can be used on a website, an intranet or for a traditional client/server solution. Those strategies can be summarised by the following paragraphs.
8.1 Highlight the Persons/Places/Things (green) which interact with large numbers of Role Players (yellow)
A Person/Place/Thing (green) which needs a large number of Role Players to interact with the rest of the system must be playing a major part and its significance may warrant its selection as a top level choice for the UI.
8.1.1 Sub-divide into details breakdown - a collection of other Persons/Places/Things (green)
Second level choices for navigation can be made by examining the related green classes which make up the whole information that we know about the Person/Place/Thing. Typically you might have Address, Employment Details or Education Details. You may find that a certain sub-set of the green classes applies to a particular Role Player (yellow) such as Customer Role. It may then make sense to rename the top level choice after this key Role Player rather than the green class itself.
8.1.2 Sub-divide into Roles Played (yellow)
Alternatively, organise the 2nd level choices based on each Role Player (yellow) for the chosen Party/Place/Thing (green). Then on each of these views present data which relates to the Party/Place/Thing for the Role being played.
8.1.3 Provide context sensitive actions or tasks
Making the navigation choices and selecting the views to be presented is not enough. You must consider grafting additional detail onto the shape for actions such as "Find", "New" and context senstive actions which change the state of the data such as "Approve", "Reject".
You may choose to do this with pop-up menus, a traditional menu bar or even modal dialogs or wizards.
8.2 For improved Customer Service, highlight the Business Transaction Moment/Intervals (pink) which cross the business boundary
If the main goal of a system is improved Customer Service, Customer responsiveness or Customer Satisfaction then the Business Transactions represented by pink Moment/Intervals will be particularly important to highlight in the User Interface. Use the most common or most important of these Business Transactions as top level choices.
8.2.1 Sub-divide into the collection of Moment/Interval details (pink)
In order to select 2nd level choices for you Business Transactions take a look at the other Moment/Interval Details (pink) collected or referenced by your chosen Business Transaction Moment/Interval. These additional pink classes should be used as the 2nd level choices.
8.3 For improved Business Processes, highlight the Business Event Moment/Intervals (pink) which don't cross the business boundary
If the main goals for the system are more closely related to improved efficiency or improved flow of "paperwork" around the organisation, or better tracking of internal processes, then it is likely that you want to highlight Business Events in the User Interface. Business Events will be represented on the UML Model by pink Moment/Interval classes.
Select the Business Events which fit closest with the desired goals for the system such as "faster turnaround on approval request for a loan", and place Business Events such as Approval Request at the top level of the Navigation UI Model.
8.3.1 Sub-divide into the collection of Moment/Interval details (pink)
Again as with Business Transactions, the Business Event may have a collection of details which are required to make a decision. These will be Moment/Interval Details (pink) collected or referenced by your chosen Business Event Moment/Interval. or previous or subsequent Moment/Intervals. These additional pink classes should be used as the 2nd level choices.
8.3.2 Sub-divide by the progression of Moment/Intervals (pink) in the process
In some cases the Business Process may be represented by a series of Business Event Moment/Intervals. No one Business Event has sufficient meaning or strength to carry as a top level choice. Perhaps the process passes through a number of Role Players (yellow) and each Role Player interacts with a separate Moment/Interval. In this case, name the top level choices according to the process involved e.g. "Disburse Loan" and select the series of Moment/Intervals in the progression of the process as your 2nd level choices.
x.8.3.3 Sub-divide by the states of the Moment/Interval (pink)
8.4 Mix the results from each strategy to obtain a well balanced design
Any one strategy may not give an optimal design. You may only have a few menu options at the top or second level. Take advantage of this and populate some more squares on the chessboard with choices from other strategies. This is effectively overlaying one population strategy with another and why not?
There are many tasks to perform with the system and different strategies will help in different ways. When a User has a certain Task or Goal in mind, the appropriate option will "leap" out at them from the available set. They will ignore the other options providing there aren't too many. A small number i.e. around 8 will help. The user won't have to scan down through a huge list deciding what is and is not appropriate.
UML in Color was first used in Singapore on a large banking project - one of the largest Java business application projects so far. The User Interface was designed with a more technology neutral approach detailed in my White Papers, User Interface Analysis and User Interface Modelling.
The techniques detailed here were later extracted from analysing the Object Model and how it manifested itself on the User Interface. The observations about the importance of Moment/Intervals and whether or not they cross the boundary was made by Phil Bradley and based on the Data Modeling work of David Hay [Hay 96]
Since then I have tried the technique in mock modelling and analysis sessions on other domains such as Telecom Billing and Recruitment. I believe that it gives a very robust and easy User Interface navigation system and should allow technical Object Modellers and Systems designers to develop a fairly simple, a-modal User Interface which is robust to change and minimises the number of screens to be designed and developed, without resorting to a UI Designer, Human-Factors department or Usability Team. Naturally, I believe that the use of trained, professional Interaction Designers will always lead to a better solution. However, the technique presented here will go a long way to providing a very usable system which maps closely to the Object Model.
It is not however the total solution. As well as understanding how to divide up a domain for navigation, it is also important to realise how to group and display data and when to make the appropriate actions available. The layout itself is not a complete UI design without those actions. Adding actions is a further layer of embellishment which must be undertaken, based upon the requirements for the system. For each top level navigation choice there will be inevitable actions such as "Find" and "New".
Hopefully this paper has demonstrated that it is possible to achieve a simple and accessible Navigation Models for a very complex problem domain without resorting to huge numbers of menu choices or many layers of hierarchical menu. Naturally, it relies completely on the ability of the original UML Modeling team. If you have faith in your model then you should be able to develop a good, clear, usable User Interface.
As such this represents an experimental area of work which I intend to pursue in greater detail and with other UI Patterns and Navigation Model shapes. I believe that it offers some significant hope that a genuinely repeatable and reliable navigation modeling system could develop from Problem Domain Analysis. The objective would be offer up the superset of navigation possibilities, then allowing the User Interface designer and/or usability team to eliminate navigations which were not required to meet the functional specification.
[Anderson 99] User Interface Analysis White Paper, David J. Anderson, http://www.uidesign.net , February 1999
[Coad 99] Java Modeling in Color with UML: Enterprise Components and process, Coad P., Lefebvre E., De Luca J., Yourdon Press, Prentice Hall, 1999
[Coad 97] OO Modeling Workshop, OOPSLA' 97
[Coad 97-2] Object Models: Strategies, Patterns & Applications, 2nd ed., Coad, Mayfield & North, Yourdon Press, Prentice Hall, 1997
[Hay 96] Data Models, David C. Hay, Dorset House, 1996
[Ruble 97] Practical Analysis and Design for Client/Server & GUI Systems, David A. Ruble, Yourdon Press, Prentice Hall 1997
|
Acknowledgments
I would like to thank Philip Bradley whose comments regarding transactions crossing or not crossing the business boundary whilst reviewing the User Interface Analysis paper from February, led directly to this investigation and body of work.
Jeff de Luca, Stephen Palmer, Eric Lefebvre all added their review comments.
The Class and Statechart Diagrams for this paper were produced using Together/J from Togethersoft
|
|