book

Professional Java User Interfaces

Name: Professional Java User Interfaces
Author: Mauro Marinilli
ISBN: 9780471486961

by Mauro Marinilli

May 2006

Intermediate to advanced

668 pages

17h 12m

English

Wiley

Read now

Unlock full access

Copyright
Acknowledgements
Introduction
The interactivity thrillUsable GUIs and usable booksThe organization of the bookThree levels of adviceThe three level of advice in the bookConventions used in the bookSource codeReader feedbackBook readers and personasLars, a Java intermediate programmerLars will then . . .Keiichi, a tech leadKeiichi will then . . .Shridhar, a professor in computer scienceShridhar will then . . .Melinda (Mellie), a managerMellie will then . . .William, a first year student in a Master in CS courseWilliam will then . . .Karole, a business analystKarole will then . . .Juan, an experienced programmerJuan will then . . .
1. Putting GUI Development into Context
1.1. Introduction1.2. Focusing on users1.3. A functional decomposition for user interfaces1.4. Tool selection: the Java singularity1.4.1. Of running little green men and wrong choices1.5. Organizational aspects1.5.1. People and GUIs1.5.1.1. Dermaphobic and graphic hedonists1.5.1.2. Who owns the GUI?1.5.2. Team composition1.6. Early design1.6.1. Use case diagrams and GUIs1.7. Lifecycle models, processes and approaches1.7.1. Rational Unified Process1.7.1.1. User experience storyboards1.7.2. Extreme Programming and other Agile approaches1.7.3. LUCID methodology1.7.4. Evolutionary Prototyping process1.8. UML notation1.8.1. Class diagrams1.8.2. Sequence diagrams1.8.3. State diagrams1.9. Summary
2. Introduction to User Interface Design
2.1. The human factor2.1.1. A model of interactive systems – seven stages and two gulfs2.1.2. Developers are part of the design process2.1.3. Short term memory and cognitive modeling2.1.3.1. An example of STM misuse2.1.4. Interacting with human beings2.1.4.1. Response time2.1.4.2. Balancing human control and automation2.1.4.3. Showing the application's internal state2.1.4.4. Techniques for getting the user's attention2.1.4.5. Some general principles for user interface design2.1.5. User-centered design2.1.5.1. User analysis2.1.5.2. Task design and analysis2.1.6. Simplified thinking aloud2.2. Display organization2.2.1. Esthetic considerations2.2.2. Abstract-Augmented Area for GUIs2.2.2.1. An example2.3. Interaction styles2.3.1. Menu selection2.3.2. Form filling2.3.2.1. Creating effective forms2.3.3. Language-based styles2.3.4. Direct manipulation2.4. Conceptual frameworks for UI design2.4.1. Entity-based approaches to UI design2.4.2. Metaphor-based approaches to UI design2.4.3. Function-based approaches to UI design2.4.4. 'Null' approach to UI design2.4.5. Object-oriented user interfaces2.4.5.1. Object views and commands2.5. Assessing the quality of a GUI2.5.1. Usability heuristics2.6. Summary
3. Java GUI Design
3.1. Java technology for GUIs3.1.1. Assembling the components3.1.2. Three levels of component cost3.2. Cost-driven design3.2.1. Ad-hoc versus custom – the difference between 'run' and 'ride'3.2.2. When ad-hoc is the only way to go3.3. Exploring the design space for a point chooser3.3.1. Standard dehsigns3.3.2. Ad-hoc designs3.3.3. Mixed designs3.3.4. Conclusions3.4. Design guidelines for the Java platform3.4.1. Introduction to the guidelines3.4.2. J2SE user interface design guidelines3.5. The Java look and feel design guidelines3.5.1. Some definitions3.5.2. The Java 'look'3.5.3. The Java 'feel'3.5.4. Some terminology3.5.5. An example – applying the guidelines for designing dialogs3.6. Summary
4. Recurring User Interface Designs
4.1. GUI area organization4.1.1. Terminology4.1.2. Main frames4.1.3. Multiple document interfaces4.1.4. Wizards4.2. Choosers4.2.1. Chooser activation mechanisms4.2.2. Chooser interaction styles4.2.3. Broadening the choice4.2.4. Conclusions4.3. Memory components4.3.1. Input history4.3.2. Saving user preferences4.4. Lazy initialization4.5. Preference dialogs4.5.1. Preference dialogs styles4.6. Waiting strategies4.7. Flexible layout4.8. Common dialogs4.8.1. The 'About' dialog4.8.2. Log-in dialog4.8.3. First-time message dialogs4.8.4. Splash window4.9. Command components4.9.1. Graphic conventions4.9.2. Toolbar composition4.9.3. Command composition4.10. Accessibility4.10.1. Testing the final product for accessibility4.10.2. Conclusions4.11. Navigation and keyboard support4.11.1. Keyboard shortcuts4.11.2. Tab traversal4.12. Internationalization4.13. Help support4.14. Icons and images4.15. Leveraging object-oriented programming4.16. Summary
5. Iterative GUI Development with Java
5.1. Iterating wisely5.2. Introduction to prototyping5.2.1. Uses for prototyping5.2.2. The two dimensions of prototyping5.2.3. Competitors' product as ready-made prototypes5.2.4. Prototyping as a philosophy for development5.2.5. Prototypes and customers5.3. Prototyping alternatives5.3.1. Different types of prototypes5.3.2. Storyboards5.4. GUI builders5.5. Reusable prototyping widgets5.5.1. A tree prototype utility class5.5.2. A visual container prototype utility class5.6. GUI refactoring5.6.1. Some classic refactorings5.6.2. Extract method5.6.3. Separate domain from presentation5.6.4. Some GUI-specific refactorings5.6.5. Failing with style5.7. Introduction to user interface testing5.7.1. Test-driven development5.7.2. What's first – GUI design or implementation?5.8. Software testing of Java GUIs5.8.1. How to test – GUI software test approaches5.8.2. What to test – test coverage criteria5.9. Usability testing of Java GUIs5.10. JRE runtime management5.10.1. Introduction to profiling5.10.2. Common problems5.10.3. CPU hot-spots5.10.4. Continuous profiling5.10.5. A posteriori profiling5.11. Summary
6. Implementation Issues
6.1. Revisiting the abstract model6.1.1. Testing the various layers6.1.2. The principle of Single Functional Responsibility6.1.3. Isolating presentation details6.2. Content6.2.1. Content assembly6.2.2. Explicit navigation6.3. Business domain6.4. Data input-output6.4.1. A comprehensive data IO design strategy6.4.2. Some design patterns6.4.3. Remote communication design6.4.4. Security issues6.5. Making objects communicate6.5.1. The Observer pattern6.5.2. Swing events6.5.3. SWT events6.5.4. Design-time class decoupling with events6.5.5. Event Arbitrator6.5.6. Misuses of event-based messaging6.5.7. Alternatives to event-based communication mechanisms6.6. Separating data from views6.6.1. Model-View-Controller6.7. Interaction and control6.7.1. Representing user actions with the Command pattern6.7.2. Control issues6.7.3. A state-oriented approach to GUI control6.8. Some design patterns for GUIs6.8.1. Adaptation6.8.2. Composite Context6.8.3. Active Object6.8.4. Object lifecycle management – a general mindset6.8.5. Value Model6.9. GUI complexity boosters6.10. Summary
7. Code Organization
7.1. Introducing software architectures7.1.1. Taming references7.1.1.1. The Dependency Inversion principle7.1.1.2. Separated Interface7.1.2. Composable units7.1.3. Evolving order and appropriate architectures7.1.3.1. Individuating patterns7.2. Some common GUI architectures7.2.1. The smart GUI antipattern7.2.2. A semi-smart GUI architecture7.2.3. A three-layer architecture7.2.4. A four-layer architecture7.3. A three-layer organization for GUI code7.3.1. Overview7.3.2. The presentation layer7.3.3. The application layer7.3.4. The service layer7.4. Two examples of a three-layer implementation7.4.1. An MP3 player7.4.2. An electronic circuit simulator and editor7.5. The service layer7.5.1. Overview7.5.1.1. Loading services7.5.1.2. Localization services7.5.2. Persistence services7.5.3. Factory services7.5.4. Other services7.5.4.1. Providing new services7.5.4.2. The Swiss army knife syndrome7.6. Summary7.6.1. Key ideas

8. Form-Based Rich Clients
8.1. Introduction8.1.1. Defining rich clients8.1.2. Java rich clients8.1.3. GUI design for rich clients: the Third Way8.2. Reference functional model8.2.1. Distributing behavior between client and server8.2.2. Common problems8.3. Runtime data model8.3.1. Validation8.3.1.1. The user side8.3.2. When to validate and notify8.3.2.1. How and where notify8.3.2.2. The hidden pitfalls of validation8.4. The cake-ordering application, the XP way8.4.1. Setting up the first Iteration8.4.1.1. Defining the testing strategy8.4.2. Content first8.4.2.1. Getting back to work8.4.3. Data second8.4.4. Commands third8.4.4.1. Implementing robust commands8.4.4.2. Handling the operation in progress8.4.5. Closing the loop with the server8.5. Summary
9. Web-Based User Interfaces
9.1. An overview of Web user interfaces9.2. GUI design for the Web9.2.1. Fine graphics details9.2.1.1. Unexpected shortcomings9.2.2. Area organization9.2.3. Levels of client-side control9.2.3.1. Bandwidth and interaction9.2.4. Navigation issues9.2.4.1. High-density information strategy9.2.4.2. Limited information strategy9.3. Implementing Web applications with Java9.3.1. The typical architecture of a Web application9.3.2. Basic Java Web GUI technologies9.3.3. Java applets9.4. From Web applications to rich clients9.4.1. Different development habits9.5. Summary
10. J2ME User Interfaces
10.1. Introduction to the MID profile10.1.1. Main UI concepts10.1.1.1. The lifecycle of a MIDlet10.1.1.2. User input management10.1.1.3. Two levels of API10.1.2. Main UI limitations10.1.3. Cost-driven design for J2ME GUIs10.2. The MIDP UI API10.2.1. UI widgets10.3. Designing MIDP GUIs10.3.1. Abstract GUI designs10.3.1.1. Segmenting the GUI design10.4. Designing navigation10.5. An example custom item10.6. An example ad-hoc item10.7. An example application10.7.1. The code10.8. Summary
11. Java Tools and Technologies
11.1. Introduction to tool selection11.2. Evaluating open source software11.2.1. Open Source Maturity Model11.3. SWT or Swing?11.3.1. The toolkits11.3.1.1. The Swing toolkit and typical problems using it11.3.1.2. Standard Windowing Toolkit11.3.1.3. Native resource management with SWT11.3.1.4. Typical problems when using SWT11.3.1.5. JFace11.3.2. Choosing a toolkit11.3.2.1. The hidden cost of learning11.3.2.2. The speed myth11.3.2.3. Heavily-loaded widgets11.3.2.4. Scenarios to which SWT+JFace is better suited than Swing11.3.2.5. Scenarios in which Swing is a better choice than SWT11.3.2.6. From Swing to SWT11.3.3. Mix and match11.3.3.1. SWT and Swing together: the Java GUI dream team?11.4. Other GUI technologies11.5. Utility libraries11.5.1. Security tools11.5.2. Deployment tools11.5.3. Glazed Lists11.5.4. JGoodies Swing Suite11.5.5. L2FProd Common Components11.5.6. Other OSS component libraries11.5.7. Some commercially-available Swing components11.6. Test tools11.7. Profiling tools11.8. GUI builders11.9. Presentation layer technologies11.9.1. Assessing a look and feel11.9.2. Swing look and feels11.9.2.1. Ocean 1.511.9.2.2. Synthetica11.9.2.3. Alloy11.9.2.4. Metal 3D11.9.2.5. Hippo11.9.2.6. Compiere11.9.2.7. JGoodies Looks11.9.2.8. Liquid11.9.2.9. Oyoaha11.9.2.10. Napkin11.9.3. SWT Presentation11.10. Declarative GUIs with Java11.10.1. XML-based formats11.11. Summary
12. Advanced Issues
12.1. Building on top of existing libraries12.1.1. Attributes12.1.2. Roll your own framework12.1.2.1. Designing usable APIs and frameworks12.2. Memory management for complex GUIs12.2.1. A practical case12.3. Restructuring existing GUI code12.3.1. Porting an old applet – a case study12.3.2. Long-life GUIs12.3.3. Providing new deployment support12.4. Exploiting technology12.5. Domain-specific and Little languages12.6. The future of Java GUIs12.7. Summary
13. Rich Client Platforms
13.1. Introduction to Java rich client platforms13.1.1. The case for RCP applications13.1.2. What's in an RCP13.1.3. GUI design guidelines and RCPs13.2. The NetBeans RCP13.2.1. NRCP architecture13.3. The Spring RCP13.4. The Eclipse RCP13.4.1. Eclipse plug-in architecture13.4.2. Eclipse RCP plug-ins13.4.3. The workbench – the building blocks of ERCP GUIs13.4.4. GUI design guidelines for ERCP applications13.4.4.1. The native twist13.5. Choosing the best RCP for your needs13.5.1. When to employ an RCP13.6. Legal issues13.6.1. Eclipse13.6.2. Netbeans13.7. An example Eclipse RCP application13.7.1. The application13.7.2. Introducing client-side modular architectures13.7.2.1. Plug-ins and pomegranate seeds13.7.2.2. Pomegranate seeds and software components13.7.2.3. Designing modular RCP applications13.7.3. The Snooper application architecture13.8. Summary
14. The Personal Portfolio Application
14.1. The scenario14.1.1. A note on lifecycle models14.2. Analysis14.2.1. Early analysis14.2.1.1. The vision14.2.2. Some scenarios14.2.2.1. User search14.2.2.2. User manages search results14.2.3. A refined use case diagram14.2.4. Individuating boundary classes14.3. Choosing a technology14.4. An initial GUI design14.4.1. An initial GUI paper mock-up14.4.2. A second GUI paper mock-up14.4.2.1. Nailing down the logical model14.4.3. A throw-away GUI prototype14.4.4. Validating the throw-away prototype14.5. The final GUI14.6. Implementation14.6.1. Software requirements14.6.2. The software architecture14.6.2.1. Boundary classes14.6.2.2. Package organization14.6.2.3. Business objects14.6.2.4. The local container14.6.2.5. The remote explorer14.6.2.6. Control14.6.2.7. Start-up14.7. Resources14.7.1. Localization bundles14.7.2. Images14.8. The code14.8.1. The remote explorer director14.8.1.1. Explorer events14.8.1.2. Representing application data14.8.1.3. Implementing searches14.8.2. The prototype14.9. Deployment issues14.9.1. Server support14.10. An alternative, cost-driven implementation14.10.1. Choosing a higher-level starting point14.10.2. A cost-driven prototype using JDNC14.10.3. A brief introduction to JDNC14.10.3.1. An example of JDNC declarative language14.11. Summary
15. An Example OO User Interface
15.1. Introduction15.1.1. A matter of style15.2. Implementing object-oriented user interfaces15.2.1. The Viewable interface15.2.1.1. Some simplifying assumptions15.2.1.2. Implementing views15.3. Some utility classes15.3.1. Brief views15.3.2. Making collections viewable15.4. Configuration views15.4.1. A utility class15.5. Interacting with the user15.5.1. The Commandable interface15.5.1.1. Composing commands15.6. Managing user commands15.7. An example application15.7.1. OOUI objects15.7.1.1. Book objects and their implementation15.7.1.2. Taming complexity15.7.1.3. Unexpected views15.7.1.4. Reducing development costs15.7.2. The code15.7.2.1. The ViewableBook class15.7.2.2. The ConfigurableBook class15.7.3. Libraries15.7.4. Some GUI design considerations15.7.5. Control issues15.7.5.1. Centralized control15.7.5.2. Scattered control15.8. An alternative implementation using Naked Objects15.9. Summary
16. An Example Ad-Hoc Component
16.1. Introduction16.2. The Drawing Sandbox application16.2.1. The application16.2.1.1. An example interaction16.3. The Sandbox architecture16.4. The Sandbox component16.4.1. Top-down refinement of functional organization16.4.2. Organizing object communication16.4.2.1. The SandboxPanel class16.4.3. Graphical objects16.4.3.1. The BitmapSymbol class implementation16.4.3.2. Open-ended communication via events16.5. User interaction16.5.1. Command composition16.5.2. The Action framework16.5.3. The Actions class16.5.4. Undo-redo support16.5.5. The Edit class16.5.6. Recording edits16.5.7. Memory issues16.6. Control16.6.1. The Director class16.6.2. Managing actions16.6.3. Enforcing logical constraints on actions16.7. The whole picture16.8. Stressing the software design16.8.1. Adding objects and commands16.8.2. The design's weak points16.9. Introducing JHotdraw16.10. Summary16.10.1. Key ideas
A. A Questionnaire for Evaluating Java User Interfaces
B. A Questionnaire for Evaluating J2ME Applications
References
General advice on usability and GUI designJava-specific links

Content preview from Professional Java User Interfaces

Chapter 16. An Example Ad-Hoc Component

This chapter describes an example of the design and implementation of an ad-hoc component with the Java programming language, focusing on the J2SE and the Swing library only.

Chapter 2 stated that a GUI can be thought of as being composed of visual components and their auxiliary elements. From a developer's viewpoint, such components can be thought of as belonging to three main groups, depending on their development cost:

Standard components, such as a 'plain' JTree instance.
Specialized components, such as a complex JTree subclass that re-implements many of the JTree auxiliary classes.
Ad-hoc components. These are visual components completely different than the standard ones provided by Swing or other GUI libraries. Ad-hoc components are much more expensive to develop, because their development effort comprises GUI design, testing, and coding.

If there were no reusable, standard libraries, we would develop components from scratch over and over, at enormous cost and without any coherence between different implementations of the same component. Luckily, the last twenty years of software engineering has provided today's developers with a wide range of tools for reusability and easy customization of their programs. See for example (McConnell 1993).

Unfortunately standard libraries don't cover all the possible components so that, although rarely, it is still possible to find yourself engaged in ad-hoc component building.

This chapter is structured as ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Domain-Driven Design with Java - A Practitioner's Guide

Publisher Resources

ISBN: 9780471486961Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design

Business

Soft Skills

Professional Java User Interfaces

by Mauro Marinilli

Chapter 16. An Example Ad-Hoc Component

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.