The papers for today's readings are:
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:
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.
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 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.
No comments:
Post a Comment