5

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 the 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.

naugtur
  • 16,827
  • 5
  • 70
  • 113
  • There are some technology specific DSLs, but no standard I know of. So please, before you create anything, if you want it to be useful, think of different UI paradigms (not all dynamic behaviour is always supported). Please don't make it technology specific and please consider textual syntax for such a specification. If you choose the textual path, look into Eclipse TMF Xtext. – Gabriel Ščerbák Apr 05 '10 at 14:34
  • I know this question is quite old, yet after 9 years I feel there is no good answer for UI functionality modeling. Did you find some solution @naugtur after these years? – Wojciech Dobry Aug 15 '19 at 17:39
  • Although not a solution to this, Event Modeling is a new workshop method for collaboratively documenting interface functionality. Check it out. – naugtur Aug 22 '19 at 21:23

5 Answers5

3

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 ...

wj.
  • 2,001
  • 3
  • 18
  • 19
  • UI prototypes are only for usability means of static interfaces. The storyboards stuff looks better, but they don't seem to have any specification. I'm not sure if it can be rated as "better than state diagrams" ;) and it remonds me of BPMN http://en.wikipedia.org/wiki/Business_Process_Modeling_Notation – naugtur Feb 04 '10 at 15:13
3

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

Jaanus
  • 17,688
  • 15
  • 65
  • 110
2

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]

Marco Brambilla
  • 466
  • 2
  • 7
2

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.

dallasvaughan
  • 21
  • 1
  • That's close to what I've been thinking. I'd also add a new way of representing events on the diagram. – naugtur Mar 04 '10 at 11:38
1

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.

Community
  • 1
  • 1
Mike Dunlavey
  • 40,059
  • 14
  • 91
  • 135
  • It seems like You skipped some parts of my question. I was talking about a non-programming language. It's supposed to be more like a UML diagram as I said - for documentation predecesing any implementation of a GUI. So You are talking about creating GUI from an application, whereas I asked about stuff for GUI architects to use that can handle functionalities/behaviours instead of the look and positioning. – naugtur Apr 28 '10 at 17:09
  • As for Your answer which also tackles interesting stuff, I am more in favour of having a programmer think only in terms of events / state changes. Being able to forget about interface problems would be nice, but then You loose control of the 'looks'. And most requests form clients are like "it's nice, but put this on top of that and give it some gradients glows and shadows". And it's back to digging in interface technologies. That's why I think there should be no binding controls, but interface should be a client to the application acting like a server. [continues in next comment] – naugtur Apr 28 '10 at 17:15
  • [continuation] Then logic only has to have a kind of api and the client is mostly just a interface+connectivity application that is easy to maintain by an interface guy. Any abstraction over interface controls makes it hard to easily and quickly do any stupid useless change that client wanted just because it looks better or his graphics designer found out some new photoshop tricks. I've seen (web) projects fail just because they couldn't adapt a ready solution to clients expectations about serving data as a table instead of making user click every item to read details. – naugtur Apr 28 '10 at 17:24
  • I'd enjoy a longer discussion without character limits. Any ideas? ;) – naugtur Apr 28 '10 at 17:25
  • @naugtur: You're making good points, and there are multiple ways to think about it. I did a PhD in AI in the 70's, and a key concept was *what is a good representation*. For example, Terry Winograd explored *Procedural Representation of Knowledge*. I also wrote a book exploring that among other things. Any encoding is a procedure if there is a program that interprets it. The only question is, what is its formal strength. If it is not formally strong, there are things it will not be able to represent ... – Mike Dunlavey Apr 28 '10 at 18:14
  • @naugtur: ... and another way will have to be found, which may make the job a lot harder. That's not to say you can't have a fancy UI to help with layout. I built something like that early on, but it never got much use. Anyway, my feeling is that there's a mental model or spec, and it has a pretty good representation in your head, because you can change it easily without making it inconsistent (screwing it up). The implementation code should have the same property. So, I say it should have states IF that's how the user thinks about it. ... – Mike Dunlavey Apr 28 '10 at 18:20
  • @naugtur: ... Ideally it should be possible to take the requirements and encode them directly, and if there is a change in the requirements, it should be equally easy to encode the change. The key to doing that is to minimize the redundancy of the encoding. I.e. if adding or removing a control, or making it appear depending on some condition, cannot be expressed *just that easily*, then the code has higher redundancy than it could. Anyway, I could blather on... – Mike Dunlavey Apr 28 '10 at 18:26