Each week is busier than the last.

On Monday, Ann, Chris and I got together to build our 2nd-generation prototype.  I don't know if it was the smaller group or our increased experience, but it seemed to go a lot faster.  The two prototype interviews I did this week also went faster, because we focused primarily on the parts of the interface that we changed.  On Sunday, we had our longest-yet marathon session, interpreting the results of our interviews, and producing the 3rd and final generation of the prototype.  We then worked in parallel on many tasks to get ready for our presentation: I worked on the powerpoint itself, taking pictures and building the slides, while we had other people focusing on producing the demonstration graphics, and working on some storyboards for demonstration in our final binder.

It's interesting how our final product turned out to look so much like Google Calendar - we really tried to stay away from Google's look and feel, because we didn't want our design to simply be a rip off of Google's work.  But with each iteration, the feedback from our users pointed towards clear and simple interface changes that ended up with our calendar really looking a LOT like Google's - so similar that to save time producing graphics for our presentation, the design incorporates google screenshots for some elements.  I don't know if our familiarity with Google led us to choose those solutions over other less obvious ones, or if the basic structure of an online calendar is simple enough that separate evolutionary paths will lead to the same analogous solutions, but I've made peace with the fact that our calendar is very strongly reminiscent of Google's.  After all, we are not here to reinvent the wheel - we are here to figure out how to use the "wheel" to the benefit of UCSD undergrads.  In fact, this points in an interesting direction for Tritonlink's sake - this is perhaps one more area where UCSD can collaborate with Google to produce a useful end product for its students.

For our presentation, I tried to take some inspiration from Lessig's signature style.  Obviously there is only so far that we can go with his style - the presentation will need to rely heavily on pictures, and I didn't want to accidentally take his minimalist powerpoint style too far in my inexperience.  So what we have is perhaps a little bit punchier than our previous presentations, but also has a similar "outline" feel to it.  Hopefully as we practice with it on Monday we'll find that it works for us.

Beth Surrell from Tritonlink will unfortunately be traveling during our presentation time, and Becky Scott from Tritonlink will be in a meeting during that time that may or may not end early enough for her to attend.  This is unfortunate, as I would have hoped they could be present for the Q&A session with the whole class and the TAs and professor present.  However, as we still hope to make some lasting contribution to UCSD, I have offered to schedule a second presentation just for Tritonlink people, and they have accepted.  Beth Surrell will not be back until summer break, so I will have to consult with my teammates and see when they're available (if you're reading this, I'll bring it up with you guys on 6/4...)

From here on out we're done with design.  We've finalized it, put on the spit and polish, and now we have to figure out how to communicate our ideas most effectively.  The presentation structure is largely going to be in the "general problem - example - general solution - how our solution works" format, repeated several times for different problems and solutions.  Now we just need to figure out what to include in our paper and binder, and how to split up the work for that.  It promises to be a busy week and a half...

This week our group finished up the paper prototypes (we made two copies to facilitate parallel interviews).  Ted and I teamed up for two contextual interviews with the paper prototype.  Because of the absence of one of our team members, I served as both interviewer and computer, which was not a great configuration but worked well enough given the exigencies of the situation.  We got a lot of data that I didn't expect, which I suppose is why prototyping is such a useful thing.

Speaking generally about the methodology, I want to learn more about minimizing the influence my expectations had on the user.  I tried to frame requests to the user in terms of situations (like, it's the beginning of the quarter, and you don't know where  your classrooms are located.  find them) rather than leading instructions (find the link that gives you a map of your classrooms).  However, despite my efforts, I found it difficult sometimes to prevent my expectations from leaking through; therefore I will continue working to minimize that leakage.

This isn't a full interpretation of the interviews, since this is just me and the transcripts haven't been posted yet.  But here are the points that stuck in my head from the interviews:

The structure of our webpage interface didn't seem to work too well for accessing functions not displayed on the default page - and even some stuff displayed right there on the default page was ignored (one user ignored our fairly prominent print button and wanted to print by right-clicking on the calendar).  When I asked users to do something, and they couldn't see how to do it right away, I would have them lead me through their expected interface, drawing and filling in components along the way, and then when we completed their expected vision I would go back and give them a gentle prod into trying the sequence we had designed (the reason being that I wanted to evaluate the later steps in these sequences as well - just because the first step was elusive, that didn't mean the subsequent steps should necesarily be thrown out as well.)  Even hints and gentle prodding were not enough to get users to try some of the buttons we designed, comments along the lines of "that button doesn't do what I want" were not uncommon, even before they had tried the button.  People can reach judgments very quickly, apparently, so the interface needs to be as accessible to a beginning user as it is to a user who has read the help file.

This is gold - I expected the users to act a certain way and they went with something completely different.  The Calendars tab in particular will need redesigning, and we may place that (and other) functionality on the screen in a different manner than tabbed the sidebar we are currently using.

The ecology of artifacts seemed to interest people.  They liked being able to add events from links, and use their cell phone to access their calendar, although both users were wary of adding events with their phones because they didn't want to get the syntax wrong.  I've just got to say that I burst out laughing whenever I handed them the cardboard cell phone I made and said "oh look, you've got a text message."

The most enthusiastic support was focused on two features - the to-do list and rich class data.  Both of our users had different ideas of what a to-do list should look like, (modality mostly - sidebar vs taking over the main display) but their expectations of what it should do were almost identical, and indeed were very close to what we had designed.  Both users also really liked the simple feature of being able to access the class website and a map showing the class location directly from the class's entry on the calendar. 

I was glad to see people using our right-click functionality - right clicking rarely accesses application-specific functionality in web interfaces, so I would almost never bother to right click.  It's good to see that other people are not constrained by the same expectations. 

One of the more tricky questions of the interface completely failed to be answered - how do we deal with the modality and durability of dialogs.  We frequently had our two users give us opposite expectations - "I want it to disappear once I select a choice, because I don't want to waste time" vs. "I want to be able to see the result and correct it if it's wrong", and we had one user wanting the to-do list taking over the whole display, with one user liking the sidebar position.  So we'll have to see the other interview team's data before making a call on that.  It may come down to different user personas just having different expectations.

We will be interpreting this data on Monday, and I think that making sequence models of some of the specific user tasks we are emphasizing (subscribing to a different calendar, printing a calendar, sharing a calendar with a friend, etc) will help us.  Once we finish interpreting the data and producing what diagrams we deem useful (perhaps a miniature affinity diagram would help us as well?  but for only 4 users we may find that overkill) we will produce a second iteration of the prototype, for further testing in the following week.

Summary of contributions this week

This week has seen a lot of formal design artifacts be produced - consolidated models, vision, brainstormed design sketch, and paper prototype.  On Monday Ted and I produced a consolidated flow model, which revealed the basic polarity of information flow for the typical undergraduate student - from "schedulers" to student (to temp storage) to permanent storage (to temp storage) to student.  Students occasionally form requests for information, or schedule collaboratively with friends, or more rarely set meetings for orgs and thus themselves become a scheduler, but much of the information is simply received.  I updated our data presentation for Thursday with this new consolidated model and provided commentary at the presentation.  My initial design reaction to this new insight was to be tempted to take the user largely out of the scheduling loop, although this has been somewhat tempered by Brynn and Hollan's comments during the presentation about how being a part of that loop helps to consolidate memories.  As our design currently stands, it still takes away much of the menial transcription away from the user, but by allowing them to retain powerful tools for planning and reminders, as well as potentially being open to such subsequent applications as desktop widgets that, for example, display the next 10 scheduled items and a to-do list, the user remains a part of the process and definitely stays on top of what needs to be done.

On Sunday we had another one of our long meetings. We began by narrowing the focus of our project, basing it on the primary issues identified at the user-concerns level of the affinity diagram. The primary issue we identified was integrating schedule data from multitudinous sources. Alongside that primary issue, we attached portability (ability to access calendar from just about anywhere) and flexibility (the ability to export the calendar to just about any format - print, html, pdf, etc...)

With these design considerations in mind, we produced our consolidated sequence diagram. Like most of the consolidated models except for the flow model, we did not find great insights from the consolidated sequence model... it was so generic as to be almost useless. I think we will continue to refer to individual sequence models as we continue the design process. Each user had different breakdowns at different points in their work activities.

Having thus completed the formal analysis phase, we returned to the data, "walking" the affinity diagram, reviewing our models and interviews on our wiki, and refamiliarizing ourselves with the users. We began to brainstorm various functional solutions to our design issues, finding that the issues of portability and flexibility are essentially implementational details that would remain similar across different solutions. Integration was the key issue, and I produced a sort of flow model made up of sketchy artifact models to show how the user could pull in data from different sources and access it on the fly (this does ignore the activities of other entities, ie how the schedulers actually upload the information and handle it, but that is as it should be - it is outside our scope, and perhaps the activities of the Events Website group will cover that).

We formally designed a few of the UI elements on the whiteboard, but ultimately found it more rewarding to work out a UI design using paper cutouts, which we then used to build the prototype. We have left a fair amount of the UI blank or sketchy, not wishing to reinvent the wheel - for example, methods for clicking on a calendar to add an arbitrary event have been designed and redesigned ad nauseum, until all of the major calendars have reached an essentially convergent, and also very satisfying solution; in such cases, we will rely on the prevailing standards. We focused mostly on the functional and UI aspects of our integrating engine - the subscriptions manager, which can pull in subscriptions from arbitrary UCSD sources and indeed from any properly formatted source. We will also be looking at other UI aspects, such as richness of data (being able to see classes mapped out on maplink, classes on the schedule link to class website, etc.) flexibility (our printing function has a lot of customization power packed into what we hope is a simple and intuitive interface - we'll see), and on the network of artifacts the design can work with (cell phones can add events, receive reminders, and request daily/weekly schedules; orgs and UCSD entities can send invitations via email that users can click to add to their calendar, etc.)

We will be performing contextual interviews this week, 2 interviews per team of 3 designers (1 moderator, 1 computer, 1 recorder). After collecting this data and interpreting it, we will produce our second iteration next week, and test it on users again. Depending on time constraints we may perform only 2 interviews as an entire group and essentially use it as a sanity check to make sure our changes didn't totally mess it up, or we may interview as intensively as the first time. In any case, we will produce a third and final iteration after that round of interviews, and hopefully produce some sort of low-fi digital prototype to illustrate aspects of our design for our presentation.

Summary of contributions this week

This week we all finished up the affinity diagram.  We used the notes from the interpretation sessions as well as notes we produced individually for interview subjects we didn't have time to interpret as a group.  I'm going to hold on to the diagram so we can present it in class on thursday when we do our data presentations.  It seems like we didn't encounter so many problems in getting useful data as we had worried - there are some holes in are data, particularly when it comes to sequences, but for the most part we have been getting useful information that correlates well across users (at least in terms of user concerns), by which I mean they all have generally the same concerns, although they've evolved different techniques for dealing with those concerns.

I've been evaluating a photoshop plugin for use as a prototyping engine - it allows you to create interactive images that turn layers on and off according to simple input like button-clicking.  It seems to be useful, it creates a more interactive prototype than if we created a digital prototype based on html or powerpoint, but with that increased functionality comes increased difficulty in setting up.  I don't know if it's worth the effort required, so I'm thinking we'll stick with a simpler digital prototype (of course, we will start out with paper prototypes anyway, and the digital prototype will only be used to represent the finalized design.

On Monday we'll be working with a reduced group (me, Ted, D, and James) to produce consolidated work models, probably just flow and artifact.  There is so much variance in things like cultural pressures, physical environments, and triggers that it would be nearly impossible to produce cohesive work models for those.  Even for flow and artifact we will be forced to abstract and generalize perhaps a little bit more than we would like in order to consolidate.  I think the affinity diagram will end up being more useful to us, because it identifies patterns separately from the actual techniques people use to solve their problems.

We will then draw to produce a small set of guiding design principles / goals to work from in our design process.  After we have these goals we'll start brainstorming right away, and then we will build a paper prototype based on what we narrow down from the brainstorming.  We'll do contextual interviews with the paper prototype, altering the design during the session if it seems warranted, and interpret the data from those sessions to come up with our finalized prototype, which we will test with a couple of users just for a sanity check.  In preparation for these coming tasks, I'm going to go over the introduction of my Paper Prototyping book again so we have some idea of how to get started on building that, and will probably set aside some time for us to practice administering a paper prototype interview on each other.

[also mention the interpretation sessions and the original model building]