From odonnell at cs.uchicago.edu Tue Dec 17 14:58:04 2002 From: odonnell at cs.uchicago.edu (Mike O'Donnell) Date: Thu May 18 12:41:36 2006 Subject: [Cs22800] Finishing off the quarter --- a bit of a mess Message-ID: <20021217205809.3E0128080A1@surya.cs.uchicago.edu> OK guys, I've been sick for almost two weeks, so I haven't been very aggressive about chasing things down. But I have to file a grade report by tomorrow afternoon (Wednesday, 17 December), and I'll be in meetings all tomorrow morning. And I'm not supposed to be the aggressive one in this class. I have Steve Dranger, Ben Johnson, Wes Pegden, and Sam Tobin-Hochstadt on my grade list. I see final reports by Ben and by Wes. I get reports of 3 messages awaiting moderation for the mailing list. I don't have the password, and I intend to leave this to Sam, anyway. Some or all of those messages were pegged for moderation just because they were a bit odd in the addressing (bcc to the list, instead of direct addressing, as I recall). Some or all of those may have been retransmitted successfully. I will try to follow Ben's and Wes' final reports well enough to assign sensible grades. If any more reports appear in time for me to absorb them through my cold, I'll do those as well. I will not try to infer from other postings what was and wasn't intended to be part of a final report. For any grades that I can't assign sensibly real soon, I'll fill in incompletes, and try to sort things out in January. Mike O'D. From sam at uchicago.edu Wed Dec 18 12:32:42 2002 From: sam at uchicago.edu (sam th) Date: Thu May 18 12:41:36 2006 Subject: [Cs22800] final report Message-ID: <20021218123242.A12935@mail.trowbridge.org> Attached is the final report for my AbiWord project. It doesn't include the screenshots I promised since my computer at school (where I am not) unexpectedly went down, so I can't access them. Sorry. sam th -------------- next part -------------- C:\Documents and Settings\etobin\Desktop\final report.xhtml

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.