13 May 16 May 20 May 01 June

 

Weekly Commentaries

 

13 May

 

 

Everyone wrote rather lengthy commentaries. Rather than cover the same turf so thorougly, a brief summary:

Sunday. Finished Affinity diagram. Prepared for presentation. Planned out paper a bit. Consolidating models now. Design ideas brewing in the backburner.

 

More interestingly,

James redesigned the wiki introduction/home page a bit. Subtle, but clean design. John G started a trend of labeling the higher order categories of the Affinity diagram with first-person narrative quotes. Really allows the design team to role play and take on the users' point of view. Everyone contributed to the Affinity diagram. Much chaos and flux, but it congealed well. The categories were in constant flux, changing, shifting, growing, dying away like dried dead skin cells collecting into dust. But from that dust, a stable, unified organism emerges. A singular vision of the consolidated user comes in view.

 

On a tangential note, in Fauconnier's class, I have been reviewing the various research about categories and how they are formed and structured in the humans: prototype effects, cluster models, and so on. This is of particular interest in that everyone on the team seemed to share a way of categorizing by common features. But from Lakoff's book Women, Fire and Dangerous Things, not all categories follow the classical model of grouping by common features.

What if we (the design team) had tried out different ways of categorizing instead of defaulting to the common classical method? What bizzare insights could we have realized?

 

Alas, the Affinity diagram and consolidated models provide a good direction for design, but design is interpretation.

And in spite of the consolidated information, focusing on a specific problem for design and limiting its scope will be tricky.

 

 Cheers.

 

16 May

 

For the presentation for Thursday I will be predominantly focusing on the Affinity Diagramming process. So today I am reviewing my memory banks

for those engrams. In the presentation I will, of course, have to cover the content of the Diagram, but I feel the presentation may

be more interesting if I also covered the process of how the team created the diagram: the negotiation of what categories to make, their names,

what notables to include or not include, and the placement of the post it notes themselves.

 

The semi-permanent transience of the post it notes allowed us to modify the diagram as fluidly as our restless thoughts. If we had used index cards (with tacks or tape) I don't believe the diagram would have been the same. It would be interesting to do an ethnographic examination of how we used the post-it notes. Perhaps in the presentation, I could demonstrate some of the tangible, physical actions we used on the post-it notes themselves.

 

Perhaps an hommage to the post-it note!

 

20 May

 

For Sunday, the group had another marathon session of consolidating another model, reviewing data, brainstorming design ideas,  and constructing a rough paper prototype. We also worked on the personas. In this vast sea of information and ideas, the team is perhaps losing focus on what the scale and scope of our design should be. James and myself are trying to limit the design ideas to the data and prevent the overly enthusiastic design venture of an entire application with all of its minutia. But once you get started, it's rather difficult to stop. John provided the central design idea around which everyone else readily contributed to. After this flux of visioning, I was basically playing the role of the devil's advocate or the extreme naive user. I tried to place myself in the role of such a user to reveal how our design was not completely being derived from the data. Hopefully, I was not too obviously dismissive. It is rather difficult to get everyone to agree how the design is coming from the information. Because of the immensity of the problems and the data, many interpretations are possible. We chose to focus on the consolidation/integration of information for the calendar design.

 

Often when someone asked where a certain feature came from, or why it was included, someone else would jokingly answer, "Google calendar." It seems Google Calendar has so many of the features we need to solve the design problems. Perhaps we should not focus on an application redesign so much as a cultural redesign, or an implementation redesign of a tool that already exists. Google calendar already exists, why reinvent the wheel? Perhaps, the problem is more in how to get the tool used, how to customize it for UCSD use, how to get the students, professors, and adminstration to adopt it as tool, rather than all this interface redesign/application construction. I could be wrong though... But it is always easier to redesign a thing than a process, a way of cognition. A process is always more ephermal, intangible, difficult to grasp.

Anyways, after reviewing some of the data last night, some design ideas came to me, both about the application redesign and the implementation practices. I am explicitly tracing their origins from our data. They seem pertinent to user problems. I'll introduce some of them for our Monday night meeting.

 

 Until next time, keep your peepers peeping.

 

01 June

Jonathan, Ted, and myself conducted two prototype interviews today. Although most of the information provided minute refinements rather than drastic redesigns (which is to be expected), one person did provide a totally revolutionary way to present the To Do list information graphically as a series of bars above the calendar. I believe this should be explored further, but there are time constraints on this project. How often does a naive person freely present a revolutionary graphical idiom for an interface? If this idea is not used for this project, it will be a crying shame. If only there were some way to get this implemented (or at the very least, kept secret).

There were also many more subtleties in the redesign, but they seemed more obviously driven by the data, in that, the connection from problem to design solution was more apparent.

Some key principles from the prototype redesign interviews:

simplicity over complexity;

although people want choice, the less options that accompany a choice the better;

a performed action should be direct and immediate, not mediated by too many options or pop-ups.

A carefully balanced tension must be maintained between choice/endless options and ease/directness.

Although the visioning and designing process is fun, it is with these interviews that I learn the most. Sometimes the most obvious things become not obvious, or the most obscure things become crystal clear. Were I to do this contextual design again (hopefully not because I dropped out of the class), I would want to do more inquiries.

 

Later alligator.