IFD:Course Interaction Design: Difference between revisions

IFD:Course Interaction Design (view source)

Revision as of 13:44, 23 March 2011

10,627 bytes removed , 23 March 2011

cleaned legacy comments/content, started restructuring

JanD

Bureaucrats, emailconfirmed

1,221

edits

@@ Line 175: / Line 175: @@
 You can search for papers by using [http://www.google.com/scholar google scholar] or the [http://portal.acm.org/dl.cfm ACM Library]. The search is free in both cases but just google scholar links sometimes directly to the papers while you need a membership for ACM. If your university has one, you are a lucky student! But even if you find a paper on ACM or google scholar links on a pricy database too you should give it a try and search specifically for that papers title. Often the researchers have published accessible versions on their webpages.
-==techniques for designing==
-"Designing" in this context means turning your ideas in somehow graspable representations. This is needed for refinement, communication and testing. In these areas the different techniques have different strengths.
-<!--
-===...in words===
-Even if this is not seen commonly as "design" you can turn your ideas into words to communicate them or to check if you are clear about what you want to do. This is a technique that is very useful in earlier stages after the first big research on your users and their goals. Guided by what you find out you can write down what you want to provide to meet these goals. Though one is tempted to start directly with the "real" design (sketches, programming etc.) you should make your mind what the system needs to do. It prevents you to overlook things.
-A structured approach of this is defining "Requirements". This is defining the things your product needs to do at the end – in early phases the very essential ones.
-You can do this by writing them down as Sentences contnaining data, an action done with it and possibly the context. Data is a "thing" that represents some kind of information. That can be a phone number, an image, a file, a bookmark etc.
-An example would be: Look up [action] a phonebook entry [thing] while talking [context]. Or: play [action] music [thing]
-You can as well structure this more and make lists with the requirements.
-* Actions - what does the system need to be able to do? (e.g. sync files with PC, text WYSIWYG entry, inform the user about current appointments)
-* Data - with which kind of data ("things") does the system need to deal? (e.g. play MP3 music, handle max. 10,000 user profiles etc.)
-* Context – Where is the system used and for which purposes? (e.g. in public and outside, so it must be durable)
-* User - Which kind of user shall deal with the system? (e.g. the product is aimed to design students)
-There my be other kinds of requiremets that you need to consider when developing your product. This could be size of the product, speed, final price, that it needs to feel "cool" for teens to have it etc.
--->
-===Sketches===
-[[File:UI-Sketch-Flickr-Kyle_McDonald.jpg|thumb|50px|left]]
-Sketches are helpful in generating different ideas. They help you to structure your thoughts and keep good ideas for later refinement or combination with other ideas. Don't worry about your sketches as long as you can understand them yourself! They are just for dealing with your own ideas and especially used in early project phases directly after research and whenever you have and idea you want to remember.
-===Mockups===
-[[File:Wireframe_Flickr-JoeCrawford.png|thumb|150px|left]]
-Mockups are more advanced than sketches: often cleaner and more carefully crafted. Mockups are used for communicating in a team and to see how the elements of your interface play together in the screen layout. They are a graphic representation of what will be visible on the computers screen. So you can communicate your ideas about an application to your team-mates. It is usually decent to just draw the element's outlines - this type of mockup is known as "wireframe" as well.
-Like sketches mockups can be drawn on paper. Chequered sheets are useful here cause they provide a grid so your wireframe will look better and organized.
-There are a couple of tools for creating Mockups like Balsamique. Many people use Visio or OmniGraffle (two popular diagramming applications) as well.
-[[File:Mockup_Fennec.jpg|thumb|250px]]
-For Mockups you use in your team or for trying out screen layouts you don't want to waste time on shiny graphics. In contrast to this you may want to do a Mockup to present it to somebody who does not know about the design process and is just interested in how the finished project looks like. In this case you need to spend more time on graphics. Often you can use "Stencils", pre-created Interface-Element collections that are used with the diagramming applications above or an image-editor like Photoshop.
-===Prototypes===
-All ways of design above have in common that they can more or less look like the intended product but they don't have any functionality. "Models" of your software that provide functionality are called "Prototypes". They are mainly used for testing your ideas. In latter chapters I will teach how to build a prototype and to conduct a test with it.
-But before you eagerly start designing it may be helpful to explore some basic knowledge and principles that will help you designing products that offer a great user experience!
 ==Basics of Psychology==
@@ Line 349: / Line 309: @@
 In some cases you will use error messages. This is common for errors that derive from the way the technology that is used. E.g. if an application syncs files via a network and the network can not be accessed, the application can not work as intended. Many applications show error messages in a case like this: "IP Level 3 Error! Syncing process failed". This will trouble the user: The message uses system oriented terms that are only understandable for programmers and the user does not know how to solve the problem and does not know what happened to the data. A good error message uses simple and known terms and helps the user to recover the problem. This could look like this:"It seems that the necessary network connection is not available at the moment. Please put in your network cable or establish a wireless connection and try again to sync. Click the help button for further information". But before we consider that, we should make up our mind if it would be possible to make the system handle the error: The syncing actions could be remembered, the application could check if the problem is just because there is no network connection at the moment and that inform the user that the files will be synced later.
-==Get to know if your ideas work!==
-<!--
+==techniques for designing==
-===User Interface Design Heuristics===
+"Designing" in this context means turning your ideas in somehow graspable representations. This is needed for refinement, communication and testing. In these areas the different techniques have different strengths.
-Heuristics are "rules of thumb" derived from experiences that are used to solve problems efficiently. The rules are no guarantee to get an optimal or even a good solution but in the most cases heuristics work good and especially fast.
+===Sketches===
+[[File:UI-Sketch-Flickr-Kyle_McDonald.jpg|thumb|50px|left]]
+Sketches are helpful in generating different ideas. They help you to structure your thoughts and keep good ideas for later refinement or combination with other ideas. Don't worry about your sketches as long as you can understand them yourself! They are just for dealing with your own ideas and especially used in early project phases directly after research and whenever you have and idea you want to remember.
+===Mockups===
+[[File:Wireframe_Flickr-JoeCrawford.png|thumb|150px|left]]
+Mockups are more advanced than sketches: often cleaner and more carefully crafted. Mockups are used for communicating in a team and to see how the elements of your interface play together in the screen layout. They are a graphic representation of what will be visible on the computers screen. So you can communicate your ideas about an application to your team-mates. It is usually decent to just draw the element's outlines - this type of mockup is known as "wireframe" as well.
+Like sketches mockups can be drawn on paper. Chequered sheets are useful here cause they provide a grid so your wireframe will look better and organized.
+There are a couple of tools for creating Mockups like Balsamique. Many people use Visio or OmniGraffle (two popular diagramming applications) as well.
-You can counter-check your interfaces using the heuristics. In a proper "heuristic evaluation" you have some (max. 5) people who have some experience in Interaction Design checking your interface against a list of heuristic principles.
+[[File:Mockup_Fennec.jpg|thumb|250px]]
+For Mockups you use in your team or for trying out screen layouts you don't want to waste time on shiny graphics. In contrast to this you may want to do a Mockup to present it to somebody who does not know about the design process and is just interested in how the finished project looks like. In this case you need to spend more time on graphics. Often you can use "Stencils", pre-created Interface-Element collections that are used with the diagramming applications above or an image-editor like Photoshop.
-A frequently used list for design principles are the [http://www.useit.com/papers/heuristic/heuristic_list.html heuristics by Jacob Nielsen]:
+===Prototypes===
+All ways of design above have in common that they can more or less look like the intended product but they don't have any functionality. "Models" of your software that provide functionality are called "Prototypes". They are mainly used for testing your ideas. In latter chapters I will teach how to build a prototype and to conduct a test with it.
-# '''Visibility of system status''' is further explained [[IFD:Course_Interaction_Design#Feedback| here]]
+But before you eagerly start designing it may be helpful to explore some basic knowledge and principles that will help you designing products that offer a great user experience!
-# '''Match between system and the real world:''' the user should not have to learn a lot to use the system. The system should be designed in a way that allows to draw form real world experiences and not to contradict those.
-# '''User control and freedom:''' Sometimes the user will find the interface or the things in an undesired stage. It needs to be possible to "escape" from unwanted stages the program is in (see as well: [[IFD:Course_Interaction_Design#Modeless_Design | modes]]) and Undo/Redo should be provided as well.
+==Get to know if your ideas work!==
-# '''Consistency and standards:''' is further explained under  [[IFD:Course_Interaction_Design#Standards_and_Consistency| Standards and Consistency]]
-# '''Error prevention:''' Design should prevent errors. Some examples are [[IFD:Course_Interaction_Design#Safety| here]]
-# '''Recognition rather than recall:''' Users should not to have remember things they from other parts of the program [[IFD:Course_Interaction_Design#Visibility|Visibility]] and [[IFD:Course_Interaction_Design#Modeless_Design | Modeless design]] are ways to support this via design.
-# '''Flexibility and efficiency of use:''' The system should not be only easy to learn but to be efficient to use for advanced and professional users. Keyboard shortcuts are a good example for such an mechanism. More on Efficiency [[IFD:Course_Interaction_Design#Efficiency| here]]
-# '''Aesthetic and minimalist design:''' Let form follow function and dont add visual clutter by over-advanced visual design.
-# '''Help users recognize, diagnose, and recover from errors:''' In case an Error cant be prevented or handled by the application itself, the error message should state problem and possible solutions in plain, non-technical terms.
-# '''Help and documentation:''' It is good if no help is needed to learn the program but some questions will appear, so provide searchable, easy to access information how to use the product
--->
 After we developed ideas it is again time to check with reality! This is known as prototyping and testing.
@@ Line 483: / Line 447: @@
 Having a list with what causes the user problems you know can refine your work. In early stages you will have seen which of some different ways will be dismissed and which will be further explored.
 In later phases of your project you will have a list with ranked problems that need to be resolved. Start with the ones you consider the most serious and solve the problems. In doing so you often can build on the think-aloud-protocol you wrote. It give insight in the way the users think about the actions they took and about the responses of the software. This will help you to find a decent solution that will work better.
-<!--LEGACY -->
-<!-- In Alan Coopers Book "About Face 3.0" there is another great example about the difference: Traveler's goals are to travel "quickly, comfortably and safely". In 1850 archiving safety included to bring along a rifle - an activity to achieve the goal. The goals remained the same for today but for flying quickly, comfortably and safely we leave our weapons at home – different activities, same goal.-->
-<!--
-==Introduction==
-I suppose when you hear about "Interaction Design" you probably think about computer applications. He or she will probably decide how the functions of the software are represented to the user as icons or menu entries. You are not wrong with these assumptions: The most people who work as "Interaction Designer" deal with applications or websites and among other things they design what appears on the computer screen.
-But in addition an Interaction Designer researches as well which functionality people actually require or could need and they test as well if the ideas they have do actually work.
-The predecessors of the current interaction designers are the product designers like Dieter Rahms. He designed products for the German company Braun which show many aspects of modern interaction design: They are easy to use, form follows function and feature a elegant and minimalist design.
-If you say it in an extreme way you even could say that a handaxe is a great example of good design: It provides a good tool: you can it use for picking, scraping and you can even sling it. It is easy to see how one can use it. And the basic design was used for over a million years.
-If we look back in time and see that there are many things that seem to be "Interaction Design" we could wonder that we need an own discipline for it!
-Over the time technology became more and more complex. With digitalisation it was not longer possible to get a some tools and just figure out how it works: the interrelation of controls and resulting actions had no physical connection any more.
-Even more important, technology became more and more wide spread. Technology that was once just for experts became available to everybody. The sell the technology to more people it had to be easier to use.
-A short history of interfaces: Lochkarten, Kommandozeile, Guis, moderne Paradigmen
--->
-<!--==What do you want to do?==
-Everything starts with an Idea. So does your interaction design project. Before you start you should take a moment (or a few more) to consider what you aim for. Sometimes it is not that difficult: A client or you professor will state in which direction you shall go.
-If you are on your own or with a team of students this is more of an issue. So think which issue you want to tackle, which problem you want to solve, what you want to try.
-In the coming parts of the book you will see that I often reccomand to write down what you want to do in the next step. This has two reasons:
-If you need to write down something in a clear and concise way you will note if there is anything unclear about your goals. It is difficult to build on a unclear vision. And a good way to test this is to write it down.
-Having a goal is even more important if you work in a team. If everybody supposes everybody works on kind-of-the-same but actually everybody images something very different it is likely that at some point this will have bad consequences like people being upset because there work was not cosidered as useful or fights about the actual direction of the project that would not be necessary and just cause bad mood or in the worst case the whole project breakes down.  -->
-<!--
-===Usability Goals===
-The usability goals are a  collection of the very basic user needs that need to be met. They are broad, but you will have no trouble to understand them.
-====Utility====
-If your product's functionality matches the needs of your users and enables them to reach their goals it has a good utility.
-You can find out your users needs and goals by doing "user research" which means that you apply some research methods. One of these methods is doing a special kind of interview with some users. I will cover this technique in a latter chapter.
-====Learnability====
-A good learnability exists if the users you target can use your product without putting a lot of effort learning. This is especially important for the very basic functions.
-Ideally users don't have to bother about new concepts and unknown terms.
-Learnability is what will be the first thing that comes into your mind if you think about interaction design. Paradoxically it is a principle that is ignored in many products: Industry often uses a lot of functions that diminish learnability and many student projects ignore learnablity and focus on efficiency.
-You can improve the learnability of your application by learning common principles of design like "visibility" or "consistency" and by testing your ideas with your users. Material for learning this will be provided in latter chapters.
-====Efficiency====
-[[File:ComandLine.png|thumb|150px|Great efficiency but hard to learn]]
-Your product has a good efficiency if the user can achieve a high productivity. This simply means he/she can do more in less time once it is known how one uses the product.
-Efficiency can be achieved with optimizing the ways the functions are accessed and with providing additional ways of interaction like keyboard shortcuts.
-Efficiency is important, but in my experience it is easiely over-emphasized as one does not need to learn one's own designs and efficient stuff feels just great. But a command line interfaces or gestural interaction are cool and really efficient if you can use it but they need to be explicitly learned before they can be used. And the difficulties of learning are often underestimated by interaction design beginners.
-====Safety====
-Safety is protecting the user and his/her creations from undesired outcomes. Very basic is that you provide a product that does not crash and destroys the users work by doing so.
--->
 <!--===Simplicity===
@@ Line 579: / Line 492: @@
 [[Category:Interaktion]]
 [[Category:Interface-Design]]
 [[Category:Design]]
 [[Category:Courses]]