Summary of the SIG Session at CHI
From Flossusability
Contents |
Summary of SIG
About 40 people (1/3 to 1/ 2 of whom were involved in open source projects as contributors or researchers) attended the CHI Special Interest Group (SIG) on Usability and Free/Libre/Open Source Software (FLOSS). The group raised many issues including the “code as currency” issue. In essence, if “code is the only currency’ can there be a “benevolent HCI dictator?” The currency problem arises when HCI people who don’t write code work on FLOSS projects, potentially preventing the common mechanism of the “benevolent dictator” who can arbitrate conflicts over coding from emerging in the design and HCI domain. An interesting benevolent HCI dictator experiment would be to have HCI people design and initiate an open source project (it could even be a rapid prototyping tool that could be used as currency between FLOSS HCI people and developers) and have developers work on the project with an HCI person as the leader. This would be interesting in terms of social dynamics and to see who prevails as the benevolent dictator: would the HCI person remain or would a developer move into the leadership position once code writing began?
(copied from Port25--look down to Part 4 )
During the SIG, we opened the discussion up to the participants and below are notes taken by the three panelists: Paula Bach, John Carroll (aka Jack), and Bryan Kirschner.
Summary of Notes
Notes from CHI 2007 SIG Compiled from Paula's, Bryan's and Jack's notes FLOSS Usability April 30, 2007
Usability
- How is usability done now?
- Large projects have usability - GNOME, openoffice, FIREFOX
- What about small projects?
- How ought it be done?
- One approach: openusability.org
- Why is it not done the same in FLOSS?
- How open are open source communities – meritocratic?
- Gatekeepers- benevolent dictators - what would a similar structure look like for usability?
- Does a similar structure make sense?
- Dynamics of major versus minor projects
- Process of analysis and design: How do you integrate analysis & design
- Culture
- User studies and design process are distributed
- Design and collaboration are complicated by volunteerism
- But some projects are driven by corporate interest so volunteerism depends on community structure
- Community source – code is currency, hard to bring usability into process
- What is HCI currency?
- How do we disseminate expertise and knowledge?
- How to pay a usability expert? - no way to get it for free
- Design process
- Is oss a channel to get good design out there?
- BUT--innovation within OSS without formal design process
- Libraries and software libraries
- Cathedral & bazaar model - how do you incorporate "we're not shipping until x"
- What flavors of FLOSS do we focus on first?
- A FLOSS model for usability could really address usability problems
- How can you incorporate usability into a process that does not have milestones?
- How could the meritocracy model be adapted to incorporate usability?
- There are objective standards to declare something good when it is just code.
- Usability testing requires a lot of equipment and infrastructure
- Where FLOSS is quite lightweight
- Lower-cost paradigms for UE: design patterns, usability guidelines,
- Capturing uses sessions and posting on utube to quickly and easily share user experience data with developers in a distributed community
- Capture and post session logs
- Where does open source fail when it fails for usability reasons?
- Has it failed wrt requirements and models, or interface presentations?
- If the failure sources tend to be fundamental, then the lower cost approaches will not help enough
- University students could be a resource – for this. Class projects could participate in usability reviews of FLOSS projects.
- What about a designzilla where people post ideas in need of a design, would create a FLOSS community at the level of designs
- Twidale – a forum tool to simply broadcast who can help with this? Capturing such communications would give you a characterization of what the problems are
- Innovation: There are different models for FLOSS now, made need to make distinctions
HCI Expertise
- Usability is universal
- FLOSS developers are reductionist and carry the aesthetic of control
- What makes a better product?
- Focus on usability vs broader HCI
- Need for usability is discovered late in the development
- What is the 'fun stuff' in HCI for people to work on
- Feature bloat not conducive to good usability engineering practices
- Feature by feature growth - you can only throw away code from someone else if you are in a powerful position
- Usability is costly—how do volunteer resources factor in?
- User centered design not evident in FLOSS
- What if a project was initiated by those with HCI expertise?
- Perhaps usability experts need to initiate FLOSS projects, that is, put prototypes out there and use them to start usability-driven FLOSS activities
- Prototypes could be currency
- Prototypes are fun
- HCI expert+fun stuff…expectation to refactor
- Communication across an expertise divide
- SW developers see it as adding usability VS broader notions include information design
- FLOSS projects often succeed via a reductionism (divide and conquer, benevolent dictators) vs holistic (architected approach) – this will not work for managing usability
- Saving time for user vs benefit to developers (volunteer) - usability is expensive
- Focus-on-the-fun bits approach may not work for usability
- Perhaps FLOSS designers would find it fun to be able to get usability engineers to evaluate their early systems (prototypes) and get feedback and interpretations
- Usability requires simplification, but this is hard for FLOSS projects
- The need is discovered later - re-engineer to incorporate usability
- Hard to make the feedback loop link to value of following HCI advice
- Unit is the experience/interaction model
- FLOSS must be easy for the developers, but this does not necessarily make things easier for the users
- A single usability issue could have implications for architectural or otherwise broad aspects of the code itself
- Different types of usability expertise – usability engineering, information design, information architecture, user experience design, interaction design
- How are they different?
- Code currency culture vs usability culture
- If you want this change code it youself
- Upfront processes … left out when code is king (UCD awareness)
- GIMP - warts in interface - resource strapped; awareness of issues - limits in volunteer projects - architecture implictions
Design Rationale
- “open sourcing” the design rationale so it becomes the currency
- In distributed environment must lay out reasons for change
- Design rationale as a tool for change
- “in the wild” design rationale is more relevant
- Asynchronous nature should make rationale easier
- design rationale is text centric in the wild
- where does rationale happen?
- Where is the real-time thinking?
- Twidale – found FLOSS developers created blogs that were effectively DR, but they don’t know why this material was not in bugzilla
- Perhaps there are so many bugzilla reports every day that your DR would be lost in all that
- Perhaps bugzilla does not support the form of rationales that people want (e.g., post two screen shots and explain how they are different and why)
- Buckingham-Shum – working on DR tools for FLOSS
- allows you to collect in one space outside urls, blogs
- using camtasia to capture user sessions and post to web
- lightweight distributed outsourcing and usability
- Design Patterns might be a good lightweight way of codifying rationale
- Passing on rationale through design patterns
- Need for patterns beyond UI presentation patterns
- Wikis for design rationale, blogs
- Repurpose of these tools - no such thing as Patch (code) for ongoing discourse (VB control, powerpoint) - not amenable to manipulation
- InGIMP - captures data (instrumentation)
- Design community specialized SW & code
Tools
- No open source tools, especially few tools to support the social/collab processes
- re-purposing tools for the FLOSS development environment
- Xcode – package up a UI to share it with others as other sharing is enabled in FLOSS
- existing tools inadequate for supporting HCI expertise
- Collaborative design - no good ways to share - lots of value in a tool to persist and share
- something like Adobe Connect – for online collab
- Asynchrosnoous shared experience only -- annotation blog
- Tools are everywhere, but how are they being used now?
- User testing tools are costly
- Design patterns as currency—pattern library tool
- tools to record user specification
- Participatory design models for FLOSS
- Online help forms as a clue to where usability problems might be
- what distributed tools work?
- "YouTube usability environment" - posting user walkhroughs of what they envision
- youtube before CVS - open source designs
- Spawns a creative commons approach to user testing
- User interface guidelines - library
- "I need to know my user" versus "how do I express my idea"
- Online forums mineable
- Firefox extensions
- Heuristics library - like Nielson's 10
From the group discussions
Usability table
- how does usability compare between commercial and FLOSS environments
- What tools are for users of FLOSS
- How to introduce usability into FLOSS environments
- OSS: who are your users and what are they doing
- Cross pollionaiton from commercial vendors
HCI expertise table
- data collection from users
- Data capture - people can opt in to open capture
Design rationale table
- patterns beyond UI that embody rationale or come with design rationale
- there is a need for DR tools and connects among projects
- Tools for extended structured discourse
Tool table
- UI designs packaged and used by FLOSS projects
- Hard to package and pass along: Apple's Xcode - package up half working interface
- use state machines to track usability and as early prototypes
- need a wiki or something to track usability issues
- virtual white board for sketching (Oracle has one)
- Adobe connect is an online collaboration tool
- HCI experts design first
