Human Computer Interaction (including usability engineering and interaction design) offers open source software development at least three important opportunities:
to create systems that are usable by ordinary people[2] claims that OSS’s have poor user interfaces. [2] has stated the challenges within the a number of OSS projects, namely NetBeans, GNOME, and OpenOffice.org. These OSS project are sharing the similar challenges such as communication problem between the geographically distributed OSS project developers. The goal of the HCI professionals is the following:
to assure that OSS behaves consistently no matter who contributes to it, and
to respect the needs of disabled users as we standardize visual and interaction interface elements to meet accessibility requirements
[…] defining and integrating a suitable usability methodology into open source processes should be the first priority. It is also vital for each project to agree on its target audience, and to specify a clear and preferably centralized decision-making process.
[3] has stated 9 reasons why OSS has poor use interface:
1. Dedicated volunteer interface designers appear to be much rarer than their paid counterparts — and where they do exist, they tend to be less experienced (like yours truly).
2. First corollary: Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.
3. Second corollary: Even when dedicated interface designers are present, they are not heeded as much as they would be in professional projects, precisely because they’re dedicated designers and don’t have patches to implement their suggestions.
4. Many hackers assume that whatever Microsoft or Apple do is good design, when this is frequently not the case. In imitating the designs of these companies, volunteer projects repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.
5. Volunteers hack on stuff which they are interested in, which usually means stuff which they are going to use themselves. Because they are hackers, they are power users, so the interface design ends up too complicated for most people to use.
6. The converse also applies. Many of the little details which improve the interface — like focusing the appropriate control when a window is opened, or fine-tuning error messages so that they are both helpful and grammatical — are not exciting or satisfying to work on, so they get fixed slowly (if at all).
7. As in a professional project, in a volunteer project there will be times when the contributors disagree on a design issue. Where contributors are paid to work on something, they have an incentive to carry on even if they disagree with the design. Where volunteers are involved, however, it’s much more likely that the project maintainer will agree to add a user preference for the issue in question, in return for the continued efforts of that contributor. The number, obscurity, and triviality of such preferences ends up confusing ordinary users immensely, while everyone is penalized by the resulting bloat and reduced thoroughness of testing.
8. For the same reason — lack of monetary payment — many contributors to a volunteer project want to be rewarded with their own fifteen pixels of fame in the interface. This often manifests itself in checkboxes or menu items for features which should be invisible.
9. The practice of releasing early, releasing often frequently causes severe damage to the interface. When a feature is incomplete, buggy, or slow, people get used to the incompleteness, or introduce preferences to cope with the bugginess or slowness. Then when the feature is finished, people complain about the completeness or try to retain the preferences. Similarly, when something has an inefficient design, people get used to the inefficiency, and complain when it becomes efficient. As a result, more user preferences get added, making the interface worse.
[4] begins with 2 of Free Software’s usual problems:
1. Weak incentives for usability
Solution: Solutions: Establish more and stronger incentives. For example, annual Free Software design awards could publicize and reward developers for good design.
2. Few good designers
Solutions: Provide highly accessible training materials for programmers, and volunteer designers, to improve the overall level of design competence.
3. Design suggestions often aren’t invited or welcomed.
Solution: Establish a process for usability specialists to contribute to a project.
4. Usability is hard to measure.
Solutions: Promote small-scale user testing techniques that are practical for volunteers.
5. Coding before design.
Solution: Pair up designers with those programmers wanting to develop a new project or a new feature.
6. Too many cooks.
Solution: Projects could have a lead human interface designer, who fields everyone else’s suggestions, and works with the programmers in deciding what is implementable.
7. Chasing tail-lights.
Solution: Encourage innovative design through awards and other publicity.
8. Scratching their own itch.
Solutions: Establish a culture of simplicity, by praising restrained design and ridiculing complex design.
9. Leaving little things broken.
Solution: When scheduling bug fixes, take into account how long they will take, possibly scheduling minor interface fixes earlier if they can be done quickly.
10. Placating people with options.
Solution: Strong project maintainers and a culture of simplicity.
11. Fifteen pixels of fame.
Solutions: Provide alternative publicity, such as a Weblog, for crediting contributors.
12. Design is high-bandwidth, the Net is low-bandwidth.
Solutions: Develop and promote VoIP, video chat, virtual whiteboard, sketching, and animation software that allows easier communication of design ideas over the Internet.
13. Release early, release often, get stuck.
Solution: Publish design specifications as early as possible in the development process, so testers know what to expect eventually.
14. Mediocrity through modularity.
Solution: Design an example graphical interface first, so that interface requirements for the lower levels are known before they are written.
15. Gated development communities.
Solutions: Free Software system vendors can coordinate cross-component features like this, if they have employees working on all relevant levels of the software stack.
[5] states the following questions the GUI application developer for Linux or BSD should ask to herself:
1. What does my software look like to a non-technical user who has never seen it before?
2. Is there any screen in my GUI that is a dead end, without giving guidance further into the system?
3. The requirement that end-users read documentation is a sign of UI design failure. Is my UI design a failure?
4. For technical tasks that do require documentation, do they fail to mention critical defaults?
5. Does my project welcome and respond to usability feedback from non-expert users?
6. And, most importantly of all...do I allow my users the precious luxury of ignorance?
[6] claims that OSS should be task-oriented instead of feature-oriented. A task-oriented configurator would have logic in it like this:
•If the machine doesn't have an active LAN interface, gray out all the "Networked" entries.
•If the machine has no device connected to the parallel port and no USB printers attached, gray out the "Locally connected" entry.
•If probing the hosts accessible on the LAN (say, with an appropriately-crafted Christmas-tree packet) doesn't reveal a Windows TCP/IP stack, gray out the SMB entry.
•If probing the hosts accessible on the LAN doesn't reveal a Novell Netware NCP stack, gray out the NCP entry.
•If probing the hosts accessible on the LAN doesn't reveal a Jet-Direct firmware TCP/IP stack, gray out the JetDirect entry.
•If all Unix hosts on the LAN have CUPS daemons running, gray out the LPD entry.
•If the preceding rules leave just one choice, so inform the user and go straight to the form for that queue type.
•If the preceding rules leave no choices, complain and display the entire menu.
REFERENCE
[1] http://doi.acm.org/10.1145/506443.506666
[2] http://doi.acm.org/10.1145/985921.985991
[3] http://web.archive.org/web/20030201183139/http://mpt.phrasewise.com/discuss/msgReader$173
[4] http://mpt.net.nz/archive/2008/08/01/free-software-usability
[5] http://catb.org/~esr/writings/cups-horror.html
[6] http://catb.org/~esr/writings/luxury-part-deux.html
[7] http://daringfireball.net/2004/04/spray_on_usability
No comments:
Post a Comment