Your SlideShare is downloading. ×
Scaladays 2011: Task Driven Scala Web Applications
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Scaladays 2011: Task Driven Scala Web Applications

4,916
views

Published on

Published in: Technology, Education

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,916
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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
  • Caveats:
  • Transcript

    • 1. Task Driven ScalaWeb Applications
      Timothy PerrettScalaDays 2011
    • 2. About Me
      • Committer on Lift core
      • 3. Author of Lift in Action
      Coding Scala since 2007
      • Background in both dynamic and statically typed languages
      • 4. Manufacturing and marketing automation is my day job
      http://manning.com/perrett/
    • 5. Agenda
      Existing drawbacks
      Task-based future
      Core analysis concepts
      Example Wireframes
      Interface <-> Domain interaction
      The role of CQRS / DDD
    • 6. Round Peg.
      Square Hole.
    • 7. “…For the majority of customers, each feature or procedure is a frustrating, unwanted puzzle...”
      Microsoft Research
    • 8. Oh Noes!
    • 9. There is a Better Way.
    • 10. “…User interface design needs to become more engineering rather than a pure creative or artistic process…”
      Martijn van Welie
    • 11. Task BasedAnalysis.
    • 12. Analysis Model
    • 13. Analysis Model
    • 14. Analysis Model
    • 15. Analysis Model
    • 16. Analysis Model
    • 17. Analysis Model
    • 18. BeAsynchronous.
    • 19. Task ! Event
    • 20. Asynchronicity
    • 21. IntegratedClients.
    • 22. Example: Server Side
      class Sample extends CometActor {
      ...
      override defmessageHandler = {
      case EmergencyNotification(msg) =>
      partialUpdate(
      Call("nameOfJSFunc", msg).cmd)
      }
      }
    • 23. Example: Client Side
      function nameOfJSFunc(message){
      // do something awesome to
      // notify the user
      }
    • 24. HiddenBenefits.
    • 25. WithDDD?
    • 26. Compatible overlap in linguistics
    • 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
    • 29. Questions?
      twitter.com/timperrett
      github.com/timperrett
      blog.getintheloop.eu
      Lift in Action
      manning.com/perrett/