The central question for this paper is how to improve the production process by closing the gap between industrial designers and software engineers of television(TV)-based User Interfaces (UI) in an industrial environment. Software engineers are highly interested whether one UI design can be converted into several fully functional UIs for TV products with different screen properties. The aim of the software engineers is to apply automatic layout and scaling in order to speed up and improve the production process. However, the question is whether a UI design lends itself for such automatic layout and scaling. This is investigated by analysing a prototype UI design done by industrial designers. In a first requirements study, industrial designers had created meta-annotations on top of their UI design in order to disclose their design rationale for discussions with software engineers. In a second study, five (out of ten) industrial designers assessed the potential of four different meta-annotation approaches. The question was which annotation method industrial designers would prefer and whether it could satisfy the technical requirements of the software engineering process. One main result is that the industrial designers preferred the method they were already familiar with, which therefore seems to be the most effective one although the main objective of automatic layout and scaling could still not be achieved.
Keywords: Interactive TV, User interface design
Subjects: User interface design system, Graphic user interface
This paper is about the investigation of a part of the product creation process of television (TV)-based user interfaces (UIs) in a multinational of consumer electronics. Two parties are involved in this process: (1) industrial designers with highly professional design skills, and (2) software engineers relying on formal specification methods. Designers create the UI concept, which they make concrete by delivering a partial prototype: a UI design. Software engineers have to convert the UI design into a fully functional software product running on diverse hardware platforms. It is often recommended that UI design should be done by multidisciplinary teams [ JGL01, Mag01, Ero03, Höö04, SRD05 ], however this is not always the case in industrial practice for mass produced products (e.g., consumer electronics). In particular for multinational companies the recommended and required mix of expertise is still located in different divisions [ BB06 ]. Iivari and Iivari (2006) argue that User-Centred Design (UCD) in its current form is not a separate systems development approach, especially because UCD is neither horizontally complete (i.e. UCD does not cover all aspects of systems development even in the earliest phases) nor vertically complete (i.e. UCD does not cover the technical implementation of the system; see e.g. [ KBK03 ]).
Several aspects are at stake in the product creation process of interactive TVs [ RSK95, Rau96, SRD05 ], and one of them is an effective graphical layout (the look) of the interaction structure. A lot of work has already been published on the graphical layout of information objects [ Mac86, Mac88, Mac91, KR94, Spe06 ], unfortunately not for interaction structures (see e.g. [ Car99 ]). In order to improve the implementation of the graphical layout of the interaction structure, the software engineers of a multinational company explored whether one UI design can be converted into several functional UIs for hardware platforms that have different screen properties. Their aim is to apply automatic layout and scaling of the UI in order to improve the product creation process with [semi]automatic tools [ Van94 ]. However, the question is whether a UI design lends itself for such automatic layout and scaling. This is investigated by analysing a prototype UI design with the help of professional industrial designers who created the prototype [ RSK95, Rau96, BNP00 ].
In our first study, industrial designers clarified the UI design by creating annotations on top of it. Since annotations can also improve the product creation process, a second study was carried out in order to investigate the potential of four different annotation methods. This formative approach [ Vic00, AMW02 ] is taken in order to assess how the most important meta-information can be transferred from industrial design division to software engineering division easily and reliably [ vKKR98 ]. Annotations can reveal the rationale behind the UI design, and the explicit design rationale can support software engineers to go beyond merely using the UI design provided via a prototype in order to formulate the underlying layout algorithms. Annotations also have the potential to limit the occurrence of inconsistencies that a UI design and its later implementation can contain [ KvKPS01 ].
The main question is how industrial designers feel about using a semi-formal annotation method and which type of annotation method they would prefer as they will be required to use them in their UI design process [ AMW02 ]. This is an important aspect because creative industrial designers almost feel threatened by formal specification methods. Any [semi-]formal annotation method is perceived as constraining the expressive power of the design space. This paper will describe two empirical studies and discuss them in the context of the product design process for interactive TV. A general discussion and the conclusions will finalise this paper.
In our first study the layout of a prototype UI design is analysed in order to check whether software engineers can convert it into several fully functional UIs for products with different screen properties.
The software engineers aim for automatic layout and scaling in order to improve the product creation process and bridge the gap between software and design. Ideally, software engineers use one UI design and convert that into one fully functional UI that can run on different products with different screen properties. Such UIs should meet different requirements resulting from diversity issues. There is diversity between products as a result of different screen properties, for example, PAL versus NTSC, 4:3 versus 16:9, dual screen and iPronto. Also within the layout of a single UI diversity can occur. Menu labels for instances, consist of a label background and a text string that is positioned on top of it. The text string should never exceed the length of its background, but can itself become longer due to a translation or because a file name is exceptionally long (e.g. DVD file names). Automatically scaling the label background and adjusting the layout accordingly could deal with such diversity.
The question is to what extent a current UI design is able to take diversity issues into account in order to support automatic layout and scaling. Furthermore, the aim of this study is to reveal the implicit guiding principles designers use in their work [ KK95, Tra97, Kar00 ].
Starting point of this study was a particular UI design (given as a partial prototype) for interactive TV that has been developed with Macromedia Director. This UI design is a typical TV-UI because similar UIs can be found in many current TV products (see Fig. 1 ). The UI design shows in full detail only a selection of all possible widgets, i.e. the menu (see Fig. 1 ; left) and a list widget (see Fig. 1 ; right). The functions have fictitious names (e.g. Item 1 stands for ′Picture′, Item 2 stands for ′Sound′, etc). A series of interview sessions was conducted with two experienced industrial designers out of a total of ten designers specialized on interaction design located at the design division. During seven sessions of about four hours each, they were asked about the rationale behind position and size of the UI elements and about the implicit guidelines they use. After each session, the designers incorporated their clarifications in Director as additional information layers on top of the UI design. This annotation method is from now on called the Director method.
The designers have told that all the graphical elements in the UI design are positioned and sized in absolute, and not in relative terms. Regarding the length of text strings the designers pointed out that they would never allow the label background to adjust its size automatically to the size of the text string. If the length of the string is known at design time (e.g. menu labels), they rather adjust the size of the label background to the longest string and use that length of the label background throughout the UI design. Abbreviations can also be used to fit a (translated) string properly on a label background. Text strings that are not known at design time (e.g. DVD file names) do not occur in current TV UIs. Designers explained that if such strings would occur, they would make use of abbreviations or the next line (as in text documents).
The most important guidelines for designers stem from typographical rules such as readability. Another important guide for their work is a company internal UI standard. However, this standard focuses on the user interaction. Little guidelines are provided about the look or layout. The end result of the seven meetings with the designers was an annotated UI design. The designers created six additional information layers on top of their original UI design. The six annotation layers, partly shown in Fig. 2 , Fig. 3 and Fig. 4 , consist of:
Elements: name tags for the UI elements.
Safe area: indication of an area inside the screen borders of 50 pixels, where important UI information can be placed in order to be properly perceptible.
Menu layout grid: guides for aligning (animating) UI elements (see Fig. 2 , left).
Widget layout grid: placement of the elements a widget consists of (see Fig. 2 ; right).
Widget grid: alignment within the widget, animation path included (see Fig. 3 ).
Dimensions: detailed alignment of a UI element (e.g. a label), animation path included (see Fig. 4 ).
In order to support automatic layout and scaling for different screen properties, the UI elements need to be positioned and sized in relative terms [ MMT02 ]. However, in current practise, designers specify the position and size of UI elements only in absolute terms. Label backgrounds are also not positioned and sized relatively. Therefore the resulting UI design cannot be converted into a reusable UI for different screen properties. In this study, the industrial designers used an annotation method (the above called Director method) in order to clarify the UI design and shed light on their design rationale. This Director method shows that the designers mainly use grids and guides in order to position UI elements on the screen. Grids and guides can act as a constraint. It enables software engineers to formulate layout algorithms that are consistent throughout the UI. For instance, the detailed internal grid (see Fig. 4 ) is used to position a text string on a label background consistently. As such, a group is created (a label). The constraints of such a group ensure that it can easily be reused in several places within the UI and therefore supports consistency. Typically, inconsistencies arise due to several people working on the same project [ RSK95, KvKPS01 ]. The Director method does not take into account different screen properties. Therefore this method is incomplete in that it is not specified how the grids and guides should be repositioned when the screen properties change. In our second study the Director method will be compared with three other annotation methods.
At the outset of our second study into annotation methods for UI design, a short questionnaire amongst five industrial designers was performed (5 point rating scale: 0=′negative′ to 4=′positive′). It revealed that using formal information additional to the interactive prototype (i.e. an annotation method for UI design) could be helpful (see Fig. 5 ). A MANOVA (repeated measure; SPSS version 11.0 for Windows) showed that the 3 questions differed significantly (F=34.57, df=1, p=0.004). Also, a post-hoc comparison was performed in order to determine which answers differed significantly (indicated by arrows, see Fig. 5 ). These promising results motivated us to investigate the possibility of introducing an annotation method in the UI production process further on.
In order to assess the advantages and disadvantages of the Director method described in our first study, it is compared with three other annotation methods. The aim of the assessment study is to identify how designers feel about producing the proposed annotation methods, because they should provide such information in the product creation process. Further, it should become clear which annotation method they would prefer. Annotations shed light on the implicit design rationale and can therefore limit the occurrence of misinterpretations and possible inconsistencies. Inconsistencies can arise due to several people (designers as well as software engineers) working on the same project [ RSK95 ]. Ideally, a standard annotation method comes forward that point out rules and constraints about position and size of the UI elements in order to support software engineers to formulate the underlying layout algorithms, also with respect to different screen properties.
The four alternative annotation methods that are compared in this study are called the (1) ′Spreadsheet′ method, (2) the ′Screenshot′ method, (3) the ′Director′ method and (4) the ′Construction Tool′ method. Only the Director method (3) is produced by designers themselves. All the three other methods are introduced for the purpose of this second study. In general the four annotation methods are comparable in that designers should be able to use them with widely available high-level tools (e.g., Excel, Drawing tools, etc). All annotation methods aim to minimize the occurrence of inconsistencies. The annotation methods differ with respect to the extent that the design rationale can be expressed in order to support software engineers. Also to what extent automatic layout and scaling is supported differentiates the four annotation methods. Below the four annotation methods are outlined.
The ′Spreadsheet′ method: This form of annotation is created in Excel and consists of an enumeration of all the UI elements (′object′) that occur in the UI design and their width (pixels), height (pixels), colour and transparency. Table 1 shows a part of such an annotation table.
This Spreadsheet annotation solely provides information about the UI elements in absolute terms as they occur in the UI design. Therefore, the information is incomplete in that it is not specified what should happen with the size and position of the elements if the properties of the screen change. Furthermore, it does not provide rules or constraints such as the maximum length of a text string. Therefore, this method is less appropriate to express explicitly the design rationale than any other method.
Vertical menu background_1
Vertical menu background_2
Horizontal menu background
The ′Screenshot′ method: The Screenshot method consists of a set of screenshots that are annotated by making notes on top of it (with a simple drawing tool) [ KP02 ]. The position, size and transparencies of the UI elements are explained. In order to explain position and size of UI elements as many screenshots can be annotated as needed. Furthermore, UI elements are described apart from their context as is shown in Fig. 6 .
Typically, an explanation consists of a written comment that refers to the UI elements in question by making use of arrows and the like. For example Fig. 7 , regarding the selection of a horizontal menu item (here ′Item x1′), three rules are stated that apply to ALL horizontal menu items. This method also contained one example regarding different screen properties. It states what happens with horizontal menu items when the horizontal screen space is limited. This method is able to express the design rationale easily by specifying rules and constraints in textual form. It provides only limited information about what should happen when the properties of the screen change. In practise though, it depends on the user (the writer) of this method how much rules and constraints are going to be specified.
The ′Director′ method: The Director method is described in detail in the results of our first study (see chapter 2.1 above). It specifies constraints in the form of grids and guides in order to express the design rationale. However, the information is incomplete in that it is not specified how the grids and guides should be repositioned when the screen properties change.
The ′Construction Tool′ method: The Construction Tool method consists of a rudimentary reproduction of the UI design (made in a freeware SVG drawing program) [ MMT02 ]. This reproduction is then annotated with a fixed set of symbols in order to position and size the UI elements [ LF01 ]. The symbols can have two colours in order to indicate what their size and position is with respect to fixed screen properties or different screen properties. Fig. 8 shows two examples: how the horizontal and vertical background are positioned and sized (left), and the build up of a vertical menu (right). The annotation is built up using layers that can be (de-)activated in order to show several aspects of the redrawn UI design and their annotations separately. As much layers can be used as needed. UI elements can also be described apart from their context (e.g. labels). This method explains the layout for fixed and different screen properties. Therefore, of all annotation methods, it is most explicit in expressing the design rationale [ BNP00, MC96 ].
Five professional industrial designers (representative sample out of 10 = 50% of total population at our multinational company) highly experienced with interface/interaction applications, who are all closely associated with creating TV-based UI designs, assessed the potential of the four methods of UI design annotations. One designer cooperated already in the first study as well.
After the UI design, the four different forms of annotation methods were presented in the following fixed order: (1) ′Spreadsheet′, (2) ′Screenshot′, (3) ′Director′ and (4) ′Construction Tool′. Each method was discussed for a couple of minutes and evaluated by means of a questionnaire before the next method was introduced.
The evaluation questionnaire (5-point rating scale going from 0=′negative′ to 4=′positive′) was identical for all four annotations and asked: ”If you, as a designer, would have to produce the < name of one of the four annotation methods > example and others would have to use it, how would you rate this with respect to the following...” continued by 12 statements: (1) usefulness (see Fig. 9 ), (2) easy to produce, (3) added value, (4) applicable, (5) efficient means, (6) effective means, (7) can be produced by me, (8) will be produced by me, (9) improves implementation, (10) reliable, (11) necessary means, (12) sufficient means (see Fig. 9 ).
After the four evaluations, the designers were asked to make an additional overall summative rating regarding the four annotation methods on a 10-point scale (1=′very bad′ and 10=′excellent′). Next to each question was the option to write free comments.
Figure 9. Mean of the 2 statements that discriminated significantly between the four different forms of UI design annotation (N=5; standard deviations between brackets). Arrows designate which items differed significantly in a post-hoc comparison (Scheffé).
To collect qualitative data and to assess the baseline attitude of our interaction designers, we asked how important it is to provide formal additional information to the UI demo design prototypes as input for the software engineering process. They commented the following: Starting with design, it would be useful to be able to combine visualization and description and to link that to the software development (version management, application development and so forth). A formalized version of the design rationale is needed. Detailed visual info can be added to support visualizations. Help software engineering to better understand the implementation of UI elements (e.g. slider with annotated info on timing, speed, number of steps). The less ambiguity, the better. Some things can be better explained with words, tables, matrixes.
After the four methods were presented, the designers remarked that all the methods more or less suffer from the fact that they are time consuming and prone to errors or misinterpretation. Per method the designers have given the following feedback.
Spreadsheet method: The spreadsheet method is very difficult to produce and to read. The information is distributed too much and misses visual links to the original design. Despite its details, it cannot describe all the diversity of a design and lacks general rules. As a checking tool it can be helpful, but the content should be updated automatically.
Screenshot method: The screenshot method feels familiar to the designers because visual material is reused. They opt for a template though. They indicate that the design rationale can be expressed which makes it easier to deduce commonalities. However, this method will produce a lot of paper and it doesn′t force the user to be complete.
Director method: The director method is very complete and can focus on points that need attention. However, it also contains too much different types of information at the same time. It isn′t layered well enough (′onion skins′) in order to make it usable on several levels. It′s questionable whether engineers can benefit. It doesn′t show the design rationale because it tackles instances. This method needs to be automated. A toolbox containing the design ele-ments would be helpful.
Construction tool method: This method is very complex (more complex than necessary) and mentally demanding (difficult to learn). This method provides poor information because it is not clear which symbol belongs to which object. It also contains information that is too obvious. They think that it isn′t directly related to their deliverables. It might be useful for engineers though.
In their comments designers frequently expressed doubts about the annotation methods because creating them takes extra time and they are prone to errors. Both indicators (′time to use′ and ′prone to error′) were not able to discriminate significantly between the four annotation methods. However, on the average, per annotation method, almost half of the designers (45% out of a total of N=20 data points, 4 methods * 5 designers) reported the ′time′ problem at least once. The same (45% out of a total of N=20) holds for their concerns about ′errors′.
Two of the 12 rating statements of our evaluation questionnaire discriminate significantly between the four annotation methods: ′usefulness′ (F=4.28, df=3, p=0.021) and ′sufficient means′ (F=5.94, df=3, p=0.006). In addition, an ANOVA was performed using Scheff post-hoc comparisons, in order to discover which ratings differed significantly. Fig. 9 shows the mean (and standard deviation) of these two significant ratings. A discriminant analysis using only these two items revealed that 70% of original grouped cases per method were correctly classified. The overall summative rating afterwards, did not reach significance among methods.
At begin of our empirical investigations, industrial designers expressed great interest in having formal information additional to the UI design (Fig. 5 ). This additional information could be in the form of annotations, which the Director method is useful and sufficient at delivering. The fact that the Director method, which was developed by designers (see our study 1 above), is most preferred confirms that user involvement is recommendable [ RS92 ]. The Director method is able to limit the occurrence of inconsistencies and provides information about the design rationale.
However, the design rationale can possibly be expressed more explicitly by means of an additional text document (or audio remarks), especially when deviations to earlier designs need to be justified. Since designers do make use of incremental design, incorporating such additional text documents or audio remarks, might improve the Director method [ Mac88, MPF95 ]. Another drawback of the Director method is that it does not take different screen properties into account.
The Construction Tool method, potentially the most powerful method with respect to different screen properties, is rated surprisingly worst. However, from our first study it became clear that designers so far do not consider different screen properties within their UI design. Our second study confirms that designers only deal with different screen properties by creating a new UI design when the properties of the target screen differ. It has to be said though, that the Construction Tool method is difficult to apply, especially with respect to different screen properties. Further, like the Director method, the design rationale is explained mainly by means of additional symbols.
The Spreadsheet method lacks a direct link with the UI design and is a numerical and textual, rather than a graphical method. Since industrial designers are mainly visually orientated, this method does not go along well with the way they act and think. Furthermore, the design rationale cannot be expressed explicitly with this method and therefore it mainly supports consistency as required by the software engineers.
Finally, the Screenshot method, rated second best by the designers, only provides a loose specification regarding the way annotations should be produced. Therefore, it is up to designers to underline the aspects of the UI design that they think are important. Designers probably appreciate the method because it is easy to use (less formal than the other methods) and visually oriented. Besides, the design rationale can be expressed in words as well.
Whether the Director method should be introduced as a standard in the product creation process remains to be seen. The doubts designers expressed about the annotation methods need to be considered as well. Creating written annotations with the Director method takes considerable extra time. Future research has to prove whether audio annotations could overcome this limitation (see e.g. [ MPF95 ]). However, the time spends on annotations might payoff in the total production process if software engineers can implement the UI more effectively. The possible errors the annotations can contain are not so problematic because software engineers can make use of the UI design in form of the interactive prototype as well. The chance that a UI prototype as well as its annotations contains the same error is quite unlikely.
Producing the annotations turned out to be more difficult than expected, especially when different screen properties need to be incorporated. At present, it seems tooearly to take different screen properties into account within only one UI design.
Two studies are performed in order to bridge the gap between interaction designers of TV-based UI design and software engineers who need to convert this UI design into a complete functional UI. In the first study, it was investigated whether a UI design lends itself for automatic layout and scaling. It turned out that current UI designs can not support automatic layout and scaling because UI elements are not positioned and sized in relative, but in absolute terms. Therefore, software engineers cannot use one UI design in order to convert that into a UI for several products with different screen properties. Nearly every TV product still needs its own UI design and implementation process.
The second study focussed on the clarification of the UI design itself. In our first study the designers had made use of annotations on top of the UI design in order to clarify their design (called Director method). In our second study, the Director method was evaluated by comparing it with three other annotation methods.
The Director method developed by the industrial designers themselves was most preferred, which confirms that involving the user (e.g. designers) is the right approach [ RSK95 ]. With the Director method a UI design is annotated mainly by producing layout grids and guides around the UI elements in order to shed light on the design rationale. The design rationale can be of use to reduce the occurrence of inconsistencies in the UI design and its implementation. However, the Director method does not take different screen properties into account, unlike the Construction Tool method. This Construction Tool method was the most explicit method regarding different screen properties. However, designers least appreciated it. Therefore, this second study also seems to confirm that fully automatic layout and scaling is yet a bridge too far and needs further research.
Motivated by this investigation, our industrial designers are currently exploring methods to write down the design rationale in order to explain the reasoning behind design decisions. Such a design rational should especially clarify the deviations from earlier UI designs because a UI design is typically based upon earlier versions (incremental design) [ Rau96 ]. Therefore, the Director method might need to be extended in order to clarify such aspects as well. The Director method is not easy to produce, takes considerable time to create, and is by no means complete. Therefore, alternative methods to express the design rationale more easily should be explored [ Car95, BNP00 ]. There is some evidence that design and software implementation should remain separate because the creative expertise of interaction designers - creating appealing UIs - can have a positive effect on usability [ KK95, Tra97, Kar00 ] and therefore should not be too constrained by engineering requirements [ Sef03 ].
When the design and engineering disciplines remain separated (e.g. in multinational companies), the product creation process can still be improved if the understanding of each other′s work processes could be increased. For instance, the awareness of software engineers can be increased when the design rationale is explained properly [ MC96 ]. Also, designers can be involved more in the product creation process, by showing them intermediate visual results of the implementation [ Mag01 ]. Future improvements of the product creation process should therefore make both disciplines more aware of each other′s work [ RS92, RSK95, Rau96 ] by getting them integrated in multidisciplinary design teams [ BNP00, JGL01, Höö04 ].
Within the domain of UI design, research in design support has generally followed different approaches. Our study focuses on uncovering and recording the rationale used to arrive at different UI designs [ MC96 ]. The Director Method concentrates on providing a shared UI for expressing designs and reflecting upon how these UIs are used by industrial designers as input for software engineers. Our aim is to draw from the experiences of both these groups. The intent of UI design rationale is documentation of the sequence of decisions made in realising a design.
In our multinational company, the current television-based UI designs do not support automatic layout and scaling. UI designers specify position and size of UI elements in absolute terms. With relative position and size, software engineers, who need to convert the UI design into a fully functional UI, could have been enabled to use one UI design and convert that into several fully functional UIs for products with different screen properties.
In our first study, designers explained the rationale behind the UI design by creating annotations on top of it. In our second study, the potential of this annotation method was assessed by comparing it with three other annotation methods. Designers preferred the annotation method created in the first study. However, this annotation method does not support software engineers to use automatic layout and scaling. An annotation method that does support automatic layout and scaling was rated worst by designers. Therefore, it can be concluded that it is yet too early to apply automatic layout and scaling in the product creation process for interactive TVs.
The most preferred Director method has other drawbacks as well. For instance, designers make use of incremental design and the Director method is not able to specify the changes and deviations from earlier UI designs. This most preferred annotation method also takes a considerable time to produce an interactive prototype as well. Therefore, in the future, more appealing and easy to use annotation methods should be considered [ Vic00 ].
We would like to acknowledge the participation of the industrial designers from Philips Design, as well as the valuable input from Kees van Overveld, Eindhoven University of Technology, The Netherlands.
[AMW02] How does the design community think about design?, Proceedings of DIS'02: Designing Interactive Systems: Processes, Practices, Methods, & Techniques, 2002, Section 02: perspectives, ACM Press, New York, NY, USA, pp. 125—132, isbn 1-58113-515-7.
[BB06] Beyond knowledge sharing: the management of transactive knowledge systems, Knowledge and Process Management, (2006), no. 1, 62—71, issn 1099-1441.
[BNP00] Creativity, Cooperation and Interactive Design, Proceedings of the conference on Designing interactive systems: processes, practices, methods, and techniques, ACM Press, New York, NY, USA, pp. 252—261, 2000, isbn 1-58113-219-0.
[Car95] John M. Carroll, Scenario-based design: envisioning work and technology in system development, 1995, Wiley, New York, NY, USA, isbn 0-471-07659-7.
[Car99] Style Guide for the Design of Interactive Television Services for Elderly Viewers, Independent Television Commission, Winchester, UK, 1999.
[Ero03] User centered research for interactive television, Proceedings of the 2003 European Conference on Interactive Television: From Viewers to Actors (April 2-4,Brighton, UK), 2003, pp. 5—12.
[Höö04] User-centred design and evaluation of affective interfaces, From Brows To Trust: Evaluating Embodied Conversational Agents, Part II: The User in Focus, 2004, Kluwer Academic Publishers, pp. 127—160, Z. Ruttkay and C. Pelachaud (Eds.), isbn 1-4020-2729-X.
[JGL01] A user-centered approach to object-oriented user interface design, Object Modeling and User interface Design: Designing interactive Systems, 2001, Addison-Wesley Longman Publishing Co, Boston, MA, USA, pp. 283—312, M. Van Harmelen (Ed.), isbn 0201657899.
[Kar00] The beauty of simplicity, Proceedings on the 2000 conference on Universal Usability, 2000, ACM Press, New York, NY, USA, pp. 85—90, isbn 1-58113-314-6.
[KBK03] Personalizing the user experience on ibm.com, IBM Systems Journal (2003), No. 4, 686—701, issn 0018-8670.
[KK95] Apparent usability vs. inherent usability: experimental analysis on the determinants of the apparent usability, Conference companion on Human factors in computing systems, ACM Press, New York, NY, USA, 1995, pp. 292—293, isbn 0-89791-755-3.
[KP00] Adaptive runtime layout of hierarchical UI components, Proceedings of the Second Nordic Conference on Human-Computer Interaction, Short Papers, ACM Press, New York, NY, USA, 2002, pp. 251—254, isbn 1-58113-616-1.
[KR94] Automatic layout based on formal semantics, Proceedings of the workshop on Advanced visual interfaces, pp. 231—233, ACM Press, New York, NY, USA, 1994, isbn 0-89791-733-2.
[KvKPS01] An empirical investigation of the defect detection capabilities of requirements specification languages, Sixth CAiSE/IFIP8.1 International Workshop on Evaluation of Modeling Methods in Systems Analysis and Design (EMMSAD'01), 2001.
[LF01] A Survey of Automated Layout Techniques for Information Presentations, Proceedings of Smart Graphics 2001, 2001, pp. 61—68.
[Mac86] Automating the design of graphical presentations of relational information, ACM Transactions on Graphics (TOG) (1986), no. 2, 110—141, issn 0730-0301.
[Mac88] Applying a theory of graphical presentation to the graphic design of user interfaces, Proceedings of the 1st annual ACM SIGGRAPH symposium on User Interface Software, 1988, ACM Press, New York, NY, USA, pp. 179—189, isbn 0-89791-283-7.
[Mac91] Search architectures for the automatic design of graphical presentations, Intelligent user interfaces, 1991, ACM Press, New York, NY, USA, pp. 281-292, isbn 0-201-50305-0.
[Mag01] Methods to support human-centred design, International Journal of Human-Computer Studies (2001), no. 4, 587—634, issn 1071-5819.
[MC95] Thomas P. Moran and John M. Carroll, Design rationale : concepts, techniques, and use, Computers, cognition, and work, 1996, Erlbaum, Mahwah, N.J, USA, isbn 0-8058-1566-X.
[MMT02] Fast and efficient client-side adaptivity for SVG, Proceedings of the 11th international conference on World Wide Web, XML Applications, ACM Press, New York, NY, USA, pp. 496—507, 2002, isbn 1-58113-449-5.
[MPF95] Ariel: augmenting paper engineering drawings, Conference companion on Human factors in computing systems, 1995, ACM Press, New York, NY, USA, pp. 421—422, isbn 0-89791-755-3.
[Rau96] Moderation instead of Modelling: Some Remarks about Formal and Informal Reengineering Methods, Manufacturing agility and hybrid automation - I, 1996, IEA Press, Louisville, KY, USA, pp. 167—170, isbn 0965339505.
[RS92] Work Organization and Software Development, Annual Review in Automatic Programming, (1992), no. 2, 121—128, issn 0066-4138.
[RSK95] Benefits of user-oriented software development based on an iterative cyclic process model for simultaneous engineering, International Journal of Industrial Ergonomics, (1995), no. 4-6, 391—410, issn 0169-8141.
[Sef03] Learning the ropes: human-centered design skills and patterns for software engineers' education, Interactions, (2003), no. 5, 36—45, issn 1072-5520.
[Spe06] The influence of information presentation formats on complex task decision-making performance International Journal of Human-Computer Studies, (2006), no. 3, 1115—1131, issn 1071-5819.
[SRD05] Work-centered support systems: a human-centered approach to intelligent system design, Intelligent Systems, (2005), no. 2, 73—81, issn 1541-1672.
[Tra97] Aesthetics and apparent usability: empirically assessing cultural and methodological issues, Proceedings of the SIGCHI conference on Human factors in computing systems, 1997, ACM Press, New York, NY, USA, pp. 115—122, isbn 0-89791-802-9.
[Van94] Automatic generation of a user interface for highly interactive business-oriented applications, Conference companion on Human factors in computing systems, 1994, ACM Press, New York, NY, USA, pp. 123—124, isbn 0-89791-651-4.
[vKKR98] A Comparative Case Study with Industrial Requirements Engineering Methods, Proceedings of the 11th International Conference on Software Engineering and its Applications, 1998.
[Vic00] HCI in the global knowledge-based economy: designing to support worker adaptation, ACM Transactions on Computer-Human Interaction (TOCHI), (2000), no. 2, 263—280, issn 1073-0516.
Fulltext as PDF. ( Size 508.2 kB )
Any party may pass on this Work by electronic means and make it available for download under the terms and conditions of the Digital Peer Publishing License. The text of the license may be accessed and retrieved at http://www.dipp.nrw.de/lizenzen/dppl/dppl/DPPL_v2_en_06-2004.html.
Matthias Rauterberg, Michel Alders, and Reinder Haakma, How to Improve the Production Process for interactive TV with semi-formal Methods. JVRB - Journal of Virtual Reality and Broadcasting, 4(2007), no. 8. (urn:nbn:de:0009-6-8006)
Please provide the exact URL and date of your last visit when citing this article.