Day 16 Readings

Today's readings cover the user interface toolkits that are commonly used in developing FLOSS software, as well as some proprietary software, namely GTK, QT and Mono. Please note that this is the final day of assigned readings for the course, so it is quite likely that it is the last blog post relating to the readings (although likely not of the course). In any event, the following are today's readings:

• Wikipedia Article for GTK+
• The Official GTK Website
• GTK Features
• Wikipedia Article on QT Framework
• Nokia/Trolltech Information on QT
• Wikipedia Article on the Mono Project
• Mono Project Site
• More Information About the Mono Project
• A Discussion of the Mono Controversy
• Free Software Foundation's Advisory on Mono Project

The following is a list of capabilities of GTK+:

• Supports a wide variety of common components (Labels, Text boxes,Radio button, List boxes, windows, menus, etc.)
• Supports a variety of operating systems (Windows, Mac OS X, GNU/Linux, and Unix)
• Supports a variety of form factors with native look and feel (mobile devices, desktops, laptops,etc.)
• Supports a variety of different programming languages (C,C++,Ruby,Java, .NET,Perl,etc.)

However, GTK+ isn't the most clean and usable widget toolkit out there. The interfaces, and mechanisms in GTK+ to handle such things as event handling, are clumsy at times. While there are a lot of GTK+ GUI builders, they aren't the most easy to use. For instance, I have used the GLADE interface builder, and have difficulties laying out controls on a window. However with other interface builders, such as those built into Visual Studio, the interaction is simple drag and drop.

A relatively recent project that has been started is Vala, which attempts to bring the high level simplicity and abstraction found in C# and Java to GNOME developers. Vala is lightweight in the sense that it doesn't impose additional runtime requirements on developers. The syntax of Vala is similar to C#, and supports modern language features such as lambda expressions, exception handling, and generics. Finally, it is meant to accomplish all of these goals in a "free," and "open," license which allows applications developed in the language to be contributed to various FLOSS projects in an unencumbered way.

QT is yet another widget toolkit that is commonly used in the FLOSS community. It supports many of the capabilities found in GTK+ listed above. In addition, it provides a variety of different modules which provide support for databases, web rendering, and vector graphics to name but a few. Some people find QT friendlier to use than GTK+ in creating GUI applications. For instance, the QT Designer which allows developers to create QT GUIs, allows for components to be directly dragged, dropped and manipulated on the form. However, in GLADE (the GTK designer), careful window layout specifications need to be laid out before performing similar actions. In addition, there appears to be a more integrated development experience with the QT Creator (QT's IDE), as opposed to using GLADE and other third party tools separately to develop a full fledged application.

In terms of history, QT was originally created by a company called TrollTech, and they used a dual-licensing scheme where QT was licensed under the GPL for FOSS applications using the toolkit. Companies wanting to use QT in their proprietary applications could purchase a license from Trolltech for several thousand dollars per developer at the time to license it for their proprietary use. The thought behind this is that some of the proceeds from licensing the toolkit to proprietary software companies could then be used to support further development of the toolkit. This dual licensing scheme as we have seen in previous readings is somewhat controversial. In any event, Trolltech was purchased by Nokia (the handset makers) in 2008 and since then Qt is now triple licensed under the GPL,LGPL and QT Commercial Developer license. Therefore the only change since the Trolltech offering of QT is that proprietary developers can now use and link into the QT toolkit unmodified free of charge. Should they want to modify QT in anyway, then they would either need to purchase a commercial license or use the GPL license with its restrictions (see previous readings). There are also differences between these licenses in terms of support and services offered by Trolltech/Nokia for the product as well.

The last toolkit we will discuss, Mono is by far the most controversial one in use by the FOSS community and developers in general. Mono is essentially a free (as in freedom and beer), implementation of the C# language and consequently Microsoft's .NET Framework. Some advantages to Mono over the previous two toolkits are as follows:

• A language that support many of the capabilities found in a modern programming language (such as lambda expressions)
• A clean and relatively well designed framework (.NET Framework), that allows developers to code up solutions quickly and succinctly
• A Framework that supports a wide variety of different technologies (from XML to SOAP and everywhere in between)
• The ability to bring the rich set of .NET Framework applications developed in Windows for Windows systems over to other platforms (such as Linux or Mac OS X)
• The ability to take advantage of a large set of developers who have familiarized themselves already with the language and the framework

On first glance it may seem very advantageous for the Open Source community to adapt and contribute to the MONO project. However, the MONO Project is not without controversy. First and foremost the technologies that Mono project will support are covered under different types of patents (for instance on the implementation of the C# language). While Microsoft has promised to not enforce their patents against the community via the Microsoft Community Promise License, that same license states that the implementation must be exactly the same as the ECMA specifications of its technologies (i.e. C#). If Mono was not found to be compliant with it in any way, then the license would be invalid and people who developed the Mono project, as well as any applications developed under it might be violating Microsoft's patent rights and in turn the software may have to be either abandoned or significantly rewritten to not use technologies that may infringe in some way with Microsoft's patents. This is precisely why the Free Software Foundation amongst others in the FLOSS community have advised developers from developing applications against Mono, or any FOSS implementation of C#. A second issue with the Mono project is that since it goes against the spirit of free software, many distributions do not include Mono by default, meaning that applications that use Mono may have to include it with their software package, whereas with GTK+ you can rest assured that it is in nearly all Linux distributions.

Day 15 Readings

Today's readings pick up on the practices of usability in the open source world. The following are a series of pages that talk about some of the tools that the open source community has built to address the issue of usability in the context of open source projects (from Human Interface Guidelines to portable usability labs):

• GNOME Human Interface Guidelines
• Mairin Duffy's Portable Usability Lab : Part 1 Part 2
• OpenUsability.org
• Open Source Usability : The Birth of a Movement
• Season of Usability
• UX at OpenOffice
• Blender Institute - Open Content Projects

Let us begin by taking a look at probably the most common Human Interface Guideline document used by the Open Source community, the GNOME HIG. While the document prescribes some guidelines for a variety of different commonly used components, we will focus on the usability principles of the document, as it is the zeitgeist of the document:

1. Design for People - Know who your users are and what you want to enable them to do
2. Don't Limit Your User Base - Make systems that are accessible to people of different cultures, disabilities, or who may speak different languages
3. Create a Match Between Your Application and the Real World - use easily understable metaphors to achieve this when appropriate
4. Make Your Application Consistent - In terms of appearance and behaviour between your own application and the application ecosystem
   
5. Keep the User Informed - the user should always be aware of what the system is doing
6. Keep It Simple and Pretty - Design the application to show only useful or relevant information - avoid clutter as it distracts the user
7. Put the User In Control - Avoid using modes of mechanisms which limit or control how the user interacts with the software, or the amount of tasks they can do at any one time
8. Forgive the User - Provide mechanisms (such as Undo), to allow the user to escape from mistakes, especially if they may be learning how to use the system
9. Provide Direct Manipulation - Allow users to directly interact with the data or objects rather than having to go through conduits such as dialogs

It is important to note that not everyone in the usability are supporters of Human Interface Guidelines. Probably one of the most famous paper written by a usability expert against Human Interface Guidelines is Don Genter and Jakob Nielsen's: The Anti-Mac Interface

We now move on to the issue of usability testing in the Open Source world. As we have read in previous readings, traditional usability testing where users enter a formal usability lab with equipment and an environment especially designed for usability testing is expensive. In addition, it doesn't take into account the globally distributed nature of users, where having colocated studies may not be possible. Therefore, it is refreshing to see that a usability professional has put together an entire usability testing system that is relatively inexpensive and can be easily moved around. The following are the tools that are used in his usability testing system:

• Carrying case to carry all of the testing components around
• Microphone and microphone plate
• Digital Video Recorder/Video Mixer
• 3 Sony Colour Security Video Cameras to record observations from three different perspectives
• Camera Stands
• Scan Converter, to convert the video coming out of the testing computer and turns it into a signal that the DVR can record
• Various accessories (i.e. power supplies/cables for cameras, DVRs, scan converters)

Looking through his site, we see that the total kit costs him around $908.08, to purchase all of the components for the kit (excluding carrying case). Therefore, it is possible to build a portable usability lab for under $1000. While you may not have exactly the same quality as a professional usability, you have the portability and affordability that the OS world requires. One thing that could be improved is the portability aspect of the kit, as I suspect that it would take a non-trivial amount of time and effort to setup the usability lab.

Openusability claims to be an initiative that promotes usability in FLOSS (Free/Libre/Open Source Software) development. They want to make usability more transparent and accessible to the open source community. By sharing methods and best practices of usability and providing hands on support to usability they could make usability happen in Open Source. The project encourages FLOSS projects to seek assistance from Openusability if they feel that their project could benefit from the assistance that Openusability provides. It also encourages usability professionals to look through such FLOSS projects that require assistance from Openusability and contribute their expertise to these projects. Finally, students are encouraged to join their mentoring program, Season of Usability, where students work with usability professionals and key developers from a FLOSS project to help improve the usability of that project during a 3 month period.

The blog post, Open Source Usability : The birth of a movement is a really nice summary of the past couple of day's readings. It covers many of the challenges already discussed about OpenSource usability, why people should care about improving the usability of OpenSource projects, and some of her experience in the field.

The OpenOffice user experience project website outlines the current activities of the Open Office UX team, the members of the UX team, various team blogs, their wiki, todo lists, resources, and Project Renaissance. They provide usability consultations for those developing new functionality for OpenOffice as well as to modify existing functionality.

What is interesting about the OpenOffice UX pages is the one on Project Renissance, which is the project that will create a new User Interface for OpenOffice. As you may or may not know, OpenOffice is a FOSS office suite containing a word processor, spreadsheet, presentation tool, and other common office applications. A major complaint of OpenOffice is that its user interface is cumbersome and outdated due to the many overstuffed toolbar, poorly structured menus, and otherwise complex dialogs. In addition, many office suite vendors (such as Microsoft's Office(R) suite), have updated their user interfaces and user experience, leaving OpenOffices work seem dated by many years. Therefore, the goal of the project is not only to catch up with the usability and user experience offered by modern office suites, but also to better know and understand who uses OpenOffice so that it can become over greater value and desire for users. The project is interested in changing the information architecture, interaction design and visual layout of the OpenOffice suite. They are not interested in extending functionality further than what is currently offered by OpenOffice.

The Blender Institute facilitates the creation of open content projects related to 3D movies, games or visual effects. Open content projects, are projects whose content is licensed under a license model similar to Open Source model (for instance the artistic license). They provide, to participating projects a small staff of between 3 to 4 people including producers, projects co-coordinators and an administrator. They also provide a studio as well as additional space for training/workshops. Since the Blender Institute doesn't make money through conventional means (i.e. royalties and copyright), each project must get financed in advance through things such as government/NGO subsidies grants, corporate sponsorship, workshops, seminars, training, and other related activities. These projects typically last between 6 to 12 months. Some notable OpenContent created by the Blender Institute include Elephants Dream and Big Buck Bunny.

Day 14 Readings

Today's readings are a continuation in a series studying usability practices in Open Source projects. The papers looked at include:

• Perceptions and practices of usability in the free/open source software (FoSS) community
• Usability in Open Source Software Development: Opinions and Practice
• How power users help and hinder open bug reporting

The first paper, Perceptions and practices of usability in the FoSS community, interviewed members of the FOSS community at a FOSS conference, at a corporation that produces FOSS software and remotely via Skype. There were a total of 12 developers, 5 user experience (UX) professionals, 5 non-code contributing project members (documentation,writers,localization contributers) and 5 core users of the software. In terms of the core users studied, they looked at users with a close social tie to project members, with domain expertise and extensive experience using the software. They also looked at users who regularly use nightly builds of the software. The projects studied included a wide gamut of OSS projects from a 3D animation package, to a web browser to a desktop operating system.

The study then posed four questions and answered them in turn.

Firstly, how do open source developers define and conceptualize the notion of usability. The study found that the definitions the participants provided span the range of definitions commonly found in HCI textbooks, which implies that the community as a whole posses a fairly sophisticated notion of the concept. The following are the top five definitions of usability provided (although there were more than a dozen definitions provided by the participants):

• Learnability/discoverability - features can be learned and discovered
• Logical - interface and interaction follow a certain logic that users can follow
• Efficiency - users can perform tasks efficiently
• Simplicity - Interface design and presentation is simple
• Transparency - the tool doesn't get in the way of the user

The second question, "What motivations do FOSS developers have for creating software that is usable by people other than themselves?" The study finds that social relationships, social rewards and subtle social pressures are some of the most important forces to keep people involved in a project. They provide quotes from participants which support each of these motivations. This is in contrast with conventional wisdom in OSS projects which is that a growing user base acted as a intrinsic motivator for contributors to OSS usability. However, the study also finds that a growing user base acts as a disincentive as it increases the number of bug reports, feature requests and complaints.

"What are current usability practices in the FOSS community?," was another important research question considered. This was the heart of the study, and so this summary will be a bit longer. Some novel usability methods practiced in FOSS communities include Graduated Testing and Open Content Projects. Graduated testing is the practice of new designs being incrementally evaluted by increasingly larger groups of users. At the beginning only the bleeding or cutting edge users use the software and provide feedback. Then a larger group of users use the software and provide further feedback. Finally, after all of this preliminary feedback, the new design is integrated into the "stable" release, touching all users and again waiting for users to provide feedback. In this way, critical design changes can be carefully evaluated, refined and released to the appropriate audience. Open Content Projects are community supported and funded projects where content creators use OSS to create content (for instance a short film in Blender, a open source movie 3D animation package). In these projects developers and end users work together to improve the software in the process.

The following are the top 5 methods for discovering usability issues provided by subjects in the study:

• Paying attention to what is asked, discussed or requested in primary communication channels (i.e. IRC, mailing lists, and forums)
• Through bug reports (i.e. Bugzilla)
• By discovering what doesn't work for them as they develop the software
• Via "reference users," or "bleeding edge," users who try out the latest nightly builds, as well as professional users who take full advantage of the capabilities offered by the software
• Through informal observations of friends, family and other colleagues

The following are the top 5 methods for addressing usability issues:

• Discussions via primary communication channels (i.e. IRC, mailing lists)
• Seeking feedback from mock-ups, prototypes and custom builds from others.
• Drawing up specifications, setting milestones, or articulating visions
• Via dedicated usability people
• Use of Human Interface Guidelines (HIG)

FOSS usability practices differ from traditional usability practices in a number of respects. The motivations for getting usability right in a OSS project are much different compared to getting usability right in a traditional closed source model. In the closed source model, getting usability right means growing the user base which in turn means more revenue and profit. This same motivation, however, isn't seen in many OSS projects, as improving usability will increase the user base, increase the number of feature request, problem reports and tasks that the contributors (many of whom are volunteers) don't enjoy as a task. In addition, certain practices in traditional usability are too costly for many open source projects, such as formal usability testing in a lab.

Usability in Open Source Software Development : Opinions and Practice looks into what contributor's opinions and knowledge of usability are. It then evaluates how open source usability is being practiced. They find in the study that OSS developers are interested in usability, as they can understand why getting usability right will allow them to win the war against commercial closed source applications, some of which have exceptional application usability practices. On the other hand, in practice usability is not a top priority compared to other technical issues that are more quickly to be addressed.

The study begins by performing an online questionnaire survey which asked contributors of a variety of OSS projects questions which explored the topics of: "About your current project,", "Communication," and "Usability." The questionnaire survey had a combination of quantitative and qualitative questions to get both easily analyzable result data as well as rich descriptive data that only qualitative data can provide. They then used the results of the questionnaire survey to provide guidance in planning a personal face to face interview with a sample of those who completed the questionnaire. Finally, they interviewed usability evaluators from a usability firm who works with open source projects on a regular basis.

The presented several surprising results for the researchers around the themes of OSS Contributors, Opinions about Usability, The OSS development process and finally Usability Evaluation methods in Practice.

Firstly, they found that the motivations participating in a OSS project were for a variety of reasons, however the five most popular reasons provided include:

• To strengthen free software
• OSS development is intellectually stimulating
• Improve skills of contributors
• Community reputation
• Professional Status

The opinions about usability from the open source community can be viewed in several different lights. We can look at how the open source community defines usability and compare it to how the field is defined. The interviewers asked open source contributors to define usability and have found that most of them (about 85%), use definitions which have to do with the effectiveness, efficiency and satisfaction aspects of usability as defined by ISO-9241. Therefore, it would seem fairly to conclude that open source contributors have an understanding of what usability is. Another way to view this theme is to consider how open source contributors rate usability as a priority. The survey found that a large majority of open source contributors see usability as a high (17%), very high (37%), or extremely high (29%) priority, with only 13% seeing usability as a moderate priority, 4% of contributors seeing usability as a slight priority and no participants seeing usability as having no priority. The conclusion that we can draw from this theme is that open source contributors feel that usability matters, as they both have an understanding of what usability is, and would rank usability as a priority.

On the other hand, their views on usability do not reflect how usability is practiced in many OSS projects. Usability experts are treated as advisors to a project likely because the community is afraid that they may dictate how things should be done and developers tend not to like to be told what to do even if it may be advice from a usability expert. In addition, while many developers felt that usability should be practiced from the beginning, there was a nearly equal proportion of developers who felt that usability could be performed iteratively, at the end of a development cycle, or during the testing/quality assurance part of the development cycle. However, it is well known that usability is not something that can be bolted on at the end of a project, but needs to be considered at the beginning as that will help dictate what functionality and features are needed to help support the way end users work. Moving usability further down the development cycle will only make costly redesigns more likely. Finally, in terms of evaluating the usability of their projects, the Open Source community appears to be far behind the industry in terms of practice. In the questionnaire completed by members of the open source community, the study found that 79% of respondents answered that they followed common usability conventions (i.e. "common sense). Less than half of all respondents answered that they used expert inspections, but were rarely performed by usability professionals. Furthermore, 21% of respondents have used remote usability in the past, which can be useful, but not as useful as performing usability evaluations in a usability laboratory, which only 8% of all respondents answered they performed.

The paper goes on to make many recommendations and discusses some notions about the open source world, and whether the data supports these results. One of the most surprising recommendations that it makes is to separate usability issue tracking from bug reporting. Currently, technical bugs (i.e. feature does not perform as specified), are clumped together with usability issues (i.e. the label of this menu item is unclear) in a bug tracking system (i.e. Bugzilla). However, as discussed in the previous days readings, these systems tend not to be designed for the complicated and nuanced nature of usability issue reporting. In addition, if developers had a choice between solving a technical problem or a usability problem in their bug tracking database, chances are they will fix the technical problem, as the usability issue is seen as being unexciting and less important in their eyes. By separating these two systems, developers will be forced to think about these two problems in different contexts. On the other hand, by not integrating bug tracking and usability issue tracking together, developers may not even be aware of, or track usability issues on a day to day basis. Perhaps one could develop a usability issue tracking system that integrates seamlessly into a bug tracking system, but that separates these two different concerns (technical bug reporting vs usability issue tracking).

Finally, the paper How Power Users Help and Hinder Open Source Bug Reporting, explores Mozilla Firefox bug reporting data since the Netscape days (all the way back to around 1994). The report categorizes people who use bug reporting systems into four types of people:

1. Core - who represent module owners, super reviewers and release drivers or managers
2. Active - who are people who report bugs and have been assigned to at least one bug
   
3. Reports - a contributor who reports at least one bug
4. Users - people who comment on bug reports and attach relevant files relating to an already reported bug

It took a look at how bugs were resolved. In most bug reporting systems, the following are common ways in which bugs can be resolved:

• Duplicate reports - the bug has already been reported in some other bug report
• Incomplete - the bug does not contain enough information to look into the issue
• WONTFIX - issues the community has decided not to fix
• Invalid reports - identify a problem that the project is not responsible for
  
• WorksforMe reports - did not involve a problem
• Fixed reports - leads to a change in the software (patch)

The paper seemed to be very data intensive which makes it difficult to summarize the findings precisely. Rather than discuss individual data points, I will move on and discuss what the results of the data collected means for the community. The study found that the "most effective," bug reports (if we define effective as the highest proportion of bug reports that resulted in fixes) was found in the active and core group. As you may recall from a previous reading, core and active users tend to be significantly smaller than the larger user population. The study found that 60% of all bug reports submitted by core developers resulted in fixes, compared to 13% of all reporters. In addition it also found that reporters mostly reported duplicate reports, sometimes even on bugs currently in the process of being fixed or that have recently been fixed. The study also found that bug reporting systems were used for more than just their obvious (stated) purpose. Some reporters for instance would use bug reporting systems to express their frustration over a particular bug, or to support a fellow reporter's argument of the existence of a bug (i.e. reporting that this happens to me too). It is also frequently used as technical support for users who may not be aware of a particular feature, or who may have difficulty in using a particular feature. At first one may be afraid that a good chunk of all bug reports may not be acted upon, and that the raw quantity of reports may have some impact on the effectiveness of resolving and discussing bugs and the bandwidth. However, the study found that if you split up all the bugs reported over the time period of interest (11 years), then you only have an average of 1 reporter report per developer every 50 days. Therefore, while the number of bug reports may seem to be large, and while it may seem necessary to take measures to stem the flow of bugs reported to avoid information overload, this is not the case seeing as there are 3,500 core+active developers total plus this is over the period of 11 years. Therefore suggestions such as making bug reporting mechanisms more approachable to everyday users (for instance removing the registration requirements and tedious tasks that "average," users have to go through to begin reporting bugs), may be a valuable suggestion, especially if it can be shown that the community bandwidth is not being wasted by excessive reporting.

Day 13 Readings

Today's readings discuss how usability issues are discussed in the open source community. These readings include the following literature:

1. Usability Discussions in Open Source Development
2. Silver Bullet or Fool's Gold : Supporting Usability in Open Source Software Development

The first paper, Usability Discussions in Open Source Development, looks into how members of the open source community discuss usability issues for the projects that they are part of in some way. In particular they look at three different sources for exploring discussions about usability:

1. The Greenstone mailing lists
2. Bugzilla Instances at Mozilla
3. Bugzilla Instances at GNOME

They searched these sources looking for terms such as 'usability', 'human computer interaction', 'interface', and other relevant terms. Then they filtered out results that had nothing to do with usability, and analyzed the resulting data set, which contained discussions about usability in some form or another. While the way in which they explored how usability issues were discussed in the Open Source community was crude, it provided a preliminary look into the question of open source usability in practice.

An interesting observation that was made during their study provided a glimpse into why usability issues are so difficult to resolve. Firstly, usability issues tend to connect with many other issues (usability or technical), and as a result in order to solve a usability issue you tend to have to tackle several separate but related issues as well. Secondly, it can be difficult for the many contributors of a OSS project to consistent apply and follow usability guidelines (implicit or otherwise). In addition, some OSS projects lack a set of usability guidelines to follow. In any event, not following usability guidelines results in a less consistent user experience, which in turn affects usability. Thirdly, the nature of usability issues requires other concerns to be considered before a usability fix can be approved. Fourthly, the text centric nature of many bug reporting tools can limit the how expressive a contributor can be to describing usability issues, especially if the description is non-trivial. Finally, a lot of the contributors to OSS underestimate the amount of effort that workarounds require to solve areas in which a particular OSS is lacking. For instance, some may argue that a particular feature need not be added into their OSS project, as a plug in already exists even if it requires users to be aware of the plug in and know how to find and install it.

Let us now consider how usability issues are expressed in online systems. Some usability problems can be easily explained textually, for instance suggesting that the wording of a menu item be changed to something else is something that can be suggested in a bug tracking system such as Bugzilla simply. However, not all usability bugs can be easily expressed/reported in this fashion and so another level of expression in reporting usability issues is the use of annotated screen shots to provide a clearer contextual referencepoint to the issue being reported. Privacy issues need to be considered when using screen shots to report usability bugs, especially if the screen shot contains identifying information, in which case screen blurring techniques are used by those technological savvy enough to do so. Another medium that was looked at in the study was the use of ASCII art to represent design ideas in a text only communication medium. What was surprising about the article was that they noted that there were no light-weight hand drawn sketches in the sampling of the usability issues they looked at. This is in stark contrast to contemporary usability design, where designers typically sketch out their ideas free hand in a sketch book and use the rough sketches as a medium to consider design choices in a design space.

There are two types of usability bugs that are out there, the authors of the paper claim, namely, subjective and objective usability bugs. Objective usability bugs are those reported that can be described using static mediums (screen shot, textual comments) which most people would agree is a problem. The only disagreement that occurs is how exactly to fix the problem. On the other hand subjective usability bugs is whenever a usability issue is experience by one person but is not experienced by the community or alternatively when the community notices a usability issue but the creator does not see it as being an issue. The paper goes on to argue that in the case of subjective usability, when there is no consensus between a group of people about whether a usability issue in fact exists, that user testing should be applied. Allowing developers and the community to observe user tests helps quantify and objectify what is otherwise an entirely subjective issue. Bug tracking tools such as Bugzilla have a bug status called, "WORKSFORME," which is used to mark such subjective usability issues. Resolving subjective usability issues therefore is of high importance to the OSS community as it is the hardest type of bug to truly identify whether it is something that needs to be resolved.

What is needed, therefore, is a way to manage the inherent complexity that arises from reporting and discussing usability issues. One aspect where complexity can be better managed is in the area of categorization, in particular in preventing the duplication of usability issues being reported to a OSS project, as the number of usability issues reported can appear to be misleadingly high due to this. Secondly, it is important that the usability reporting system only contain one issue, rather than the multi-issue reports that are seen in many bug tracking systems. Complexity can also arise whenever you layer additional levels of usability testing methods, and so OSS projects need to carefully plan how they will manage the complexities that each usability method adds in return for the many benefits that they provide. The precedent of how usability issues were solved in the past should be formalized in guidelines to ease future usability issue reporting as well as to maintain consistency in the application of usability decisions in a OSS project. Falling back to precedents rather than rehashing the same old arguments will reduce the amount of time needed to discuss and resolve each usability bug on average, and so reduce the overall complexity of usability bugs under consideration. Finally, the complexity of usability issue reporting and solving can be reduced by several orders of magnitude by carefully planning thinking about how resolving a usability issue will interact with other components of the software. In fact many usability issues when solved, will cause other usability issues to appear. Probably the best way to reduce this type of complexity would be careful planning in the first place to prevent usability issues from being committed to code, especially if the code interacts with many other components in some fashion.

I'd like to close discussion about this paper by looking at one final aspect that was discussed in the paper, namely that conventional bug report design may be insufficient, especially if the discussions surrounding a interface are particularly complex. Usability issue reporting is not always a linear process, and may require engaging many parties on many different types of discussions and thought processes when discussing usability issues. This is different from reporting functional bugs in software.

The second paper, Silver Bullet or Fool's Gold : Supporting Usability in Open Source Software Development, was in fact an abstract to a talk given about the dynamics of OSS development, and how it is different from contemporary usability practice in closed source software environments.

Day 12 Readings

Today's readings pick up on the topic of usability in the open source projects and approaches the issue from an academic paper on the issue, as well as a blog post about how open licenses can affect usability.

The papers for today's readings are:

• Usability and Open Source Software
• How Open Licenses Affect User Experience

The first study, looks into how usability is perceived and practiced in the Open Source community. It is important to realize that the Open Source community is a generalization, and while there may be examples of poor usability in the Open Source community, there are certainly examples of good usability practice in the usability community as well.

In any event, what is usability? The paper provides a definition, which many in the industry use, namely: Usability is typically described in terms of five characteristics: ease of learning, efficiency of use, memorability, error frequency and severity, and subjective satisfaction (def'n from Jakob Nielsen's 1993 book : Usability Engineering). It is from those five broad characteristics where we can collect qualitative and quantitative data based on representative metrics that support those goals where formal usability studies come from. The authors mention several common usability techniques in practice, namely: usability inspection methods, interface guidelines, testing methods, participatory design, inter-disciplinary teams, etc. (again drawing from Jakob Neilsen's 1993 book : Usability Engineering). In addition, it is important to note that there is no such thing as an, "average," user or alternatively a, "power user." Typically most people are slightly different than average (for instance they may have a disability or be taller or shorter), and so grouping the majority of people into a category which represents only a small minority of users is misleading at best.

There is a growing consensus in the OSS community to make OSS approachable to more people not just hackers, the authors claim. Attempts have been made in many OSS projects to make usability a priority, albeit many of these usability efforts have not reached its full potential the authors claim. The authors then discuss some of the approaches currently in use by the OSS community, in general, as well some of the factors that make some OSS unusable.

In any event, the study mentions that an approach for testing the usability of OSS has been to perform comparison tests between the OSS and the name-brand commercial closed source software (such as Eklund et al.'s 2002 study comparing StarOffice to Excel). The problem with this approach is that such comparisons are imperfect at best. Furthermore, many OSS projects tend to copy the state of the art in commercial software to entice users of closed source software as they don't have the resources to do innovative interaction design. As a result, interfaces are rarely improved upon, and never provide innovation in interface design that put them ahead of these closed source software companies.

The authors go on to claim that not all OSS is unusable, there are many projects that adopt contemporary usability techniques (such as OpenOffice.org). Furthermore, there is no consensus on whether there is a systemic usability issue in the OSS ecosystem.

However, that being said, there OSS community has its own rotten apples for usability. Rather than just bashing the OSS community, we must understand what causes usability to take a backseat in software development for us to better understand what changes need to be made to improve the state of usability in such projects. Firstly, developers are designing systems for themselves and their peers and not so much for less savvy users (i.e. scratching a personal itch), whereas commercial systems development is usually about solving the needs of another group of users. Secondly, poor usability habits are formed overtime and become conventions other use. Thirdly, trends in OSS usability are lagging behind proprietary software systems - many OSS projects are playing catch up with their closed source rivals. Fourthly voluntary open source software (aka VOpen Source Software), doesn't have the resources to hire usability experts unlike commercial software companies.

There are additional constraints that usability tends to impose on all types of software development. Understanding how these constraints clash with the OS culture, and style of work can also explain why many OSS projects are so hesitant about making usability a priority. Firstly, the nature of usability requires a very subtle, details oriented outlook to development, that takes into account the behavioral aspects of design, which is quite different from the skills required for a programming challenge that many developers are familiar with. Secondly, usability problems tend to be harder to describe, harder to fix incrementally (which clashes with the Release Early Release Often mentality of OSS), and may require large overhauls. Thirdly, unlike software development, adding more people to usability design tends to make the design less coherent. Fourthly, getting usability right means that design and careful planning must be considered before writing even a single line of code. In fact it has shown to be faster and more productive than the heads first development approach found in many OSS projects. Finally, usability requires a level of care to be provided to the aspect of simplicity. However, Open Source solutions tend to stress technical competency over simplicity, as many open source projects seem to only be adding functionality and not taking away older or confusing functionality. As a result many open source projects tend to have increasingly complex interfaces due to rapid featurism. There are several social factors why features are not simply being removed from OSS, for instance "saving the face" of other fellow developers. The last thing the community wants to do is alienate contributors by making their efforts and contribution vanish. However, without removing the clutter and simplifying the software, many OSS software has too much choice, and too many options to confuse the user with.

The paper goes on to discuss inherent advantages that OSS projects have over their closed source counterparts. Since end users are involved in the development of OSS this can lead to more direct usability improvements. Some methodologies of OS lend itself well to usability (for instance hashing out ideas quickly through release early, release often). In addition, the large distributed nature of OSS lends itself well to usability studies, especially in studies where you need a significant amount of user data collected (i.e. high sample size for study population).

The potential usability techniques that can be readily applied to make a difference in the usability of OSS projects was another area of focus of the paper. Firstly, OSS projects can run automated tools for testing such things as consistency, user expectation and other instrumented sources of data on a regular basis to catch obvious usability glitches and correct them. Secondly, the academic community, more precisely students studying usability could contribute to improving the usability of OSS. In addition, this would provide the usability student with real-world experience in solving usability problems. Thirdly, it mentions that end-users can be better engaged in reporting usability issues by creating a tool that would allow them to report usability issues without having to: register, navigate to a particular site, or understand the complexities of a separate bug reporting tool. It points to Microsoft Windows XP and Mozilla's built in reporting agent for reporting bugs/crashes back to the manufacturer. Fourthly, it mentions that having pre-packaged usability tests (such as performing a particular task in the software) built into software which users can run and which the results are published back to OSS projects would also be beneficial. This would mean that open source projects would finally have a large enough sample size to conduct more formal usability studies. It is important to note that the contributions of the end user via the third and fourth suggestion must be recognized and appreciated by the community, as well as for the contributors to see how their suggestions are affecting the OSS for the incentive for end-users to contribute to be there. Fifthly, and most interestingly is the idea of creating a usability discussion infrastructure, through the use of ASCII art, sketching, annotation and other contemporary techniques for expressing design ideas. These tools must be readily approachable to the wide community as a small amount of extra effort is enough to deter users from participating.

Another important question that was brought up in the paper was the role of usability experts in the development of OSS projects. Previous papers that have been discussed in the blog have shown that usability experts have either been too heavily relied upon by OSS teams, or alternatively have been marginalized by the OSS community. Usability expert must clearly articulate what it is that they are doing, and how it helps the project. Otherwise the technical meritocracy of most open source projects will not appreciate the seemingly non-technical contributions that this group is making to the community. In addition, usability experts should be the advocate of the end user, to ensure that end users and not just "expert users," are having fair representation in the project.

Beyond the discussions of potential tools for improving usability, how usability experts can better situate themselves in an open source projects and other surface level improvements to usability in OS, the authors make a more fundamental suggestion for how usability can be improved in OSS. They argue that OSS projects must learn that usability is an important issue if they want a huge user base which is an inherently motivating factor for contributors to OSS. No longer can the shared understanding of usability in the community be seen as a nice to have, and something that doesn't take rocket science to get right. The community must learn more about usability and be more receptive to ideas and suggestions that improve usability. Developers and the technical community that supports OSS projects must be taught social skills to make usability experts and end users be welcome and embraced by the community. End users must be seen as first-class citizens in the community, and not be relegated to slaves that depend on the fruits of the technical elite.

The second reading, How Open Licenses Affect User Experience, is a blog posting by the professor of this seminar. While on first thought it may not seem apparent that different licensing models affect the user experience of applications, the author claims, the rights and freedoms granted under certain licenses can have unexpected effects of not only the software ecosystem, but the user experience (part of which is perceptions the user makes about the software).

The author argues that open licenses lead to:

• Greater choice and variety in software for end-users
  
• New types of workflows (uses of software), namely:
• Temporary Domain Experts who learns enough just to solve a particular problem with the tool
  
• A La Carte Computing where users are focused on using the tool just to get a particular task done occasionally
  
• The Trivial Use of "fat" apps which would be using a minor feature of a feature-loaded software to get "trivial," task done
  
• Software as a communication medium for ideas
• Increased collaboration through the use of a shared computing environment

The reason why greater choice and variety in software end-users arises from the forking and customization that open licenses afford. For instance there are hundreds of Linux distributions available due to the freedoms that the open licenses Linux uses affords. The reuse of open source libraries in projects means that many projects use the same underlying components as others. Finally, while commercial closed source applications leave the software ecosystem as soon as their parent company disappears, open source applications can live on for perpetuity.

The implications of all of this choice for end-users can be good and bad. On the one hand providing end-users with much choice means that knowledgeable and informed users have a broader selection of tools which they can select from to suit their needs. However, many end-users may not be so knowledgeable and so all of this choice may confuse and make it more difficult for the user to decide which solution is best for them. In addition, the lack of a price tag found in many OSS projects as well as it being difficult for users to perceive the reputation and commitment to the software, removes many common measuring sticks which end-users would normally use in evaluating software. As a result, users will evaluate software based on an ad-hoc selection criteria, in particular first impressions. Therefore, OSS projects must focus on the first impressions of the software and its surrounding project, and developing their solution to make the first impression be positively memorable (i.e. easy to discover and learn how to use the software).

FOSS is also being used as a communication medium. For instance many ideas are being conveyed using a free programming language, such as R. The interactivity that these free solutions afford in expressing ideas (such as redrawing graphs as you change parameters in R), allows for a new kind of communication and expression to form. However, in order to communicate ideas through these mediums, typically software needs to be installed on one's computers (such as R), which means that the installation of applications must be as easy as possible.

Finally, FOSS can support active collaboration through the use of a standardized computing environment which virtual machines afford. The author mentions that he uses virtual machines in his course which contain OSS to standardize and remove the issues that typically occur when you have many students that are all running different computing environments. In addition, the "openess," of open source should afford a type of collaboration that is difficult to find in the closed source world.

Day 11 Reading Summary

Today's readings started looking at how usability fits into the open source community, and considers several case studies where usability is being applied to popular OSS project (such as GNOME). The readings are:

• Getting to know you: open source development meets usability
• Professional usability in open source projects: GNOME, OpenOffice.org, NetBeans
• Why free software usability tends to suck
• Why Free Software Has Poor Usability and How to Improve It
• The Luxury of Ignorance: An Open Source Horror Story
• The Luxury of Ignorance: Part Deux
• Daring Fireball : Ronco Spray-On Usability

The paper, Getting to Know You: Open Source Development Meets Usability, introduces a new track of study in the SIGCHI 2002 conference, which is around the issues of usability in the open source world.

The paper begins by reiterating the point that most Open Source endeavors are a form of Computer Supported Collaborative Work (CSCW), as contributors are scattered across a wide geographic area, and use computer tools to aid in communication and co-ordination. In fact the open source community is likely the largest community using CSCW on a daily basis and to an extreme degree. The study of usability in such a large CSCW community is of particular interest to the HCI community for several reasons. Firstly, it tells how the development of products occurs in non-hierarchical organization which doesn't have geographical boundaries. Secondly, usability practitioners can study a community which contributes their time in many cases free of charge for the development of products, and what impact that has on issues such as the quality of products. Finally, the benefits and potential costs for making product development follow a participation chaotic and open process to product development, can be better studied.

On the other hand, the Open Source community has much to learn from the HCI community. For one thing, as the value of open source software begins to be realized by corporations and the adoption of open source software starts, usability becomes an increasingly important topic. While the open source community tends to be enthusiasts that can handle the eccentricities of OSS projects, corporations are less patient when usability issues arise. In addition, due to the chaotic nature of OSS projects due to the lack of hierarchy and control structures makes coming to a consensus on a wide variety of issues difficult. By applying HCI methods, a set of goals and priorities can be formed from these tools that provides a basis for sound design in the future. HCI methods therefore can become the standard by which the meritocracy of the community use in evaluating designs. There are challenges in educating the open source community to appreciate these concepts. Likely the most important thing that the OSS community needs to learn more about is that there are people out there that can help them with usability .

The article argues that there are three sore spots in usability in the open source world, namely:

1. Lack of systems that are usable by ordinary people
2. Lack of application of consistent usability principles across contributors
3. Lack of attention to accessibility issues in OSS

The paper, Professional Usability in Open Source Projects studies the contributions that Oracle/Sun (formerly Sun Microsystems) made to three projects : OpenOffice.org, GNOME and Netbeans. In addition, it also discusses the usability challenges that these three projects face.

The OpenOffice.org project is an open source spinoff of the Sun Microsoft's Star Office. The OpenOffice.org project has access to the StarOffice User Experience team which the author claims includes professionals from all fields of HCI. Formal user requirements for future releases of StarOffice/OpenOffice come from several sources including:

• Sun's Marketing Team for Business Requirements
• The OpenOffice.org Bug reporting system provides a venue for the Open Source community's requirements

The design and specifications for future releases go through a formal iterative process which engages the community through several mechanisms (such as newsgroups, community events, etc.) The author's don't seem to express any weaknesses as far as usability is concerned in the OpenOffice.org project, which seems troubling as any usability project can be improved

It makes the controversial argument that providing usability know-how to OSS projects leads to usable and used products which in turn is beneficial for developers, corporations, and users. However, there have been several studies which have shown that many developers in OSS projects see usability as a disincentive for writing applications as they have to field questions from beginners, and accommodate a group of users which don't represent the user base that the developer created the project to, "scratch an itch," for.

The usability of GNOME is another area where Oracle/Sun has contributed its resources. One of the major contributions and advancements in usability the paper argues was the adoption of Human Interface Guidelines (HIGs) and the establishment of the GNOME Usability Project (GUP). As a result, the paper argues, usability many usability bugs in GNOME have been caught and addressed. Accessibility technologies have also been added to GNOME which in turn makes GNOME approachable for those with various disabilities. Finally, documentation has been improved over time and translated to several different languages so that developers and users a like have reference material for using GNOME.

The challenges that still face GNOME, the author argues are:

• An approachable communication medium for non-technical contributors
• The GUP doesn't provide consultancy for applying GNOME HIGs to their applications which can cause an inconsistent user experience
• The vision of GNOME's target audience is not well documented.
• Lack of application of a rigorous usability process
• Many OSS developers don't contribute to the usability aspect as they feel Oracle/Sun can pick up the slack

Finally the Netbeans project is an Open Source Java IDE. The author claims that Sun performs regular usability studies of the program, with usability issues being given equal priority to functionality bugs. In addition, to usability studies they also created usability guidelines for the development process of the project. Beyond the functional usability aspects of the project, the graphics assets of the project are also evaluated for usability as well. Finally, accessibility and localization of Netbeans to several languages also means that the software is more usable for those with disabilities or who communicate in different languages.

The biggest challenges of Netbeans the author argues are:

• The lack of a unified communication system (currently scattered between mailing lists, and bug reports)
• Are we targeting and engaging our audience through appropriate mechanisms (i.e. mailing lists)?
• A lack of ownership for functionality, as both developers and designers contribute

The paper also makes the argument that Open Source projects should lend themselves more easily to usability techniques. Indeed the cathedral method of development encourages quick and often iteration over careful monolithic, "cathedral," design. Iterative prototyping techniques, for instance latch on the cathedral development philosophy. Nevertheless, making usability techniques approachable to contributors whose incentive is to contribute some of their spare time to causes that they find fun and interesting will be an important factor that needs to be considered when determine how to make usability more approachable and applied in the Open Source community.

Why Free Software Usability Tends to Suck is a laundry list of usability issues that the author notes in open source projects, and include the following:

• Few non-paid dedicated interface designers, who tend to be less experienced
• Every contributor to the project tries to do interface design, which leads to inconsistent vision and detail of design
• Dedicated interface designers are given less weight in OSS projects as many don't know how to contribute patches and may lack the technical skill the meritocracy seeks
• OSS projects copycat Microsoft,Apple and other proprietary software companies that may have poor design and which leads to a lack of usability innovation
• The software is designed for power users as it is made by power users
• Minor details (such as fine tuning error messages) are ignored by developers as they are seen as unsatisfying to work on
• Many features and capabilities are options hidden away in preference dialog boxes due to disagreements that occur between contributors, as well as for credit
• Releasing early and often means that the community experiences buggy, slow and unusable systems, which causes users to push back the proposed changes

The article, Why Free Software has Poor Usability and how to Improve it, is a follow up article by the author of the prior article, several years after the article was written. The author argues that while some minor incremental improvements in usability have occurred over the years, usability still needs improvement.

Suggested improvements to Open Source usability the author argues are:

1. The Open Source community needs incentives for making software usable, much like proprietary software companies have the incentive of increased revenue for usable products.
2. Have developers learn the principles and concepts of usability.
3. Create roles in FOSS projects specifically to handle usability issues.
4. Make design suggestions have equal footing with code patches
5. Implement concrete usability measurements that can be monitored over time
6. Incorporate frequent user testing
7. Get the design right before getting the code right ; don't make design be an after thought
8. Interface design should be conducted by dedicated professionals who can create a consistent user experience
9. Innovate in design - don't copy others who may have usability issues of their own
10. Encourage simplicity in design as opposed to a design suitable for power users
11. Focus on the small details of interface design, they really make all the difference
12. Use strong project management to remove the option overload found in OSS projects
13. Find alternative mechanisms for giving contributors credit than adding items in options dialog box
14. Use high bandwidth communication mediums for discussing design (such as VoIP, virtual whiteboards,etc.), as design is a rich medium.
15. Make user's expectations resemble final product expectations when releasing early and often
16. Test modules/components against a variety of different use cases, so that it can integrate better with front-ends
17. Increase co-ordination and communication across project and team boundaries

The article, An Open-Source Horror Story, discusses Eric Raymond's difficulties in setting up CUPS (Common Unix Printer System), to connect to a networked printer in his house. He attempted to install the printer in what seemed to him to be an intuitive way (Selecting System Settings -> Printing). He then proceeded to add a printer queue as it would seem to him that he wanted to add a printer. However, as he later discovered the way the developers implemented the system, you are supposed to join an existing printer queue rather than add one. In any event, he mentions that when he proceeds to the next screen of Add New Printer Queue it presents him with a variety of different options, that seemed confusing to him, as well as to a beginner user, he feels. When he attempts to access help, the context sensitive help only discusses adding a new local printer, and not the actual problem he was trying to solve (add a new networked printer). The story goes on to discusses what he feels are less intuitive things, such as fields filled in by default but which have no meaning to the, "typical user."

Eric Raymond's central argument in this article is that while open source usability is improving, it still seems focused on the style of what is archetypically considered usable software (i.e. GUI interfaces, online help,etc.) He argues is that what the Open Source community needs to think about is the substance usability. Part of this he argues, is putting themselves in the shoes of novice users. Novice users, he argues by definition won't understand the technical jargon that is found in many OSS projects, and frustrated will stop using OSS with the perception that all OSS is hard to use. Other things that he felt OSS lacks include discoverability, as many features and capabilities are hidden away or are made to not be the default option. In addition, local documentation is lacking, and one tends to need to Google the solution, which in turn may contain pages with half-solutions and half-truths in them. He goes on to make the controversial remark that if you want to make software for novice users, the users shouldn't (and likely won't) consult the user manual to complete the tasks they want done.

The Luxury of Ignorance Part Deux, is another article by Eric Raymond where he reviews the community feedback that he received several days after he published An Open Source Horror story. An interesting aspect of the article is that the author claims to have received many e-mails from readers more or less saying, "Gee. And all this time I thought it was just me...". This implies that there many users have pent up frustration with many OSS tools, but never act on their frustration, namely making more public that the problem is not with them, the user, but rather with the system and the way in which it was designed.

The e-mails that Eric Raymond received included many users (from beginner Linux users to veteran UNIX user of 20 years), which each discuss a frustration that they have in using an aspect of OSS. Some have hinted that they were thinking of switching back to proprietary solutions are they are easier to use. Many of the writers discussed the time spent (and arguably wasted) trying to figure out how to setup something in Linux. Others argue that Linux users should not be embarrassed or, "flamed," for having difficulties using Linux, and that these complaints ought to be taken seriously. Finally he argues that it doesn't matter who is at fault for these usability issues, but what matters is that these usability issues be fixed.

Finally, the article Ronco Spray-On Usability is a critical review of Eric Raymond's Open Source Horror Story, as well as to further satirize Eric Raymond.

The review of Eric Raymond's Open Source Horror Story, begins by arguing that Eric Raymond's insistence of having developer's put themselves of the shoes of Aunt Tillie (a novice user) is dangerous. For one thing, he argues, how many novice users want to setup a shared networked printer? More often than not, he argues, they will want to connect to a locally attached printer. The central theme behind this is that the novice user may very well have different typical use cases and scenarios than a power user, and hence one should study how people actually use the system. This is in stark contrast to asking, "How do I make this feature easier for a novice?" What was interesting he noted was that non-novice users (i.e. power users) were having difficulty completing many tasks in OSS, as they have mentioned in the e-mails sent to Eric Raymond, even though they thought that they were the only ones experiencing those types of problems.

He makes another important argument which is that user-experience, and user interface design aren't something that you just spray on a technically competent solution. He mentions several times that in Eric Raymond's Open Source Horror Story, he mentioned that UI design, was not, "rocket science," or difficult. He implies that the hard part (getting the low-level technical development correct) has already been done and all we (the community) need to worry about is strapping on an easy to use user interface. However, as everyone in the HCI community knows, this isn't the right way to get user experience right. In fact techniques such as Contextual Design, are processes where the low-level and high level design of a solution are built around the needs of users.

Another particular reason why Open Source usability is not done well is the fact that in most open source development projects, people are not paid or compensated for their work. However, it is a well known fact that good user interface design is the result of long, hard work by talented developers and designers. Having many developers and designers work part-time on a project creates a lack of focus and consistency in user experience. In fact many open source supporters are switching over to closed source solutions due to these frustrating technical problems for which the closed source community got right!

Finally, he ends by discussing the engineering adage, that you can build something that is, "fast, good,cheap : pick two." While Linux is both fast (release early, release often) and cheap (low cost to free), it is not good. The fact that Linux is cheap may appeal to Wal-mart shoppers and people who are genuine cheap-skates, most people are willing to pay for the luxury of ignorance (i.e. good systems). This is precisely the market that Windows and Mac OS X serve (fast and good) and why Linux is struggling to overtake these two proprietary solutions.

Day 10 Readings

Today's reading includes a look into the socialization of open source software projects from a dynamic perspective of networks and micro and macro sociological issues surrounding such projects. The reading is titled:

• Socialization in Open Source Software Community : A Socio-Technical Analysis

In the paper, the author argues that while open source software projects have been studied for a long time, the majority of such studies were in one of two camps. In the first camp researchers consider sociological aspects of participating in open source software projects, such as what incentives are there for people participate and contribute to OSS projects. On the other hand, there are a camp of researchers who are solely interested in the technical implications of OSS projects, such as the defect density of OSS projects versus commercial software projects. The author's work looks into both the sociological and technical aspects of OSS projects to form a more nuanced understanding of the dynamics of OSS projects.

Beyond studying the socio-technical aspects of OSS projects, he also applies several new viewpoints to research in the field. Firstly, he considers the socio-technical aspects of OSS projects from an ethnographic prospective, studying how people work in both a micro and macroscopic perspective. For instance, while a lot of research has looked into the aggregate statistics of a OSS project, few have studied how individual entities evolve, communicate, and belong in an open source community. Secondly, he considers the evolution of an open source community, namely the Python project, in several different dimensions (such as evolution through time), in a dynamic manner. This is in stark contrast to prior work which has simply looked at fixed, or "static," moments of time (for instance the CVS snapshot ending on a certain day). Finally, and most importantly he treats an open source project as a collection of networks as defined by Bruno Latour's work on actor-network theory as opposed to the conventional research view of open source communities, which are simply individuals who can be classified and placed into one of many layers people and resources that make up an OSS projects.

The author goes on to discuss software that he has created to aid in the ethnographic research that he conducted on the Python project. The software has been designed to expose the hybrid networks that form in an open source project, such as between people and people, as well as between people and artifacts, and other entities that exist in an OSS project. It was also designed to offer the ethnographer a dynamic perspective on activities in an OSS project, and allow for observations and information to be tracked over time. Since studying OSS projects leads to information overload and difficulty in analyzing trends in OSS projects, the system also allows for data to be aggregated while at the same time preserving the referential data. Finally, the system allows for not only the study of macro phenomenon, but also the ability to track a participant in the OSS project. It then goes on to demonstrate the software in action, for the python project, noting how the software's capabilities allow for a more in-depth study OSS projects to be conducted.

The author goes on to explore the Python project from a socio-technical perspective apply ethnographic techniques as well as the software to analyze this particular project. Python is a fairly old, large, mature and successful OSS project, which he claims represents one end of the OSS project spectrum. One aspect that the study considered was the mail archive of the python developer's mailing list and the CVS source tree for the project throughout the year 2002. We have seen in previous day's readings that this is a common data source that OSS researchers look at. It is from this data that the study was able to confirm the findings of similar studies in the technical aspect of OSS proejcts (for instance that a small number of developers make up the largest proportion of contributions). However what was interesting about the paper was that the author sampled a small portion of the python community to better understand OSS projects from a micro level.

The paper comes to an important discovery, by my interpretation, which is that open source communities rely on a networks of trust. Since members of a particular open source community are in essence strangers from around the world, trust is an important element in determining what rights and privileges (such as CVS commit access), a particular member of the community should have over time. The paper argues that members of the community gain trust not only through participation, but also through building an identity and reputation (technical or otherwise), the political posturing (such as building allies), and how they behave in the context of the community. Furthermore this trust cannot be gained instantaneously, but rather over the span of many months or perhaps years. The paper goes on to argue that an open source project has several well-defined routes or trajectories for which a newcomer may follow, and which results in different outcomes. Those who do not follow such trajectories, or who too rapidly assume that they have gained the trust of the general community, are destined to not move forward that far in the community.

The author tells the story of two individuals which he followed.

The first individual, Fred, began his relationship with the python community by asking questions about python to the python development community. It is through conversation that Fred began to build connections with other Python contributors as well as to uncover the structure of the network for which he may join. He then moved on to reporting bugs, followed by attaching potential fixes to these bugs, which in turn made himself recognized as a trusted bug fixer by the community. Finally, he moved on to suggesting that Python include his library in their project.

On the other hand, another member who was studied, David, began engaging the community by posting a simple bug report to the mailing list, without any suggestions as to how to fix it.

One week later, he asked the community to consider a module which he created for the next release of Python, which was promptly rejected by the core members of the community.

Clearly, David did not understand the network and inherent rules that govern this community.

He pushed too hard, too fast for rights and privileges when the community was not in a position to trust these rights to him.

Several other important discoveries were made about OSS projects and communities:

• Contributors are part of a network connecting themselves to different entities (people or otherwise) and that these connections can strengthen or weaken over time
  
• Contributors to OSS projects are rarely (if ever) coached - they bring their technical expertise to the table
• Correcting bugs or suggesting new improvements are areas where conflict can arise in a OSS project which can be critical historical events for a OSS project
• While the open source community likes to claim that their process is entirely transparent, in fact it is not transparent, processes and discussions are often times hidden from the outside observer
• Networks are designed to minimize the effects of radical changes, they must be weakened in some respects when important changes must be pushed through

Finally, the paper goes on to discuss the implications of the software that was developed for the paper (OSS Browser). This software could help people joining an open source effort to better understand the networks and dynamics of the project. This is a skill that many potential contributors lack (see the case of David), but is essentially to begin to build the trust of the community. In addition, the tool could assist in helping these newcomers navigate the political and socio-technical dynamics that are inherent in any organization. These two capabilities, as well as the other capabilities already mentioned that the software offers, could provide the opportunity of project maintainers to better help newcomers understand and assimilate to the project's culture. Currently, the most common ways that a newcomer can understand an open source project are also the most primitive methods - such as electronic mail and newsgroup clients. In addition, by making the structure and dynamics of the network readily available to members of the community, such members can determine who their allies are more accurately than ever before. This in turn could potentially improve the evaluation, debate and potential integration process for additions to an open source project, or alternatively for resolutions to bugs that appear in OSS.

Day 9 Reading Summary

Today's reading included the following papers:

1. Free/Open Source Software Development: Recent
   Research Results and Emerging Opportunities
2. Toward an Understanding of the Motivation of Open Source Software Developers

Let us consider the last reading, as it discusses what motivates volunteers to contribute to an open source project, and furthermore uses a well known model to suggest why participation in open source projects is as large as it is today.

It's people's own interests which determine their role in the project and they can have
one or more of the following several roles, in decreasing order of influence on a OSS project:

1. Project Leader - person who started the project and decides on the vision for project
2. Core members - people involved in the proejct for a long time who guide and co-ordinate development of the project and work together to resolve conflict
3. Active Developers - those who regularly contribute new features and fix bugs
4. Peripheral Developer - are essentially active developers who participate irregularly in development
5. Bug Fixer - fix bugs that they find or that have been reported
6. Bug Reporter - simply discover and report bugs
7. Reader - active users of the system who try to understand how the system works by reading the source code
8. Passive User - use the system much in the same way that most of us use commercial software
   

By far most users of OSS are passive users (for instance 99% of people who use
Apache are passive users), and continues to drop the higher up the role ladder you are
(i.e. there are fewer project leaders than core members). However, many users find a path
that sees them becoming a greater part of the OSS project, for instance becoming a reader
from that of a passive user. A regeneration of the community is important to prevent OSS
projects from dieing due to active members retiring from the project.

A key to success in an OSS project is that there be a large base of members contributing
to the project. An interesting aspect to consider is that as the project evolves, the
roles of contributors becomes more well defined, as you will notice certain contributors have
the tendency to contribute in certain ways. It is through this group discovery of roles
that structure can come to an OSS project. In addition, these roles are not static, members
may switch between roles regularly which conflicts with the traditional development structure
of commercial software companies.

The paper,Toward an Understanding of the Motivation of Open Source Software Developers, goes on to study members of the GIMP community, and their participation in mailing lists and other contributions to the community. Similar to the results in a paper read in the prior
day's readings, the amount of people who contribute to a OSS project, be it in e-mail discussions, or code contributions rises as the number of contributions per person falls. It further goes on to identify which group these contributors are in, and notes that the amount of contirbutions per group is directly proportional to their influence in the OSS project. For instance, a large
amount of contributions made in the GIMP come from core members, who exert a great deal of influence.

It then goes on to discuss the theory Legitimate Peripheral Participation. This theory argues that learners do not learn through being taught but rather through direct engagement in the social, culutural and technical practice of the community. For instance novice users learn more about a OSS project by enaging with veterans in the community who discuss and demonstrate
how the OSS project works. At first, novice users peripherally participate in the community, learning the requisite skills needed to understand the OSS project. However, as they become increasingly knowledgeable and perhaps interested in the project, they take
on an increasingly important role in the OSS project. In other words, as time progresses the participant changes roles to match their increasing competencies within the community. These users in turn will eventually become masters of the OSS project and in turn become
mentours to novice members of the OSS project. This repeating process is what allows OSS projects to regenerate members to sustain progress on the project. The desire to learn, the paper argues is one of the key reasons why people join OSS projects.

Therefore people become part of an OSS project because they want to learn more about a particular technology or solution. They may also want to gain reputation and credibility within the community through evolve through ever increasing roles of influence. Finally, the OSS community that successful OSS projects have, allows for high quality software to be developed and supported.

If you want to encourage learning and participation in a community ideally you want to have a transparent process where the entire development community is part of the discussion and decision making, as well as a open development process where everyone in the community can access the same sort of resources as other roles in the community. However, there are downsides to having an entirely transparent process, for instance it may be difficult
to control and manage an OSS project. Therefore one must balance the interest of community learning and participation with the need for managability and control.In any event, one should strive to build community within their OSS project, and people in various roles of an OSS project should make themselves available to the community for the community to grow and regenerate over time.

The first paper, Free/Open Source Software Development: Recent Research Results and Emerging Opportunities, essentially summarizes a lot of the studies and empirical data that has been conducted in the area of Open Source Software projects, and compares it to traditional Software Engineering methods. Rather than attempt to summarize a summary of papers, I would encourage people to read this article as it distills a lot of what is now known about the open source software way.

In particular, it discusses:

(i) why individuals participate;
(ii) resources and capabilities supporting development activities;
(iii) how cooperation, coordination, and control are realized in
projects; (iv) alliance formation and inter-project social networking;
(v) FOSS as a multi-project software ecosystem, and (vi) FOSS as a
social movement

Preliminary Hardware Requirements for Digital Sketchbook

I've begun to put together a list of requirements for what I feel would be hardware that would support the vision of the designer's sketchbook. The following is a list of hardware requirements for a computer system that would support this sketchbook:

1. The system must be extremely portable (i.e. under 3 lbs) if you want designers to have this tool around them at all times. In fact, Alan Kay, through careful studying, has noted that 3 lbs is the optimal weight for a portable computing device.
2. The system must have a long battery life (at least 4 hours). Designers may not be able to find a power outlet when they are inspired to sketch out a new idea. In addition, carrying a power adaptor around with you, adds to the weight of the machine.
3. Pen input via tablet is a must have, as designers typically sketch out their ideas free hand with a stylus. Touch input is something that is nice to have, but not absolutely necessary. In any event, this capability must be built into the device, as designers won't carry an external tablet that adds to the weight of the device, and for which they could easily leave behind.
4. Screen size of at least 10.1 inches (if not more), as designers typically need a canvas the size of a regular sheet of paper or larger to sketch out their ideas. While there have been stories of designers sketching out ideas on the back of napkins, this is usually the exception not the rule to sketching out ideas wherever you are.
5. Reasonable hardware performance. Designers don't have to wait for the sketchbook that they carry around with them to boot up, and load the sketching software. Therefore, why should a digital version impose this constraint upon them? The amount of time that a designer should wait to get back to the sketching software should be no more than 15 seconds.
6. The cost of the system should be relatively inexpensive (less than $600), so that it remains in the budget of many designers. In addition, if the system is expensive, designers will feel less inclined to bring the sketchbook with them for fear or damaging or losing the system. To reiterate, this system should encourage designers to have this system around them at all times, as ideas can happen at any time and anywhere. I know that this may be a difficult requirement to achieve, as it is possible to built a system that meet netbooks s the above 5 requirements in the thousands of dollars. However, I believe with the rise of and other inexpensive computing devices, this may become possible in the near future.

To sum up, the system that I am looking for to build this designer's sketchbook would meet the following abbreviated requirements:

• Extremely portable
• Long Battery Life
• Pen input via built-in tablet
• Screen size of at least 10.1 inches
• Reasonable hardware performance
• Priced Under $600

I now ask the community, are there any computers out there that meet these specifications? In addition, are there any other hardware requirements which designers feel are essential and which I have omitted?

Let me know what you think!

Designer's Sketchbook Vision

Imagine a system that would allow you to rapidly sketch out new ideas, wherever you are. This tool would provide all of the affordances that a traditional sketching system would have (a canvas to sketch, sketching tools of various types). In addition, this new sketching system would provide capabilities that are difficult to find in a pencil and paper sketching system, such as ease in organizing and managing the large amounts of sketches that designers produce on a day to day basis with the projects they work on.

This system could be customized for the needs of each designer. For instance, as a user interface designer, I could tell the system that I am designing user interfaces, and it would structure the sketching system in a way that would make sense for me. In this case it would manage my sketches on two dimensions, one dimension being the fidelity of the sketch (which can be seen in most design domains), the other which allows me to see how all of these sketches fit together. For instance, if I am sketching a user interface, I may want to specify how this user interface interacts with another user interface.

This system would be as quick to use as a traditional pencil and paper sketching system, even though it is in fact a computer system of sorts. In addition, there will be minimal interaction needed with non-sketching aspects of the system. The system would be designed for sketching and sketching related tasks only. As a result, the system will not be as bloated and have as much complexity as traditional workstations that are used for design.

This is my preliminary vision of what this designer's sketchbook project would look like. I would appreciate to hear peoples comments and feedback with the vision of what this project would entail.

For Want of a Sketchbook

Welcome to a new section of my blog (called the Designer's Sketchbook Project). People

who have frequented my blog for some time have known that I have been publishing reading summaries and reviews for the CS889 Open Source Usability Seminar I am currently taking.

However, this new section will discuss a project that I am beginning to think about which is the possibility of creating a digital sketchbook which designers would carry around with them in lieu of a traditional sketchbook. This sketchbook would be both a hardware and software solution that would be designed to meet the needs of designers, rather than the arbitrary needs of technology/computing.

In these blog posts, I would like people's feedbacks on my thoughts about how I envision this digital sketching medium, so that I can begin to put together a specification of what would be the ultimate sketching tool for designers. It is important to realize that I am a Computer Scientist with an interest in User Interface Design, so what may make sense for me will probably not make sense for designers in other fields, and perhaps not even within the UI design field.