professional java user interfaces phần 9 pot

504 The Personal Portfolio Application 1:33 PM 13 March 2006 c14.fm 1.0 4. User changes search preferences (search name, search parameters, and so on) to modify the set of retrieved documents. 5. User commits the changes. The search is submitted to the server. From this point on this scenario follows the preceding one. In a real-world use case document, more refined scenarios would follow. A refined use case diagram After further interviews with end users and more analysis activity, the following use case diagram is defined. Note that this refined diagram includes a new actor, the local operating system (OS), which is needed to store and view downloaded documents, together with a more structured use case organization. This diagram forms the input to the first GUI paper mock-up prototype. The next step in following an RUP methodology is to elicit the actors-system boundary classes. Figure 14.4 A refined use case diagram c14.fm Page 504 Monday, March 13, 2006 1:34 PM Choosing a technology 505 1:33 PM 13 March 2006 c14.fm 1.0 Individuating boundary classes Boundary classes are those classes that lie at the boundary between the system and the external actors. Using the concept of a personal portfolio of documents, and studying the previous scenarios from the viewpoint of the end user actor, we could think of the main boundary class as a collection of search objects: search objects gather retrieved documents from the remote repository, and users will mainly deal with a collection of searches. After initial interviews a partial conceptual model of the application domain is nailed down, as shown in Figure 14.5. Before proceeding to the design, we need to make some basic choices about the underlying technology. Clearly, our design will be radically affected by this stra- tegic choice. 14.3 Choosing a technology The choice of a suitable implementation technology is basically restricted to Web- based technology, essentially JSP, php, or other Web page–based technologies, and some form of client technology. The choice of Java is driven by several cultural and practical issues: • The repository server is implemented with J2EE technology. • Developers feel more comfortable with Java rather than with other technologies. • It takes advantage of existing development tools to minimize risk and addi- tional cost, such as expensive licenses, the evaluation of and training for new software, and so on. The class diagram in Figure 14.5 is related to the conceptual domain only, and shouldn’t be confused with the implementation class diagram that we will consider in a later section. Figure 14.5 An initial conceptual class diagram c14.fm Page 505 Monday, March 13, 2006 1:34 PM 506 The Personal Portfolio Application 1:33 PM 13 March 2006 c14.fm 1.0 • The end user population relies on recent machines with a variety of OSs, and Java would be a cost-effective choice at least for the first generation of the application – the riskier one. This scenario dictates that, among the various Java client options, the most useful deployment technology is the JNLP protocol, as it is available for all Java-enabled platforms. Deployment aspects are considered later in this chapter. The choice of JNLP choice ensures the following benefits: • A team of developers is available that is familiar with the implementation platform. • Synergy between client and server technology is guaranteed. • Ease of deployment and debugging facilities over the Web is supported. This is particularly useful for the frequent deployment of updated prototypes. Now that a stable set of functional requirements for the application exists and the technology has been chosen, the GUI design phase can begin. 14.4 An initial GUI design The main tasks that need to be addressed by the application are: • Authenticate the user • Create and manage repository searches • Access documents retrieved by these searches • Manipulate and modify the searches • Store the searches The preliminary design phase produces a number of documents that describe the basic functional requirements, the product vision, a number of use case diagrams and scenarios, plus some models that sketch the application domain, and other informal observations. All this information is ready for convergence into a tenta- tive GUI prototype. The team follows a participatory design approach, in which users actively contribute to the GUI design. This method is chosen because of the nature of the current case – the intended user population, the focus on usability, and so on. An initial GUI paper mock-up From an informal meeting among designers, the first design proposal is sketched out. The main window is composed of a toolbar, a list of all the active searches, and a status bar, as shown in Figure 14.6. Each item in the list represents a search, with a title and other useful data, such as the current status of the search, an is available c14.fm Page 506 Monday, March 13, 2006 1:34 PM An initial GUI design 507 1:33 PM 13 March 2006 c14.fm 1.0 for quick selection. The commands in the toolbar affect the currently-selected search item in the list. By double–clicking on a search item, another window pops up that lists the docu- ments retrieved by the search. This second window is sketched in the paper mock- up in Figure 14.7. Double–clicking on a single document in the list starts the download process, following which the relevant viewer for the specific document type is opened. The buttons in the toolbar manipulate the currently-selected document in the list. The Info command pops up a dialog with the document’s data, such as author, publi- cation date, and so on, without downloading the document. The View command works like a double click: first the document is downloaded, then it is opened. From a conceptual viewpoint, the prototype relies on the idea of a list of searches created and maintained by the user. Any of these searches can be opened to show all the retrieved documents and, in turn, the documents can be manipulated by the user. This mock-up is used as a starting point for a subsequent discussion with repre- sentative users. The objective of this second meeting is to produce an early GUI prototype that is representative of user’s needs, and which in turn will be vali- dated with a larger user population. Figure 14.6 The first paper mock-up c14.fm Page 507 Monday, March 13, 2006 1:34 PM 508 The Personal Portfolio Application 1:33 PM 13 March 2006 c14.fm 1.0 A second GUI paper mock-up The design team holds a second meeting, in which a selected group of users discussed the GUI design sketched in Figure 14.6. Their objective is to nail down an initial stable prototype that is validated by representative users. This meeting results in a major redesign of the GUI: the users explain the most frequent tasks for which they intend the GUI to be suited, using the first prototype as a common discussion ground. A crucial aspect that emerges from this meeting is the desire of users to be able to fully customize their workspace. They see this as one of the major limitations of the existing Web interface. Many different interaction strategies emerge from this second meeting. End users turn out to have radically different (and unexpected) approaches to solving the same tasks: for example, one uses several slightly different searches to explore the documents on a given topic, carefully recording the best searches on paper for future reference, while another is accustomed to launching broad queries and then scanning the large list that results. Other important issues expressed by users were: • To be able to use more natural interaction styles, such as ‘drag and drop’ (there is a significant Apple Macintosh community among end users). Figure 14.7 Another paper mock-up c14.fm Page 508 Monday, March 13, 2006 1:34 PM An initial GUI design 509 1:33 PM 13 March 2006 c14.fm 1.0 • The importance of having a lot of information in one screen, rather than continuously switching between different windows. • Gearing up the GUI for repetitive users, providing powerful ‘horizontal’ features rather than complex specialized ‘vertical’ ones – continuously popping up windows to inspect search outcomes seemed too awkward. • To focus the whole GUI on common tasks, or at least making them as easy as possible. • The difficulty of making comparisons between two different searches. • A bookmark concept, very useful in practice, is lacking. • A properties panel beside the search lists, including some basic information about retrieved documents, would help the details of each search to be inspected more easily. The designers gather all these suggestions, and after further interaction, worked out the prototype shown in Figure 14.8. This GUI is substantially different than that shown in Figure 14.6 – ‘drag and drop’ and a more flexible interaction allow for a richer GUI experience and more intuitive interaction. Figure 14.8 The revised paper mock-up c14.fm Page 509 Monday, March 13, 2006 1:34 PM 510 The Personal Portfolio Application 1:33 PM 13 March 2006 c14.fm 1.0 Lurking behind the GUI design sketched in Figure 14.8 are some interesting conceptual considerations. As often happens, limitations in a GUI design often derive from a poor conceptual model. As well as the concept of an explorer object that represents the searches performed by users, as previously implemented by the list in the prototype in Figure 14.6, the prototype in Figure 14.8 introduces a new and useful abstraction, the local container. This is an object that contains all the documents of interest to the current user, and follows the Desktop metaphor used by all modern OS GUIs. This container maintains an image of selected documents that can be manipulated by the user, and documents transferred in the container can later be downloaded to the user’s local file system. A typical interaction for creating a search object now leads to the creation of a new node in the tree on the left hand-side of the GUI, termed the remote explorer area. Retrieved documents are shown as subnodes of the search node, mimicking a file system hierarchy. Clicking twice on a document node, or dragging a node to the right-hand side of the screen, transfers the relevant document into the local container. Documents in the container can be managed just like documents in a desktop environment. In particular, by double-clicking on a container document, it is possible to view the document’s contents, perform background user authen- tication, billing, and other operations, and finally download the document content to a local cache. The ‘drag and drop’ metaphor is intended to be coherent outside the container as well – dragging a document out of the application window and onto the OS desktop area should cause the document to be downloaded to the desktop or to a target folder. Locating the exploration task on the left-hand side of the screen and the manipu- lation area on the right follows a general and widely-accepted pattern in modern GUIs, as we saw in Chapter 4. Taking advantage of this kind of convention is usually a ‘win-win’ approach: on one hand designers get useful guidelines for limiting the initial design space to the promising avenues, while on the other users feel comfortable using a GUI that resembles software with which they are familiar. Nailing down the logical model This is an important and often overlooked aspect of GUI design. Designers may need to change their assumptions later in the development process, but a sound conceptual analysis is still indispensable at an early stage to achieve a professional GUI design. Designers should carefully refine the conceptual model behind the GUI, searching for inconsistencies and conceptual fallacies. The two abstract concepts the new document repository client’s GUI relies on so far are: • Remote explorer. A collection of search objects defined by the user and the retrieved document metadata. The document metadata only contains sparse c14.fm Page 510 Monday, March 13, 2006 1:34 PM An initial GUI design 511 1:33 PM 13 March 2006 c14.fm 1.0 data, to avoid downloading useless information. The search objects reside on the server, allowing for collaborative features, and are updated when the application is started. • Local container. This represents a collection of information about the docu- ments transferred by the user as a result of document searches. Document transferred into this container are not yet downloaded. The final step in fully accessing a document – after initiating a search, selecting one or more retrieved documents, and transferring them into the local container – is by downloading the document and viewing it via a suitable OS-dependent viewer application. Document metadata stored in the local container is kept in a cache on the user’s local file system, together with document content files. Clearly, this is only the first refinement of the GUI’s conceptual model, but it is important to define it a soon as possible, even if it may be changed in the future. A throw-away GUI prototype Having tested the mock-up with users, the designers are ready to implement it in order to build a more vivid representation of the final GUI that can be validated by a larger number of users. Technology now enters directly into the design process. The aim is not to produce a working GUI prototype, but rather to capture basic interactions (inexpensively), and hence requirements, in further interactions with users. They produce the prototype shown in Figure 14.9. Figure 14.9 The throw-away prototype (Ocean1.5) c14.fm Page 511 Monday, March 13, 2006 1:34 PM 512 The Personal Portfolio Application 1:33 PM 13 March 2006 c14.fm 1.0 The GUI closely resembles the revised paper mock-up discussed in the previous section (Figure 14.8). Users can drag items from the tree on the left-hand side into the container on the right of the window, mimicking the transfer process. Three system icons are placed in the virtual desktop container on the right-hand side, as shown in Figure 14.10. These icons are used for ‘drag and drop’ manipu- lation of documents . For example, dragging a document onto the wastebasket icon removes the document from the local container. We will go into the implementation details of this prototype later. Validating the throw-away prototype Usability tests done on a larger user population reveal that some of the GUI assumptions were wrong. In particular, the system folders on the right-hand side in Figure 14.9 and Figure 14.10 are misunderstood by the vast majority of users – only few of them can correctly work out their use. Clearly, it seems that the design team, including the users who participated in the design, were biased in their preliminary assumptions. In such cases – when the interaction needed to activate some functionality is not clear – the best solution is to rely on the underlying platform guidelines. Here the Figure 14.10 The throw-away prototype at work (Ocean1.5) c14.fm Page 512 Monday, March 13, 2006 1:34 PM The final GUI 513 1:33 PM 13 March 2006 c14.fm 1.0 designers adopted the Java Look and Feel design guidelines 1 , so in this case a typical interaction would follow a contextual menu style. By right-clicking on the chosen item, users could access all the available functionalities for the selected item. A second version of the prototype is produced in which the system icons were removed. This second version, using contextual menus, was successfully vali- dated with users. Finally the design team came out with a reliable and detailed design, ready to be used as a specification for the first release of the Portfolio project. 14.5 The final GUI Before getting into the details of the implementation, let’s review the final GUI from an end user perspective. This will help to better clarify the interaction details while keeping the discussion at a intuitive and concrete level. Figure 14.11 shows how the final application looks. Suppose we create a new search My Search using the toolbar button, or by right-clicking on a remote explorer folder via the contextual menu. The new search folder will appear in the remote explorer, as shown in Figure 14.11. 1. See Chapter 2. Figure 14.11 Creating a new search (Ocean1.5) c14.fm Page 513 Monday, March 13, 2006 1:34 PM [...]... User Interface An Example OO User Interface In this chapter we will explore some software design techniques for building professional user interfaces, demonstrating a way to implement GUIs with the Java programming language by taking advantage of the OOUI conceptual approach introduced in Chapter 1, within the reference architecture introduced in the previous chapter As well as providing a set of Java. .. pre-existing standard libraries such as SWT or Swing1 Several existing OOUI implementations exist for Java, for example the Favabeans project Compared with such frameworks, we adopt a more lightweight approach 1 3 :9 PM 9 March 2006 For an alternative approach to these issues, see (Holub 199 9) c15.fm 1.0 538 An Example OO User Interface when designing an OOUI implementation, favoring simplicity and clarity over... object-oriented user interfaces introduces a simple framework for implementing object-oriented user interfaces (OOUI) 15.3, Some utility classes extends the simple framework introduced previously with some useful classes 15.4, Configuration views discusses the specifics of configuration views 15.5, Interacting with the user discusses some general-purpose implementation strategies for representing user interactions... objects need to offer different views, depending on some external parameter such as the current user s role A partial view is provided by an Object to expose visually some particular aspect of its state Usually some extra parameter is needed to 3 :9 PM 9 March 2006 c15.fm 1.0 5 39 Implementing object-oriented user interfaces specify domain-specific details and a convention shared with the Viewable class to... made with Java The solutions proposed here are partial and not intended to be definitive, as the task of choosing the correct software architecture for a given GUI design is a complex one and involves many variables, such as the architect’s preferences and habits, the GUI’s inherent complexity, the project size, and so on 3 :9 PM 9 March 2006 c15.fm 1.0 537 Implementing object-oriented user interfaces. .. projects 15.2 Implementing object-oriented user interfaces Object-oriented programming (OOP) is a good match with Object-oriented User Interfaces (OOUI): although the two concepts are not strictly related, it is not by chance that GUI widgets model nicely as objects On the other hand, from an OOP purist’s viewpoint, many of the GUI libraries provided with Java, such as Swing or SWT, are not perfectly... a much constrained GUI design The chapter concludes with a summary 3 :9 PM 9 March 2006 c15.fm 1.0 536 15.1 An Example OO User Interface Introduction As technology evolves, developers and designers can rely on more and more powerful computers, enabling them to afford more sophisticated designs, a trend that doesn’t only apply to the user interface – the software architecture behind the UI has also been... the user either by a status bar message, as in the Portfolio application, by a progress dialog that allows users to abort the process, or in other ways, for example by modifying the mouse cursor shape The demonstration code employs a minimal notice strategy, using only the status bar and visually disabling the transferred/transferring node, because its GUI is intended for experienced, repetitive users... container The next step is to refine these two major components 3 See Chapter 15 for more details about these interfaces 1:33 PM 13 March 2006 c14.fm 1.0 5 19 Implementation Figure 14.17 Class diagram for publications The local container This component is logically a folder of documents selected by the user We implemented it as a sandbox instance – that is, following the ‘desktop’ metaphor Icons in the sandbox... code for the Prototype1 class can be found in the source bundle of this chapter – we are now left with the deployment aspects of the Portfolio application 14 .9 Deployment issues Deployment is an often overlooked part of the software lifecycle Professional products are characterized by the way they ship and how they can be managed remotely Deployment services are essential to high-quality software (Marinilli . repre- sentative users. The objective of this second meeting is to produce an early GUI prototype that is representative of user s needs, and which in turn will be vali- dated with a larger user population (inexpensively), and hence requirements, in further interactions with users. They produce the prototype shown in Figure 14 .9. Figure 14 .9 The throw-away prototype (Ocean1.5) c14.fm Page 511 Monday,. technology. The choice of Java is driven by several cultural and practical issues: • The repository server is implemented with J2EE technology. • Developers feel more comfortable with Java rather than