Monday, October 30, 2006

Why does our team work?

Our team is going swimmingly; I think the project is coming along fantastically, and Chandra and I love Phil and Hiroo. We sang their praises (LauLima wizards! Glorious user studies! The paper, the paper, the paper!) in class today.

Apparently this is an anomaly; we are the smoothest-running team by far and nobody knows what happened. Why does our team work? My guesses are below.

  1. Preset meeting times. One of the first things we did was set up frequent meeting times for the rest of the project duration. When issues crop up, knowing we'll be face to face in 48 hours helps alleviate a lot of concerns, since we can wait for our teammates to explain things instead of jumping to conclusions.
  2. Preferred modes of communication. "The fastest way to reach us," the email read, "is through email." "Oh - us too!" came the reply. Knowing how your teammates prefer to talk is incredibly helpful - if you speak in their preferred mode of communication, they're more likely to respond.
  3. State limitations up front. Nobody's Superman. If you have a regular football game, let us know; if you can't hear videoconferences, let us know. Far from annoying the rest of the team, it makes us more sensitive and accomodating.
  4. Get to know each other. This is something Chandra has to continually remind me of - asking "hey, how are you doing?" is not a waste of time, since knowing a little about people's lives outside the project lets you understand how that affects the way they're contributing to the project. Plus it's really cool to hear about Phil's job and Chandra's Halloween costume; even if the tangent only lasts 10 minutes, it has a gigantic effect on how we see each other, since we're starting to relate as students and people instead of additional man-hours contributing to this work-unit.
  5. Talk meta. Talk about team dynamics. Set up communication norms. Step back once in a while and ask if this is okay, how are things going - instead of designing a paper cup holder, we're really designing a distributed design experience through designing a cup holder, and I think that this manages to flicker to our consciousness often enough that we're able to find and voice issues before they become a problem.
  6. Optimism. I get the feeling that all four of us came into this project wanting to like each other, and so we did. As Joe (one of our classmates) put it, "you see each other as people, not just teammates."
Any other ideas? I'm running out of steam on this topic, but I'm sure there's got to be more. What are we doing right? What could we do better?

Wednesday, October 25, 2006

User observations, round 1

These notes will be shorter than I'd like, but here goes. Note: I'm pretty groggy from an entire week of waking up much earlier than usual - my sleep cycle's not so great at being thrown off like this, so I'm going to ask if we can not meet more than two days in a row or something. Consequently, these notes may be written less coherently than usual.

Chandra and I went out early this morning. The planned route was two independent coffeehouses and one large chain for user observations (no interviews), but when we got to the first independent shop it became apparent that there was no parking, no room (and therefore no place to observe), and everyone was walking out with generic coffee equipment. We hadn't considered that; apparently only big chains have really custom-shaped cups or holders. At this point we decided we were skipping the independents and watching two large chains instead.

Actual notes follow.

  • Most people just get one cup of coffee. Really.
  • Most people hold their single cup of coffee up by the rim because of the nice grip afforded by the lid; holding it higher up also lets them keep their hand away from the scalding liquid (which still radiates a respectable amount of heat through the paper cup). With no lid, the circumference of the cup's top is pretty compressible, and holding the cup higher up by the rim becomes dangerous (too easy to squeeze the top and slosh the contents out).
  • Trays are by the condiments counter or the cash register. Customers get them, not baristas.
  • Trays are generally a one-hand operation; the only time I saw a person hold a tray with two hands is when the tray was stacked on top of a box he was holding with two hands.
  • A very common use of trays and cups when you're holding multiple things is to pin things against each other - for instance, holding your donut bag in the same hand as your tray by gripping both the donut bag and the tray together in a pincer grip, or clamping the bag and your cup together. You can also place your bag on top of the cups or wedge it between the coffee cups on top of the tray.
  • The tray, if it accomodates cups, may want to to hold thick foam, paper, and plastic cups.
  • Both places had a box of coffee - a thin tagboard box folded up (with a decorative design) and lined with a thick-gauge plastic bag with a screw-on lid on the side (it looks like a stubby watering can of cardboard). It's an alternative to cups.
  • Coffee undergoes a lot of acceleration. People grab cups off the counters, whirl around with trays in their hands, and crash backwards through doors when their hands are full.
  • People generally do not drink the coffee in the store unless they are sitting at a table (not a common occurence during morning commuter rush); they carry it straight out instead.
  • One person usually acts as the coffee go-fer for a car of commuters; everyone else sits in the parked car waiting.
I believe that was the important stuff.

Tuesday, October 24, 2006

A conversation between Mel and Chandra

Chandra: In videoconferencing, you're more likely to stick to one thread of conversation because it's a turn-taking system and that makes us tend to stick to one topic at a time, and it's also more more like two groups communicating (Olin and Strathclyde) instead of four people.

Mel: I liked the four people feeling. It makes the distance divide seem less for me.

Chandra: But there were a lot of times when we (Mel and Chandra) typed the same thing at the same time, and we could probably be more efficient if we filtered out the double responses.

Mel: On the other hand, when we were video conferencing we had to wait so long to take turns; we'd talk, and then the other side would discuss what to say, and they'd talk, and then we'd discuss what to say - dialogue by committee.

Chandra: I value the chatroom because it feels more like four people than two teams; it feels like we're more comfortable and less hesitant at talking in the chatroom, maybe because we're a computer generation. And obviously I think that it's great that you (Mel) can understand the stuff in chatrooms. But because the lag is so slow and we're having a lot of topics on at once, it's easier for us to do other things while chatting. So we should be okay with listing aside tasks to do later (like "oh, I'm going to blog this") instead of doing them during the chat.

Mel: I think we're less hesitant to talk in a chatroom because all the attention isn't on us. We know we're not taking away our teammates' chance to say what they want to say, because there's that tiny bit of asynchronity built in to chatrooms over videoconferencing. I have a hard time with videoconferencing; it's not that I absolutely can't understand it, it's that it takes so much extra effort, like when you learn a second language well enough to understand people but it takes so much more concentration to speak and listen to than your first; you'll prefer communicating in your native language because it's just so much easier, and frees up your brain to do other things, like think.

Chandra: In the chat we have to backtrack a lot because someone will be carrying on with a conversation and another person hasn't had a chance to say what they've typed on the same subject. I don't want to institute Robert's Rules in the chat, but on the other hand it's less efficient because it's more efficient; it's too easy to keep going with a conversation without realizing everyone else is on a different track. There isn't signalling from other people.

Mel: We can do artificial signalling.

Chandra: We can, maybe we should, but we're not doing that yet.

Mel: Do you want to try it?

Chandra: I don't know. I'm trying to think of what would make our chatroom more efficient; would it help if we had a facilitator, a way to signal each other that we're typing (grab attention)? But I think if we do that we be losing some of the feeling that we are comfortable having an equal voice in the chatroom (as opposed to videoconferencing where Mel doesn't talk at all).

Mel: So what do you want to do?

Chandra: I don't have an answer, I think it's something we should think about. It will be interesting when artifacts come into play, when we have our user videos and physical prototypes.

Mel: And we can't do that over chat.

Chandra: I'm worried that there's content we'll keep losing unless we find a better way of communicating around physical artifacts. Like if I'm looking at a video of Phil's user study, should I be writing my comments and responses, when do I send those, should I just try to remember everything, when do we have time to go through all that information? We have the content (the video), the content creators' condensed version of the content and their responses to it, the other three members' responses to the content, the responses of all four members to each other's responses, and the new content that develops out of that conversation.

Mel: That's a lot of content. Would it work if we actually formalized it that way, "now it is the time to show content," "now it is time for Chandra to respond?"

Chandra: I've tried that and it doesn't work. You need it to be more rapid-fire, or you will lose the instantaneousness of the response, and everything keeps on dragging out and taking more time.

Mel: Even in an face to face conversation you have limited bandwidth. If the four of us were meeting in person there would be things I would want to say that I would not be saying. That information would be lost. In the digital world, you can transmit every bit of information; it's all stored. It might just take a long time to get through.

Chandra: But in a face to face conversation people usually take notes or minutes. Like right now, we're talking and you're typing (not verbatim, but a rough description of what we're talking about). Then also you have physical artifacts that you bring to, create at, or take from meeting, like we're bringing videos and responses to our next videoconference; that might happen as well if we were meeting face to face. If I was working with you (Mel) face to face on the project I would still bring my videos and my responses.

Mel: Anything else?

Chandra: I really want the ability to visually cue each other with a quick response to things - thumbs up ("I'm with you on this one"), thumbs middling ("I dunno, ehhh, can we talk about it"), thumbs down ("no! no!").

Mel: Can't we do that in the chat, ask people for a quick poll response?

Chandra: Only if we if come up with a more structured way of talking. Otherwise we don't know which conversational thread each poll response belongs to. Unless we do it outside the chatroom.

Mel: It has to be a short-term (on-then-off) notification rather than a mode switching (it stays on until you switch modes) otherwise everyone's status will be really outdated. (click a button and it will flash your response to everyone, then fade).

Chandra: It's like at Olin, at our meetings, people will hold their thumbs up and down while the speaker is talking, because people value a very quick response to things. Every group that I've been in that didn't have a quick mechanism for people to respond has eventually ended with someone being frustrated by the lack of response.

Mel: What if we could tag each other's chat lines with our thumbs-up, thumbs-down? I can click on individual things that you have typed and "vote" that way. I'll look and see if anything like that is out there.

Chandra: I'm hungry.

Mel: Let's eat.

Settling down on a routine

We seem to have found a pretty good communication medium. It's a compromise between Campfire and Flashmeeting - we chat on Campfire, so everyone can talk and there's no "waiting for someone else to finish" bottleneck, but keep Flashmeeting around so we can point the camera at things. That works a lot better for me, personally, because I have a much easier time being fluent and attentive in text rather than a videoconference - I think and work in text all the time, so it's my "native language." Hopefully it's not an inconvenience to the others (if it is, let me know and I'll switch modalities).

I'm also really glad we set up a regular meeting time and a set communications infrastructure. The faster you can make that kind of stuff habitual, the more time it frees up for you to do actual design work.

So far things seem to be going well - it's taking longer to start up than I'm used to, since we're getting through the "getting to know you" phase and the "having technical difficulties, please stand by" phase simultaneously (I couldn't get into the chat until 10 minutes after everyone else) but it's worth it; Phil and Hiroo's brainstorm brought up things we hadn't thought about, like standardization of cup sizes, different kinds and types of coffee-selling places, and so on. I'm also glad Chandra and her mad matsci skillz are on board. And I seem to be falling into the role of Person Who Finds Magical Technology. "Hey, we need something that does... this!" "Well, I happen to know three websites and two open source projects that do just that..."

Mmmm, technology.

Oh - and humor does work online. *grin* I drew the worst possible logo demo today as an example of why I shouldn't be allowed to make our actual logo (our team name is Long Distance Coffee), and we all had a good laugh.

No meeting tomorrow; we're splitting up to do user studies instead, so Chandra and I will be making the rounds of the local coffeehouses in the area. I love user studies. They're an excuse to go out and play (or in this case, chug coffee and claim it's "for class.")

Monday, October 23, 2006

Introductions - Mel

This is a project design notebook of sorts for the Distributed Engineering Design course between Strathclyde, Olin, and Stanford in the Fall of 2006. I'll be keeping my notes, sketches, updates, and generally everything else I generate here. Other team 2 folk, if you want to join the blog let me know and I'll make you an account; it's really easy to upload notes and pictures here.

By way of introduction, I'm Mel, a senior at Olin studying electrical engineering with a more softwareish bent. I'mactually interested in everything. I play piano and do vocal percussion, live in the same suite as Chandra, read in my non-copious amounts of free time, play with math, and attempt to sketch things occasionally. Engineering education is one of my more prominent obsessions. I plan on becoming an engineering professor eventually.

I am overly optimistic. If I had a superpower, I would be able to transmit and recieve electronic messages through my fingertips (so I could read/write hard drives without a laptop intervening, jack directly into ethernet ports, and such). I am hearing impaired, and rely on lipreading, which makes it hard for me to videoconference (you'll see me typing furiously in the back of the webcam instead).

I've worked on distributed teams before, so I've got a suite of favorite collaboration tools to use. They've all been software teams, though, with others experienced with distributed collaboration - it'll be an interesting learning experience doing my first distributed physical-deliverable project. I have a tendency to be mildly loud and adamant in text, but everything I say should be open to criticism, comment, and modification - I'm throwing ideas out for other people to play with. I'll modify my communication style upon request.