artifakters livsløp: design & bruk Tone Bratteteig Rune Rosseland inf1510: 25/1 2016 + Magnus Søyland Jørgen Valen Peter Havgar
etter forelesning & fellesøving skal dere: - forstå den overordnede prosessen i bruksorientert design - forklare modellen for bruksorientert design (og hvordan er forskjellig fra modellen i inf1500) - forklare hvorfor bruk & brukere er viktig for design - og hvorfor design er viktig for bruk - forklare forskjellen på fokus i inf1500 og inf1510 - være motivert for å starte på inf1510-prosjektet refererer til kap 1, 2 og 9
hovedfokus Our job is to give the client... not what we wants, but what he never dreamed he wanted; and when he gets it, he recognizes it as something he wanted all the time. (Lasdun, 1965) kundene sier at de vil ha en bedre støvsuger, men det de egentlig vil ha, er renere gulv.
hovedfokus bruk er del av aktivitet & bruk er mer enn kommunikasjon kap 1: What is interaction design? By interaction design, we mean: designing interactive products to support the way people communicate and interact in their everyday and working lives. Put another way, it is about creating user experiences that enhance and augment the way people work, communicate, and interact (s. 8)
hovedfokus (2) kap 1: What is interaction design? Designing interactive products requires considering who is going to be using them, how they are going to be used, and where they are going to be used. Another key concern us to understand the kind of activities people are doing when interacting with the products. (s. 6)
hovedfokus (3) kap 1: What is interaction design? A key question for interaction design is: how do you optimize the users interactions with a system, environment, or product, so that they support and extend the users activities in effective, useful, and usable ways? (s. 7) lage de riktige tingene & lage tingene riktig
samarbeid mellom designere og brukere brukere kan bruk best kap 1: What is interaction design? Designers need to know many different things about users, technologies, and interactions between them in order to create effective user experiences. At the very least, they need to understand how people act and react to events and how they communicate and interact with each other. (s. 10)
brukeropplevelse er en del av bruk kap 1: What is interaction design? The user experience (UX) is central to interaction design. By this it is meant how a product behaves and is used by people in the real world. It is important to point out that one cannot design a user experience, only design for a user experience. (s. 12) McCarthy & Wright: sensual, emotional, compositional, spatio-temporal aspects
brukeropplevelse er en del av bruk kap 1: What is interaction design? The user experience (UX) is central to interaction design. By this it is meant how a product behaves and is used by people in the real world. It is important to point out that one cannot design a user experience, only design for a user experience. (s. 12) brukbarhet består av mange ting
grader av brukermedvirkning kap 1: What is interaction design? The user experience (UX) is central to interaction design. By this it is meant how a product behaves and is used by people in the real world. It is important to point out that one cannot design a user experience, only design for a user experience. (s. 12)
bruks-orientert design: prosessen kap 1: What is interaction design? The user experience (UX) is central to interaction design. By this it is meant how a product behaves and is used by people in the real world. It is important to point out that one cannot design a user experience, only design for a user experience. (s. 12) kap. 1 s. 15 & kap. 9 s. 332
bruks-orientert design: prosessen etablere krav evaluere designe alternativer prototype
bruks-orientert design: prosessen evaluere prototype designe alternativer + prototype etablere krav
bruks-orientert design: prosessen starte / planlegge evaluere undersøke prototype bruk designe alterna- identiiisere tiver + prototype behov & ønsker etablere krav & eval.kriterier
bruks-orientert design: prosessen starte / planlegge evaluere undersøke prototype bruk designe problem- alterna- identiiisere problemtiver løsning + prototype behov de=inering & ønsker etablere krav & eval.kriterier
iterasjoner av bruksorientert design oppstart bruks-praksiser sette mål, planlegge problem-situasjon testing & evaluering undersøke praksis problem-løsning materialisering, konkretisering problem-deginering identi=isere behov & ønsker konkrete evalu- eringskriterier
iterasjoner av bruksorientert design oppstart bruks-praksiser sette mål, planlegge problem-situasjon testing & evaluering undersøke praksis problem-løsning materialisering, konkretisering problem-deginering identi=isere behov & ønsker konkrete evalu- eringskriterier
utgangspunkt: tingenes livsløp design design bygg test brukskontekst ide ting søppel (produkter, systemer ) tid
hvorfor starte med bruk?
hvorfor starte med bruk? Automatica, Vol. 19, No. 6. pp. 775 779, 1983 Printed in Great Britain. 0005 1098/83 $3.00 + 0.00 Pergamon Press Ltd. 1983 International Federation of Automatic Control Brief Paper Ironies of Automation* LISANNE BAINBRIDGEt Key Words--Control engineering computer applications; man-machine systems; on-line operation; process control; system failure and recovery. Abstract--This paper discusses the ways in which automation of industrial processes may expand rather than eliminate problems with the human operator. Some comments will be made on methods of alleviating these problems within the "classic' approach of leaving the operator with responsibility for abnormal conditions, and on the potential for continued use of the human operator for on-line decision-making within human-computer collaboration. Irony: combination of circumstances, the result of which is the direct opposite of what might be expected. Paradox: seemingly absurd though perhaps really well-founded statement. THE classic aim of automation is to replace human manual control, planning and problem solving by automatic devices and computers. However, as Bibby and colleagues (1975) point out: "even highly automated systems, such as electric power networks, need human beings for supervision, adjustment, main.tenance, expansion and improvement. Therefore one can draw the paradoxical conclusion that automated systems still are man-machine systems, for which both technical and human factors are important." This paper suggests that the increased interest in human factors among engineers reflects the irony that the more advanced a control system is, so the more crucial may be the contribution of the human operator. This paper is particularly concerned with control in process industries, although examples will be drawn from flight-deck automation. In process plants the different modes of operation may be automated to different extents, for example normal operation and shut-down may be atomatic while start-up and abnormal conditions are manual. The problems of the use of automatic or manual control are a function of the predictability of process behaviour, whatever the mode of operation. The first two sections of this paper discuss automatic on-line control where a human operator is expected to take-over in abnormal conditions, the last section introduces some aspects of humancomputer collaboration in on-line control. 1. Introduction The important ironies of the classic approach to automation lie in the expectations of the system designers, and in the nature of the tasks left for the human operators to carry out. designer errors can be a major source of operating problems. Unfortunately people who have collected data on this are reluctant to publish them, as the actual figures are difficult to interpret. (Some types of error may be reported more readily than others, and there may be disagreement about their origin.) The second irony is that the designer who tries to eliminate the operator still leaves the operator to do the tasks which the designer cannot think how to automate. It is this approach which causes the problems to be discussed here, as it means that the operator can be left with an arbitrary collection of tasks, and little thought may have been given to providing support for them. 1.1. Tasks after automation. There are two general categories of task left for an operator in an automated system. He may be expected to monitor that the automatic system is operating correctly, and if it is not he may be expected to call a more experienced operator or to take-over himself. We will discuss the ironies of manual take-over first, as the points made also have implications for monitoring. To take over and stabilize the process requires manual control skills, to diagnose the fault as a basis for shut down or recovery requires cognitive skills. 1.1.1. Manual control skills. Several studies (Edwards and Lees, 1974) have shown the difference between inexperienced and experienced process operators making a step change. The experienced operator makes the minimum number of actions, and the process output moves smoothly and quickly to the new level, while with an inexperienced operator it oscillates round the target value. Unfortunately, physical skills deteriorate when they are not used, particularly the refinements of gain and timing. This means that a formerly experienced operator who has been monitoring an automated process may now be an inexperienced one. If he takes over he may set the process into oscillation. He may have to wait for feedback, rather than controlling by openloop, and it will be difficult for him to interpret whether the feedback shows that there is something wrong with the system or more simply that he has misjudged his control action. He will need to make actions to counteract his ineffective control, which will add to his work load. When manual take-over is needed there is likely to be something wrong with the process, so that unusual actions will be needed to control it, and one can argue that the operator needs to be more rather than less skilled, and less rather than more loaded, than average.
INF1510 våren,2016 uke dato Obligatoriske,oppgaver forelesning, felles;øving prosjekt 18/1 intro&bruksorientert&design 4 emnet,&opplegget,&læringsmål&mm& 25/1. artifakters&livsløp:&design&&&bruk bli&kjent 5. intro&til&prosjektarbeidet prosjekt;tema 1/2 intro&arduino øve&arduino Arduino 1 6 10101oblig.1:.3/2. &. 8/2 mer&arduino øve&arduino & 2 7 10101oblig.2:10/2. &. 15/2,. ideer&for&arduino gjøre&ferdig&arduino & 3 8 10101oblig.3:17/2. &. 22/2 Obl,1 fredag,26/2 start&prosjektet utvikle&prosjektideer prosjekt 1 9 (ind) Arduino;oppgave praktisk&planlegging &. 29/2 10101oblig.4+5:24/2+2/3 hvordan&bruk&forstås/undersøkes observasjon&og&intervju & 2 10 10501oblig.1:.4/3 observasjon&og&intervju &. 7/3,, hvordan&design&forstås/utføres& brainstorming & & 3 11, &&&hvordan&får&vi&design;ideer? forberede&presentasjon & &. 14/3 Obl,2 mandag,14/3 presentasjon&prosjekt;ideer & & 4 12 pres.,prosjekt;ide & &. 21/3 10101oblig.6:16/3 & & 5 13 påskeferie & &. 28/3 til&og&med&mandag&28/3 & & 6 14 10101oblig.7:30/3 & &. 4/4 10101oblig.8:6/4 design&med&brukere& prototyping & & 7 15 10501oblig.2:.8/4 prototyping workshop&med&brukere & &. 11/4 analysere&data&;&kartlegge&behov analyse & & 8 16 10101oblig.9:20/4 identifisere&behov&og&krav & &. 18/4 Obl,3 mandag,18/4 presentasjon&prototyper design;kritikk & & 9 17 (grp) pres.,prototype begrunnet&i&behov & &. 25/4 Obl,4 mandag,29/4 gruppearbeid evaluering&av&prosjektets & & 10 18 (grp) eval.gruppearbeid. organisering&&&fremdrift & &. 2/5,. Tomm&Eriksen:&evaluering&hos& evaluere&med&brukere & & 11 19 10501oblig.10:.4/5 USIT&UiO&+&om&evaluering & &. 9/5 intro.humsam1fag.+.pizza Hovde:&sosiologi Liestøl/Rasmussen:&medier & & 12 20 10101oblig.11:11/5Mørch:&pedagogikk Torvund:&jus & &. 16/5 fri&mandag&og&tirsdag & & & 13 21 10101extra:18/5 & &. 23/5. Astrid&Larssen&fra&Halogen,&som&& skrive&rapport & & 14 22. jobber&med&bruksorientert&design video&&&pitch & 30/5 oppsummering& & 15 23 eksamenstips slutt& 6/6 24. 13/6 15/6 Eksamensoppgave,grupperapport,og,video,(m/dok) 25. 17/6,individuell,oppgave NB! foreløpig plan gjesteforelesere ikke bekreftet
Forelesning: mandag 10.15-12.00 Fellesøving: mandag 12.15-14.00 Tid for gruppearbeid + Arduino-arbeid med mulighet for veiledning - tirsdag 8.15-10.00 - onsdag 8.15-10.00 Sonen (Ada) - torsdag 8.15-10.00 + C/Caml - fredag 8.15-10.00 (med noen unntak på rommet)
prosjekter 2016 forslag til tema for prosjekt: - interaksjon uten skjerm: prosjekt-oppgavene presenteres i dag - tangible interaction - wearable computing - embedded computing - Internet of Things - smarte omgivelser hva slags problemer kan Arduino løse? NB krav: 1 Arduino 2 forankre design i bruk 3 ikke studenter som brukere 4 intervju & observasjon