27. Summary Task-based analysis provides an abstract for the entire task world Mental model that is wholly compatible with powerful patterns like DDD and CQRS Capture UI interaction with true user intent Slick real-time UIs with Lift’s comet support Scalable domain and service layers from Akka
28. Further Reading Task-Based User Interface DesignMartijn van Welie Inductive User InterfacesMicrosoft Reasearch Moments of SignificanceDix, Chisalita, van der Veer The Inmates are Running the AsylumAlan Cooper Online TB analysis example: http://is.gd/BwGtxO UI Pattern Library: http://is.gd/5mVGKE
Afternoon everyone; welcome to this talk on Lift the web framework for Scala.
Before we get started with the presentation here’s a little information about me.** CLICK **I’ve been working on the lift project for around 2.5 years and using it in production for about 3 years. I work on a lot of different aspects of the framework but I am particularly interested in localization and process abstractions within Lift core. I also use Lift during my day job as do most of the other committers so in that sense we are not just making a framework for the sake of it, what we put into lift are real-life abstractions from the field ** CLICK **I am the author of a new book called Lift in Action, available on Manning publications. At the end of this talk I will be giving away a 40% discount for people who are interested in learning more about Lift.** CLICK **CodingScala since the end of 2007 – both with Lift and standalone Scala applications** CLICK **Before I came to the scala community I was working extensively with Ruby, along with Rails. Before that I was coding a lot of Objective-C and Java for desktop applications. ** CLICK **My day job is producing interesting sections of middleware for marketing automation and cross-media marketing for a division of Xerox corporation.** CLICK **
Love thy user!Ultimately, someone, a real, living person is going to be using the systems we create so it seems somewhat mad to present an interface that is simply convenient for developers to make. These CRUD-style, or so called “Smart Uis” are often a disaster both in terms of the user experience itself and the representation of verbs in the ubiquitous language of the application domain. When users update records in the UI, you cannot capture the intent of that action, only diff the previous and new states of the represented object and thus see what changed, rather than why it changed. Broadly speaking, use of these types of interface conveniences result in exceedingly suboptimal and confusing experiences that users never fully understand. There must be a better way: I’m sure we can do better
Here’s a classic example of a developer created user interface that is a 1-1 mapping in user interface and data model. Each control no doubt directly relates to an attribute on the data model or structures represented in the code… whilst this may be a more extreme example, its fairly indicative of the kinds of mistakes often made when building application interfaces, both for web applications and on the desktop. It’s important to note that the actual UI toolkit used in this example is completely separate from the model used to arrive at the interface itself. If you’re using straight HTML, GWT or Lift or anything else for that matter, the salient point is that often developers make the mistake of directly representing the data structures in forms on the interface.
There is a better way: task based interfaces and analysis.In the early 2000s there were several individuals and organizations alike who had recognized the deficiencies in the CRUD approach; specifically, a Dutch researcher called Martin van Weille released his PhD thesis studying task-based interfaces and around the same time Microsoft research released a paper on so-called “Inductive User Interfaces”. I’m sure many of you here have been in a talk on DDD or CQRS that has perhaps had a single bullet point mentioning task based user interfaces and referencing the Microsoft paper, but whilst both papers share the idea of putting the user and their interaction intention right in the heart of the interface design, TBUI and IUI actually target different segments of the software marketTBUIs are really designed for applications that are regularly used and often have “power users”, whilst IUIs are typically put in place for large scale consumer software that is infrequently used, and in many cases IUI will fall down in situations where power users are present as they often feel like they have to do too many things in order to achieve the simplest operation. It is however worth noting that both TBUI and IUI style approaches are no good for systems that are largely devoid of humans. Rather they are specifically designed for analyzing and implementing intuitive systems that are used by real people.
The first part of task based analysis is the idea of a goal, or a desired state of the task world. That is to say, task based analysis looks at every single part of a business operation, otherwise known as the task world which includes actions and operations for all parities: the business, its customers and everyone (or thing) that interoperates with the goals. Examples of a goal could be something as simple as “Deliver Package” if you were building a logistics system, or “Provide lodging” if you were a hotel operator. The goal concept is an encapsulation of the a desired state of the task world. GOALS=====- Order Pending- Order Ready to ship- Order Dispatched- Order Delivered
In order to achieve goals, tasks must be completed which in and of themselves may have subordinate task items. This is key to the flexibility of task based analysis as you can build up sophisticated trees of tasks where a given task requires that other tasks be completed before the calling task can be deemed complete. In this way, goals have many tasks.TASKS=====+ Gather Order Items|_ Pick Items|_ Pack Items- Create Consignment- Assign Consignment to Transport- Reassign Consignment to Alternative Transport- Collect Route Consignments+ Operate Delivery Route|_ Deliver Consignment- Sign for ConsignmentROLES=====- Service Order (Gather Order Items, Create Consignment)- Logistics Co-ordinator (Assign Consignment to Transport)- Driver (Collect Route Consignments, Operate Delivery Route)- Contact Person (Sign for Consignment)AGENTS======- Picking Line Worker (Service Order)- Shift Fleet Manager (Logistics Co-ordinator)- Delivery Person (Driver)- Consignment Recipient (Contact Person)EVENTS======- Item Picked - Item Packed- Consignment Created- Consignment Assigned to Vehicle- Consignment DeliveredGOALS=====- Order Pending- Order Ready to ship- Order Dispatched- Order DeliveredOBJECTS=======- Consignment- Item- Van
The next component is known as “object”. This is of course a very overloaded term in computer science circles but in the context of task based analysis an object represents something that the task represents. So, for example, if you were again providing a hotel booking system, “Passport” might be a legitimate object as any booking task would need to collect passport information from guests. It’s important to note that “object” can be both tangible things that exist in the real world, and also intangible concepts. For example, in addition to passport information the hotel would need to collect the address of the visiting guest and as this would need to be interacted with from other tasks that use the address information it should be modeled as an object.
Events.Now things get interesting. Events trigger tasks to take place, and typically encapsulate a change in the users task worldEVENTS======- Item Picked - Item Packed- Consignment Created- Consignment Assigned to Vehicle- Consignment DeliveredGOALS=====- Order Pending- Order Ready to ship- Order Dispatched- Order DeliveredOBJECTS=======- Consignment- Item- Van
A role is essentially a someone or something that is response for a particular task and as with objects and tasks the roles can be hierarchically composed. ROLES=====- Service Order (Gather Order Items, Create Consignment)- Logistics Co-ordinator (Assign Consignment to Transport)- Driver (Collect Route Consignments, Operate Delivery Route)- Contact Person (Sign for Consignment)
Agents are, in the typical use case a human players that interact with the application. The important definition is AGENTS======- Picking Line Worker (Service Order)- Shift Fleet Manager (Logistics Co-ordinator)- Delivery Person (Driver)Consignment Recipient (Contact Person)
Be AsynchronousA few slides ago we spoke about how CRUD interfaces simply are not servicing the
Integrated Clients
Hidden BenefitsRich diagnostics from capturing user intentProactively handle issues before they have even been reported by usersUI layer is largely a thin clientUser closer to the domainDesigners working in parallel with developers
For those in the audience who may have done any kind of DDD-style development before some of the analysis terms may well be familiar, and indeed there is a fair degree of overlap with some of the concepts between task based analysis and DDD. Specifically though, this overlap is a compatible one, and by utilizing a task based user interface you can effectively represent the
CQRS does not demand TBUIDDD requires a TBUINecessary for verbs in the ubiquitous language
![About Me ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)