Save Your Design
The thing about the UI class is that it's known around campus for the amount of work it requires as part of the final project. Given the fact that I've seen someone levitate a lit light bulb as part of a final project at MIT, this should tell you something about what the last few weeks were like. Fortunately, I had the luxury of a quality group with fellow PLW members Annie Ding and Kate Hollenbach. Otherwise, I don't think I would have been able to keep moving as long as I did. Good groups, I have found, make you want to work harder. There's almost always a sense that you are getting something done because someone in the group is always committing some bit of code that is itself a small accomplishment. That's certainly the type of group we had and, in the end, I think our final project reflected the dynamic.
We actually started the project early in the term, but since the course focused on user-centered and iterative design, we spent a large portion of that time prototyping cheap implementations, like one created using only paper and glue, and putting it before users to see how well it actually worked. I won't bore you will all the details here, but I can assure you that much can be learned about design by putting it before a users early. We certainly worked our butts off during the course, but I think we would have worked much harder if we had blindly implemented our first design.
Save Your Design
The software we designed over the course of the term can be most easily described as “CVS for graphic designers.” If you have no idea what CVS is, well, consider it like a really good way to save all the different versions of a document during the course of its creation. Say for instance, you were creating a poster and had meticulously arranged some text that took you hours to get just right. In the meantime, you get a new idea to change the text completely and start changing things around furiously. At some point you realize that your new idea is some sort of insanity brought on by the cup of green tea you accepted from the resident hippie a few hours earlier. If you were working smart, you put away your old design with the meticulously arranged text so you can easily revert to that version and swear off the green tea forever. Of course, if you weren't working smart you have your work cut out for you … again. CVS, and similar software, has been the way for software developers to work smart. Not only does it preserve all the versions that developers work so hard to produce, but it also generally puts those versions somewhere safer so that nobody's failing harddrive can't bring an end to the entire project. The other thing version control systems, like CVS, do is allow others to get access to all those versions you have decided to save. You can always tell an office that doesn't use this type of software because the email server is crawling as everyone tries to send files to one another during the course of some big project. When working smart with version control software, you simply save your new version to the “repository” and everyone else working on the project can just come along and pick it up. Software developers have made a science and a lingo around these types of systems, so our project tried to allow it to work it's magic in another domain, graphic design. Hopefully, with that very long preamble out of the way, this paragraph from our final report will make sense:
While version control software is considered a “must have” among teams of software developers, it has had very slow adoption in other disciplines that require similar processes for creation. One of the primary reasons for the slow adoption is that the current generation of version control tools seem to favor the text based “source” that is common in software creation. Disciplines like visual design, which generally involve sources that are graphic in nature, are therefore unable to fully capitalize on such systems despite an overwhelming need for tracking and preserving revisions. The current tools regard a visual designer’s source, images, as indecipherable binary data. Many of the typical operations that make version control so attractive, like “diff”, are therefore unavailable. Also, options are still very limited for GUI-based tools and visual designers tend to be much less comfortable in the text-based world of command line interfaces. So, while designers stand to profit from version control systems, the current systems do not consider their unique requirements.
That's what our project, to which we gave the name “Save Your Design,” attempts to do: consider their unique requirements. “Considering their unique requirements” manifested itself in three different ways in our design: the process of version control is made simpler, more responsive, and definitely more visual. Hopefully some of those qualities are, at least partially apparent in the following screen shots.
Features & Details
The first item were were eager to boast about is the fact that our application featured a fully functional backend. That was not a strict requirement in the course. It was certainly strongly encouraged, but seeing as it was ultimately a class about user interfaces, a functioning backend wouldn't excuse a lousy interface. We were determined, though, to make something that was actually somewhat useful. After looking at a few options for providing a true repository-like backend, we finally settled on using JavaSVN to make the connection to a real-life fully functioning subversion server. The whole mechanism proved a bit slow, as we were expecting, but with some caching and threading tricks we were finally able to make something that seemed responsive even if it did take some time for the actual work to get done. Another set of threading tricks also allowed us to keep a constant watch on the repository status, so that as other people added new versions they would immediately show up in the interface. This even gave us the opportunity to detect and indicate conflicts before they actually occurred.
Another boasting point was an idea that actually came directly out of user testing. We had designed the interface to have an area for local copies on the left and a scrollable region with all the versions in the repository on the right. What we originally missed was that this spacial arrangement inferred another spacial interaction scheme, drag-and-drop. Picking up a local copy and dropping it in the repository side has the logical effect of committing that version to the repository. And, as may well guess, dragging from the repository to the local copy area is an easy way to initiate a revert command. The folks in our class really loved that. It was one of those things that was so incredibly obvious when someone was kind enough to point it out and Kate did a great job on the implementation.
One final thing we were quite eager to show off was the ability of Save Your Design to handle more than just the limited image formats available in Java's standard libraries. After all we intended this to be a tool for designers and Java doesn't have a good cross-platform way of rendering formats like Photoshop, Illustrator and PDF. Cocoa, the OSX objective-c libraries, on the other hand, do. So, in a sleepy haze, we threw that together as well by creating a little JNI library for thumbnail rendering. It took away any claims we had on platform independence, but that had been deteriorating all along thanks to the general quirkiness of the varying Swing implementations (with the OSX implementation being the undisputed king of quirk).
Impressions
On Wednesday, the class concluded with an open house up in the lofts of the Stata Center. We showed what we had and received far more positive feedback than we had anticipated. Not that we weren't proud of what we had accomplished, we were just too sleepy to give much thought to how it would be received. However, It's always a rewarding experience when people ask you if you intend to continue development on something, because they are interested in using it. A lot of people also told us how intuitive we'd made version control. I think the design impulse in all of us were very proud to hear that.