Google Summer of Code: Example Proposal

Here is an example of a successful proposal from Evergreen's participation in the 2011 Google Summer of Code.

Name: Joseph Lewis

Email: [joehms22 gmail com]

IRC nick on Freenode: joseph_

Current course of study/major: Computer Science (Information Security specifically)

The problem I am proposing to solve comes from the wiki:

Bring sanity to the Evergreen configuration interface  

Problem: There are currently 139 individual settings that a library can
change within one interface in the Evergreen staff client. The presentation
is a simple alphabetical list, with no further means of filtering these
settings. Help for these rather complex settings is limited to a single
string. There is no provision for tracking changes to the system configuration
over time to correlate configuration changes to problems that may be observed.
This interface is daunting for system administrators and would greatly benefit
from a skilled user interface designer/implementer.    

Required skills: JavaScript, CSS    

Level of difficulty: Easy to medium    

Mentors: Galen Charlton

Here is what I proposed implementing:

• Page keyword search (JavaScript)
• Complete descriptions of each configuration (it looks like this is stored in the database)
• Re-Organize the page in to logical sections and sub-sections with easy links at the top.
• Add an introduction to the page.
• A logging feature/revision control like feature.
• A tag like feature that allows smart suggestions of similar settings/easier setting search.

This will not take up the entire time you get me however, there are some more configuration interface irregularities that should be cleaned up though, which I have added in to the timeline below:

• Get familiar with Dojo and the project hierarchy/code-base.
• Get friendly with my mentor.
• Create/send out some mock-ups to test.
• Fix some small bugs with the project to get fully comfortable with coding styles.
• From GSoC Calendar: “Students get to know mentors, read documentation, get up to speed to begin working on their projects.”

• Set up new table(s) needed for better organization of library settings (tags).
• LSE: Add tags to items.
• LSE: Send some UI mockups to the community for input.

• Library Settings Editor: Re-write/create new javascript functions needed for generating page content.

• Library Settings Editor: Re-write/create new javascript functions needed for generating page content.
• Library Settings Editor: Add a way to import/export settings.
• Library Settings Editor: Add a log quick viewer to see what changes have recently been made (possibly to revert bad ones). Also provide a context sensitive log viewer (see changes for a particular setting over time).

• Library Settings Editor: Create page visual design.
• Implement page/individual help/search and make sure it works.
• LSE: Add new i18n strings (if needed).
• LSE: Re-create/add help strings.

• LSE: Re-create/add help strings.
• Ask for feedback on the new LSE (set up interactive server)
• Test all functions with all (within reason) possible variations, fix any errors that arise.

• Circulation configuration policy: Cleanup: add help-text to “add page”, and only show back and next if applicable. Make sure a scroll-bar shows if the table scrolls off screen.
• Various other small-scale usability fixes as they are found.

• LSE: Implement feedback and ask for more, run some usability tests. (Possibly on-line)
• Implement fixes from usability problems (make sure every feature is easy available and understandable).

• Midterms Due
• Buffer time / Bug-fixes

• I’ll be out of the office. (Don’t worry, I’ll distribute the time that I would have spent here across the other weeks, probably May 25 - June 10)

• Clean up the printer settings editor to only show relevant information about the currently selected options.
• Integrate “Do not attempt auto-print Settings” in to the printer settings (seems more logical). [Either make this all XUL or HTML]

• Buffer for the unexpected, if nothing unexpected happens, I’m sure there are still some interfaces needing usability cleanup.

• Finish up anything that needs doing, begin looking at more difficult things to do for Evergreen. :)

I have built some web technologies before; as a student I aided others getting around the school firewall by creating my own PHP/JavaScript flash games site. I have been paid to develop a secure web-application for a Real Estate firm in Denver (PHP/JS); therefore I’m not entirely unfamiliar with these sorts of web technologies.

I have also read some of Jakob Nielsen’s books on User Interface design/usability, and so have a somewhat better than average knowledge of what makes things easy for people to use.

I recently submitted a rather minor bugfix that makes osrf_ctl.sh smarter: https://bugs.launchpad.net/evergreen/+bug/741088

I have oftentimes come back from the library (several kinds city/school) disappointed because their systems are so archaic. The interfaces are difficult to navigate, doing common tasks seems difficult, and search results are oftentimes less useful than those brought up by Google. I have also sat next to librarians for days on end listening to the groans they have when their software doesn’t work. That is what makes me so excited about this project, (and I’ll still probably get involved if I don’t get accepted, although not to the same extent), open source software has the ability to be incredibly agile and bring modernity to institutions that are still central hubs of information in the world.