CCT 333: Imagining the Audience in a Wired World

1. CCT 333: Imagining the Audience in a Wired World Class 10: Prototyping and Applied Looks at Design Issues in CSCW

2. Prototypes • Are based in research done to date • Make stories told in scenarios concrete • Represent determined requirements

3. Fidelity • Low-fi prototypes - mockups using readily accessible, cheap tools and material • Aims to make tangible basic functions while being flexible in use • Hi-fi prototypes - more closely resemble final design look and feel • Can constrain feedback in evaluation - things like look finished might not solicit valuable information

4. Participatory Design • Prototypes can be communal spaces for discussion with users • Lay users might not understand technical details, but they can experiment with use and provide valuable redesign information • IPS example

5. Rapid Prototyping • Quickly created - and discarded - iterations of a design vs. tons of work to prove something might never work • Computing’s role in rapid prototyping - FSAE examples • Change in development models - e.g., waterfall vs. agile development

6. Evaluation and Redesign • Design is never “done” - but it does have to end somewhere • Versioning control, planning for future iterations • “retirement” of product - when does incremental revision fail?

7. Do Users Know What They’re Talking About? • A caveat to user testing and feedback - sometimes, users can’t vocalize what they actually want • Or, overly engineering products/messages come out “focus grouped to death” - banal, inoffensive, uninspiring • User testing and feedback still valuable here to determine latitude of acceptance/rejection, possible strategies of adoption, and to see if redesign is palatable

8. Project prototypes • Lo-fi prototypes fine • Redesign tied to user studies, scenarios, requirements - nothing should come out of nowhere • Testing of redesign depends on nature of project - but probably necessary if you’re violating their expectations learned in user study

9. A note on cost • Cost control plays strong role in limiting design options - redesign must be feasibly purchased by consumer and at profit (or at least not loss?) to producer • Cost controls and design compromise - examples? • Bottom-line driven design not necessarily effective - examples? • Keep in mind for your prototype - full costing not necessary, but if it appears it’s going to be a problem, be prepared to answer to it

10. Collaboration Technologies • CSCW - structured group communication technologies to share knowledge • CSCL - learning vs. work environments - difference? • But it is all just computer-based? Broader definitions of technology apply here - learning often not computer mediated, goes through many “mechanisms” (Popper/Lipschitz)

11. Meetings Artefacts Lab notebooks Trial and Error Email Alumni contact Industry contact Telephone Past Reports Books/articles Gossip and Informal Chat Reverse Engineering Corporate Intelligence A few FSAE learning mechanisms

12. Grudin’s 8 Challenges • Challenges (pp. 713-15) common to many design issues, not just CSCW • FSAE racecar study: very much about resolving these issues technologically and organizationally

13. Who works, who benefits? • Sharing information takes time • If costs of sharing outweigh benefits, people quickly stop sharing • Short and long term cost-benefit has to be clear and acceptable to all • FSAE: report writing, testing procedures issues - but also extraordinary examples of informal information sharing

14. Critical Mass • Collaboration technologies must be used by critical mass, or it ceases to be effective • Too much mass can be confusing though - email in particular • FSAE: Email system (over)use and KM database issues, also importance of f2f

15. Political and Social Factors • Technologies for collaboration exist within social and political contexts and often influences them - new technologies can create enemies quickly • FSAE: issues in enforcing safety and testing procedures

16. Exception Handling • Computing technologies in particular - rule driven and formalized • Humans - random, contingent, able to sort out new ideas on the fly • Handling exceptions necessary • FSAE: move to searchable full text data vs. formal database architecture

17. Group Communication as Exception • Some technologies compel sharing, create significant demands on time • Individual work important - sharing should supplement but not trump it • FSAE: meetings - making them efficient, necessary and few

18. Evaluating success • Hard to tell if a particular collaboration strategy is working • What works changes over time and changes in organizational culture • FSAE: annual reports with recommendations, some of which were contradictory

19. Collective intuitiveness • People intuitively know how to represent information for themselves- shared representations are harder • FSAE: issues in notation of data, interpretation of reports; use of physical models as instructive tools

20. Managing acceptance • Without organizational buy-in, even the best technologies may fail • FSAE: buy-in at leader and faculty advisor level, but also on the ground level; MBWA (management by walking around); balance of carrots and sticks

21. Technologies and Collaboration • One technology does not fit all requirements • Same time/place - meetings, support tools • Same time, different place - IM, collaborative whiteboards, tele/videoconferencing • Different time, same place - project management artefacts, post-its • Different time/place - discussion forums, email, wikis • FSAE: multiple mechanisms clearly used - representing shared results can be hard as result

22. Specialized vs. Common Technologies • Some argue for specialized technologies (e.g., integrated databases like Notes, PeopleSoft) • Can be powerful and tailored to org. needs, but expensive to design and maintain • FSAE: very little financial or human resources to maintain complex systems, off the shelf components easier to coordinate and use

23. The “right” mix? • Multiple avenues of learning • Avenues can and will contradict each other • Individual preferences play a role • Design for multiple complimentary channels, encouraging discussion and debate while minimizing noise and error • Information generally follows path of least resistance (for better or worse)

24. Next weeks • March 25: Guest lecture - Vic Cauchi • April 1: Project presentations in lab; last minute help and exam advice (reiteratred) in lecutre • April 8: Final test in lecture (no labs…)