Hello all,
I have posted my latest working copy of GUIIO to CPAN. It can be found at:
http://search.cpan.org/~jsimpson/App-Guiio-0.991/lib/App/Guiio.pm
Please note that there are some remnants of the project for which GUIIO repurposes (namely ASCIIO), and that can be seen in the areas describing the project. I will try and get this taken care of shortly, and resubmit to PAUSE/CPAN. You learn a lot from submitting to these places, how their systems work and also what conventions they use to handle aspects of your project.
Hope you enjoy GUIIO,
James Simpson
Undergraduate Student
University of Waterloo
Monday, August 16, 2010
Monday, July 26, 2010
GUIIO - A Postmortem
Over the past two or so months, I have been working on a project that has received no discussion on this blog. Namely, the use of ASCII Art to describe user interface (UI) design ideas. Many of you probably have seen examples of what it is I am talking about, in fact there are several examples of this on the Bugzilla database for The Mozilla Project
Here's a quick example of a User Interface designed using a tool I have developed called GUIIO (more on this later):
Our study was broken into three distinct parts. In the first part of the study, background information of the subject (age, profession, computer expertise, etc.), their experiences in designing user interfaces, and finally their perceptions on ASCII art were collected and analyzed. The second part of the study had subjects rank and comment on the ASCII art designs of several common controls (comboboxes, textboxes, listboxes, etc.). Finally, the third part of the study presented the subjects with a series of completed interfaces in ASCII art. The subjects would then identify which components of the interface they could recognize. There was a total of 11 people who participated in the study, 9 male students, a female student and a male civil servant. While the study may be somewhat biased based on the low number of participants in the study, as well as the the fact that our sample isn't representative of UI designers and the UI design community, given the constraints that I was working under (time, energy and otherwise), it was the best I could afford.
There were five questions that were of interest in the study which I will briefly highlight and discuss which were:
The results of the second research question, which explored how people communicate, is reflected by the following graph:
As the graph clearly shows, e-mail and instant messaging are the two primary communication channels participants primarily use. This has important implications on design mediums, as the design mediums designers use, should match the communication channels they use. Otherwise, it would be difficult for them to receive timely, rich feedback from their colleagues on their designs in the forms of critiques. Design critiques, by the way, where your colleagues rip apart your design ideas, is a tradition of design culture. Luckily our design medium seems to match the communication channel participants indicate they use as both e-mail and instant messaging primarily make use of text.
Speaking of critiques, we had participants rank and comment on ASCII art designs we have put together for several common UI components, such as listboxes, textboxes, and buttons. What we discovered was that certain components, such as buttons, labels and checkboxes had a particular design which was consistently highly ranked. However, there was another group of components, such as menus and vertical sliders did not have a design which was consistently highly ranked. Certain types of controls are easier to design for in this text only medium, than others. In addition, it is possible to design controls in this text only medium which most people can recognized. The following is a graph which summarizes the rankings of the various designs of UI components which were presented to participants:
There are many reasons why ASCII art isn't a common design medium in practice. Rather than speculate on possible reasons why people hastily ignore this medium, we asked participants directly during our interview what issues they had in creating,viewing, modifying and sharing ASCII art. It is important to note that not all participants in the study were familiar with the concept of ASCII Art. In any event the following charts highlight the difficulties participants mentioned in the creating/modifying and sharing/viewing activities:
Before I discuss the final research question we explored, I think it is important to briefly discuss exactly what these issues were. In creating and modifying ASCII art, getting things to look the way they want refers to the classic problem of a designer translating the design idea they have in their head to the design medium they are using. This difficulty can be found most all design mediums including sketching on paper, which is why many people aren't that great at drawing. However, ASCII art amplifies the difficulty factor, as it is not immediately obvious what combination of computer-printable characters will give you the desired look you want for a particular UI component. Furthermore, it can be very time consuming adjusting for proper formatting to get the design to render correctly on your screen, which poses as a difficulty in viewing and sharing ASCII art. Finally, adjusting a design in this medium is typically a time consuming and painful process involving the careful realignment of rows and columns of characters whenever an aspect of the design is changed.
There are some guidelines that I can pass on to those who are interested in using ASCII Art to represent UI components and UI ideas. Firstly, there seems to be a fine balance in ASCII art between the design having too little detail and too much detail. Secondly, there may be certain aspects of the design of one components that may be appropriate in the design of another component. Designs in ASCII art must have a clear beginning or end, otherwise people viewing the ASCII art may have trouble interpreting the art. Certain visual components, such as containers which are items which hold inside of them other items, need to have a clear outline, otherwise the visual hierarchy is lost on users. Fine grained details often go unnoticed, take advantage of this fact to make designs which are space compact, which not only make it easier to fit content on the screen, but also make editing the components easier. Finally, realize that you cannot win them all. What I mean by this is that not all ASCII designs you create will be universally recognizable. It may take several different attempts at a design before you have a large enough audience of people who can recognize the design you are after.
We have developed a tool called GUIIO which is designed to alleviate the problems associated with representing UI designs in ASCII Art. GUIIO is an open source project which is based on a PERL module called ASCIIO (which can be found here).
GUIIO brings the ease of use and direct manipulation of UI components found in GUI Builders such as QT Creator, or the GLADE Interface Designer, but to ASCII Art. To draw a UI component, simply click its button from the component palette and the component's representation in ASCII Art will be drawn on the GUIIO form, which is an ASCII art form that renders designs in the Monospace font, hence removing the issues associated with rendering ASCII UI designs on other types of forms. One can then drag the component anywhere on the form to place it where ever the designer chooses. Using just a text editor, this task would take a very long time, as one would have to offset line by line the characters that make up the component that needs to be moved, and then worry about alignment and formatting to make the UI design look consistent.
In addition, since each of the components has its own ASCII rendering, the designer doesn't have to think about how to represent the UI component in ASCII reducing the cognitive strain on the designer. In fact the designs of these ASCII Art representations of the components have been field tested and many of the designs that have been implemented have been highly ranked in a study we conducted. That isn't to say that these components could perhaps later have an improved ASCII representation.
Finally, UI designs created in GUIIO can be saved as a plain text file, meaning that the GUI design you have created will be saved exactly as you see it, in ASCII Art. You can also copy the ASCII Art design into your clipboard and easily paste it into another application, such as an e-mail application for discussion of how a UI design looks like, inline in the body of your e-mail. You can even do the inverse. That is you can open a file which contains an ASCII Art representation of the UI someone else has created, and GUIIO will determine what components are in the design, and populate the GUIIO form with those components and its associated properties. You can also copy and paste into GUIIO an ASCII Art representation of a UI you saw somewhere else (such as on a forum and newsgroups) and GUIIO will again recognized the components and populate the GUIIO form with the design. As a result you can have all of the flexibility and time saving capabilities of the GUIIO regardless of whether you created the design in the tool or found it somewhere else.
The following is a screenshot of GUIIO in action:
I would like to thank the people who have worked on ASCIIO all this while. It has provided me with an excellent foundation to base my work upon. It has been fairly easily to add new components (called Stencils in ASCIIO speak) to GUIIO, as one needs to only edit a single text file, and change some self-explanatory fields (such as Text, to change the text that the component will render). It was also a breeze to change the behaviour that a component takes on (called Stripes in ASCIIO speak), as common actions, like dragging, clicking, and resizing are all given their own functions in its own respective stripe source file. However, the development was not all cakewalk, for instance developing the capability to read in plain text representations of UI designs and convert them into something GUIIO can understand (such as textboxes, listboxes, labels, and other UI components it has a vocabulary for) was tricky. For one thing, some of these components are multi-line and so the standard technique for solving this problem (regular expressions) was not enough, as you cannot immediately apply regular expressions to multiline patterns of characters, although I did manage to make good use of them along with a look up table to decipher detected components and their properties.
I would also like to thank the graphic designer(s) who contribute to the GLADE Interface Designer project. I have borrowed the icons you use to represent available controls in the toolbox/control palette, for use inside GUIIO's tool palette. I have no doubt spent countless hours designing those descriptive icons, and it has been a great time saver for myself to rely on this other important contribution from the OS community.
In the next couple of weeks I intend on uploading my work to CPAN including source for all others to take a look at. It will be licensed under the PERL license. I will post an article to this blog describing how to access the PERL module and code, when this all becomes available to CPAN.
Here's a quick example of a User Interface designed using a tool I have developed called GUIIO (more on this later):
The project consisted of an application, GUIIO, which makes designing User Interfaces (UI) in ASCII as simple as using a UI Builder such as the GLADE Interface Builder,QT Builder,etc. It also consisted of a study which looked into the practice and perceptions of design and this textual design medium (i.e. ASCII art). Finally, a paper was developed based on the results of the study, as well as a presentation which discussed the work. I will now briefly discuss each of these aspects of the project.
.........................................
. .
.User name : [_____________] .
. .
.Password : [_____________] .
. .
. .
. .
. .
. ---------- ---------- .
. | Login | |Cancel | .
. ---------- ---------- .
.........................................
Our study was broken into three distinct parts. In the first part of the study, background information of the subject (age, profession, computer expertise, etc.), their experiences in designing user interfaces, and finally their perceptions on ASCII art were collected and analyzed. The second part of the study had subjects rank and comment on the ASCII art designs of several common controls (comboboxes, textboxes, listboxes, etc.). Finally, the third part of the study presented the subjects with a series of completed interfaces in ASCII art. The subjects would then identify which components of the interface they could recognize. There was a total of 11 people who participated in the study, 9 male students, a female student and a male civil servant. While the study may be somewhat biased based on the low number of participants in the study, as well as the the fact that our sample isn't representative of UI designers and the UI design community, given the constraints that I was working under (time, energy and otherwise), it was the best I could afford.
There were five questions that were of interest in the study which I will briefly highlight and discuss which were:
- What user interface design mediums do people use?
- How do people communicate?
- Which ASCII art design best represents UI components?
- Are there issues in using ASCII art?
- Are there guidelines in designing ASCII art?
The results of the second research question, which explored how people communicate, is reflected by the following graph:
As the graph clearly shows, e-mail and instant messaging are the two primary communication channels participants primarily use. This has important implications on design mediums, as the design mediums designers use, should match the communication channels they use. Otherwise, it would be difficult for them to receive timely, rich feedback from their colleagues on their designs in the forms of critiques. Design critiques, by the way, where your colleagues rip apart your design ideas, is a tradition of design culture. Luckily our design medium seems to match the communication channel participants indicate they use as both e-mail and instant messaging primarily make use of text.Speaking of critiques, we had participants rank and comment on ASCII art designs we have put together for several common UI components, such as listboxes, textboxes, and buttons. What we discovered was that certain components, such as buttons, labels and checkboxes had a particular design which was consistently highly ranked. However, there was another group of components, such as menus and vertical sliders did not have a design which was consistently highly ranked. Certain types of controls are easier to design for in this text only medium, than others. In addition, it is possible to design controls in this text only medium which most people can recognized. The following is a graph which summarizes the rankings of the various designs of UI components which were presented to participants:
There are many reasons why ASCII art isn't a common design medium in practice. Rather than speculate on possible reasons why people hastily ignore this medium, we asked participants directly during our interview what issues they had in creating,viewing, modifying and sharing ASCII art. It is important to note that not all participants in the study were familiar with the concept of ASCII Art. In any event the following charts highlight the difficulties participants mentioned in the creating/modifying and sharing/viewing activities:
Before I discuss the final research question we explored, I think it is important to briefly discuss exactly what these issues were. In creating and modifying ASCII art, getting things to look the way they want refers to the classic problem of a designer translating the design idea they have in their head to the design medium they are using. This difficulty can be found most all design mediums including sketching on paper, which is why many people aren't that great at drawing. However, ASCII art amplifies the difficulty factor, as it is not immediately obvious what combination of computer-printable characters will give you the desired look you want for a particular UI component. Furthermore, it can be very time consuming adjusting for proper formatting to get the design to render correctly on your screen, which poses as a difficulty in viewing and sharing ASCII art. Finally, adjusting a design in this medium is typically a time consuming and painful process involving the careful realignment of rows and columns of characters whenever an aspect of the design is changed.
There are some guidelines that I can pass on to those who are interested in using ASCII Art to represent UI components and UI ideas. Firstly, there seems to be a fine balance in ASCII art between the design having too little detail and too much detail. Secondly, there may be certain aspects of the design of one components that may be appropriate in the design of another component. Designs in ASCII art must have a clear beginning or end, otherwise people viewing the ASCII art may have trouble interpreting the art. Certain visual components, such as containers which are items which hold inside of them other items, need to have a clear outline, otherwise the visual hierarchy is lost on users. Fine grained details often go unnoticed, take advantage of this fact to make designs which are space compact, which not only make it easier to fit content on the screen, but also make editing the components easier. Finally, realize that you cannot win them all. What I mean by this is that not all ASCII designs you create will be universally recognizable. It may take several different attempts at a design before you have a large enough audience of people who can recognize the design you are after.
We have developed a tool called GUIIO which is designed to alleviate the problems associated with representing UI designs in ASCII Art. GUIIO is an open source project which is based on a PERL module called ASCIIO (which can be found here).
GUIIO brings the ease of use and direct manipulation of UI components found in GUI Builders such as QT Creator, or the GLADE Interface Designer, but to ASCII Art. To draw a UI component, simply click its button from the component palette and the component's representation in ASCII Art will be drawn on the GUIIO form, which is an ASCII art form that renders designs in the Monospace font, hence removing the issues associated with rendering ASCII UI designs on other types of forms. One can then drag the component anywhere on the form to place it where ever the designer chooses. Using just a text editor, this task would take a very long time, as one would have to offset line by line the characters that make up the component that needs to be moved, and then worry about alignment and formatting to make the UI design look consistent.
In addition, since each of the components has its own ASCII rendering, the designer doesn't have to think about how to represent the UI component in ASCII reducing the cognitive strain on the designer. In fact the designs of these ASCII Art representations of the components have been field tested and many of the designs that have been implemented have been highly ranked in a study we conducted. That isn't to say that these components could perhaps later have an improved ASCII representation.
Finally, UI designs created in GUIIO can be saved as a plain text file, meaning that the GUI design you have created will be saved exactly as you see it, in ASCII Art. You can also copy the ASCII Art design into your clipboard and easily paste it into another application, such as an e-mail application for discussion of how a UI design looks like, inline in the body of your e-mail. You can even do the inverse. That is you can open a file which contains an ASCII Art representation of the UI someone else has created, and GUIIO will determine what components are in the design, and populate the GUIIO form with those components and its associated properties. You can also copy and paste into GUIIO an ASCII Art representation of a UI you saw somewhere else (such as on a forum and newsgroups) and GUIIO will again recognized the components and populate the GUIIO form with the design. As a result you can have all of the flexibility and time saving capabilities of the GUIIO regardless of whether you created the design in the tool or found it somewhere else.
The following is a screenshot of GUIIO in action:
I would like to thank the people who have worked on ASCIIO all this while. It has provided me with an excellent foundation to base my work upon. It has been fairly easily to add new components (called Stencils in ASCIIO speak) to GUIIO, as one needs to only edit a single text file, and change some self-explanatory fields (such as Text, to change the text that the component will render). It was also a breeze to change the behaviour that a component takes on (called Stripes in ASCIIO speak), as common actions, like dragging, clicking, and resizing are all given their own functions in its own respective stripe source file. However, the development was not all cakewalk, for instance developing the capability to read in plain text representations of UI designs and convert them into something GUIIO can understand (such as textboxes, listboxes, labels, and other UI components it has a vocabulary for) was tricky. For one thing, some of these components are multi-line and so the standard technique for solving this problem (regular expressions) was not enough, as you cannot immediately apply regular expressions to multiline patterns of characters, although I did manage to make good use of them along with a look up table to decipher detected components and their properties.
I would also like to thank the graphic designer(s) who contribute to the GLADE Interface Designer project. I have borrowed the icons you use to represent available controls in the toolbox/control palette, for use inside GUIIO's tool palette. I have no doubt spent countless hours designing those descriptive icons, and it has been a great time saver for myself to rely on this other important contribution from the OS community.
In the next couple of weeks I intend on uploading my work to CPAN including source for all others to take a look at. It will be licensed under the PERL license. I will post an article to this blog describing how to access the PERL module and code, when this all becomes available to CPAN.
Wednesday, June 30, 2010
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):
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:
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.
- 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
- Design for People - Know who your users are and what you want to enable them to do
- Don't Limit Your User Base - Make systems that are accessible to people of different cultures, disabilities, or who may speak different languages
- Create a Match Between Your Application and the Real World - use easily understable metaphors to achieve this when appropriate
- Make Your Application Consistent - In terms of appearance and behaviour between your own application and the application ecosystem
- Keep the User Informed - the user should always be aware of what the system is doing
- Keep It Simple and Pretty - Design the application to show only useful or relevant information - avoid clutter as it distracts the user
- 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
- 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
- Provide Direct Manipulation - Allow users to directly interact with the data or objects rather than having to go through conduits such as dialogs
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)
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.
Saturday, June 26, 2010
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:
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:
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:
- 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
- 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)
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
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:
- Core - who represent module owners, super reviewers and release drivers or managers
- Active - who are people who report bugs and have been assigned to at least one bug
- Reports - a contributor who reports at least one bug
- Users - people who comment on bug reports and attach relevant files relating to an already reported bug
- 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)
Tuesday, June 22, 2010
Day 13 Readings
Today's readings discuss how usability issues are discussed in the open source community. These readings include the following literature:
- 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.
Subscribe to:
Posts (Atom)
