One of the main reasons that I keep on being so involved with OOPSLA is the people. I've had the opportunity to meet so many people who are immensely knowledgeable, funny, and friendly.
One of the people that I've been honoured to know is Steve Metsker. Other people know Steve through his books (Design Patterns in Java, Design Patterns in C#, Building Parsers with Java), but I've always known him first and foremost as a fellow OOPSLA attendee and committee member. We always found some time to chat, catching up with what had happened in the months since we last saw each other. He's always been one of my favourite members of the OOPSLA community.
I learned this afternoon that Steve passed away yesterday shortly after having been diagnosed with cancer. He is survived by his wife and two young daughters. He will be very missed -- OOPSLA won't feel the same without him.
Edited on Sunday, 10 February 2008 to add the following from his family:
Steven John Metsker passed away on Friday, February 8, 2008 after a short illness with cancer. Aged 49, he is survived by his loving wife, Alison, and their daughters, Sarah-Jane and Emma-Kate. Having earned Engineering degrees from both the Colorado State University and the University of Massachusetts, Steve was accomplished in a profession for which he had great passion. Born in Colorado, he also lived in Massachusetts, Maine, Texas, Switzerland, Kentucky, England, and Richmond. He made many friends everywhere he went. A loving and caring husband, father, brother, son, friend, and colleague, he was also a humble and wise mentor. He was a positive and loving influence on all of us, who will miss him dearly. In lieu of flowers please send donations to St. Baldrick's fund raising program for childhood cancer or to Our Lady's Children's Hospital, Dublin Ireland.
Edited on Tuesday, 12 February 2008, to add the following from a colleague of Steve's:
Steve's memorial was yesterday and it was an beautiful summary of an incredible life -- the church was filled to over capacity. Steve touched many, many people who will miss him dearly.
Several people have asked how they can best help Steve's family through this difficult time. The following information from Alison's brother describes an education fund that has been established for his daughters to ensure their college planning is continued without disruption. Please send this information to others you know that may interested in helping in this way.
I don't want to post this information publicly, but if you would like to assist his family in such a way, please email me and I will share it. I can also share an address for condolences.
This question came in via email, regarding my Tufte seminar review post:
Thanks so much for your review of the Tufte seminar. I was about ready to plunk down the money but first did a search. I don't currently have any of his books, but I'd rather learn through the books if the seminars are not earth-shattering. Do you have a recommendation for the best one to start?
Edward Tufte's books tend to assume that you are already familiar with what he has already written, so I thus recommend that you read them in order of publication: Visual Display, Envisioning Information, Visual Explanations, and Beautiful Evidence. The order of publication is also, in my opinion, the order of the importance of their work: Visual Display and Envisioning Information are seminal works, but the latter two aren't quite as strong. I suppose that I should re-read them and post reviews sometime.
I'm not sure that I would say that Tufte has a methodology so much as a strongly worded (and sometimes self-contradictory) opinion. For all the issues that I have with implementing his opinions, I think that his opinions are ones that should be carefully considered even if they ultimately rejected for a particular design. If you find yourself disliking Tufte's approach, you might instead try Don Norman's The Design of Everyday Things for a less dogmatic approach to design in general (although obviously not to interaction design in particular). Next up in my to-read queue is a book that was highly recommended by a co-worker: Sketching User Experiences by Bill Buxton (I'll offer the disclaimer that Buxton is a fellow Microsoft employee) which she said was an excellent book about design.
Last February, I complained about my bank's updated security requirements which require me to answer three so-called personal questions. Today, I found out that the situation is even more annoying than I had originally thought. They want me to change my questions annually.
My bank does this by randomly selecting questions from some list, and presenting three non-overlapping groups of questions. Last year, I had to repeatedly generate new questions (by quitting the process and logging back into the website) until I could get one question in each of the three groups that I could actually answer. The questions this year appear to be worse. Or maybe they're asking the same questions, and I'm just crankier about it because I didn't think that I'd have to go through this whole thing again.
Reading through my bank's website, I see that they're going to continue to do this about once a year. This is enough to make me consider switching banks. I'm generally happy with my bank, but I've recently established a relationship with another bank for a mortgage. The general desire to minimise the number of accounts that I need to login to and the specific desire to avoid security features which don't actually make my account more secure is enough to make switching banks look rather attractive.
Another point that annoyed me about going through this process this time was reading the FAQ to see why they were doing this again. I'm rather annoyed that the FAQ insists that my personal information is even safer than before. If they're going to make that kind of assertion, I'd like to see some kind of proof. They also recommend that, if you have a joint account and both of you login, you should select answers together so that both of you know them. But their questions are all written with a single answerer in mind, so both parties have to somehow know where one of their four (or more, if there were divorces) grandfathers were born.
My favourite useless question of those presented to me is 'what is your favourite culinary ingredient', although 'what was the family name of your nearest neighbour in 2000' is a close second, and 'how much were you paid per hour in your first job' is also entertaining. The first is rather subject to a brute-force attack (how many people are going to answer 'garlic' or 'chocolate' to the first?), the other two are questions that I will never be able to answer. I also liked that one of the so-called secure questions is to ask for the name of my high school, which anyone who has access to my Facebook profile can answer.
All of this serves to make my account less secure in practice. I'm generally a good girl about passwords: I update them regularly, they're never things that people could guess (they're randomly-generated strings), I don't share them with anyone, I don't even write them down. I somehow manage to keep all of my passwords in my head -- I don't use any utilities to keep up with them for me. But answers to questions like these, even ones that supposedly I'm the only one who will know, I'm not going to remember very well. Someone suggested ignoring the questions and treating them all as password fields themselves, but I'm not going to be able to remember something used so infrequently. In any case, it seems likely that I'm going to have to write the passwords down, which is inherently less secure than keeping them all in my head.
Observing users in their real-world setting is very humbling. Recently, I listened to one user say, over and over, that they trusted that the software was doing the right thing for them.
Trust. Such a small word, but the implications of it are absolutely staggering.
My time observing real users reminds me of the responsibility that I bear, that MacBU bears, that Microsoft bears. Software is a part of the everyday lives of our users. These people let this software into their lives, into their jobs, into their homes. And they expect that it will do the right thing. Many users (maybe not all of us jaded blog readers :) trust that software is going to do the right thing.
That is a huge responsibility. We've got to do our absolute best to live up to it. We don't always succeed, but it's imperative that it be our goal to do so. We have to be worthy of the trust that so many people place in us: that we make it easier for them to do their jobs, that we get out of their way, that we don't lose anything. For those whose trust we have lost, we have to rectify our errors and be able to prove that we're willing to work to regain their trust.
I've spent some time over the past couple of weeks conducting informal interviews with some internal folks about their app usage. These are folks who gave up an hour of their time in exchange for nothing more than the knowledge that they were helping out a fellow employee.
One of my findings from these interviews is that there are some absolutely awesome people who work here. I sent out an email to an internal mailing list explaining what I was up to, and had 20 responses within an hour. Responses ranged from worker bees in the trenches in groups all around the company to one of our vice presidents. Today, I got to spend an hour chatting with Major Nelson, and learned that he's one of the nicest people in the world, personable and funny and insightful. My chat with him is the best hour that I've had at work all week. (Nothing against everyone else that I've talked to!)
And that's one of the reasons that I work for Microsoft. Every time that I've sent a request out to someone on another team, regardless of whether I know them in advance, I've gotten a great response that's timely and helpful. When I've had the chance to meet other employees across the company, they've been pretty much universally great people.
Today's Alertbox from Jakob Nielsen is a list of top 10 application design mistakes. Something from the intro caught my attention:
Of course, people don't want to hear me say that they need to test their UI. And they definitely don't want to hear that they have to actually move their precious butts to a customer location to watch real people do the work the application is supposed to support.
The general idea seems to be that real programmers can't be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they've spent a day observing a few end users.
I have to provide a corollary to that: You are not your target user. You might be a user of your application, but if you're the developer of the application, you are probably not the target user.
This can be hard to remember when you're developing applications that are widely used, and when you are a user of your application. I'm not immune to this. I sometimes have difficulty separating out my Entourage wishlist from my data about Entourage because I live in that application all day every day. And while I might want Entourage to give me a pony, and I even have data saying that there are other Entourage users who also want a pony, I'm sorry to say that the pony-wanting Entourage users aren't our target users. (Sorry, guys.)
I had one of the program managers in my office yesterday, having a great talk about some possibilities for the future. He kept on saying 'some people want this ... ', and sometimes 'this is how I do it in our app'. I kept on asking him the same question: 'who is this user, and is that user one of our target users?' It was a point we kept on circling around. When you are talking about an app that is used by millions of people, it's trivial to find one guy who wants you to add any given feature. But how does that suggested feature impact our millions of other users, does it help them or hinder them? What is the opportunity cost of adding it? Does adding this help us towards our stated goals?
We can't be everything to everyone. Oftentimes, a particular user will have needs that are diametrically opposed to another user, and you've got to choose the direction that you're going. This means that someone is going to be unhappy with you, and that's a choice that you have to make. It should be a conscious decision, made by weighing the benefits. And one of the ways to make that conscious decision is to observe real users doing real tasks in their real-world setting. Don't make the mistake of observing yourself in your office or (although this is at least slightly better) observing the guy down the hall in his office. Get your precious butt out of your office and go observe your users for a few days.
You know, it's weird. Office 2008 has been out in the field for a little over a month. We had an awesome launch at MWSF. But I've been so focused on my work for the next version of Office (which I've been working on for months now) that I haven't been talking much about the version of Office that's brand-new to everyone who isn't in MacBU. So let's do a little bit to address that.
I noticed that the folks over at Mactech Magazine have a preview of their Office 2008 benchmark posted now, and their full results will be published in the March issue (which should be out any day now, I'd guess).
In honour of Super Tuesday, Silicon Valley gossip rag Valleywag has now endorsed Steve Jobs for President. Their reasons? As quoted from the site, these are their reasons:
State of the Union address will need to be read on Engadget.
Taxes $200 higher for early filers.
Dialing any goverment phone number gets a recording, "Did you know that you can get many of your questions answered online at support.apple.gov?"
White House press briefings closed to everyone except Walt Mossberg.
American flag: Black, with one white star in the middle.
$6 trillion budget most expensive ever, but fits into a manila envelope.
Foreign policy: "Boom."
Well, I'm glad that I haven't filed my taxes yet. Any other reasons that you'd vote for His Steveness for Prez?