1 / 28

Enhancing Usability with a Dynamic Hierarchical Undo Facility in Fine-Grained Component Environments

This paper, presented at TOOLS Pacific 2002, discusses the implementation of a dynamic hierarchical undo facility specifically designed for interactive applications with Graphical User Interfaces (GUIs). The authors, H. Washizaki and Y. Fukazawa, explore various types of undo operations, from linear to non-linear and selective approaches, emphasizing the impact on usability and complex GUI design. They also detail the structure of an object-oriented undo framework to manage user actions effectively, catering to the challenges of maintaining application state and command complexity in modern software development.

enye
Download Presentation

Enhancing Usability with a Dynamic Hierarchical Undo Facility in Fine-Grained Component Environments

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Dynamic Hierarchical Undo Facility ina Fine-Grained Component Environment TOOLS Pacific 2002 Waseda University, JAPAN H.Washizaki Y.Fukazawa { washi, fukazawa }@fuka.info.waseda.ac.jp H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  2. Undo facility • Definition of undo/redo operations • Undo: Unexecute the last performed action • Redo: Re-execute the last undo action • (Undo/redo several actions) • Effects of undo facility • Improvement of usability • Support of complex GUI design Undo facility is necessary for interactive application systems with Graphical User Interfaces (GUIs) H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  3. Conventional implementation • Basic mechanism • Command: corresponding to user’s actions • History list: storing executed commands • Types of undo facilities • Restricted linear undo facility • Undo/redo operation in the order of user’s actions • Most comprehensible for users • Non-linear undo facility • Arbitrary past commands can be undone/redone • Problem: internal states become complex for users • Selective undo facility • Isolated commands can be undone/redone • Problem: dependency settings is necessary • Hierarchical undo facility • Using predefined hierarchical commands • Problem: definition of hierarchical commands is necessary corresponding to each specific application H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  4. Conventional implementation (Restricted linear undo facility) • Restricted linear undo facility is the most general • Comprehensible for users • Object-oriented undo frameworks (UndoFW) • Command Processor pattern • Restoration target: user’s actions Command Processor UndoableEditListener Command Processor (History List) Command UndoManager UndoableEdit 1 Stores/ Undo/Redo * undo() redo() Passes-UndoableEdit Concrete Command Executes/ Re-executes Controller Supplier Generates UndoableEditSupport ConcreteUndoableEdit FooEditSource undo() redo() component.setData(v1) component.setData(v2) Notifies-user-action-performed H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  5. Problems in conventional implementation • Potential for an excessive number of command classes • Necessity of command classes according to each user’s actions • Example: • CopyCommand, PasteCommand, DeleteCommand, … (for text editing applications) • Internal modification of the edit source class • Addition of procedures in the edit source class (in the original logic part) • Incomplete separation of the original logic part and the UndoFW applied part H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  6. Targeted software components • Common definition • Reusable/substitutable software artifacts • In a narrow sense • A physical packaging of executable software with public interfaces • An object-oriented class, reusable at the instance level • Distributed in the form of an object code, without source codes • Systems: CORBA・EJB, JavaBeans・ActiveX/COM • Classification with granularity • Coarse-grained: business components • Medium-grained: application components with specific logic • Fine-grained: GUI widgets, generic components Component Interface glue code Coordination services Component Framework H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  7. Fine-grained components • Usage • Widespread with RAD tools, libraries • JavaBeans, ActiveX, … • Feature • Property (data) • Attribute by which component's behavior is decided • Readabl-property, writable-property • Read method (getData) • Operation to observe the property’s value • Write method (setData) • Operation to change the property’s value • Event method (fireEvent) • Operation for notification of events • Starting point of the reactive control Facade Facade Sub system FooBean -data : Data #fireEvent(event: Event)+getData(newData: Data)+setData(newData: Data)+doSomething(p:Param) H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  8. Additional implementation of undo facility • Target • Type: restricted linear undo facility • Environment: Fine-grained component environment • The behavior of the entire application is shown as sets of properties’ changes • Restoration: all properties’ changes • Mechanism • Undo function • resetting the old property’s value using the write method • Redo function • resetting the new property’s value using the write method redo setData(v2) data = v2 setData Old State New State data = v1 undo setData(v1) H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  9. Undoable extension • Mechanism • Automatic generation of the subclass by Generator • Separation of the logic part and the UndoFW applied part • Overriding of methods with notification functions • Restricted restoration types • PropertyChangeEdit: undo/redo setting property’s value • PropertReferEdit: (getting property’s value) • EventEdit: (firing events) UndoableEdit Listener Component 1 * UndoManager UndoableEdit - data : Data Stores/ Undo/Redo +setData(Data) +getData() : Data +fireEvent undo() redo() Passes-UndoableEdit PropertyReferEdit EventEdit Executes/ Re-executes Generates UndoableEditSupport PropertyChangeEdit UndoableComponent undo() redo() component.setData(v1) component.setData(v2) Notifies-user-action-performed H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  10. Comparison of command granularity • Conventional undo facility • One command represents one action • Our undo facility • One or more commands represents one action • Proposal of dynamic hierarchization • Organizing commands dynamically into a hierarchy • Three types: Basic, Pattern, Container Copy action 1: User push the Button[C3] 1-1: getting value on TextField[C1] 1-3: setting value of TextField[C2] History list (conventaional) (Ea) TextCopyEdit represents text copy action Application composition History list (our) TextField [C1] represents setting value (P3) PropertyChangeEdit TextField [C2] Represents gettiing value (P2) PropertyReferEdit Button [C3] (F1) FireEventEdit reperesents event notification H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  11. Preparation for definition • Component • Command Component’s ID ::= (Unique identification value of component, C_id） Method’s ID ::= （Unique identification value of method in component, I_id） E ::= （Single command）, E ::= Pc | Pr | E | S Pc ::= (Property change command) Pr ::= (Property refer command) E ::= (Event command) S ::= { E } (compound command) {(k,i)} E ::= ( v : hierarchical level on the history tree, Level, n : sequence number, (k,j) : pair of the generator C_id and the generator I_id ) v n C_id=1 Component X I_id=1, generation of Pc(1,1) at the invocation time data : Data setData(Data) getData() : Data fireEvent() I_id=2, generation of Pr(1,2) at the invocation time I_id=3, generation of E(1,3) at the invocation time H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  12. Basic hierarchization • Policy • Use of the reactive control (event-driven) • Making compound commands • event commands as their parents Realization of undo/redo operations corresponding to the event-driven behavior Demand Undo/redo the firing event (1.1) ～ the writing property value (1.4) collectively 1.1: fires event 1: Push C3:Button :User 1.2: notifies event 1.3: reads property value adapter C1:TextField 1.4: writes property value C2:TextField 2: Push C5:Button 2.1: notifies event H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  13. (4,2) (3,3) (6,0) (5,3) (2,6) Pc E Pr E E 1 1 2 1 2 1 6 4 3 5 Basic hierarchization (mechanism) • Adding property change/refer commands (Pc,Pr) as children of event commands (E) Basic-hierarchized History tree Basic-hierarchized History list (Level=1) History list root objective-state objective-state (3,3) E 1 Undo Undo (1,1) (1,1) Pr Pr 2 Basic hierarchization 2 2 Undo (2,6) (3,3)(1,1)(2,6) Pc S 3 1 Undo (5,3) E 4 Undo Undo (4,2) (5,3)(4,2) Pr S 5 2 current-state current-state (6,0) (6,0) E S 6 3 [time] [time] H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  14. Pattern hierarchization • Policy • The same kind of compound commands series as a pattern • Making compound commands • New command as their commands Realization of undo/redo operations for the repeated series of actions Demand Undo/redo the repeated series of actions (push C3 ～ push C5) collectively 1.1: 4.1: 4: Push 1: Push C3:Button :User 1.2: 4.2: 1.3: 4.3: adapter C1:TextField 5: Push 1.4: 4.4: 3: Push C2:TextField 2: Push C5:Button 2.1: 3.1: 5.1: H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  15. S’ 1 1 (3,3)(1,1)(2,6) (5,3)(4,2) (5,3)(4,2) (3,3)(1,1)(2,6) (6,0)(4,2) (5,3)(4,2) (6,0)(4,2) (3,3)(1,1)(2,6) (6,0)(4,2) (3,3)(1,1)(2,6) (6,0)(4,2) (5,3)(4,2) (3,3)(1,1)(2,6) (5,3)(4,2) (3,3)(1,1)(2,6) (5,3)(4,2) (6,0)(4,2) S’ S S’ S S’ E’’ S S’’ S S’’ S’ S’’ S’’ S’’ S’’ S’’ S’ S’’ S’ S 3 1 1 2 1 1 2 2 1 2 1 2 1 3 1 2 2 2 3 3 2 8 7 6 1 4 10 5 5 2 4 3 4 8 7 9 3 1 2 3 S’’ 1 6 Pattern hierarchization (mechanism) • Decision of commands equivalence with pairs of C_id ant I_id • Retrieval of same set of id pairs Pattern hierarchized History list (Level=1) History tree root root root objective -state Undo Pattern hierarchization (B) Pattern Hierarchi- zation (A) (3,3)(1,1)(2,6) (5,3)(4,2)(6,0) (4,2) S’ Addition S’’’ 1 5 1 Undo Addition (3,3)(1,1)(2,6) (5,3)(4,2)(6,0) (4,2) S’’’ 2 H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  16. Container hierarchization • Policy • Inclusive relation of parent components of generator components • Effects of commands are localized inside those parent component Realization of undo/redo operations corresponding to components composition Cz Demand Undo/redo the repeated series of actions localized in Cx・Cy・Cz MainPanel Cx C6 Button CopyPanel Inclusive relations: Cz ⊃ C6, Cx Cx ⊃ C1, C2, C3, Cy Cy ⊃ C4, C5 Cy C3 C2 C1 Button TextField TextField Panel C5 C4 Button CheckGroup H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  17. (5,3)(4,2) (5,3)(4,2) (3,3)(1,1)(2,6) (3,3)(1,1)(2,6) (6,0)(4,2) (6,0)(4,2) (5,3)(4,2) (6,0)(4,2) (3,3)(1,1)(2,6) (5,3)(4,2) (6,0)(4,2) (3,3)(1,1)(2,6) S S S S S S S S S S S S 1 1 1 1 1 1 1 1 2 2 1 3 2 1 2 1 3 3 5 6 6 4 4 5 Container hierarchization (mechanism) • Decision of the parent component which includes all parent components of generator components • Using component ids • Checking the component composition at each time Container hierarchized History list (Level=1) History list in(con(S1),con(S2)) = (Cx⊃Cy) = TRUE objective- state root root Undo con(E1)=x in(C_id1,C_id2) ::= TRUE | FALSE (C_id1 contains C_id2) con(E) ::= C_container ( ∀C_id | in(C_container, C_id), C_id ∈( E’s { (C_id,I_id) } ) (3,3)(1,1)(2,6) (5,3)(4,2) S’ 1 con(E2)=y con(E3)=z Undo (6,0)(4,2)(3,3) (1,1)(2,6)(5,3) (4,2) S’ 2 Container hierarchi- zation Undo (6,0)(4,2) S’ 3 current-state [time] H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  18. Implementation environment • Component system • JavaBeans: Java based component system • Treats fine-grained components • Undo framework • javax.swing.undo package (in JFC) • Undo extension and hierarchization system • UndoableBean <<framework>> UndoFW JavaBeans <<framework>> UndoableBean Our development H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  19. Hierarchization framework • Three types of dynamic hierarchization • Strategy pattern • Encapsulation of hierarchization algorithms • Decorator pattern • Extensible hierarchization classes • Dynamic combination of hierarchization objects (e.g. new PattenStrategy(new BasicStrategy()); ) UndoManager Delegates-process <<pattern>> Strategy <<pattern>> Decorater 1 HierarchizeStrategy UndoableBeanManager 1 1 1 process(edit) Manages Composites * 1 deployment UndoableEdit BasicStrategy AdvancedStrategy <<framework>> Hierarchization PatternStrategy ContainerStrategy H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  20. Evaluation • Methods • Conventional method: • [Con] javax.swing.undo package • Our method: • [Non] no-hierarchization • [Basic] Basic hierarchization • [Patt] Basic+Pattern hierarchization • [Ctan] Basic+Container hierarchization • Samples • Sample A: LunchApplet • Sample B: Test • Sample C: FontViewer • Sample D: extended FontViewer FontViewer H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  21. Development cost • Necessary development costs for implementation of undo facility • Types of cost • Codes/classes which programmer writes (hand coding) • Codes/classes which can be generated automatically • Result of our method • Codes which programmer writes, 78.4% has been reduced • Effect of Generator in our method • Lower values in number of classes H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  22. Usability (preparation) • Environment • Athlon 800MHz, Memory 256MB, Java2 RE1.3, Windows 2000 • Usability test • Four testers executed 20 tasks with Five sample D: [Con], [Non], [Basic], [Patt], [Ctan] • Task: • Each task has target strings (e.g. task1: “Sample”, task2: “Sample code” ) • Testers can perform specific operations (add, delete, change size, change style, change name) • Testers can perform undo/redo (+ advanced undo/redo at our methods) • Measure: • Number of specific/undo,redo operation times • Execution time • Relative usability score score[x]=100 * total_operation[Con] / total_operation[x] H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  23. Usability (evaluation) • Results of our methods • [Non]: large number of undo/redo operation times, low usability • [Basic]:large number of undo/redo operation times, low usability • [Patt] (Basic+Pattern hierarchization) • The number of undo/redo operation times was smaller than [Con] (but, more experience in advanced undo/redo operation is necessary) • [Ctan] (Basic+Container hierarchization) • The number of total operation times was smaller than [Con] • The relative usability score exceeds 100 point • Effect of container-hierarchized undo/redo operations Type [Con] [Non] [Basic] [Patt] [Ctan] Execution time [ms] 5082 6402 5409 5246 5385 Specific operation times 2.98 3.73 3.33 3.31 3.82 Undo/redo operation times 3.38 7.88 4.72 3.17 2.41 11.61 Total operation times 6.37 8.05 6.48 6.23 － Relative usability score 54.8 79.1 98.2 102.1 H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  24. Conclusion • We propose a new implementation technique of the dynamic hierarchical undo facility • Low implementation cost • High usability with container hierarchization • Future works • Limitation in usage • Target applications should be based on fine-grained component • All behavior should be performed by properties’ changes Solution by introspecting all elements of application, and decomposing into fine-grained components H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  25. Maintenance cost • Necessary adaptation costs for specification change • Types of cost • Modification in original logic part • Modification in UndoFW applied part by handcoding • Modification in UndoFW applied part by autogeneration • Data structure change: StringBuffer to String, • Sample C was used • Results of our method • Programmer actually need not modify UndoFW applied part • Impacts of specification change were localized in generated UndoableComponent [Con] codes (classes) [Ours] codes (classes) Type Original logic part 6 (1) 6 (1) UndoFW applied part (handcoding) 14 (3) 0 (0) UndoFW applied part (autogeneration) - (-) 80 (1) H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  26. UndoableBean • Additional framework for JavaBeans Storing commands Undo/redo operation Original application Generator Application Pre generates Changes-property/ Fires-event adapter Bean1 Bean2 1 Creates * Undoable BeanEdit UndoableBean1 UndoableBean2 Resets-property * * * 1 Notifies, stores UndoManager Taken-out, undo/redo 1 1 <<abstract>> HierarchizeStrategy UndoableBeanManager Delegates- hierarchization process Undo/redo operations H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  27. E E E 4 4 4 (3,3) (3,3) E E 1 1 Preparation for definition (diagram) • Diagram representation • History list: set of commands actually used • History tree: internal representation of hierarchized commands History list (Level=1) History list History tree root root Initial state E4 was undone (3,3) E 1 1 1 State (E4) Edit Compound command (E1,E2,E3) (1,1) (1,1) (1,1) E E E (E3) Edit 1 2 2 2 2 (E2) Edit Command (E1) Edit (2,6) (2,6) (2,6) (3,3)(1,1)(2,6) E E E E’ 1 3 3 2 3 1 Current state Undo Undo (2,6) (2,6) (2,6) (2,6) E’ 1 1 2 Hierarchization [time] [time] H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

  28. (5,3)(4,2) (6,0)(4,2) (6,0)(4,2) (3,3)(1,1)(2,6) (5,3)(4,2) (3,3)(1,1)(2,6) (6,0)(4,2) S S S’ S S S S 1 1 2 2 1 3 1 5 2 3 4 6 3 Support of flexible undo/redo operations • Flexible undo/redo operations • Change and selection of the tree’s level at run time History list (Level=1) History list (Level=2) History list (Level=3) History tree root Undo Undo (3,3)(1,1)(2,6) (3,3)(1,1)(2,6) S’’ S’’’ Undo 1 1 Undo Undo (3,3)(1,1)(2,6) (5,3)(4,2) (5,3)(4,2) (5,3)(4,2) S’ S’’ S’’’ 1 2 2 Undo Undo (6,0)(4,2) (6,0)(4,2) S’’ S’’’ 3 3 Undo Undo (3,3)(1,1)(2,6) S’’’ Undo 4 (6,0)(4,2)(3,3) (1,1)(2,6)(5,3) (4,2) Undo (3,3)(1,1)(2,6) (5,3)(4,2) S’ S’’ (5,3)(4,2) S’’’ 2 4 5 Undo Undo Undo (6,0)(4,2) (6,0)(4,2) S’’ S’’’ 5 6 [time] [time] [time] H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia

More Related