1 / 34

GUI

GUI. Designing your own. This presentation covers. Basic GUI design principles Increasing usability. Introduction. GUI have become the favourite interface by many. However, many applications fail to provide a good user interface, especially on the web.

harley
Télécharger la présentation

GUI

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. GUI Designing your own

  2. This presentation covers • Basic GUI design principles • Increasing usability

  3. Introduction • GUI have become the favourite interface by many. • However, many applications fail to provide a good user interface, especially on the web. • There are some simple rules that should be applied when designing a new GUI.

  4. Things to consider • There are certain principles that should be followed when designing a new system: • The principle of user profiling • The principle of metaphor • The principle of feature exposure • The principle of coherence • The principle of state visualisation • The principle of shortcuts • The principle of focus • The principle of help • The principle of aesthetics • The principle of user testing • The principle of humility

  5. User profiling • Know who your user is. • Remember that different types of interfaces suit different needs. • An novice user would find it hard to use an expert interface such as a command line.

  6. User profiling • Consider: • What are the user's goals? • What are the user's skills and experience? • What are the user's needs? • Consider: • Skilled vs Unskilled • Young vs Old

  7. Metaphor • Borrow behaviors from systems familiar to your users. • Complex systems can be made a lot easier if they resemble a system that a user is already familiar with. • Good examples include the VCR or CD player examples: • The same style of buttons are used for all of them. • You have to be careful about audience though. People in different countries always find it hard to find post boxes because they are different in most countries! • Changing styles within applications can cause the same confusion!

  8. Feature Exposure • Let the user clearly see what functions are available. • Two types of user: • ‘Intuitives’ • Like things in a logical way e.g. command line and scripts. • ‘Sensibles’ (more people are like this) • Like things up front and in their face.

  9. Feature Exposure • DOS is an example interface that ‘intuitives’ like. • Tool bars and menus are good examples of an interface feature that ‘sensibles’ like.

  10. Feature Exposure • It doesn’t mean that all systems need a GUI. • What is important is that the features can be quickly and easily found through visual representation. • Help in DOS • Images in GUI

  11. Feature Exposure • Help menu in DOS

  12. Feature Exposure • Tool bars in MS Office 2003 • Note: Look at the icons and think about what was said in the metaphor section – Using familiar things.

  13. Feature Exposure • Tool bars in MS Office 2007 • Note: Look at the icons and think about what was said in the metaphor section – Using familiar things.

  14. Coherence • The behaviour of a program should be internally and externally consistent. • Internally • If a user wants to change the colour of a font and clicks on a pop-up to do this, it should be expected that if they wanted to change the colour of anything else the same style of pop-up will be used. • Externally • Should design the software so that it matches the operating system it runs on, and with the software applications it is likely to be used with.

  15. Visualisation • Changes in behaviour should be reflected in the appearance of the program. • A good example of this is include changes in the cursor, for example: • Hourglass cursor when the application is busy • Arrow for selecting menus • Text cursor when selecting text.

  16. Visualisation • The application should change with the user’s behaviour. • For instance, when a user is working their way through a set of commands, only the options that they could interact with should be made available to them. • Some common mistakes include: • Not dimming an application window when it becomes out of focus.

  17. Shortcuts • Provide both concrete and abstract ways of getting a task done. • The more a user uses an application, the more familiar they become in its working. • The frond-end design can start to seem cumbersome. • The useful design that was used to break down complex tasks becomes tedious. • The use of shortcuts can boost productivity in the experienced user.

  18. Shortcuts • There are different levels of shortcuts too. • As the user builds confidence in the application they can call about quick keys to select options through menus: • Alt + F +P will take you through the File menu and into the Print option visually. • As the user builds in more confidence they will no longer need the visual aid: • Ctrl + P takes the user to the print options without the user needing a visual guide.

  19. Focus • Some aspects of the UI attract attention more than others do. • Our eyes are non-linear and have: • Edge-detection hardware • We see a third colour when two close matching colours are placed next to each other. • Motion-detection hardware • We are hunters…our eyes are highly tuned to see and track motion.

  20. Focus • The mouse is the most looked at object on any system. • The user will track the mouse to aid in navigation. • This is also why the mouse reflects the state of a computer. • It is highly accepted that this is the most useful way to feed back information to the user.

  21. Help • Understand the different kinds of help a user needs. • Goal-oriented: • "What kinds of things can I do with this program?" • Descriptive: • "What is this? What does this do?" • Procedural: • "How do I do this?" • Interpretive: • "Why did this happen?" • Navigational: • "Where am I?"

  22. Help • You can have all kinds of help systems installed: • Help when a cursor rests over an object • Help in a help file • Help in user manuals • Help using step by step wizards • Use can answer questions relating to a problem in hope that a solution is found. • Bit like an expert system that a doctor my use to help diagnose a patient.

  23. Aesthetics • Create a program of beauty. • An application doesn’t have to be a work of art…but it can’t be ugly. • Artist William Rotsler: "Never do anything that looks to someone else like a mistake."

  24. Aesthetics These icons are neatly arranged, are all the same size and colour. The look professional and are easy to use. These icons have not been lined up perfectly, are different sizes and some are a slightly different colour. They have an off-balance feel.

  25. User Testing • Recruit help in spotting the inevitable defects in your design. • Good designers will spot the fundamental flaws in their application. • However, the use of real end user testing can be invaluable and has proven incredibly effective for ironing out bugs in the system.

  26. User Testing • Set up an observation • Tests should include sample tasks which need to be completed. • The testers should be of the same experience level as the intended end user. • Explain to the user that you are testing the system…not them. The user should be at complete ease. Explain to them that any mistakes is because of the system. This is why you test.

  27. User Testing • Talk about and demonstrate the equipment where the test will take place. • Explain how to ‘think aloud’. • Testers should be reminded that they should try and verbalise their thoughts so the designers can understand their though processes. This is a very useful thing to know when designing any system.

  28. User Testing • Explain that you will not provide help. • Describe the tasks and introduce the product. • Ask if there are any questions before you start; then begin the observation. • Conclude the observation. Tell them what you found out and answer any of their questions. • Use the results.

  29. User Testing • User testing can occur at any time during the project. • According to a lead specialist, Tognazzini, you should not need more than 3 testers per iteration. • Any more than this and you will just be confirming known faults.

  30. Humility • Listen to what ordinary people have to say. • By listening to people you get a good understanding of what the majority of them want. • Although you can not cater for everyone’s needs and desires, you can design something that benefits the majority.

  31. Humility You need to design for the majority.

  32. Humility • Most people have a biased opinion about what they think people want (its usually what they want). • Most people have some sort of core competency, and can be expected to perform well within that domain. • The skill of using a computer (also known as "computer literacy") is actually much harder than it appears. • The lack of "computer literacy" is not an indication of a lack of basic intelligence. • A high proportion of programmers are introverts, compared to the general population. • This means that they tend to find

  33. Humility • Remember • the best way to understand someone is to spend time with them!

  34. Questions • Can you write a brief summary about each of the topics that were covered? No more than a paragraph for each if possible. • The principle of user profiling • The principle of metaphor • The principle of feature exposure • The principle of coherence • The principle of state visualisation • The principle of shortcuts • The principle of focus • The principle of help • The principle of aesthetics • The principle of user testing • The principle of humility

More Related