User interface functionality modeling languages?

Question

I am looking for a user interface functionality modeling language (UML-like "thing", but for user interfaces) that is already accepted and possibly has its own design patterns and handles the problem better than a state or activity diagram.

This question recalled as a result of the fact that UML and its diagrams cannot describe the complex functionality of the user interface with an event-driven execution flow (i.e. large javascript / jQuery projects)

EDIT: I was thinking about using BPMN , but it was not created for this purpose.

Answer 1

Perhaps prototypes of the user interface or storyboards can be useful ... they are not part of the "modeling language", but have proven very good when developing a graphical interface ...

Answer 2

One thing that comes to mind is Jesse James Garrett Visual Dictionary for Information Architecture.

Answer 3

I do not think that there are any standards for this specific purpose (I was thinking the same thing the other day). SysML is close, I think, although it is definitely redundant.

Basically, I thought that if a UML profile or metamodel is defined with components and events of the main interface ("text box", "one click", etc.), various user interface implementations (HTML, Swing, AJAX) can be generated using transformations on instances of XMI models. Given that, at least, there will be a clearer and more formal way of describing the functionality of this user interface.

Answer 4

You can use traditional modeling notations to model the user interface, but it soon ends with messy and useless models. You should consider models like WebML (it will soon become the OMG standard called IFML ). In this case, you will also get a free WebRatio modeling tool that provides rapid prototyping and integration with BPMN specifications.

[Disclaimer: I am with Politecnico di Milano and WebRatio and among the inventors of WebML / IFML]

Answer 5

I just stumbled upon your question, and this is a problem that I take seriously. Here is my answer to this question, and I have used it in various forms for over 20 years.

Basically, here are the criteria I'm looking for in such a descriptive language:

• The language should not be irrigated and incapable of such things as data access or basic primitives for flow control, such as IF, FOR calls, and subroutines. I accomplish this by creating a language on top of a basic standard language using macros and function definitions. Thus, it does not require a parser or interpreter, has direct access to application data and has primitives of the control flow of the main language (but only some of them).
  The reason for including flow control primitives in a descriptive language is their descriptive usefulness. The IF (test) -ELSE-END construct is a way of saying that one of the two sets of controls should be displayed depending on the value (test). The FOR - END construct is a way of saying that a set of controls are displayed in multiplicity, for example, a linear array of controls. They can be nested to obtain a 2-D matrix of controls, if necessary. A subroutine (with parameters) can display a set of controls and then can be called in several places to replicate this set several times. Without such primitives in DSL, such structures are difficult to define.

• The language should not require the user who defines the user interface to deal with problems that are implementation-only, such as handling input events, creating, deleting, and naming controls and moving data between controls and application data. So, for example, each edit, button, or other control is a single line of code. The code for handling events, such as clicking on a button, is written directly next to the line of code defining the button (not in a separate function or closing). Binding controls to application data is handled "under" and is not a problem for the user interface programmer. To do all this, it is based on a management structure called Differential Execution, which I stumbled upon in 1986. It is based on incremental re-execution of the program so that it can gradually update its output. In this case, the output is a set of controls on the surface of the window. These controls are automatically created, deleted, moved, or otherwise changed in response to changes in the state of the application, without the need to program the user interface in terms of state changes.

I used this only in the desktop user interfaces, and I almost did not do any web development. I am pretty sure that the same principles can be applied to web interfaces and that this has not yet been done.