I have been thinking of the way by which UI mockups are created. In most Visio-style applications - which are the mainstay for this kind of thing - there's usually a pallette of known "widgets" that can be dragged onto a canvas and put into place using the Painter's Algorithm. The good part about such an arrangement is that they allow easy creation of UI mockups, and thereby expression of the look of the app-to-be.
This works when the UI framework is an established one and the set of widgets is known. But what if you're trying to create a new UI framework and you want it to be completely (or sufficiently) different from the current pack?
The other problem I see with the current way of doing things is that UI mockups/wireframes are still woefully disconnected from the rest of the development process: the designers build their mockups, pass it onto the graphic artists who finish up the design with dimensions, colors etc and finally deliver a finished design (typically in html for webapps, most probably psd for others) to the developer - who now has to tear down the carefully crafted design to get at its constituent pieces.
I was thinking of an alternative that's inspired in part by Graphviz.
Imagine being able to draw a picture by describing what it contained. So a description of a wheel would be something like:
wheel:
circleA: circle
circleB: circle
line1, line2, line3, line4: line
circleA contains circleB
line1: pointAt(circleA, top) - pointAt(circleB,top)
line2: pointAt(circleA, right) - pointAt(circleB,right)
line3: pointAt(circleA, bottom) - pointAt(circleB,bottom)
line4: pointAt(circleA, left) - pointAt(circleB,left)
The syntax is obviously very handwavy at this point, but hopefully the intent is clear:
This works when the UI framework is an established one and the set of widgets is known. But what if you're trying to create a new UI framework and you want it to be completely (or sufficiently) different from the current pack?
The other problem I see with the current way of doing things is that UI mockups/wireframes are still woefully disconnected from the rest of the development process: the designers build their mockups, pass it onto the graphic artists who finish up the design with dimensions, colors etc and finally deliver a finished design (typically in html for webapps, most probably psd for others) to the developer - who now has to tear down the carefully crafted design to get at its constituent pieces.
I was thinking of an alternative that's inspired in part by Graphviz.
Imagine being able to draw a picture by describing what it contained. So a description of a wheel would be something like:
wheel:
circleA: circle
circleB: circle
line1, line2, line3, line4: line
circleA contains circleB
line1: pointAt(circleA, top) - pointAt(circleB,top)
line2: pointAt(circleA, right) - pointAt(circleB,right)
line3: pointAt(circleA, bottom) - pointAt(circleB,bottom)
line4: pointAt(circleA, left) - pointAt(circleB,left)
The syntax is obviously very handwavy at this point, but hopefully the intent is clear:
- You describe the scene, not paint it
- You define relationships between the objects not place them in specific positions.
- You provide dimensions only if absolutely required, else the system figures it out for you.This is obviously not intended for a "to scale" diagram; although I can already imagine a Graphviz style mode that outputs the same format as the input - only annotated with dimension information that can further be processed to make it to scale.
The advantages I see with such an approach are:
Design notes:- Diagramming becomes descriptive. It could easily have a Canvas backend as a GL one, but the scene would be the same
- UI wireframes can be built "from scratch" easier than before and thus support early exploration of new ways of expressing design intent
- UI wireframes become instantly accessible to version control
- Developers can literally write diagrams!
- There will obviously be primitives - line, circle, arc etc come to mind.
- The system will allow creation of compound objects from simpler ones and primitives
- Spatial organization in a 2D plane will be represented by a logical grid, or using predicates such as "contains", "to the left of", "to the right of" etc
- Overlapping objects will be represented by a Z-ordering (as in most such tools) using predicates such as "in front of" "behind". Alternatively, the system could allow depiction of each "layer" in the Z-axis as a slice within which no front/behind predicates are allowed
- Objects can have "anchor points" defined which allow other objects to use those specific points in other areas of the script.