- Usability Discussions in Open Source Development
- 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:
- The Greenstone mailing lists
- Bugzilla Instances at Mozilla
- 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.
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.
No comments:
Post a Comment