1. Notices Assn 3 is posted – due this Friday. Quiz marking underway (still). See assn 3 forum postings on use of Color class and meaning of second Emitter argument. Winter 2016CMPE212 - Prof. McLeod1

2. Today AWT, Swing, JavaFX. Event-Driven Programming. GUI Design. Winter 2016CMPE212 - Prof. McLeod2

3. Winter 2016CMPE212 - Prof. McLeod3 Hierarchy Example - GUI Components Of Historical Interest: Many of these are part of the Component hierarchy in javax.swing Swing was a modern improvement, built on the older, AWT (“Abstract Windows Toolkit”) classes. The following diagram is a simplified summary of the structure:

4. Winter 2016CMPE212 - Prof. McLeod4 ComponentGridLayoutBorderLayoutFlowLayout Container Abstract Class Concrete Class Object Window Frame JFrameJComponent java.awt javax.swing

5. Winter 2016CMPE212 - Prof. McLeod5 AbstractButton JMenuItem JLabel JMenuBar JPanel JTextArea JFrameJComponent javax.swing JMenu JButton JTextComponent JTextField

6. JavaFX JavaFX classes are no longer part of this hierarchy. JavaFX is a bold, new world of GUI coding! Swing code will not longer be updated. Any improvements will be in JavaFX packages only. Library code used to be in a separate API, but now javafx.* packages are included in the distributed JRE (in jfxrt.jar). You still need to configure eclipse to program in JavaFX (later). Winter 2016CMPE212 - Prof. McLeod6

7. JavaFX, Cont. Swing was developed mostly for enterprise/business use, not for personal use and certainly not for mobile devices. Available in the API since Java 7. The latest is called JavaFX 8. There are 30 javafx.* packages in the API. Jazzier controls, more support for portable devices. Winter 2016CMPE212 - Prof. McLeod7

8. “Client Technologies” For lots of links on JavaFX and Swing see: http://docs.oracle.com/javase/8/javase- clienttechnologies.htm It would be fun to learn JavaFX right away, but we need to “walk” before we can “run”! Winter 2016CMPE212 - Prof. McLeod8

9. Winter 2016CMPE212 - Prof. McLeod9 Event-Driven Programming So far, for assignments, you have written single threaded “batch” programs – the coder (you!) controls the flow of execution. For event-driven programs, the user controls the flow by initiating events. A GUI interface consists of components contained within a frame (or “window”). Components and even the frame itself can respond to events.

10. Winter 2016CMPE212 - Prof. McLeod10 Possible Events Some things that can trigger code execution: –Left mouse click down on a command button. –Left mouse click down on any component. –Similarly for any mouse button. –Similarly for holding a mouse button down. –Similarly for mouse button up. –Double click on a component… –Cursor over a component. –Cursor leaving a component. –Cursor hovering over a component. –Component has focus or has lost focus. –Component contents have changed. –Alt-key or Cntrl-key or Shift-key, etc…

11. Winter 2016CMPE212 - Prof. McLeod11 Events, Cont. Most events you ignore – your interface does not have to respond to every possible keyboard and mouse initiated event – that would be crazy!! To respond to an event in code, you attach an Event Handler object to a component. When an event occurs the handler receives an object which contains information about the source of the event (which mouse button, etc.) You decide which events are of interest and what you want your program to do when these events occur.

12. GUI Construction Construction of a Graphical User Interface involves: –Creating the design of the window – choosing components (buttons, labels, text boxes, etc.) and where they are positioned in the window. –Changing properties, including appearance properties, of the components. –Adding and linking functionality to events, where needed. –Repeating these steps for each window! –Connecting the program flow between windows. Winter 2016CMPE212 - Prof. McLeod12

13. Winter 2016CMPE212 - Prof. McLeod13 GUI Design Interface design is a BIG topic – beyond the scope of this course. IDE (Integrated Development Environments) tools can make it easy to choose and position components on a frame – but is the design as user-friendly as possible? Too many GUI programs have been slapped together without much thought as to their usability.

14. Winter 2015CMPE212 - Prof. McLeod14 Interface Hall of Shame! This site is dated (circa 2000), but the points it raises are still valid. And many of the examples are humorous! http://hallofshame.gp.co.at/index.php?mode=original Also has links to other resources on interface design. Also: http://www.webpagesthatsuck.com/index.html

15. Winter 2016CMPE212 - Prof. McLeod15 Isys Information Architects Web Site Part of their development philosophy: “Software must assist the user perform a task, not become a task in itself. Software must not make the user feel stupid. Software must not make the computer appear to be stupid”.

16. Winter 2016CMPE212 - Prof. McLeod16 “Principles of Good GUI Design” by James Hobart (CCI) (Corporate Computing International) Avoid the Biggest Problems: –Forgetting the user. –Not allowing the user full control. –Putting too many features at the top level. Understand People –Pattern/picture recognition – don’t expect a user to work from memory all the time. –Stay open to the different experiences and perspectives of your users.

17. Winter 2016CMPE212 - Prof. McLeod17 James Hobart, Cont. Design for Clarity and Consistency –Use consistent, self-explanatory terms for operations throughout the entire system. –(Enforced by Macintosh, but not Microsoft…) –Pay “homage” to common operational terms like “copy”, “paste”, “save”, “save as”, etc. Provide Visual and Audible Feedback –Use progress bars for operations that take more than a few seconds. –Use sounds to warn users, but allow him to turn these off later…

18. Aside – “Design Leadership” From: http://blog.userfocus.co.uk/design- leadership/ Winter 2016CMPE212 - Prof. McLeod18

19. Winter 2016CMPE212 - Prof. McLeod19 James Hobart, Cont. Use Text Sparingly But Wisely –Text should be descriptive but concise and accurate. –Might be a task for a trained technical writer? Provide Traceable Paths –The user should always know how he arrived at the current window and how to get back out again. –Not so easy to implement!

20. Winter 2016CMPE212 - Prof. McLeod20 James Hobart, Cont. Provide Keyboard Support –Challenge: Can a user navigate and use all of your program without using a mouse? –What operations should be mouse only? Maintain a Consistent “Look and Feel” –Give a lot of thought to a single look and feel style that can be used throughout your project. –(Changing the style of your presentation later can be very time consuming!)

21. Winter 2016CMPE212 - Prof. McLeod21 James Hobart, Cont. Control Window Types and Numbers –You can use “modal” dialog boxes for finite tasks (such as getting a specific user input). –Otherwise try to keep the number of simultaneous modeless boxes to three or less. –(What is the difference between modal and modeless windows, anyways?)

22. Winter 2016CMPE212 - Prof. McLeod22 Google Web Page Design See: http://www.youtube.com/watch?v=697KX4Ciiws Skip the first few minutes – start at about 2:40

23. Winter 2016CMPE212 - Prof. McLeod23 Web Usability See http://www.usability.gov Good on-line books: http://www.webstyleguide.com/ http://www.usabilityinstitute.com/resources/userInYo urFace/userInYourFace.htm

24. Books ( whatever they are… ) “GUI Bloopers 2.0”, by Jeff Johnson (also see http://www.gui-bloopers.com) “Designing with the Mind in Mind: Simple Guide to Understanding User Interface Design Rules”, also by Jeff Johnson “Don't Make Me Think: A Common Sense Approach to Web Usability”, 2nd Edition, by Steve Krug Many others! Winter 2016CMPE212 - Prof. McLeod24

25. Web Design vs. Application UI Design What are the different design considerations between a web app, a PC app and (what the heck!) a portable app? How about touch screens vs. a normal keyboard/mouse interface? Winter 2016CMPE212 - Prof. McLeod25