Classnotes for The Fluency User-Interface Builder Document
Department of Computer Science, Indiana University, Bloomington, Indiana 47405, USA.
Fluency would not only not be possible, it, literally, wouldn't be thinkable without the four principles continually enunciated in class:
Here's a list of the 12 design patterns you'll need to know to fully understand this document: Observer, Command, Proxy, Adapter, Composite, MacroCommand, Factory Method, Abstract Factory, MVC, Singleton, Null Object, and Mediator + 4 more we haven't covered in class: Strategy, Prototype, Bridge, and Interpreter.
You need to recall what a 'Dictionary' is from data structures. It's any implementation of a Collection interface that specifies that it can add(), delete(), and find() elements. Normally it can also test for empty() and report its size().
The section on problems in the current implementation is necessary to help guide this term's project development but it may also sound like I'm blaming past students. I'm not. All of Fluency's faults are mine. I'm only now developing the skills needed to run a major software research project in an academic setting with students who start with variable knowledge and ability, and who also have no experience with modern tools and design patterns, or of working in teams, and on large projects, and who also have limited time to do real work since, until this term, it used to take most of the term just to give them the basic skills needed for modern software development. This is the first term that I've figured out a way to intermix both tools and real team experience early enough in the term so that project development can begin in earnest much earlier than in years past. Further, like most programmers, I have no special skill in user interface design, although I can at least recognize when something is wrong. Figuring out the right thing to do about it, though, is a different matter, especially given the state of open-source visual tools. Even simple ones, like graph browsers or layout algorithms, are still hard to find in the commercial world, and almost non-existent in the open-source world. More often than not, past students had to roll their own, unable to leverage earlier open-source graphical projects partly because those projects were so extremely limited, so badly designed, or so badly written. The credit for Fluency as it stands now, thus goes to a few outstanding students over the years who each worked long and hard on Fluency near the end of their respective terms, and far beyond. Thus, Fluency's user interface wasn't as planned as its architecture was---it simply happened as various programmers fought their weak and buggy open-source graphical tools to get something working up on screen so that you can critique and extend it today.
Programmers are poor user-interface developers for several related reasons.
There are also more social and political and economic reasons that we have the user interfaces we have today. First, computer applications are still growing because computer penetrance in the general population is still growing. It's not worth a company's while to develop a near-perfect user interface because possessing such a user interface doesn't guarantee that the company will seize or hold on to its market share. Companies like Microsoft hold on to the share they do not because they produce brilliant software but because they own the desktop and have enough money to buy products when such products finally manage to service a new population segment tolerably well. A startup company is more motivated to produce good software, but may not have the resources. And all companies are in a race where every year or so the population of users doubles. Thus, whatever products they offer, the population of people they can offer them to will double in a year. Why spend a lot on continually improving what you have when you can throw something together for the new population, which will be at least as large, and much less computer literate than, the old population? A good user interface can still be a net plus, so companies are motivated to produce them, but with our present system of producing them, the production costs are far too high to make them economically attractive the way they are in a static or slowly changing engineering field, like say, washing machines or cars or airplane cockpits. There, interface problems have been well-studied for generations. Further, in many consumer devices, not only have they been well-studied because they've been around a long time, but physical dangers, like electical shock, brake failure, aiplane crashes, and so on, have placed forces on the developers to make sure everything is done right. few such forces yet operate on computer software today, even as it comes to dominate many markets today.
Design Pattern References:
MVC: http://www.cs.indiana.edu/~cbaray/projects/mvc.html http://www.javaworld.com/javaworld/jw-04-1998/jw-04-howto.html
Abstract Factory: http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/FactoryPattern.htm
Null Object: http://www.cs.oberlin.edu/~jwalker/nullObjPattern/
Pipes are related to the Pipes and Filters design pattern of Buschmann et al, 1996, which is intended for largely linear non-visual data processing tasks, as in the Unix command line, or various parallel processing tasks: http://www.cs.ucl.ac.uk/staff/J.Ortega-Arjona/patterns/PF.html http://www.vico.org/pages/PatronsDisseny/Pattern%20Pipes%20and%20Filters/