ITE 474 - - Human Computer Interface 1/12/00 ======= Initial programming - the programmer was given a set of specifications and he figured out what kind of modules had to be written...and the programmer actually controlled the type of sequence the program ran in. You would get the data, process the data, present some type of output. New stype of programming - interactive, event driven program. The user might click on a button and certain things might happen. ---------GET DATA----------- ------PROCESS DATA----- --- OUTPUT DATA --- You might then go back in and do something like this: ---(1)---GET DATA----------- -(2)---PROCESS DATA----- -(3)-- OUTPUT DATA --- Somewhere between treating the user like an idiot and between blowing them completely away with a wordy dialogue...you can find a happy medium. In the traditional method of programming, the programmer CONTROLED all the choices. Basically, you started a program, and it asked for information. This was basically because older programs worked in a batch processing mode. EVENTS - These were actions caused and run by a user or a program. OBJECTS - These are actually graphical representations of choices on the screen - such as a clickable button. MESSAGES - EVENTS - dialogue boxes, changes of the screen, et cetera. Programmer says "This event could have occurred" - i better figure out just exactly what needs to be done. The meaning of "print" might have more than one meaning here. Interestingly enough, just in word processors, if you press print - some big screen comes up and asks if you want to print (a printing dialogue). In MS word, it prints everything. However, if you go to the file menu and select print, it'll ask you what you want to print. In this "world" - the only things that are important are the events. You design and develop "objects" - but they are generic. You need to assign what needs to happen when you press it. There are a TON of events which are options to you - mouseup and mousedown, for example. Visual basic uses "delegation" - in each instance, there is a method in there that says do this when a button is clicked. There is a connection between that blank method and a delegated sub-routine in that code. There's a linkage from that object to another routine you choose to execute. What happens if a user clicks on something once? twice? If the object is clicked more than once, what happens to the second click? it's up to the designer. Most of the time, event queueing takes place. The system can act on the first event and queue the others. OR...you can act on the first one and throw the others away. In some instances - you want the 2nd click. In others, you don't. If you're loading a webpage, the program has to constantly check to see if any of the other buttons have been clicked (loading code...did he click stop?) An IBM computer in 1982 - the computer ran at 4.77 mhz. :) The user, and his perception of what is going on, is very powerful. What you do for deciding issues - such as event queuing - has to be driven by the perceptions of the user. WINDOWS ITSELF =============== (1960's) Who invinted windows? Xerox. Windows was actually invited by "douglas indovark?" - working for stanford univ, and he went down the street to xerox and perfected his ideas. The first mouse was carved out of 2 x 4's :) It was refined at the PARC - a research center. During this time - they invented Windows, Ethernet, Mouse, Object Oriented Programming, and Programming with Graphical User Interfaces. The Xerox Star was the first to implement all these things. Xerox management looked at all these ideas and said "these things don't help put ink on paper - these suck." In the 1970's, Xerox made a fatal mistake. They invited a computer entrepanuer to Xerox. Steve Jobs was invited. He saw all of this stuff, and said, "wow, you guys have this figured out!". He went back to Apple, his little company, and was trying to build a computer. He picked up the phone and called Xerox back and said why don't I come up there with a lot of engineers. A lady whom he talked to said No. Jobs called the chairman of the board of Xerox - and asked for a tour. The Chairman of the Board had to write a letter for the lady to let them into Xerox. This Atkinson person went to "APPLE" and saw "Windows." He saw a windows metaphor - a desktop - with objects. There's a trashcan. There's a folder. If you opened up any application program, it would put a window (like a sheet of paper) throughso which you could look. If it was too big, the window might scroll. Unfortunately, Xerox could never figure out how to have two screens that overlapped with one another. This is where TILE came from. However, they did come up with screen that were one on top of another. Atkinson said "If Xerox can do it, I'm smart enough to do it." Xerox actually COULDN'T do it - they were lying ;-) Xerox knew how to put windows side by side...but Atkinson figured out how to put windows on TOP of one another. It was actually Atkinson who figured out how to make windows work how it's supposed to work. After all this worked - the lisa was initially produced. Then the macintosh was produced. After this worked - Steve Jobs gave Atkinson a plain brown 8 1/2 / 11 envolope and no one knew what was in it. It's just well known that anyone who ever got this envolope never really had to work again. :) The interesting thing about the Windows Metaphor is that this gives us the ability to build virtual 'devices' - which allows us to build anything on this screen and give it any functionality and make it do anything we want because it resides on this windows screen. In the windows world, if you have a "big ol' a" - that "A" is a virtual "A". It's only a picture - a representation - of an "A". If you want that "A" to be times, or ariel, shape size , color - you just change it, and the system will take care of it. BITMAPS and VECTORS - when you put something on the screen, its mostly dots (a bitmap). It's an array ; a data structure of those dots. Some things on the screen of the windows world are bitmapped. We want to be able to put them up REAL quick. The other types of graphics, like the boxes we view in, those are described by mathmatical formulas. These, of course, are vectors. 1/19/2000 ========= typical application screen: ==========================| O _#X| | | control...title bar...disappear, maximize, exit custom and consistant rules for operation... most controls work the same way from applications to applications. you have the screen "real estate" in the middle. :) people use it up by putting what needs to be on it - on it. in using your real estate, finding a way to plan your real estate, you must effectively plan. when you click on file, there are two types of menus you need to be made aware of - implicit menus and explicit menus. implicit menus pop up and are made available by activation however, the explicit menu - such as file - you must select something to make it go away. menus are arranged in a hiarchical manner typically. [buttons and sliders] the whole set of controls that are out there that are user manipulated, such as buttons and sliders, they are intended to be manipulated and used by the user. in this event driven world, nothing is going to happen unless an event - from the user (or, less so, the system) happens to cause the event to occur. [text fields] include labels, text, list boxes, and combo boxes. these devices usually know how many items are in the list or which item is selected, there are all sorts of actions that are related to objects. [dialogue boxes] there are several ways to deal with the program and the user - these are primarily informational messages to the user. there are several types of messages: MODAL - the user must respond to a dialogue before proceeding to any other part of the program. MODALESS - the information only box that basically will let you click anywhere else on the screen and the box will go away. This is basically an informational box only. [query boxes] dialogue boxes to confirm information, et cetera... [cursors] a graphical representation of a pointing device -- typically only around the hot spot. It depends on how big the hot spot is. The cursors in the system are part of windows - it's not necessary part of the cursor. there are several types of cursors, the text one , the click on the hand one, and the regular mouse. there is also an hourglass (or an wristwatch on the mac) as you may or may not be aware, as windows has gone through versions, there is much better capability. cursors can now be animated and can also be color. all of a sudden, cursors become a tool available to the user. say you want to maybe click on something. if you moved into a certain area near a clickable item, the arrow could be green. the more you filled the options up, the better the choices, it would be even greener THE FOCUS ========= Becuase there is more than one object on the screen, only one object should be able to accept the input from what is going on. for example if you had a box with ten items on the screen, the object with the focus would be where you are able to type. generally, not only does it have the text insertion point there, but it might also be highlighted or darker than other places there. Those objects also respond to the TAB ORDER which is something else windows maintains. you might even consider hitting the enter key and remapping it to be a tab key. it would then move to the next field. Occasionally, you can build single window controls - where everything else that is in your application programs appear inside an actual window. that window is basically a viewport to the rest of the world. Traditionally you might have multi-window controls. Geez, if you add a second of third window, you basically create tiled windows - which makes everything else smaller and smaller. In the microsoft world, you get one window that 'lays over' the other. traditionally, in that environment, the window that has a focus has a problem - in some systems, the title bar becomes bright or dimmed, depending on which one has the focus. three systems: ============== tiling overlapped and iconification (like closing - in win31) HCI BASICS ========== (put definition here) This field was developed in the 80's. We didn't have any real graphical user interfaces, though, until the advent of the interactive systems, which have allowed us to build newer systems. Terms which we may have heard about interfacing with computers might be: User Interface - allows you to interface with your computer. since the 60's or so, we've had user interfaces with computers. However, it didn't necessarily have to be so clear. :) Started as early as the computer key-punch machine. User Friendly - everything might should be user friendly. Are you computer literate because you can actually use the computer? This really isn't really discussed anymore becuase we don't know what it means. Consider two topics: there are two concepts that come from peopel who have studied these things: AFFORDANCE ========== if a user interface functions, the components in the user interface must be visible, and they must have affordance. VISIBILILTY =========== the user can not use what he can not see or does not know it's there -- if you tried to use MS-WORD and find something new...it's becuase you've never seen stuff before. everyone know what it's supposed to do. 1/24/2000 ========= What are the goals of Human Computer Interface? To provide a useable, safe, and functional system ================================================== Computer software need to function correctly. Financial institutions and people's lives - depend on it. There is a well documented case where an xray program killed two people - just random exposure. Test Usability =============== Find out what they're supposed to do, test them, and then use them. If they are useable and acocmpolish what you wanted them to accomplish, they might be useable. If we build systems like this and these systems have lots of functions, people can test them and see how they work. A fella looked at a banking system and counted 36 ways to get customer's account balances. 75% of all access to account information used only four methods in this study. In the 1980's - they discovered the USERS were important! :) If they had asked "what would you be doing it and how would you be doing it", they could have had more efficient programming. We will be moving into user-centered design. the best way to figure out how to make something useable - ask the people who will be using it. Most of the problems the office was having - were user difficulties. If you are not allowed user-centered design - __DO NOT TAKE THE JOB__ 40% of all software installed FAILED. 40% of other systems provided some marginal improvement over older systems. 20% of the systems installed were actual successes. Part of this failure rate is because the people who bring the systems in can not assertain the problem well enough to solve the problem. A large part of sales come in from "a friend down the street has one, I want one too!" Objectives ========== the objective of an organization using technology was to use a technical system as a controlling mechanism. Another objective is to use it as a tool. If you do this and you have a job, the things people do - tech systems control the people who do the work, the changes people might expect are: the work becomes de-skilled. (no need to hire smart people) the work might become enriched (tools help!) These technical systems can very in what they are supposed to do: They can become very structured! You better enter item a before you enter item b...sometimes it won't even let you enter b before a... the organization chooses technical systems of these types because they can predict some benefit. There are some different sides to this view: control tool ======= ==== increased productivity similar production increased quality initiative inflexible (i'm too busy doing my job, bring inflexible, et cetera..) so... work can be: (job changes) deskilled enriched paced unpaces structured unstructured repititive non-repititive isolated (human response) dis-satisfaction satisfaction 1/26/2000 ========= What are other HCI factors? =========================== What are environmental factors of working with computers? such as do you have a small keyboard? do you have a comfortable chair? Health and Safety? - what about eye strain or carpel-tunnel syndrome? Are you organizaed? - there are organizational items which reflect on our systems. are you properly trained? are you properly staffed? What about the user's factors? Does he enjoy using a system? Does he feel gratified? Motivation is partially influenced by a paycheck. However , it doesn't end there. Usually people would like to show confidence in an employee, and employers would like to know that you are satisfied with work done. User Interface Factor - how easy is the program to use? what about colors? Constraint Factors? - Time scaled , budgets, staffing, what are your constraint factor? System Functionality - How well does the computer run? Will it accomplish what you need for it too? Most of the time, you can't print envolopes. You have productivity factors - they increase quality, the amount of time, errors, giving us extra productivity. That's one of the list that makes it the most important issue. What other disciplines make up HCI? =================================== Computer Science - we study algorithmic processes which are sets of instructions which are developed to solve problems which TRANSFORM DATA. Cognitive Psychology - We look to this as a decispline which might be able to explain how your brain works. You'd have to find a way to test theories as to how the brain works without killing the subject. That's partially what makes artificial intelligence so hard. Social or Organizational Psychology - This studies how others act or participate in groups. Human Factors / Ergonomics - If you're designing a chair or keyboard...how does the chair feel? Et Cetera? Linguistics - despite whatever we try to do, don't make it too hard. We might need to eliminate certain keys..certain keystrokes. Artificial Intelligence - Assuming a zip code can find a city and state before you have to type it in. Learning as it goes.. Engineering & Design - for a long time, it had a methodology insuring projects could be setup, designed, and implemented successfully. Let people really try to damage whatever it is you're building. Find a way to try to insure success. Try to figure out the best way to do engineering -- but we took too long to do it. :-( Maybe use something that is useful and creative. 1/31/2000 ========= Coding practices: name date modified changes (for each line / segment) symantic errors are pointed to by the comments of your program. We had talked about those disciplines the other day. today we're going to focus on the cognitive psychology aspect: Focus on the human and how the human does everything. We are interested in: How do we store knowledge? (learning...receiving these facts from the outside world) - how do we get information into the brain? How do we figure out how to process information and get it back into our heads for use later on? Multistore model - the human information processing system ============================================================ this is only a theory - a set of rules that have been experimented and proven more than one. if it's an absolute fact, indisputable, it becomes a law. actin-shiften model - said information comes to you from the environment: stimulus -->> (in environment) -->> |================ --->> |==============| |sensory input | |sensory memory| | system | | | |===============| |==============| |---<<--(recalling)-<<--| -->> |================| |==================| | short term | | long term | | memory | | memory | |================| |================== |--->>--(learning)->>--| - - - - a t t e n t i o n / - (e x e c u t i v e c o n t r o l ) - - - - - - - this brings selective attention - the same way you can tune out an air conditioner "Miller" - in 1956 - proposed that our short term memory had a capacity. Through all of his tests - were 7 things...plus or minus 2 things (or chunks of information). Seven was the ideal number. duration was actually 30 millaseconds - once you put something in , it was gone in short order. example - the psa commercial - about marajuana...how many ppl are affected by marajuana. Other mechanisms force memories into the system - such as being scared, or constantly remembering something - refreshing those brain connections. 2/2/2000 ======== Breating and cognative processes are not controlled within your brain. Selective Attention: ==================== As an interface designer, you have to constantly move the persons attention from element to element. 1. - Something else focusing attention on us is the meaning to the individual: If you're given a task to do, generally, you pay much more attention if it has some kind of meaning to you. For example - your ears pick something up from across the room. [your info receptors were receiving that] 2. - we can control our simularities by the differences coming in to us through simulus. For example, we can read a book and listen to the radio at the same time. 3. - complexity is controlled by the things we are doing - for example, we can not carry on more than one task reliably at the same time. It's either complex or difficult. You can't reliably tell your brain to really do more than one thing. If you used memomics (a song or sentence containing information...the first letters or something) - you might be able to recall _10_ things. PERCEPTION =========== When you feel or intreprit information using your sensory systems. The monitor is hot, the air is cold...especially visual perception. GESTACT - focuses on psychology. you see things, and what you percieve is the information -- which is greater than the sum of what you look at. Different intrepritations lead to different contexts. How do you intreprit characters on a screen or the difference between an "H" and an "A" - written close together? What about this? OOO OOO OOO it's 3 groups of 3...instead of 9 circles. CLOSURE ======= When your brain finishes up the drawing for you. (for example - you have 99% of a circle, missing one or two pixel) this is a neat feature for interface designers - because we only have to get close - but we don't have to be perfect. Continuity - larger items in 'front of' smaller items - the arrangements of dots eventually give you the ability to reconize a letter. Above 700 dots per inch - the brain can't dissertain that there are 700 dots making up a character. Most of these example patterns are in the book - on page 79-80 PERCEPTIONS ============ Perceptions come in from all over the place. We get information about patterns, textures, and colors - in addition to everything else. We basically get 3-d information - the fact that one is bigger than the other. Spercifically, we get information from: Textures Shape Why are these things important? Becuase we're humans, we understand these things, and we're using all of our senses in involing the user in our interfaces. therefore, when we start using them, we need to understand how people use these things ourselves. We have to study people to be good interface designers. 2/7/2000 ======== Suggestions - Think about what it means to get a schedule and pick out the classes and enroll in the kids of actvities you do. What can be done to make the process easier for the user? (add searches for each item) What can i add to the process that is not there now that would make it even better? [add value...Value-Added!] Why haven't we handled pre-requestites? If you click on something and you don't have the pre-req, notify the user. Draw raw prototypes on paper and come up with design on paper. What would be an expected function for this system? name student id select classes delete a class finalize - tell how much money you owe - id check, cash, or money order financial aide, scholarship hard wire items - fill them up. THEN - test if the user can find that class (search?) then, select a class put it on their schedule, do whatever has to be done. finalize logon to usa register for cis100 register for cis200 register for cis300 put 20 courses on the interface test for course they don't have prereq for - pull up dialogue box. they'd have to delete or pull up another course. go with the PROCESS..........not the PRODUCT specifications come up with idea build a prototype build a test plan run the test ask review questions when you run it, you'll have a test of data. turn this data back in. questionnaires, et cetera. think big initially....get the money....get the people enrolled in the school. overdue parking tickets? outstanding library books? IDEA ==== Suppose you had two classes - one at 10 am and one at 11 am. One is in the business bldg and one at the humanities bldg? Notify user this is a 10 minute walk, and you can't get there in 10 mins. QUIZ NEXT WEDNESDAY ==================== 2/9/2000 ======== Perception concepts - proximety, perception, closure. How do humans deal with things and percieve things? Humans do a pretty good job of reconizing patterns they have seen before. One of the things the humans store are shapes and templates that allow us to reconize other things. We use this technique to attempt to reconize shapes and sizes. We call these kinds of things mental knowledge: =============================================== || 1) Declarative - [facts, et cetera] || 2) Proceedural - [how do you accomplish something?] || 3) metaknowledge - [knowledge about knowledge] (allows you to filter out useless knowledge) || 4) impressionistic [creative problem solving] (resolving probems? :) ) \/ more difficult, and more expensive Organizational Methods ====================== Somehow, the information in your head is organized. Otherwise, you literally would not be able to retrieve the information. One type of organizational method would be a SEMANTIC NETWORK - connected by attributes which might connect something to something else. For example, a little bird is a chickadee. There are always knowledges - but also exceptions to the rule. There is another way to organize information: frames: ---------------- ---------------- types of information go in every little 'folder'.... ---------------- Some types of 'houses' might have more information that other 'houses' - you might drive by. If you go to a resturant, many concepts should come directly to your mind - you be seated, you order a drink, look at a menu, eat the food. Mental Models: =============== A particular, individuals view of an object. It is based upon their interaction with that particular object. Each one of us has similar models on individual objects, but they are different based on their interactions. Over time, for every object that you interact with, you build up an actual mental model. Since everyone has a different set of mental actions, everyone's perceptions are different. 2/14/2000 ========= ON TEST ======= What is usability? What is ? Why is gestalt phychology important to interface design? Usibility on the web - an article from USA TODAY was printed out. More on Mental Models: Mental Models: We have more mental models as we interact with objects. As we see or deal with various objects, everyone's mental models are different. It's only what it is perceived to be. [A traffic light was used on an example] There are two types of mental models: Structural Models : They describe the internal workings of an artifact. In some sense, they describe the inner workings. Functional Model: An electronic calculator - something you understand just its interface, but have no idea how the inner workings are. Our job is to facilitate the user to use these tasks which might be related to those models somehow. We would use a mental model to suggest or control the users into doing this. basically - you'd have to do a before b , et cetera. Humans build METAPHORS which allow us to actually tap into knowledge that humans use. We use the concept of money to relate to time. Time is money - we relate them to explain them. Metaphors come in several flavors: when we figure out or decide on some type of task, then we would look and see what it is that the user would be expected to understand - try to understand their mental model, apply it, and then suggest that analogy by using that metaphor. Visual - file folders on the computer, recycle bin, the desktop Verbal - Suggest things into words - when we describe to users what they need to do. Sometimes we call a computer he, she, or it... Virtual - We have to figure out for ourselves how to convey the information. basically, if you use this, you're going to have to convince someone else, or teach someone else, to understand that something happens when something is pressed, thus linking a metaphor. That lightning bolt from TP4.5 eventually became compile. So....what is an interface designer to do? he look for some kind of understanding for what the user already knows. He should build a metaphor that would appeal somehow, and that is his job. however, if you think abotu it, you have to be really careful. The mental models are the problem. Example: [post mail outgoing box] Make sure your mental model matches the one you'd consider it to be. Wedding dresses here are white ; wedding dresses in Asia are red. This is definately an international interface issue. Basically , we CAN NOT use our mental models by default. Everyone may not understand the world the way we understand the world. When we use mental models, the meaning of a word should be clear. We should also be consistant. Each time we use it, we should use it in the same way. Figure out what the user knows, and then figure out how to cater to them. 2/21/2000 ========= TONIGHT - Metaphors - Conceptual Models - Projects Project ======= We should be working onwards towards the interface. Owen is interested in the process. He is not interested in the product. You must build a prototype that can be tested. You can have it look up a list of classes, say, for computer science, which might 'connect' to a database. Therefore, hard code 10 items in the list : ) Then, you build a test that tests what is in the actual prototype. You don't interface with a database. Prototype that can be tested Build it anyway you want - preferably the simplest way. Once it's working - ask users if it's right or wrong (use survey) Develop a Test Plan (based upon how the prototype works) Example: if you had a list of six classes for you to register on. You develop questions like: 1) I am interested in how efficient or how effective a student can find a particular class. Develop a scanario - that will allow them to understand what it is you want them to do but allow them the opportunity to test your interface. you are student jane joe, you are a computer science major, your serial number is 116814 your pin is 914 . please logon to you system and register for computer science 105. if it happens to be one that doesn't have a prerequeistite, it should notify them one. you have have them check for several scanarios for functionality. Evaluation of the existing interface ==================================== Typically, if you were building an interface to replace an existing product, you would go analyze the existing product. find a piece of software that you can analyse and you understnad how it works - and you answerthe questions outlined in the existing interface. then you explain the functionality of it, explain or locate examples of where the designer got the interface correct, or rather they got it incorrect, or rather things might possibly be left out. you are going to describe a piece of software. if you make some choices in software - you can not answer some of those questions. pick something that is not "wordperfect 8". ;-) (possibly do this to the senior project metaphor) Metaphors / Models ================== Conceptual Model - the model that a user holds in their knowledge base. It explains how some artifact or object behaves. If you are given a diagram of something - for example: O - understanding of 'some thing' - some process or task. (user's conceptual model) say...that task might be to write a term paper. (might have to gte a computer, some english, some language...et cetera). * - might be a diagram of the implementation model. the reason it may be bumpy is because there could be several details to make things different. (implementation model) conceptually - you designate something and discard it. implementation view =================== get the filename get a command to get that filename in the file directory determine the extent of it - how many bytes? issue a command to have it deleted (remove filename, record, et cetera_ manifest models - what i can build that the user can understand? might look something like this: might have some bumps, but was mostly round. % (windows 3.1 - delete a file? are you sure?) if it were better - you could see the files and click on them (like norton commander) we would like for the user to be as CLOSE to their conceptual model as possible. @ - almost there. how could you delete a file without really deleting a file. It's hard to make things work the way users expect them to do. (which is why we don't actually react this way) We should always strive towards the conceptual model since that is what the users automatically do. Finalize or Put this on hold. Instead of that, pick something like create schedule or something. :) LEARNING ======== How do you learn? Why is it important to understand learning as an interface designer? What is learning? Well, it's putting things in long term memory for starters. Ther will be some point of someone seeing your interface for the first time. If they could understand it when they first see it, the process would be very short. The more efficient and productive the interface, the person will learn it quicker. How do you learn stuff? 1) Learning is an ACTIVE PROCESS. If you don't do something, you ain't gonna learn. For example, you must actually DO SOMETHING in order to learn. tutorials can assist. 2) Users fall in the range of novice to expert - and for a user interface to be considered successful, it has to satisfy that broad range. That's pretty tough. 1/28/2000 ========= Comments and suggestions behind what we turned in towards the project: 1) Course ID number is a dumb thing to do. FIND A BETTER WAY! Completely build a newer way to do it. Perhaps select a class and have available times pop up. Try to improve functionality of what we have now. Perhaps: Step 1 : Enter your Student Number - Step 2 : Show remaining courses left (in current major). Select check boxes for which courses you want them to take and if you check courses, have a section come up with how many courses are available and then select which ones you wish to use. (dates, times) show me the catalogue description...future information about when it might be offered again? check to make sure you don't have two classes together. Step 3: Continue... Step 4: Financial Aide, Scholarship, Check, Money Order, Credit Card when you're logging in, pick up the tentative schedule if there is one and continue from there. States - only certain places can you get after coming from other places. This is a stately system - you should only have options at certain times. Example - no finalize available until you're ready. Documents in preliminary design: if it's not clear what is happening, write down what is happening Organizations ============= Nature of Organizations: Factors: 1) People in the organization - most organization you would admit have people in them that have each different roles, skills, and abilities. they have different roles - they have different skills - they have different motivations - these people cause us more trouble as interface designers than anyone else. think about a large organization and the peopel involved from the president down to the janitor. they have different motivations, responsibilites, and skills. take the president and give him the janitor's job during one day (or vice versa) and see what gets done. they are all people oriented. 2) Technology that people adopt. Organizations use technology -some set that they deem approphriate to the problems they encouter or try to solve on a daily basis. as they bring technology into an organization, organizations display a reliance on technology and a reluntence on changing to new technologies when new technologies appear. if you think about the technology out there, the policemen use guns, not computers, to catch crooks. now, of course, they use both. 3) Work Organizations - In the organizaiton, there is usually a division of the kind of work or how it is structured. Currently, organizations tend to divide themselves up by the functions or tasks of how they do. Even here - in CIS - we are divided into teachers, office help, and students - into different tasks. Interestingly enough, because of the cultural makeup of organizations, usually in larger organizations, the functions get so structured, they don't tlak to each other, and they don't have communication. City Government is supposed to provide us with services that we may need. Garbage men haul garbage, Water dept brings water, et cetera... None of those people talk to each other. In fact, they don't necessarily like each other. Large companies like Crystler realized how large they had gotten and took steps to solve this problem. 4) Culture - an organization generally develops a culture - which usually has a set of rules. These could be written or unwritten, and maintained by the organization using peer pressure. If you bug the culture, you are in trouble with the organization. IBM had blue ties on down from the president - and they moved own down. Everyone is in blue suits and a plain tie. It's unwritten, thou. Disney and no facial hair or no picking up trash...et cetera... that is the culture. Next Time: Make an organization change, adopting new technology. If you build a new interface, changing the technology, you'll have to convince them to change it - otherwise, it will FAIL. 3/2/2000 ======== Methods for managing organizations. An example would be the scientific methods - which started in the earlier parts of this century. They revolved around the work of a fellow named Taylor? Said organizations should be approached with some kind of rules? Can we get a handle on how to manage organizations? Decided to use planning and production ====================================== 1. You must use seperate planning and production. For everything you have to build - you have to stop and design. This makes for designers, planners, and production people. 2. Study tasks - to determine the best way to do a task. 3. Find the best person to do the job. Figure out who the best person to do the job would be. [Frederick Taylor - 1911] 4. Monitor Performance - to look at how many things someone does and check achievements. train people ; 5. Train the worker to do the job. Workers to actually do the job. All of these things were designed to perform the workers. This method makes people kind of a clog in the machine. We could interchange them or replace them or whatever. It was a very strong movement by management with strong movement BY management. There are other models out there that can be see and used: Socio / Technical Model (or the sweedish model) A model which attempts to empower the worker and try to make him feel responsible for his work. "Lets make the worker responsible for their work". Lets give some power to the worker so they can decide HOW to do their work. If you did work using the scientific method - you'd do this 10,000 times a day (putting in a right front hinge #1 ) New method - in a group - you put the doors on the way you want to as long as you put the doors on in a certain method. You might actually find a better way to "put the doors on" then the way the planners did. give them power to make decisions and let the people of the group decide how they want to do something. The management probably lies somewhere between the two. How do you make organizations change? ===================================== Difussion of Innovation - This area of looking at organizations was studied by a guy named Rodgers in Illinois. He was interested in understanding how he could get a group to adopt a new idea. He started to study how people adopted new ideas and started to study groups of people. He thought that adoption is a process: 1. Awareness - MP3 Players for example - You look at that technology and become aware of it. 2. Interest - People are aware of personal digital assistants. You have done some research and are in the mood to find information about it. You simply want to know more about it. 3. Evaluation - You begin to make judgements about the various competing technologies. How much are you willing to spend to play this kind of music. 4. Trial State - You aquire one and you use the innovation to determine if the benefits you thought about were actually true. At the completion, you will know if you adopt or not. 5. Adoption - If you adopt somthing here , you would convert all your music to MP3, than possibly chunk all of your old music. This could be fairly expensive, too (throwing away 10,000 typewriters? - replacing by computers..) More on: 3/13/2000 ========= Diffussion: There are various stages of the process. (Adoption, Awareness, et cetera) Awareness Stage Interest Stage Evaluation stage Trial Stage Adoption Discontinuance - you may choose at any time to stop using the innovation. It could have several reasons for this - for example, you might adopt something and discontinue using it because it was not fitting your needs. Rodgers actually studied this and discovered adoptors could fit into different categories: | | ---- | / | \ | / 3|4 \ |----/1|2 5|6\------------------------ ====================================================================== T - time for adoption this is two deviations away from the mean. Category #1: Innovators : Represents 2 1/2 percent ================================================== Innovaters are interesting groups of people - they make the decision to adopt or not to adopt. They are risk takers, they adopt easily, they "risk occasional failure" (or give up because they might have adopted an idea that is really bad)...they're on the bleeding edge of technology. These people are willing to risk an occasional failure - which usually means there is some loss of money from trying it. Category #2: Early Adoptors: Represents 13 1/2 percent of the population: ========================================================= They are early adoptors: They are more careful in their analysis, usually respected and sometimes considered leaders. They were telling you all of this because they likely just adopted something new. They are influential because they have not gone through the trial process in haste - they were more patient and analytical, and exert somet influence on an adopting group. Category #3: Represents about 34% - the early majority ====================================================== They look at the experiences of groups 1 and 2. They say the innovators have tried it and the early adoptors have tried it - i better get on board. They're more deliberate, and are probably not as analyitical about things because they watch someone in group 2 or 1. Category #4: The late majority - about 34% as well =================================================== They try to get on board before the train leaves town - they are skeptical, but after the majority of their peers do it, they jump on board. Windows was a good example of this....after the majority goes, (60-70%), you're almost forced to adopt. These people are skeptical, but they do adopt. Category #5: Laggards - about 16% ================================== They are the last to adopt, usually only when forced to adopt. The car is a good example...Henry Ford builds the car...car gets run off the road by horses. "I don't want no damn snortin' machine, I like my horse". All of a sudden, all the roads are paved...you can't do this, you can't do that...so you MUST get a car. Category #6 - do not ADOPT under any circumstances ================================================== There are a few people who _WILL NOT ADOPT__ under any circumstances. Why stop using a type writter? (Can you still get a fabric cloth ribbon for a type writter?). Ted Kezensky is so against technology he did not want to adopt anything. The omish might be another example of this. 3/15/2000 ========= The user development model ========================== The software development team - includes: Project Manager - Function is to oversee the project in such a way that it becomes completed. He may interface with the customer, resource management, task allocation, et cetera. Programmer - All of the progammer tasks such as systems analysis, systems analyst, might be in charge of understanding the problem, formulating the design, & implementing the design Sponsor / Client - Provides the initial requirements and the money. (may not provide enough money, but he causes the project to come into being) Hardware Specialist - They look at the target system the software is being developed for. The other system is the development system. in some instances the hardware specialist might be responsible for keeping the infrastructure of the organization running. also, they identify the characteristics of the target system you're developing for. Remember more than one job might be held by one person. Interface Designer - Looks at the tasks and functions that have to be provided by this project and understand and design the interface (which is the connection between that kind of functionality and the things the user is going to do). Will develop interfaces and probably perform some usability testing not to mention taking into account the usability of the user. Software Tester - Makes sure the software performs the functions it was designed to do. Tests the software against it's requirement specifications. User - They use the system that is being developed. Should help with the design of the interface and continue to test it. Project Financial Officer - Pays the bills and might help the project manager to budget things. System Writer - Person who writes all of the documentation for systems. [this is the user documentation / manuals , et cetera] Janitor - If someone does not haul off the trash, the rubbish adds up and builds up until the entire process comes to a halt. Neighborhood Bartender - He's the guy you go complain to when you want to kill one of the other nine people on your team. If you're married, don't vent to the spouse. Who is the most important person on this list? - the user. The user is more likely to see what is actually needed and if it's actually getting accomplished. Principals of User - Centered Design - we have design models, and the most common design model looks like this: = = = = = this would be the waterfall model... Problem Statement Requirements Specification | Systems / Analysis Design | | | Implementation | | | | Testing | | | | | Product ^ ^ ^ ^ ^ ^ There is one thing missing mainly from this waterfall ; there is a path across the bottom with the function of being a feedback loop. Why would we have a need for a feedback loop? Because you can make errors at any of these locations. there has to be a correction method as we go here. The user is missing in here - it's more or less only a one pass operation. There are other models that affect creation : The spiral model: | analysis / |- each area improves the design / | \ (goals / |\ \ ..more) / / | \ \ risks ----------------------\------------- \ | / \ \ | / testing \ |/ / software design \| | / - This is the older model - there's no place for the user in there. If you do not understand everything at the beginning, you might get so off track, you have to abandon something. your initial evaluation of the problem might have been so bad, they just completely started over. Missing from the spiral model also - is the user. it's not really a built system until you've spiraled around the model each time. It's always really a prototype until you've been around several times. User centered design has to produce systems that are : ======================================================= 1) easy to learn to use - why is that important? - for every new system that is developed, it's handed to a user and that user is a novice when they first turn it on. if it is easy to learn, the amount of time it takes to move from novice to expert will be at minimum. 2) easy to use. this has not always been the case in our software design efforts. 3) safe to use - we build systems that do not let us screw up. Suppose we had a task that one of the job functions said "Enter zip code" - you might verify which areas could support which areas - and verify the data is valid. 4) effective to use - as you build the software it should make the user more productive than they were before they used that software system. Suppose someone was writing scaning software at __DALECHAMPS__ - you would require the barcodes be upright and perfectly parallel with the checkout. Item #4 is the item most people key in on when looking at designing systems. 3/20/2000 ========= Worst case scanario - if you're learning how to write a paper _AND_ how to use a new software tool, you're going to have a very difficult learning curve. At one point in time, you were looking through the menus looking exactly for something, but you had to find the correct menu to find it. User-Centered Approaches: Over time, as we started to develop systems for people, we learned the user plays an important part. If you got reqirements and specifications in some sense, you would assume the user was involved in there somewhere. If we design a new system, there are some steps we should do in order to create a good system. [he was trying to build an air-traffic control system] 1) Evaluate the controller's tasks. Look at the controller and see what he does. 2) If we're going to build a system, we should develop a first cut design (a prototype) of what might take place. 3) Establish a user system design group. If the people do not make accurate controbutions to your focus group - your project might fail. 4) Concept testing and user feedback. Do the end users like it ? Do they not like it? 5) Produce an updated prototype - based on the user comments which came back in. 6) Road Show - took their updated prototype to as many airtraffic control units in England and took more comments on the program. 7) Develop the system specifications [software design lifecycle] [you want to do the best you can to create the right project the first time when dealing with airtraffic control] 8) Development, Testing, and Implementation of the program 9) Gather Feedback They were able to develop a system that worked, the people were happy with when they got it - it did what they thought it would do and it actually worked. There are several models of user-centered design mentioned in the book: Eason Model: ============ Plan for Systems /> \ (task analysis) (gather stretegic information) Manage Design ^ (Job Design) \ / (usability study) & < (tech support) Implement Four states in development and design: We would plan for systems and decide what it is you want to do. If you think about looking at the waterfall model - the processes look independent of each other. It also looks more like a one-shot kind of deal. This is more interesting - and this (and the spiral model) were developed along the same time. Star Model: =========== <---- ->IMPLEMENTATION TASK / FUNCTION ^--| EVALUATION | | ------------| - --> |EVALUATION | --->> REQUIREMENT / -----^------- SPECIFICATIONS PROTOTYPING < / | ^ | | | | ^ \/ | ---> CONCEPTUAL DESIGN | / | / Basically , everything revolves around the evaluation of a program. This model allows for this continuous refinement concept. There are some obvious places where you could start... 3/22/2000 ========= Figure out more about user-cenetered design Cooperative Design Models - Requires cooperation between the designers and the users - It's entirely possible for you not to have that cooperation. There are two primary cooperative design methods: 1) Participative Design - we develop systems by getting people we need in the process to be involved in the design process in all stages. [maybe you should get the users involved by actually placing them on your DESIGN TEAM - during the needs analysis?] ** ONE OF THE BIGGEST PROBLEMS WITH USING SYSTEMS IS GETTING THE USERS TO USE THE SYSTEM CORRECTLY** 2) Socio-Technical Design Philosophy - Technology and sociatial parts of the system can not be seperated from one another - so you must seperate these components. [use this type of technology to make this type of system more productive..impact users in the organization and they impact your design methods] - ask "is this going to make your life better?" ; "how might this impact you?" Example - registrar's office - you key data in instead of manually processing something. What's improved? anything? In this instance you can not seperate the technology from the organization. Requirements Gathering from the user ==================================== 1. Requirements gathering - you go out and talk to someone else OR Analysis - you sit down and brainstorm this material out yourself. There are three areas of concern to gather these requirements: 2. Functional requirements - You must figure out what the user has to do and what the SYSTEM has to do. The documents you'll produce here formalize the requirements around the functionality of the program. [get the entry, depoisit in the right account, extera] Also includes data flow diagrams, entity relationship documents, et cetera Captures some type of formal mechanisms for representing this data. (Structured Walkthrough - design team gets together in a formal method and says "this module does this" - might enumerate from diagrams and charts the functional methods needed to produce that type of functionality) Task Function - This is what the user does in general. We figure out what the user does and how they do it. [Example, you might require some person to enter some certain set of data ; as far as the technology is concerned, any order you enter the data is ok. 3. Data Requirements - This allows us to focus on the data / the relationships of the data to the project, and the actual data flow documents, et cetera. 4. Userability Requirements - there are several componets of usability that are out there that should be evaluated and understood - (a)Learnability - (b)Throughput - [how many errors are made?] (c)Flexibility - we would be interested in gathering requirements of a system to accomodate changes to accomplish tasks for which a program was designed. [if you're building a tellar scanning system for dalechamps, and you want the user to be able to do something, and there had to be a certain amount of light in order to do something...what if the power went out? are the buttons large enough to see the light, et cetera?] (d)Attitude - Do the users have a positive attitude towards the system? Does the system help the users to solve their problems? Most of the time, a usability test is required to gather this data. Gather requirements at beginning of process - pose questions in the beginning, but gather the results at the end. What do you have to do? ======================= In your test plan, you have to decsribe the people you have to ask to test your system, describe where you're going to get the people to test from DESCRIBE THOSE PEOPLE ===================== [not the population, but colleges who are in the class and two people who are not in the class] they have to be students and they have to be complete with the complete registration process at south alabama. would freshmen be able to use this system? - if it were friendly enough and they had good enough directions? TEST USABILITY ============== There are certain issues you should have in your mind that if you place objects on the screen and figure out if they really understand what this means or how to do that. Deisng a test to collect this data. Example: System should not allow a user to register for the same class two times. you want to know if a user tried to register for the same class twice - if that person understood the reporting of the problem at the time the error was given to them. [what about a time conflict? give the user a task -- register for this class and register for that class. - give them two classes at the same time and see if they conflict...] example: logon to the system your username is blah..blah your pin number is blah..blah.. register for cis 120 and anthropology 604 both of these should be at the same time and generate an error message. you have a mastercard #...whatever....use this on questionnaire - what happened? what did you do next? did you consider the system usable? questions... . . scanario.... . . questions... . . scanario.... . . questions... . . scanario.... . . ...overall result? you can check and see if the error messages are clear? ask "this scanario will allow the user to encounter an error messages. these questions determine if the user understood the error message and continued to the next area acceptably]. can they enter the data and pay for the classes they signed up for? ++++DO NOT DO THIS++++ [test plan] go to screen 1 - type j. doe in logon type 4567 in password. don't do that. 3/27/2000 ========= Task Analysis - think about and develop a system that works with the tasks that the user is hoping will be created. Typically, there are people who model in general for task analysis. Here is the general goal: 1) Identify the goal of the system - for each goal or task that / the state you would want the human to reach by doing something [by balancing the program, for example, enter a transaction - for a bank...] 2) Tasks - internal things that the user performs or believes that are necessary to achieve the goal. 3) Actions - figure out those things that do not require any high level skills. The types of activities reqired to reach the goals state. There are several models for this: GOMS: ===== Goals / Operations / Methods and Selection Rules: These four things allow you to analyze the task / action relationships. Goals: The things the user wants to accomplish Operations: Those things required to reach the goals Methods: The plans to accomplish the goal / the different options Selection Rules: The rules the user will go through to accomplish the goals EXAMPLE ======= Goals: Lets go from the airport to your hotel Methods: Taxi, Walk, Hitch-Hike, Courtesey Van, Limo, Rent a Car, Subway, Bus Operations: Describe spercific activities - [bus - find a bus stop, get money, figure out which bus to take, get on the bus, pay the bus, ] - there are spercific operations to match each method Selections: Walking is cheap but slow. Taking a bus is more complicated if you don't understand the bus system. A taxi is more expensive. Renting a car can get you lost. If you're writing something in word processing, what kind of rules are there: You have to know how to turn on the computer Have to find the application Have to start the application What composes a letter itself? (What is the format?) Layout... Selection Rules: ================ Would it be better for me to use wordpad or word? Goal: Word Processing Open WP Enter Text Edit Print Letter -find it type keys -click on it -voice reconition -OCR -type -import it from file -clipboard... further down they get, the simpler it actually is... There are people who say we should have HOLISTIC DESIGN - all the process takes one basic time - it happens all at one. These folks came up with a list of design principals... 1) For this approach to work, you had to be familiar with a conceptual model of what you want the client to be able to do: 2) Seeing and pointing is easier than remembering and typing. 3) It should be possible to use universal commands [apple first utilized this] Once you figure out where a command should go, use that command everywhere. 4) You should also have consistancy. 5) Simplicity 6) There should be modal-less interaction - operations should flow... 7) WYSIWYG - If you are using a graphical user interface, you should WYSIWYG practically everything. 4/3/2000 ========= Dr. Sciderman's 3 ideas of design principals: __________________1______________________ Plan for diversity - there are several levels of diversity we need to be concerned with: (a)understand the user - users are diverse. they are different because they are people. one of the things you have to think about when you think about users and their diversity is their skill level. Typically users of a system fall into one of several categories: (b) skill levels: NOVICE user - does not understand the task or the interface [or both] [in our homework assignment, users most likely understand the TASK] KNOWLEDGEABLE INTERMIDIANT users - if you think about yourself and some software system you use, you can classify yourself for some packages as this. you understand why it is you want to use this software, you just don't use it enough to understand everything about the software. you forgot where some buttons are, you forgot some task - those things you don't know on a regular basis. POWER USERS - users who completely understand the task and the interface and are generally looking for and desire to have faster operational commands and faster responses. (c) interaction styles - styles are "preferences" that stick to you. there are several identifiable styles built into interfaces that people find enjoyable to use. DIRECT MANIPULATION - we seek to have the user interact directly with the objects of the interface [selecting by pointing and clicking, dragging and dropping] - the user actually manipulates the object and they can move it or select it... MENU SELECTIONS - gives the user something to sort through, look at, or read - usually good at reading, understanding, and forming connections between elements of "lists" - something will happen when they select it. FORM FILLIN - this style is forced on us by some operations built in our systems - that require information to be inputed into systems [usually text or numerical] [some people don't understand age from student number] COMMAND LANGUAGE - a user is interested in the syntax of the language of the system and is able to enter information into the system directly in 'system type language' NATURAL LANGUAGE - this is the one we talk about for the future - we're working on this right now. we'd like our systems to respond to our language and our command structure and not the ones that are within the syntax of the system. (d) cultural diversity - when we think about diversity and building systems that have an appeal over a wide audience, cultural diversity becomes an issue that must be dealt with. It covers all areas - areas we understand easily, other areas we don't really understand [colors, words, et cetera] - and especially actions and activities we might not expect. Some people have biases which also play here. __________2__________ Use good design rules - [the eight golden rules for interface design] 1) strive for consistancy - If you have a sequence of operations where you lead to a certain goal - those operations should remain the same in other places. You should also strive for consistancy in language to the user - the type faces should be the same ; the colors should be the same, et cetera. Strive for consistancy in dialogue. 2) Give power users shortcuts - hotkeys, things running "fast" 3) Provide informative feedback - should provide obvious information that they selected the right choice. They might sort elements and not provide positive feedback - you should give people some type of feedback that the operation is underway and something is coming later. 4) Provide dialogues that lead to closure - (do NOT use any hex number, feature, to notify user whats wrong). Another example might be with a compiler, please close yer semicolan... 5) Provide simple error handleing - correct your glitches before you report them....correct misspelling, et cetera... 6) Provide easy reversal of actions - if you click on something and it's a very complex action, we should be able to completely reverse the action. It can go all the way back. 7) Support an Internal Locus of Control - your conception about what is controlling you. This is an understanding that you are in control of your environment. [internal - you're controlling environment ; external - environment controls you] 8) Use millar's 7 +/- 2 when developing screens and information. When you have to present information to the user for processing and to retrieve, you do not want to overload the local working memory of your user. ___________________3______________________ Prevent Errors! We've been trying to do this for a long time. We've been doing data validation for eons and eons. You should build systems that decrease the number of errors the user can committ as compared to prior systems. To prevent errors, you have to understand different kinds of errors. There are all kinds of simple errors such as "completed sequence" errors, [you do the left paranthesis and not the right], and you have to know when the errors occur? The problem with this is while it's a great design princile, it's very difficult to speed up operations and try to eliminate errors. Perhaps some day, we will build systems that will have a measure of some sort of intelligence and then apply some set of rules. TOPICS WE HAVE COVERED -- FOR TEST COMING UP 4/5/2000 [innovators] laggards, non-adoptors, each area here -- each group of people has to be appealed to. Appeal to the early adoptors first...because the innovators will try ANYTHING USER-CENTERED APPROACHES importance of user centered design roles the user plays software-development models [spirals, waterfall, other models centered] user centered models - star model CREATIVE DESIGN - the types of ideas that come into design as a process some of the visual approaches to design [images that appeal to people] transfer lots of information in very small visual spaces - designer must use creativity to accomplish some of the models. WHAT'S THE FUNCTION OF A USABILITY TEST? It's to test the design of the interface as it relates to the user. TEST PLAN - formal mechanism to identify questions to test the plan, criteria for successful testing or failure of your interface. Certainly an interface has questions. you've done creative design, does it work? the test plan identifies important issues which must be tested. 4/10/2000 ========= ** PROCESS ** NON-HIERARCHICAL ** TRANSFORMATIONAL ** DISCOVERING NEW (GOALS) The Design Process ================== Characteristics of the design process - a process that is a set of activities that we continually go through. It is not static, and it constantly evolves. It is NON-HIERACHICAL the design process is transformational. This means that it involves the development of solutons that we will ultimately be classified as intreum solutions which will be discarded in favor of later solutions. [example - initial process of design] * add new features * throw out features you can improve on. The more mature the designer, the less faulty starts people have. The design process is about discovering new things. (think about it in terms of goals) If someone told me to design something and they told me what it was supposed to do, I'm going to go back to those people and say we need to add this in here.. Discovering new goals - is what design is all about. Snidernan says there are three pillars of good design: ======================================================== 1) Have guideline documents and processes. He's talking about to insure a good design - build some design guidelines into your system so you are more efficient at design. Guideline documents outline various fundamenal things that the design team has settled on - fonts , sizes, shapes, et cetera. It should be documented and used to help you choose consistancy. Documents are design documents and prototypes which come from places like microsoft. The processes talk about some of the mechanical things (things in design documents): words and icons - what they mean and the terminology- chapitolization, size, shape, color, et cetera screen layout issues - how to use up the real estate that you have. input / output devices - should a button make a noise when it's pressed? it depends on what you're trying to achieve. (someone would have to make a design choice). [response times, how long does it take to retrieve info?] action sequences - having direct control and giving this to the user. allow the user to manipulate our interfaces. every interface should have training, tutorials, and help built into them. 2) interface software tools it is clear without approphriate tools, we would not be talking about some of these issues. [we not only need to have a graphical design, windows, mac, xwindows], but tools as well. the notion here is now one of building a prototype. Currently, rapid prototyping is becoming more common. Designers have always built prototypes, but they used to be expensive and hard to build. Now they're becoming more and more efficient. 3) usability testing one way to test the pillars is developing the test plan and conducting the usability test. this is used to find out how close you are. however, it turns out there is another way to find out how close you are - that is an expert review. it is possible to find a series of experts to look at the systems you have build to apply techniques that determine if you meet some of the goals you set out for in the beginning. some of those techniques are: [EXPERT REVIEW] 1) heuristic review - an expert criticques a series of reviews to allow him to understand how well the project he's reviewing is going [for example, a movie review] 2) guideline review - any process that went through the development of a consistant and well thought out guideline can tell if the guideline will help develop a good product - especially if there is a comprehensive guideline. [lots of people have guidelines they don't follow] 3) consistancy inspection - if you look at a piece of software and saw someone do a real good function and task and noticed other tasks have the same level of work - you would reach the conclusion that each area was a good job- cause every area had the same look and feel. 4) cognative walkthrough - says if i'm not going to think about what your software does, i'm going to think about what the user does when they're using your software, and see if the software provides those kinds of cognitive things. if it does, you're in good shape. 5) formal usability inspection - this one's like a trial. the expert comes in and says "you said this was gonna work - prove it to me". the developer proves to the expert that something accomplished the goals that were setup for in the design specifications. **THIS IS TO DETERMINE HOW WELL / CLOSE YOU GOT TO HITTING THE TARGET** [SAMPLE could be too small or biased for some statistical techniques] you have the bias of the user to deal with, here... PROTOTYPING =========== Reasons - We want to make sure it works when we go with it... prototype can provide information about several areas that are important for us. **Necessary functionality** - is this what you REALLY need? **help us find the operational sequences** - **user support level** - enables you to find problems with the interface and structure training / tutorials to help solve those problems. **check to see if the required representations are right** - should it be last name first? first name? a student number? some people would rather know your first name or your last name. International programs would definately have to deal with some of these things. An interface is a semi-functional, quickly and cheaply built, which allows us to study these issues. Some of the types of prototypes that can be built are: Full Prototype - a prototype that has all the functionality but decreased performance levels. Horozontal Prototype - a prototype that shows a full interface, but has no functionality behind the menu items or buttons. [This is basically a mockup] Vertical Prototype - It's all not there, but the pieces that are there work. You don't have all the components, but the other components , if they worked, would work the same way. if you click on something, it should say "not implemented". High Fidelity - a prototype that resembles as closely as possible the finished product. Low Fidelity - paste everything on a sheet of paper and say it'll look a lot better than this. :) Chauffered Prototype - you have some intermediary sit down in front of it and explore it, but don't let a user at it yet. Wizard of Oz Prototype - a prototype that allows a system to operate, but the operation is actually taken care of via a third party. it might look like a macintosh, but a wire runs to another system to explore another functionality. EVALUATION ========== [Formative Evaluation] To determine or fix the value of. to determine the signifigance or worth by careful evaluation or study. You evaluate the current state of design while you're designing it. You want to improve upon it. Somewhere in your design specifications you have to point out what is enough. [Summative Evaluation] / Acceptance testing After it has been fully implemented and tested by developers, it's tested to see if it meets its design goals and objectives. The people who develop it and test it generally do not test it in the environment it's likely to operate in. They might in fact develop a chofferred sequence. :) This is a devilish thing for people to do because a negative evaluation is really really bad, [you've been working for three years, you're waiting for your 10 million dollar check, and you take it out to the checkers to test on a busy banking day] This is expensive and done SOMETIMES, but the downside is that it is done in the environment it is intended to run in and can fail for all kinds of STUPID reasons! (one was there wasn't enough plugs for everything!) REASONS FOR EVALUATION ====================== 1) To understand the real world - you are testing to see if it fit the environment and see if it mets the real tasks. 2) Comparing designs - each of us were asked to outline and critique a particular interface. This is the first step in comparing designs. 3) Engineering towards a target - He didn't know how to build his idea, but he knew what he wanted to do. He wanted to build that machine, but he couldn't accomplish it affectively. 4) Checking conformace to a standard - If you have a standard, you could evaluate to see how well you have met them. There are also external standards you might want to check conformace to - to see how well the product met the standards that were specified for it. 4/17/2000 ========= CRITIQUE some application you have used (Email Connection) and clarify what they got right and what they got wrong. Why? [For Final Project] It stores email addresses and other stuff, but there are other problems with it Screen Prints Code Listings Description of what it should accomplish... For Test Plan: ============== how effective is the design? how efficient is the design? Those equestions shoud be evaluated in the test plan Don't ask questions like "did you like the interface" What about shape? size? font ? could you read the text? [no?] no clue what the problem was "Was the wording understandable" "Were the characters the right color for you to easily view on the screen? Two people who aren't in this class four or five that are in the class use "like" ok - ! :) Example "Do you like the background color?" A "Likkard scale question" - must have two opposing ends. Excellant and Poor would be better to be: Very Good Good Average Bad Very Bad Data to help determine questions: What is the goal of the question? Do the users like the color? Does the color confuse the user? Does the color interfere with the interface? What is the best background color? Does the question provide a complete answer? Does the question have validity? [does it measure what it's supposed to?] Does the question have reliablility [A question will produce similar responses on seperate occasions] How often do you use a computer? How many hours a week do you use a computer? Games Internet Surfing Getting a girlfriend Buying cheap beer? Other? Specify___________________ [Good Question] I think the phone registration system is: 1....2....3.....4.....5 Very Bad Very Good Verify you must have a login/password. At the end, tell them thanks! ;-) 4/19/2000 ========= Under Evaluations, there are two types of evaluations people look at: Pilot Studies - A short test , small study carried out for evaluation methodology. We talked questions last time, gave a test to see if it works, and find out what the results were. We've talked about ways of collecting data. Watch people and take notes, if you have everything ready and the people went so fast you couldn't write anything down. A field study is something done in a natural setting something resided in... Much more involved and larger and generally samples the real world experiences. Methods of Evaluation: ======================= 1) Observation - We can give users some tasks and observe them as rthey complete those tasks, watching them do things. There are two methods of observations - DIRECT OBSERVARTION - I look at them, they see me looking at them. You notice behaviors, things that you may not normally notice. It generally gathers information quickly because it's a real-time process INDIRECT OBSERVATION - Another way to do things. It trys to fix this Hawthorne problem, but you might also mess up the privacy thing. In another sense, indirect observation is good IF you annouce before hand the people who are being observed can opt out from being observed. 2) Develop what we call PROTOCOLS - we develop a data gathering methodology. One protocol is a think-aloud or talk-aloud protocol. If your interest is collecting information about what people are thinking or doing is you can ask them to take the test and everytime they do something speak out loud and record it on tape about why they did it. "everytime you click a button, say why you did it..." Another type - POST EVENT PROTOCOLS - you ask the user to look at a video of what he did and ask what were you thinking of right here? why did you choose that? There are all sorts of ways you can evaluate information and collect information on those particular methods... DATA LOGGING - why couldn't you have each event log each activity that was on the screen, et cetera, what page it was on, et cetera... Check the last click, subtract first click - time they used the interface Current click, subtract last click - you can see how long they took to understand the interface. INTERVIEWS ========== Another way to collect information from people is INTERVIEWS There are two types of interviews: Structured - Everyone is asked the same set of questions. Unstructured - You might ask a dalechamps worker "what do you like about your job" - and they might reply "the light from the ceiling". You set it up where you ask more detail about the light. You (the interviewer) - ask questions other than the ones set in a structured approach. ADVANTAGES: You get additional information (probably) [specially in unstructured] You also get re-enforcing information (if you are NOT there, you don't get body language, et cetera.....like stress, or like hesitation) DIS-ADVANTAGES: It's actually VERY time consuming/costly - it's one on one. Also, someone has to be paid N times - based on how many interviews are made in person. The expert develops and trains for the interview. He then sends out trained interviewers. SEMI-STRUCTURED Interviews - they can pause and ask why if they so feel... they can probe for more info... CLOSED ENDED / OPEN ENDED QUESTIONS Closed end questions don't really allow a custom answer, whereas open ended questions are designed for that. List two questions you found beneficial (open ended) Was this questionnaire helpful? yes. no. (closed ended) You also can use open ended to expand understanding about the question. You can use closed ended questions to QUANTIFY (mark a,b,c) your answers. Surveys and/or questionnaires are generally either: printed computer based web based There are some advantages and disadvantages: advantage: cheapest method of sampleing pretty low cost to cover large audiences "offline" - you're not connected to the people doing the survey. (for example, an interview might be considered "online" disadvantage: low response rate - there's not much enducement. question clarity or completeness. If you took your questions - froze them - mailed them - and when they come back, you're stuck. There's not much you can do. That means the DEVELOPMENT of the questionnaire is more important because you only have ONE SHOT to collect your information. QUANTITATIVE or QUALITATIVE: IF i only gather mathmatical data and ignore people's feelings, the data is flawed. There is stuff I can physically measure, and there are emotions... Evaluation of Existing Interface: 2 pages minimum interface complexity include a readme.txt file listing filenames and contents this was email connection do lots of comments...most everyone else did (pre and post conditions) in and out... thank people for your stuff, in the end.... do intro screens...[no print shop] 4/26/2000 ==========