2008/07/18

Part four: Modeling the user interface

kick it on DotNetKicks.com

In the previous part of this tutorial, we modeled the business logic of the application. Now, we are going to define how the user interface is going to look like and which functionality and data is to be presented to the user. If you do not already know the running application prototype, I would suggest you to check it out: http://www.blogger.com/post-edit.g?blogID=2481650812860323753&postID=7311055574856183066#.

The user interface modeling is very important for the application because we all know that an application that is uncomfortable to use will never be used. So, we listen to the “customers” requirements, which are the following:

I need an interface that allows me to administer things such as departments, cost units, cost centers, cars, receipt types, travel cost groups and users. This part of the application is to be called “administration”.

The user interfaces for managing trip requests from the employees and the managers perspective should be optimized for usability as they are supposed to be the most frequently used part of the application.

All business objects should if possible be selectable in a dropdown list when processing data in forms.

The administration part of the application needs to provide the functionality to create, edit and delete the mentioned business objects as already (partially) specified. If nothing else is mentioned, a business object can only be deleted from the database, if it is not referenced anywhere else. So, for example, if a Car is used for a trip, the car cannot be deleted unless the trip request is also deleted.

You might think now that this requirement is strange as it does not match the needs of a real-world application. The reason why I chose the requirement to be like this is because this is just a demonstration of the application, although this can be further developed in the future. Just in case, I will specify another more complex exception from the rule above:

If a receipt type is to be deleted, the administrator should get the possibility to define another, previously defined receipt type that is going to replace the receipt type that is to be deleted for all referencing trip requests. The new receipt type should be selectable by a dropdown list and that input parameter has to be mandatory. Of course, the dropdown list must not contain the receipt type to be deleted. If, however, there is no trip request referencing the receipt type the user wants to delete, the administrator is not required to specify a new receipt type and the input parameter in the user interface is disabled.

If it is possible to implement this feature for the class ReceiptType, it should also be obvious that the same feature could be implemented for any other comparative class, with almost arbitrary complex logic.

When creating a new trip request ("travel application"), the application should ask the employee whether he or she wants to enter receipts for the trip request just created. If so, the application should display the form for adding a receipt to the trip request. If creating the receipt succeeded, the application should ask the user if he or she wants to enter another receipt or if he or she wants to return to the trip request overview form.

Let's move on from specifying and start to model those (and all other) requirements concerning the user interface.

The user interface can be modeled when clicking on the eye-button on the modeler toolbar. The following dialog window pops up and gives us the option to define views and services, navigations, filters and so on.




As you can see, each class modeled in the class diagram is listed underneath the so-called “Conceptual Schema”. For starters we need to define a list view on the administrator objects and need to provide a way to access the services create_instance and delete_instance of the class Administrator.

I will briefly explain the concepts you see on this screen. For each class, you can specify default patterns that are used in the user interface if you do not specify explicitly an interaction pattern. Currently, there are three default interaction patterns that we can define:

  • Instance IU is a interaction unit that displays data from a single object, you can define which attributes of the object (or associated unary objects).
  • Population IU represents a list view of a set of objects of the selected class. Here, you can specify filters on that class, the attributes to display, order criteria and so on. We will come back to this later.
  • Supplementary Information: sometimes, it is useful to display additional information to the user when he just selected an object in a subform. The Supplementary Information pattern defines which attributes are displayed to the user in this case.

Of course, there are a few more presentation concepts, but for now, we will create a Population IU in order to provide a view to display and control the available administrators of the system. If I click on the + button beneath the dropdown that says “(void)”, the following window pops up and lets me specify presentation patterns specifically for this view:



So, here you can see several input fields. The name needs to be unique for the model, the alias is the text that is displayed in the user interface whenever the Population IU is used in the application. “Nr. Instances” is the default value for the number of instances to be displayed when loading the data into the view.

Moving on to the second tab: definition. This is by far more interesting, as you can define which attributes should be displayed in the view, which order criteria should be offered and which filters upon data should be offered to execute.



As a first step, we leave the displayset (Auto) as it is because the class administrator has only one attribute and so we do not need to create an additional displayset.
Next, we define a simple order criteria by clicking on the + button on the right border of the order criteria section. I defined the order criteria shown in the screenshot to sort the instances alphabetically by the attribute id.

I will explain the Filters in a more complex example for you later on.

The third tab lets us specify additional patterns for the view. I will not dive any further into details but want to tell you that you can specify which services can be accessed from the view, which related objects can be navigated to and which service should be directly attached to the data view in order to edit data faster.

I could document dozens of further features but as I have limited time for this tutorial, I just modeled the following features in 1.5h:

  • Defining the menu navigation
  • Creating the wizard-like interaction dialog that allows the user to quickly decide whether to add receipts to a travel or to return to the overview screen
  • Adding grid-inline-editing features for Population and Instance IUs
  • Providing other filters on data, including a administrative filter on receipts that has (amongst other controls) two dropdown input fields: one lets the user choose a department and the other lets the user choose an employee – but if you try out the application, you’ll notice, that I also implemented a dependency between those two dropdown lists. The list of employees is automatically repopulated when the selection in the department dropdownlist has been changed
  • Defined additional order criterias
  • Grouped service input fields
  • etc.


Stay tuned for the last part of this tutorial that will show you how to generate the code from this small and simple model!

kick it on DotNetKicks.com

Keine Kommentare: