Generative techniques for creating User Interfaces involve a specification at a higher level of abstraction than a designer or markup language such as HTML or XAML.

Generative techniques can be used on top of almost any user interface technology (HTML, WPF, Windows Forms, Cocoa, etc.) This session is for general discussion of benefits and limitations, along with different approaches.

As an example, at Carenet we have created a simple DSL for defining a certain kind of user interface ('Scripts' which guide an agent through a 'phone call.) The DSL is close to how the business users talk about the Scripts (in terms of panels, verbiage, notes, captures etc.) The DSL is consumed by a generator which follows Carenet UI standards to render

Session Notes

Traditionally User interfaces are created with designers, or mark up, The is a one-for-one relation between what you put in the mark-up, and your UI elements. Now we want to take this up a level. The standards for the layout is implemented in generators that understand WPF. There are a lot of challenges for UI creation. A technology that was used by Damian is an HTML Control from ASP.NET using a VS type of application wiht a tree control on the left. There were default themes. Phils implementation was an internal DSL. A goal is conform to company specified standards. I feature that would be nice is to specifically what type of UI is generated, WPF, or HTML, etc. Damian said it was kind of interesting trying to make the UI look good. There are many ways of laying-out an interface. A smart-phone app may use multiple screens, while on a PC, that may not be the case. Damian suggested creating paper forms like a PDF. It would be an interesting DSL. Phil had an experiance where the engine became un-maintainable. There were lot of inter-dependencies, and their own proprietary XML. There is a concept of add-question, and choice-answer. At the moment its a mater of getting the visual elements laid out on the screen to our standards. There is a desire in the company to quickly to put the scripts together. You could probably create a table schema based on what's in your script. The capture is getting the information that you are getting from the customer. It depends on who needs access to the table, and populate based on there database. How did you start to initialy design your WPF UI? Phil discovered what he wanted to do woud use the designer to do a spike.  You can new up all the elements with code, and add elements. Do you modify the WPF at runtime, or just spit-out a new layout with the new elements? You can keep these all in memory invisible, and the don't lose their state. One challenge is making sure that the user generated UI components look like the standard UI components, complete with menus. How avoid getting the case where you get say 50 check boxes, from some code-generated UI. Perhaps a rules engine, what they used to call expert systems, to prevent this. There is an idea where the system gets feedback from the UX to modify the UX. For example if they go from screen 6 to 5 to 6 to 7, there needs some work on screen 5. Or noting that  the user spends a lot of time on some paragraph, it is needed to re-write that paragraph to be clearer. There was some discussion of the failed UX for hiding rarely or never-used functionality in the menu. It is better to show it disabled, therefore you don't search the menu system for it.