Results
The results of my thesis are placed in the RESULTS section.
Add comment May 31st, 2007
Card Game Case
I created a ‘card game case’ on two different screen-sizes, which are interpolated.
- movie1
- movie2, with some rule-modifications
- screenshot of the designer
Add comment April 25th, 2007
Structural interpolation result
I have some results for the structural interpolation, which is demonstrated in this movie. It’s also noticable that the rule-editor is changed, intervals can be specified by the rules near the interface.
Add comment April 12th, 2007
Interpolation runtime: Remappings work !
I have completed a new version of the uiml.net interpolation runtime. The three types of rules described in a previous post are working now. The remapping-system follows a slightly modified version of the working principle described in this post. The major differences/additions are:
- The designer now generates two xslt transformation files: one for the vocabulary and one for the interface. This involves a double xslt transformation in the uiml.net renderer also.
- The identifiers used to map part-elements on vocabulary d-classes are uniquely defined per part. The mapping between the part and the concrete interface element is decided trough an xslt-transformation. For example: part id=”part_1″ class=”part_1″ will be mapped trough d-class id=”part_1″ maps-to=”checkbutton” at size X, or trough id=”part_1″ maps-to=”label” at size Y.
- The uiml.net renderer should be called like this: ./uiml.net.exe -uxsl interface_transform.uiml -voc vocabulary_transform.uiml
Example of a very simple mp3-player
- A screenshot of the designer
- A movie which shows the output in the uiml.net runtime with the intervals (conditions) automatically calculated by the designer. In this movie some annoying effects are noticeable: the horizontal ruler goes over the play button and the image comes above the listbox.
- To solve this, some modifications on the conditions were made trough the built-in rule-editor.
- A new movie shows the output after some modifications on the rule-conditions.
- The vocabulary and interface xslt’s generated by the designer.
Structural interpolation
The runtime and designer doesn’t support structural interpolation so far. For example: a button should be a child of a panel at size X and a child of a tab-page at size Y. To support this, a new type of rule is necessary: ‘restructuring rules’. When the user modifies something at the structural level of the interface, a rule of this type should be created. The serialization of this type of rules into uiml and xslt is not clear for me right now.
Jan
Add comment April 9th, 2007
Uiml.Net interpolation Runtime: first results
I have completed the first runtime version for the uiml.net renderer today 
. This runtime interprets the resizement and position changing rules of the design environment.
Working principle:
A short explanation of the working principle:
- The width and height of the interface are stored in a device-model.xml file (= a configuration file for the interface)
- The output of the designer is an xslt file which transforms the device_model.xml file into an uiml file. Examples of designer outcomes are: export2.uiml, export3.uiml, export4.uiml and export5.uiml
- The uiml.net renderer has a new startup argument: ‘./uiml.net.exe -uxslt export3.uiml’. When the renderer is called like this, an xslt transformation will be executed before the document can be rendered.
- When the interface is resized, device-model.xml is adjusted with the new width and height. The xslt transformation is executed on the new device-model and the outcoming uiml file is rerendered.
This working-principle involves that the rule-based interpolation system is embedded into uiml without affecting the uiml standards!
Example and movie:
In this example, an interface is created by the designer as shown on THIS screenshot, the export of this interface is given by export5.uiml. The result of export5.uiml in the renderer is demonstrated in this movie. Most of the rule-conditions were set by the designer automatically but some fine-tuning was necessary (some rules depend only on the height, larger intervals, …).
The next step will be the implementation of the mapping-rules in the uiml.net runtime. I’ve already pointed out how to do this, I just need some time to complete it.
1 comment April 7th, 2007
Rule serialization in uiml
Hello,
Today I’m going to serialize the rules into UIML. There are two places to store the rules:
- style section : the rules which expresses the changement in size and position will be placed here
- vocabulary-section : the rules which expresses the used mappings will be added here
The rules will be expressed by the xsl:choose statement in which conditions can be specified by XPath expressions.
When this serialization works I’m going to finish the runtime environment which should execute the different rules. When time is left, a forward chaining technique with more types of pré-conditions will be added to the rule-based interpolation.
Bye
Add comment April 6th, 2007
Rule-Extraction and Rule-editing
Hello,
Today the second stage of the interpolation process is accomplished : rule-extraction and editing. A rule contains pré-conditions and a rule-effect. When the pré-conditions are valid, the effect of the rule will become visible in the interface. For example, ‘transform the radiobutton in a checkbox when the interface’s height reaches 50′. While the transformation can be seen as the ‘rule-effect’, the constraint on the interface height figures as the rule’s précondition.
Three types of rules are distinghuished:
- Changements in the widget’s size
- Changements in the widget’s position
- Changements in the widget’s mappings: For example, an abstract component can be mapped to a checkbox or a radiobutton depending on the conditions.
In the uiml.net designer, rules are dynamically generated when the user modifies the cloned interface. Athough, it’s possible to change the conditions of the extracted rules trough a built-in rule-editor. As usual these new features are demonstrated by a movie in which the three types of rules are extracted. The rule-editor shows the extracted rules on the selected widget. When these rules are executed, the selected widget will appear (= the target widget). The rules are shown in a listbox, when one is clicked further details are shown in two tab pages: one to edit the conditions and one which explains the rule-effect (the execution tab-page).
A good heuristic to determine the conditions automatically should be added. I propose a sort of heuristic which sets the conditions such that the rule will only be executed when the target widget lies completely inside the interface.
1 comment April 6th, 2007
Interpolation: Referencing Widgets
Hello,
Today I accomplished the first step in the ‘interpolation phase’ of the uiml design tool. It’s possible to duplicate (clone) the original interface and edit these duplicates. An important point here is to create ‘references’ between widgets in the original interface and the new one. For example, when a checkbutton in the original interface should be transformed into a radio-button in the new interface, a reference between these two widgets should exist in order to facilitate rule-extraction. During the interface-duplication, references between the different widgets can be made automatically (the two interfaces are the same). Later on, when widgets are added/deleted, these references should be made by hand.
In the uiml.net design tool, a flexible mechanism is introduced to create and visualize the references between corresponding widgets. When a widget is selected in an interface, the referenced widgets are coloured yellow in the other interfaces. A reference can be created trough the ‘reference it’ option in the context-menu of a widget. For example, when ‘reference it’ is called in the contextmenu of the checkbutton, the next clicked widget in another interface (= the radio-button widget) will be referenced to the checkbutton.
This is illustrated in this movie . The steps shown in this movie are:
- Creation of an original interface
- Duplication of this interface
- Visualization of the references (the yellow-coloured widgets)
- Referencing a progress-bar to a horizontal scroll
In the next phase, rules should be extracted between the related widgets. When a widget in the original interface references to nothing, this means it will be removed towards the new interface. A rule-editing dialog will be added to the designer, in order to make the fine-tuning of the extracted rules possible (for example the discrete rule-execution interval).
Add comment April 4th, 2007
Designer Framework Finished
Hi all,
The past 2 weeks I added some new features to the Uiml-designer. Upon this designer framework, the UI interpolation will be built.
A short introduction to the most important features:
- TabPages : the creation of tab-pages in a toolkit-independent manner was not straight forward. I did this trough a context-menu, which is responsible to switch between and create new tab-pages. The details of this mechanism are illustrated in this short movie.
- UIML Deserialisation and Serialisation: these two processes work now perfectly. Modifications in the WYSIWYG part are reflected instantly in the UIML view and vice versa. These processes are shown in this movie.
- Open UIML files : It’s possible to open UIML files which are made outside the designer. This is done for the (famous) pizzaform example in this movie.
Further more, LOTS of bugs are solved and some structural improvements are made, especially the widget-tree datastructure is redesigned. Now it’s - finally - time to build the interpolation mechanism !
Add comment March 27th, 2007
Some results
There are some new features and fixes added to the uiml.net designer. To get an impression, please watch this movie.
The new features are :
- New datastructure : The underlying datastructure was a vector in the previous version, for this version I changed it into a tree.
- Relative positioning : Every widget is positioned relatively against his parent
- Layered Widget Tree management : To manage the widget tree it’s possible to manipulate the z-order of every widget with a context menu. When a widget lays above another widget, the former will be the parent of the latter.
- Rendering : In the previous release were some problems with the rendering, this is solved now
- Automatic Uiml Generation : The new designer has two major tabs: one for the designer and one to display the corresponding uiml code. When the uiml’s tab is clicked the uiml code will be shown automatically.
Some features that are scheduled for the next version:
- Uiml deserialization and file loading : When something is changed in the uiml code, it should be reflected in the designer view. The uiml.net parser can be reused to make this work. To load files, the deserialization mechanism will be used.
- Property manipulation : Every property is represented by a textbox in this version. In the new version it should be possible to manipulate content properties with listboxes, color values with a color wizard, integers with spinboxes, … .
- Resizement of the user interface : It should be possible to resize the user interface, which is fixed in this release. This is also the connection with the second part of my thesis, the user interface interpolation.
- Copy, delete widgets : There is no ability to copy, cut or delete widgets right now. In the future this will be placed in the contextmenu.
Everything is implemented to support multiple widgetsets: dynamic widget panel generation according to the chosen widgetset, a self made widget tree datastructure without using widgetset logic, modification of widgets directly by manipulating uiml, … .
It’s the intention to complete the uiml.net designer as fast as possible, I hope to do this by the end of february. Afterwards the second part of my thesis (UI interpolation) will be integrated into the designer. The writing of my thesistext will be started in a couple of days.
Add comment February 10th, 2007