Presentation of the Usi4Biz Platform at Hasselt University

Last Thursday we presented the Usi4Biz Framework in the Expertise Centre For Digital Media (EDM) at the University of Hasselt, Belgium. We were specially happy about the discussion after the presentation, when the task model was put under pressure by an audience of model experts. It was an opportunity to reinforce the arguments that we have been using to justify the need for this model, which is so left aside by the market.

Presentation at University of Hasselt

Presentation at University of Hasselt

The task model is one of the most used and discussed models in the Human-Computer Interaction (HCI) scientific community. But it is so unknown out there that the term “task model” doesn’t even have a definition in the colossal Wikipedia so far. When you search for this term, you will probably get “Did you mean: tsk model“, which is related with the thermodynamics of crystal surface formations, a totally different concept. Despite the almost complete lack of adoption by the market, the task model continues to be widely explored by the scientific community, as an essential tool to describe the behavior of information systems and their end users.

If the task model is so ignored by the market why did we decide to adopt it anyway? First of all, we are glad to be the first one or one of the first projects to present the task model to the market in a way that they didn’t reject it as one more model to make them fatter and inefficient. The task model was considered in the Usi4Biz Framework to intermediate the communication between two different domains: business process and user interaction. People have tried to connect these domains directly by declaring which user interface is used to perform each activity of the process, but this approach seems to be very simplistic, not addressing most of the real world situations, where user interfaces becomes more and more complex, not forgetting legacy systems which don’t have any kind of support from existing business process frameworks.

Nowadays, companies are rethinking about their adoption of models because some software development methodologies are innovating the way requirements and architecture are elicited. Widely used models as the UML ones are gradually being disposable with less people using tools and more people just sketching them and throwing them out later. However, some models are resisting very well, which is the case of the business process model and the data model. The first one is going well because companies are investing in corporate governance and describing their operations through business process models to become more communicative and transparent. The second one is also very relevant because data and the way it is organized is extremely import for the company. Entity relationship models are an essential source of information for all those who develop business applications. These models are relevant for two main reasons: 1) they are used to communicate and teach; and 2) they save resources by generating precise artifacts to the development team. In order to provide the same benefits for the company, we have made 2 decisions that may transform task models in an essential model as well. The decisions were:

  • Don’t force companies to change what they already have established: task models will not replace any useful model adopted by the company. Instead, it will increase the value of existing ones by addressing details they do not consider, like the end user interaction. Therefore, the adoption of the task model will not demand any adjustments on existing business process models and user interfaces. It will be inserted to connect both worlds, no matter how they are designed.
  • Take a mature representation of the task model and simplify it as much as we can: we want to demonstrate that the adoption of a new model is not so time consuming and unnecessary. If you have the chance to describe how people perform your business activities without falling back on long and boring text descriptions, instead, using a simplified model that doesn’t have so many structures to memorize and without any redundant information, you will see that time and money are actually saved.

A mature representation of the task model was proposed by Fabio Paterno, from University of Pisa, Italy. It is widely used by the scientific community because of its rich representativity. Most of the current evolutions were made on top of that initial proposal. However, when a specific context of application is chosen then the task model can be refined to address specific needs, which was our case when working on the corporate environment.

What changes we made and why are subjects for another post. Follow our updates and join the discussion.

This entry was posted in User Experience and tagged , . Bookmark the permalink.

2 Responses to Presentation of the Usi4Biz Platform at Hasselt University

  1. J.S says:


    I totally agree with you sentence : “If you have the chance to describe how people perform [...]
    you will see that time and money are actually saved.” Models (e.g., descriptions of something) are something to enhance productivity, comprehension, documentation and, I hope software maintenance and evolution. Current work on Model Driven Engineering(MDE) already shown the gain in productivity of models. But as you said, it is still not convenient in all cases : ” Don’t force companies to change what they already have established”.

    For sure Task model (as Patterno describe it) is not convenient for any case. It is supposed to be quite independent from the actual interaction (e.g., 3D, vocal, etc.). For example describing vocal interaction (where all task are accessible by keyword) gives a unclear linear model. I mean the problem of Task model is that is is more or less a “tree” (Some UML state-charts, activity diagram can gives support to express interaction).

    Finally, I strongly agree with your statement : ” However, when a specific context of application is chosen then the task model can be refined to address specific needs”. The clue of the problem may be to design a Domain Specific Language (DSL) which ease the description of specific needs. But DSL itself don’t solve the problem, you’ll need to have a really efficient modelling framework to support this.

  2. Hi,

    Thank you for your feedback. It emphasizes the importance of the topic. We hope we could contribute somehow to your reflections in order to change for better the way how people look at models today and beyond.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>