think-cell technical report TC2003/01 A GUI-based Interaction ...

More documents

Recommendations

Info

3.2 Computer Supported Layout STATE OF THE ART idea of snapping the drawing caret to prominent locations. To determine geometrically prominent locations, snap-dragging uses the ruler-and-compass metaphor traditionally used by draftsmen. Based on explicit hints given by the user and some heuristics about typical editing behavior, snap-dragging constructs transient align- ment objects – points, lines and circles – on the fly. A gravity function drags the caret to align with one or more of these objects, enabling fast and accurate drawing with little time spent in moving the tools and setting up the construction. Bier and Stone’s snap-dragging forgets about the relationships between shapes immediately after a shape is constructed, whereas Gleicher [Gle92] takes snap- dragging one step further and presents augmented snapping. Roughly spoken, in Gleicher’s prototype system Briar the snap-dragging technique is used to specify constraints that are maintained from then on. This way, geometric relationships between drawing objects are invariant against editing operations like drag-and-drop. The specification of constraints through direct manipulation implies important sim- plifications compared to traditional constraint-based systems: Because constraints start out satisfied, there are no constraint-satisfaction problems to solve or state jumps to explain. There is no concern about conflicting or unsatisfiable constraints, since there exists at least one configuration which meets the constraints. An essential feature of snap-dragging as well as augmented snapping is the im- mediate on-screen feedback to user actions and intentions. In snap-dragging, align- ment objects are visualized such that they can easily be distinguished from concrete objects. In augmented snapping, the effect of applying a drag-and-drop operation while existing constraints are being maintained, is continuously displayed during the dragging action. Other systems have been realized that support quick and geometrically precise drawing without using any grid or gravity function and without the explicit no- tion of constraints. Notably, Igarashi et al. have demonstrated various work in this field. Interactive beautification [IMKT97] infers relations between new strokes and existing line segments and thus generates geometrically accurate 2D shapes from plain and generally imprecise drawing input. In contrast to snap-dragging, interactive beautification “beautifies” an irregular input stroke after it has been drawn. Relations between the new stroke and existing objects are not explicitly shown. In Teddy [IMT99], on the other hand, two-dimensional drawing gestures are “inflated” into 3D models. Because the user interface is entirely based on direct manipulation gestures, no traditional UI widgets – buttons, sliders, menus, dialogs – are required for 3D construction using this technique. Support for imprecise mouse movement and maintenance of spatial relations between on-screen objects is not restricted to the domain of freehand drawing. In [BNB00], Badros et al. present SCWM, an “intelligent constraint-enabled window manager”. SCWM is a window manager for the X window system that handles relations between windows and enforces them when windows are moved or resized. SCWM implements a UI for constraint specification and visualization of active constraints. Constraints are implicitly inferred by augmented snapping and explicitly 30
3.2 Computer Supported Layout STATE OF THE ART specified using on-screen buttons. Both, buttons and constraint visualizations, use iconic representations of the supported constraints. 3.2.2 Automated Layout As opposed to interactive drawing aids, by automated layout I mean a “specify- then-solve” approach. In such systems, the user describes the model by declaring relationships that must hold true and the system configures the model to meet these requirements. This approach allows a user to specify the important aspects of the design and have the system resolve the details. A nested tabular layout can be seen as a set of spatial constraints. Typical UI toolkits and layout managers, widely deployed examples being Sun JFC/Swing [Sun02] and Microsoft Foundation Classes [Mic97], are based on this idea. These systems for development and presentation of window based user interfaces are de- signed to present the same UI widgets on different screen resolutions. Sizes and positions of the widgets are chosen at runtime, based on a simple built-in layout policy and a set of parameters specified by the programmer. Typical layout policies include row-major vs column-major, regular grid, or border layout, that can be combined in a hierarchical manner. Parameters specify details like minimum and maximum sizes. Hence, the layout as such is not automated; rather, the layout that was specified by the programmer is instantiated with respect to the conditions (screen resolution, window size, etc.) that prevail at runtime. While the popular UI toolkits are merely based on spatial constraints, for more general applications it is favorable to be able to specify abstract constraints, too. Techniques that use markup tags, such as L ATEX [LaT] or HTML [W3Cb], present simple examples for spatial (e. g., vspace{lineheight}) and abstract (e. g., level-1- heading) constraints. A frequently used vehicle to achieve a rectilinear layout in L ATEX or HTML are tables. Tables in markup languages have similar characteristics as a grid: Table cells follow a strictly horizontal and vertical layout, but in contrast to a regular grid, the table’s row heights and column widths are in general irregular. Cell sizes are dynamically adapted to meet the requirements of the contained objects on the one hand and the window or paper size on the other hand. Cascading style sheets (CSS) are an extension to HTML that allows clean separation of structural markup and actual appearance. Badros et al. noted in [BBMS99] that the procedural specification of CSS 2.0 [W3Ca] is complex and sometimes vague, in any case not easy to understand and implement. They propose a constraint-based extension to CSS 2.0, which is backwards compatible and has the advantage to declaratively specify the standard. Badros et al. argue that a constraint-based approach to style sheets would greatly simplify the implementation of rendering engines as well as the web designers’ use of cascading style sheets. Moreover, they suggest some more general and flexible style specification syntax that can easily be implemented using constraints, but is not easy to implement using the procedural approach of current CSS. 31
Page 1 and 2: think-cell technical report TC2003/
Page 3 and 4: Contents List of Figures 5 1 Introd
Page 5 and 6: List of Figures 1 The consultant’
Page 7 and 8: 1 Introduction INTRODUCTION “Layo
Page 9 and 10: 2 Field Study FIELD STUDY Jeff Hawk
Page 11 and 12: 2.1 Qualitative Aspects FIELD STUDY
Page 19 and 20: 2.2 Quantitative Aspects FIELD STUD
Page 25 and 26: 3 State of the Art STATE OF THE ART
Page 27 and 28: 3.1 User Interfaces for Layout Spec
Page 29: 3.2 Computer Supported Layout STATE
Page 33 and 34: 3.3 State of the Art - Résumé STA
Page 35 and 36: 4.1 A New Approach to Slide Layout
Page 43 and 44: 4.2 Interaction Toolbox INTERACTION
Page 53 and 54: 4.3 Specifying the User Interface I
Page 69 and 70: 5 Implementation IMPLEMENTATION The
Page 71 and 72: 5.1 Program Architecture IMPLEMENTA
Page 77 and 78: 5.2 An Application of Dynamic Progr
Page 79 and 80: 5.2 An Application of Dynamic Progr
Page 81 and 82:
5.2 An Application of Dynamic Progr
Page 83 and 84:
6 Evaluation EVALUATION In this cha
Page 85 and 86:
6.2 Case Study EVALUATION presented
Page 87 and 88:
6.2 Case Study EVALUATION AÖGHKÖ
Page 89 and 90:
7.2 Résumé CONCLUSION User Studie
Page 91 and 92:
References REFERENCES [Adoa] Adobe
Page 93 and 94:
REFERENCES [Hur78] A. Hurlburt. The
show all

think-cell technical report TC2003/01 A GUI-based Interaction ...

Create successful ePaper yourself

Delete template?

Save as template?