Thanks for the write-up, Lars! For me, it raises a couple of compelling issues or problems, and the neat thing about problems (unlike, say, conditions) is that they can more or less be solved.
First, in respect to the order of the day, we spent our first hour looking at a functioning Dotlrn 1.0 site so we might introduce our designers to the basic functionality that the interface would have to address, and we accepted it as a given, as I understand it, because we have a limited budget and mandate to make it pretty and with some attention to improving functionality and code structure but not much. The problem with this is that there are components that made sense before but might not make much sense now, and my call to give the designer some license was to give her some space to help us rethink what we are doing "on the fly", so to speak: she can see things the rest of us likely can not so easily: we are too close to the functionality.
Second, since we have inherited all this baggage, including code and our habitual way of looking at it, and since we are not consulting everyone all the time and don't want to offend anybody, it is much easier for us to add stuff then cut things away and re-organize things. This means we add and add to the point that the whole design, in my view, has became incredibly top-heavy, adding a terrific tax on the user. Hence, my call for simplification to make it easier for the user who, as I have argued, has a limited number of things to do in a given session and has no need for most of it most of the time.
Third, over-riding principle was to "make it pretty", but not "make it simple", and if we had begun with "make it simple" we would likely have ended up with something far different. We did not, for example, begin with user scenarios based on a needs assessment based on empirical research. I think it is fair to say that our task was defined, basically, as stacking the old bricks in new ways. We did not start from a usability study of, say, three different course structures and needs and as these needs changed over the beginning, middle, and end of the course. For example, courses typically start with the problem of presenting a syllabus, organizing meetings, and presenting materials. After a few weeks, students are making presentations and working on projects. At the end, homework is being submitted and evaluated. Each of these involves different proportions of application use: syllabus and file storage to start, then sub-groups and forums, then adding of minutes, reports, and homework as well as feedback. There are other models, to be sure, but I think this illustration suggests how general and function-oriented has been our solution thus far, and that this is a liability.
Fourth, to use a metaphor from Kant's aesthetics: there is a difference between knowing a pyramid by counting the bricks as an arithmetic series and knowing it as a geometric solid. When I work with databases and logic my head is in the former. When I compose my photographs and look at graphic design my head is more in the latter. When I look at the list Lars has offered I agree with every single thing. When I look at the whole, as I described, many of these things sit uncomfortably with each other. Hence, my suggestion that at this stage of the design we give the designer some space (license, mandate) to design a simpler, more comprehensive solution that users might read in a glance and find their way to using more comfortably.
