Final Report
1. About AbiWord
AbiWord is a free software, cross platform word processor, available for Mac, Windows and Unix. It strives to be properly integrated with each platform that it runs on, and to follow platform guidelines for interoperability. AbiWord is under active development by a team of independent developers from around the globe, all working in their spare time to bring the best of word processing to free software.
On Unix platforms, AbiWord is a part of the GNOME project. AbiWord uses the GTK toolkit, and integrates with GNOME libraries. It also strives to follow GNOME guidelines for the proper behavior of a desktop, end-user application.
2. About the GNOME HIG
The GNOME Human Interface Guidelines are a project to specify guidelines for the user interface of all GNOME applications, so that they are simple, easy to use, and consistent from applications to application. From their web site:
This document tells you how to create applications that look right, behave properly, and fit into the GNOME user interface as a whole. It is written for interface designers, graphic artists and software developers who will be creating software for the GNOME environment. Both specific advice on making effective use of interface elements, and the philosophy and general design principles behind the GNOME interface are covered
This document was created for GNOME 2.0, and is the standard that all GNOME applications, including AbiWord, should meet, to be good citizens of the GNOME community.
3. The Project Goal
The project that I took on was to improve AbiWord's compliance with the GNOME HIG. I did this by reviewing all important interface elements of AbiWord, and comparing them with the specification in the HIG for how they should look and act. Then I worked on fixing those aspects that were not up to par.
4. The Project Process
The process for working on this project consisted of three stages, not necessarily separate chronologically. The first stage consisted of determining what problems needed to be addressed in AbiWord. This required examining the HIG and understanding its recommendations and the reasoning behind them so that they could be properly implemented in AbiWord. The results of this stage were bugs filed in the AbiWord bug tracking system, (located at bugzilla.abisource.com) under bug 4142. The second stage consisted of bug triage, where I evaluated these bugs for whether they were reasonable to implement in AbiWord. It was necessary to determine which of these were appropriate for the specific needs of AbiWord. The final stage consisted in implementation and actually fixing the bugs.
5. The Results
This project made a substantial contribution to the compliance of AbiWord with the GNOME Human Interface Guidelines. A total of 10 separate issues were identified, which can be seen in the dependencies list of bug 4142. Five of these issues were fixed, and the others should either be fixed soon, or require additional discussion among the AbiWord developer community.
6. Bug Breakdown
These bugs were relatively easy to fix, and represented the major outstanding violations of the HIG.
It was decided that a Go menu was not useful for a word processor. We discussed this in class. It should be noted that no other word processor (that I've seen) has such a menu.
We haven't decided what to do about this yet. The argument from consistency is that there should be a desktop wide way to switch windows. The argument from usefulness is that such methods don't work as well as we would like.
This requires some way to parse file paths, which needs to be done cross platform. This hasn't yet been worked out.
Unfortunately, this requires major re-architecting of our keyboard handling code, so it hasn't gotten done yet. Once that is done, the fix should be easy.
Unfortunately, doing this requires either hard-coding all the different ways that time could be represented in words, for translation purposes, or some major change to the way our translation and strings system works. The latter would be hard, and the former would be ugly, since the same text would appear in lots of different places. Ick.
This, it turns out, is a discrepancy between the GTK toolbar code (GTK is the toolkit that underlies GNOME, and AbiWord) and the GNOME toolbar code. Once we change to the GNOME toolbar code (which will happen when we move to GNOME 2, and not just GTK 2) this will be fixed automatically.
6. Conclusions
I feel this project was quite successful. I analyzed many aspects of AbiWord's user interface, and improved it in several respects. Those issues that have not yet been resolved have raised important considerations with the AbiWord community, and these issues will be resolved in the foreseeable future, hopefully before the next stable release of AbiWord. Also, this project has raised the consciousness of AbiWord developers about the need to adhere to interface standards, and hopefully similar efforts will be conducted for the other platforms AbiWord supports, which have their counterparts to the GNOME HIG.