Does anyone know of a formal grammar approach to UI design? I currently have wireframes for 100+ pages and I'm now driving out the commonality / identifying reusable components.

I'm interested in the idea of a grammar. For example, a page in BNF may be:

<page> ::= <nav-bar> + <title> + [<alerts>] + <data-grid>

And a data grid:

<data-grid> ::= [<filter-bar>] + <table-header> + <table-rows> + [<edit-pane>]

My motive is to spot common patterns and formalise in to a UI specification.


The short answer appears to be no, there does not seem to be a formal approach to describing UIs using a grammar. However, based on the answers below and further research I've rolled my own solution.

I've created a my grammar as an XML schema, but using RELAX NG due its simplified syntax.

Here's how a simple page schema is visualised:

enter image description here

I'm then using an XML editor with auto-complete to aid describing UI pages:

enter image description here

Which is proving to be very productive.

Then finally I have a simple script to turn XML page UI descriptions into HTML mockups, along with some CSS for rendering:

enter image description here

The most exciting part is ability to programatically apply heuristic analysis, plus the simplicity in globally applying different UI layouts to the whole set of mock pages quickly and easily, allowing for rapid mutations and iterations of UIs.

  • As far as I know there isn't one. It could be extremely useful. I would be most interested in describing transitions (revealing divs, ajax) on a screen
    – Mayo
    Feb 28 '15 at 12:47
  • I haven't come across this approach before but it's really interesting
    – tohster
    Feb 28 '15 at 16:37
  • Maybe you could check out notations like GOMS, Keystroke Level or User Action Notation to get some further inspirations. By the way, I think there are also a lot of different approaches on how to name elements of a page (e.g. Modular Design System: Page>Template>Navigation>Content type>Modules, Atomic Design: Pages>Templates>Organisms>Molecules>Atoms) so you have to deal with that as well.
    – ITJ
    Feb 28 '15 at 17:02
  • FWIW, the reverse is often simpler...find the commonalities and build a pattern library. THEN do any necessary additional wireframing.
    – DA01
    Mar 2 '15 at 0:04
  • Are you looking for something like UML (en.wikipedia.org/wiki/Unified_Modeling_Language) ?
    – RobC
    Mar 2 '15 at 16:13

Interesting question.

Yes, grammars do exist for UI design, but no, I haven't seen one as high level as what you are describing. Templating systems like jinja2 and django implement grammars for domain-specific languages (DSL's) which are well adapted to describing UI's. But these grammars are highly specialized and more focused on concrete implementation than on abstract design.

There are some problems with adapting generalized programming grammar to describing UI's. For example:

  • Layout order is important to UI's so operators like '+' are non-commutative (e.g. header + footer ≠ footer + header).
  • Interactive UI's often depend on external controller logic, so proper encapsulation becomes a problem when layout is dependent on outside application logic.
  • UI includes a 2D or 3D ordering of objects, so finding a decent set of operators to describe multi-dimensional layout is challenging.

Nevertheless, it could be pretty interesting to use a high level language to describe UI's. For the reasons above, it would probably need to be a DSL, and I think it would need the following properties:

  • Object orientation. Multiple inheritence and extending is a common conceptual pattern for UI's. For example, a Page is a base class that contains a Header, Body and Footer. You would want to be able to create specific pages like HomePage and ShoppingCartPage which inherit and extend this base object without the need to redefine it.

  • Declarative*. UI's work well with declarative grammars. You would want to be able to include a CalendarWidget and then specify it later on.

  • Highly abstracted. Despite the problems with encapsulation above, UI's are particularly well suited to high level abstraction. So concepts like Page and Shopping cart can be described and manipulated at very abstract levels, and this really helps with planning or (in your case) common-factoring.

Since we are talking about a high level, abstract DSL it's not that hard to just create your own. If you need something more concrete and detailed, then I would look at templating languages like jinja. But for what you are doing (common factoring and architecture), I think it'd be easy to come up with some O-O DSL conventions to describe the UI. I might give this a try on my next project...it's an interesting approach to translating storyboards into object-oriented templates.

  • I took this on board whilst thinking of a solution, and I've moved to an even more abstract approach. I've tried, wherever possible, to remove the notion of precedence when describing pages - when you're describing a page you know it needs a nav bar, and some global alerts, but at this point you should be describing where they're placed. Instead, that's done in a final pass at the end of the process - turning page meta data into a 'real' mock ui. I've found this approach very liberating and forces me to think about what elements the page needs, rather that where elements should be.
    – JimmyP
    Mar 5 '15 at 17:02
  • And, sorry, another thing - by using an XML schema all the pages have to adhere to rules. Thus, I can enforce that you should never have element X and element Y on the same page. (For example, in our app, there should never be a data grid and a tabbed form on the same page). I'm evolving the schema as I explore the UI patterns, and as it changes I can re-validate all previous pages to ensure they don't break new rules.
    – JimmyP
    Mar 5 '15 at 17:05
  • @JimmyP great comment, and you're right that in some cases (particularly in common-factoring) precedence doesn't matter so you can use general grammars. I would point out that much of UX is concerned with creating user flows...so once you move beyond "inventory" or "asset" style modeling of what's on a page, order starts to matter a lot so there are some limitations on commutative grammars in terms of UX design.
    – tohster
    Mar 5 '15 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.