User Interface functionality modelling languages?

I am looking for a UI functionality modelling language (UML-alike "thing", but for user interfaces) that is already accepted and maybe has its design patterns and handles th开发者_Go百科e problem better than state or activity diagram.

This question came to mind as a result of a discovery that UML and its diagrams fails at describing complicated UI functionality with event-driven flow of execution (ie. javascript/jQuery big projects)

EDIT: I've been thinking of using BPMN but It was not created for this purpose.

Maybe user interface prototypes or storyboards can be helpful ... they are not part of a "modelling language" but very well proved techniques for designing GUI ...

One thing that comes to mind is Jesse James Garrett's Visual Vocabulary for Information Architecture.

I don’t think there are any standards out there for that specific purpose (I was thinking of the same thing the other day). SysML is close, I think, although it is definitely overkill.

Mainly, my thought was that if a UML profile or metamodel is defined with core UI components and events (“text-field”, “single-click”, etc.), different UI implementations (HTML, Swing, AJAX) could be generated using transformations on an instance model’s XMI. Barring that, at least there would be a more clear and formal way of describing the functionality of a given UI.

You can use traditional modeling notations for UI modeling, but this soon ends up with messy and useless models. You should think to domain-specific models like WebML (soon to become a OMG standard under the name of IFML). In this case you also get a free modeling tool called WebRatio that provides quick prototyping and integration with BPMN specifications.

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

I just stumbled onto your question and it's an issue I take seriously. Here's my answer to that question, and I've used it in various forms for over 20 years.

Basically, here are the criteria I seek in such a descriptive language:

• The language should not be watered-down and incapable of things like access to data or basic flow-of-control primitives like IF, FOR, and subroutine calls. I accomplish this by building the language on top of the underlying standard language, by means of macros and function definitions. Thus, it requires no parser or interpreter, has direct access to application data, and has the control-flow primitives of the underlying language (but only some of them).
  The reason for including flow-control primitives in the descriptive language is for their descriptive utility. The IF(test)-ELSE-END construct is a way of saying that one of two sets of controls is to be displayed depending on the value of (test). The FOR - END construct is a way of saying that a collection of controls to be displayed in a multiplicity, such as a linear array of controls. These can be nested to get a 2-D matrix of controls, if desired. A subroutine (with parameters) can display a set of controls, and can then be invoked in multiple places to replicate that set multiple times. Without such primitives in a DSL, structures like that are difficult to specify.

• The language should not require the person specifying the UI to have to deal with issues that only exist for implementation's sake, such as input event handling, creation, deletion, and naming of controls, and movement of data between controls and application data. So, for example, each edit, button, or other control is a single line of code. Code to handle events such as a button-click is written directly adjacent to the line of code specifying the button (not in a separate function or closure). Binding of controls to application data is handled "underneath" and is not the concern of the UI programmer. In order to make all this work, it is based on a control structure called Differential Execution that I stumbled upon in 1986. It is based on incremental re-execution of a program in such a way that it can incrementally update its output. In this case the output is a collection of controls on the surface of a window. Those controls are automatically created, deleted, moved, or otherwise modified in response to changes in the application state, without the UI programmer having to think in terms of state changes.

I have only used this in desktop UIs, and I have done almost no web development. I'm pretty sure the same principles could be applied to web UIs, and that it hasn't yet been done.