Abstract form

What is a UI Only Interaction

Posted in Dig and Win, Modeling by Homam Hosseini on December 29, 2008

In our business documents we use a concept named “transaction” to describe requirements and workflows. A transaction is simply a list of jobs including the roles that perform them and their sequential relationship. Although I am not satisfied with this approach, as it is not a standardized discipline, I worked to improve it, you know when your boss keep talking about some sophisticated ideas for more than a year, you have little choices but to endorse his ideas.

Anyway, I was working to model how we deal with UI in this transactions approach yesterday, I thought it’s a good idea to record my work here because I have doubts we ever use my model 🙂

In business documents describing transactions we define some UI elements related to transactions. So a transaction, lets call Tk has a collection of ejTk of UI elements associated with. A UI element could be a composition of other UI elements, in my notation: ejTk = {viejTk}. In contrast with ejTk These viejTk are a matter of importance for UI designers.

image

image

Em is a composite UI element:

image
A transaction (or user interaction) in user perspective changes viejTk to vi’ej’Tk’. The interaction T will be a UI only interaction if and only if j = j’ and k = k’. Business documents don’t deal with these kinds of interactions because they are not part of a transaction. For example if transaction T requires a pack of data D to be collected in UI, the UI designer has freedom to collect all the D in a single form or a wizard (utilizing multiple UI only interaction). The business document that described T has stated there’s a UI element ejT that collects D, it does not matter for the business document if ejT is a composite element or if the UI designer introduces several UI only interactions.
image
This is a transaction as is seen in UI:
image
This is a generalization of the concept:
image
Advertisements