Google Earth: Stone Circles, Crop Circles, White Horses

Whilst planning a trip to the UK, I turned on satellite view to find myself a nice green village in the midlands for an overnight - and spotted the remains of a hill fort or stone age earthworks in a field. Nice!

I poked around and found this cool site, GoogleSightSeeing.com, tagline "Why bother seeing the world for real?" They have some nice references, although I find it slightly frustrating that they don't let you load the coordinates into Google Maps yourself from their site - maybe this is a Google Maps API UI issue, though?

Here's the White Horse of Uffington (about it here), a chalk horse on the hill near Uffington, not far from Oxford:

View Larger Map

Another chalk figure is at the Long Man of Wilmington, and in Mexico there is a surprisingly similar Juarez White Horse (I wonder if that one is a hoax).

The Alton Barnes one is from the 1800's and is kept in good modern horse condition:

View Larger Map

There are some fun crop circles, like the one near Doncaster (hey, I'll be quite close to this next month...):

View Larger Map

And here are more crop circles near the M1.

Stone circles don't all turn out so well... I'm disappointed that Avebury is hard to make out, and the Callanish stones in Lewis aren't very visible. Stonehenge is acceptable:

View Larger Map

Another circle in the Lake District is only visible as a ring on earth, at GoogleEarthHacks. I also enjoyed on that site the link to Peru's 13 Stone Towers, an observatory structure - but the massive earthwork remains to the upper left of it are much more impressive to inspect by air.

Ireland's passage graves are very visible, too. Here's Knowth, part of the amazing Boyne Valley collection of sites (where Newgrange is, with other stone age mysteries that are really worth a visit):

Not just for aerial tourism, of course - I was reminded of the folks who've used Google Earth/Maps to find new archaeological remains. A couple years ago, a computer programmer made some important Roman discoveries. Archaelogists are using Google Earth fairly regularly, and some recent Afghanistan sites are due to Google Earth usage by a Ph.D. student.

Good UX from Happy Employees?

More on creating good user experience from good organizations: a short blog post by Adam Richardson at CNET entitled "Good user experience comes from good employee experience." He points out comments from airlines with happy employees who convey happiness to their customers, like SouthWest and JetBlue, as opposed to American and other airlines with rather surly, unhappy employees.

Over the years, whenever reporters would ask him the secret to Southwest's success, Mr. Kelleher had a stock response. "You have to treat your employees like customers," he told Fortune in 2001. "When you treat them right, then they will treat your outside customers right. That has been a powerful competitive weapon for us."...

"There isn't any customer satisfaction without employee satisfaction," said Gordon Bethune, the former chief executive of Continental Airlines, and an old friend of Mr. Kelleher's. "He recognized that good employee relations would affect the bottom line. He knew that having employees who wanted to do a good job would drive revenue and lower costs."

I've worked at more than my share of offices in the past dozen years, and I think there may be something in this. Watch out if you've got customer-facing employees who don't answer internal colleague emails, are rude or curt to peers in their organization, promise stuff but don't deliver, hold onto information for their own advancement rather than the sake of the team. You probably also have a customer relations problem at the very least. Is this person answering customer email or calls politely? Sharing customer problems with other people who can help? Looking for help in solving the problems that the customer has?

Then look at the tools your employees have to use... if you find crappy tools in use internally, then double check that this isn't exposed to customers in some form. The MathWorks has an internal usability group that works on design and development processes for corporate tools. I think it pays off in many ways, not all of them related to internal efficiency. It's a sign of respect for your staff to give them the best tools to work with.

If you hire well, trust your employees, and give them a reasonable job to do, they can be your strongest advocates for hiring, referrals, and posting nicely about you in their blogs! And they'll go the extra mile on the job. Besides, a lot of your employees, past and future, are customers too.

Staffing for User Experience: What Can Go Wrong

You decided to hire a bunch of interaction designers and "user experience" people to improve your product, service, or general business from a customer-focused design perspective. You were lucky enough to find some experienced folks, who've proven their worth at other companies.

It may not be obvious, even if you hired evangelists to help convince the rest of the company of their value, how many ways you can still get it wrong AFTER the hiring. It takes more than headcount! Your new people need to be empowered to make a difference on the product. The issues below amount to (a) cultural and process openness around adding more design into the team software mix, (b) how the dynamics of decision making in your company can impact design for evil rather than improvement.

1. Did you hire the right people? Let's assume you did, but a couple reminders here: Your biases and your interviewer biases may be some of the problem you are actually hoping to solve. Did you hire looking for collaborative people who get along with everyone (and cave in an argument, in order to preserve the peace?). Did you hire people who do evaluation of other people's designs, or did you hire designers? Did you hire GOOD designers? (Would you know how to evaluate their design skills?) What kind of power dynamics are going on with the interviewers you lined up: Are any of them threatened by the whole idea of outside new people influencing the product? Are they looking for "yes" people or new ideas? Remember they may say something quite different from what they really secretly feel after 3 beers.
2. Does anyone other than development or product management get a say in how things turn out? How much will these expert new hires be heard? A development manager who is used to being in control may not like having to invite someone new to his planning meetings; a product manager may be unhappy if your new hire questions her market research based on usability data. How much of the time will your new staff be looking for data and ways to convince people to listen, versus actually making an impact on the product? If you had to hire evangelists, you're set up for this problem from the start - expect a lot less productive impact on the product from your new hires, and a lot more organizational time suckage.
3. Do you have ugly cultural problems you don't know about: Prejudice against non-"technical" input, assumptions that women aren't as smart or good at software or technical decisions. Women are more likely in UX/design than they are in engineering jobs, even if they started in development positions. Check out the dynamics at the whiteboard here, a scene I've watched many times...
4. Will other people take UX team work as optional input to modify, redo, ignore? Does someone else secretly want their job; not realize it's a separate real job in the process; or actually HAVE their job on the project. I've seen teams where two people were meant to be the customer design input, and didn't agree, and it led to time-wasting fights for the whole group around them, with people taking sides on issues and duplicate work being done. I've seen plenty of QA teams forgetting about the spec, developers not reading or forgetting about the details, and other errors of omission that prevent design from being fully effective.
5. Do you have decision processes that are functional in your company - or do you regularly have meetings that bog down with "votes" or too many inputs, and open more issues than they close on a regular basis? This environment won't scale well to adding players especially in design discussions. (If your team is arguing with the designer about whether to use radio buttons or checkboxes, you have a dysfunctional decision process which means you are wasting resources and time.)
6. Is there enough time in your shipping cycle to actually add design as a separate process? Not a trivial question to laugh off; mistakes made early, in requirements and design, are much easier to fix than anything after some code has been written, assuming you have processes in place to catch them before you get too far. This well-known fact doesn't make most companies happier to slow down. I think it has something to do with what's seen as "progress" and "work" in the development cycle, and the glorification of risk-taking that exists in so many software companies that have money to burn.
7. Does your company regularly bite off bigger projects than it can deliver in a release cycle? These giant projects are unlikely to be high quality when they ship after all the cuts and compromises are made to squeeze them in. Partial functionality is usually worse than no functionality because your company looks like it just didn't get what the customers were asking for. No UX person can entirely save you from this, but a good one consulted and involved in the process from the start might keep you focused on the must-haves for minimal usefulness.
8. Have you got project management to track team issues and milestones and make sure things aren't grinding down to a halt, or loaded with bugs and unresolved issues. Are they also concerned about tracking design stages, and blocks to those deliverables, rather than just safeguarding developer efforts? (Before you say "of course," maybe you should check with the designers.) These things can add up and make everyone less useful in the end; software is a team effort.
9. What will you do with the designs your designers produce -- they can make mockups till the cows of management come home from their offsite, but that doesn't mean it's useful in your process.
10. Do you have your new UX people spread too thinly to be effective -- with an average of 20 developers to one designer (who is shared over multiple projects), there will be a large number of meetings they miss; bugs they don't have time to provide input on; bugs they don't have time to file; builds or releases they didn't get to see closely enough to catch last minute errors; bug review sessions they weren't at to push for the usability/experience bugs; doc they didn't look at to see if it covers the main use cases and important details; customers they didn't have time to call or visit. And spec modifications they couldn't keep up to date. Their morale will suffer proportionally to the things they don't have time to do that decrease their effectiveness.
11. Is the UX person involved early enough to be (a) able to influence the crucial early decisions (b) and to be a true team player in the project, rather than an end-game consultant check-mark on your process? It's often in an overloaded (dysfunctional) environment that the designer or usability specialist is involved only at the end of the cycle to "review" and "bless" things. If you're tired of hearing from your new hires that they didn't know something had been decided, or that they wish they'd been consulted earlier, then you've got this problem headed your way. Remember it's much harder to effect change after code is written! And they want to be able to make an impact, otherwise they will be wasting their skills.

There are lots of ways to miss, even with good staff. I've been in good teams and bad teams for design process, but seen a lot of these failure modes. I'm keeping score of how many companies have teams that argue with their designer about radio buttons versus checkboxes, wasting valuable time in their cycle. The stats aren't looking good. But if you take care of your processes and oversee design as a separate stage and responsibility, your company can be better than that.

Wordle on Ghostweather

Playing with Jonathan Feinberg's artistic tag cloud generator Wordle, I plugged myself in (of course) and got this one (this is the "ghostly" color scheme):

Randomness is a powerful toy in design - it helps you discover things you wouldn't have seen with a purely organized eye. It's inspirational. It's fun.

Some Fun Entries in the Create the Future Design Contest

Now that the Create the Future Design Contest is open and collecting entries, it's time to point out some of the reasons I love this contest. Before I do, I should say that although I help with the site design and administration, I have nothing whatever to do with judging, which is done by a panel of engineering and research experts recruited by NASA Tech Briefs. And my opinions won't mean anything to them!

One thing that makes this contest fun are the wacky ideas - the napkin sketches, the weird diagrams, the mad scientist schemes. Some of them just sound funny at first, but are actually quite earnest. Take, for example, the "Thumbtack Remover." Or the "Personal Transport Pod" (I especially like the solar panels). (Be sure to check out the scheme for the "Personal Safety Belt" by the same inventor, which slightly resembles a super hero's costume.) And then there's the eSpider, a recyclables pre-sorter with a hand that looks like a spider.

Some of the entries have terrific images, rendered with high-end tools like Rhino and SolidWorks. Here's a student entry using Rhino to illustrate a convertible boat. Another student entry uses Rhino to diagram a medical self-diagnosis unit, called Sintomatico. And there's a student design for a vertical bike rack, using SolidWorks, which makes any design look very professional. Here's a part of a SolidWorks entry for an electromagnetic rail motor:

Some have surprising descriptions - this one for a breast exam device features a quote from a famous columnist that I didn't expect, but supports the case! This one is for handling hair-oil storage, which makes me flash back on Clooney's hair treatments in "O Brother." In another odd hair-related device, you've got to check out the Bowman, which I find hilarious. He submitted pdfs, so be sure to open them up! Some also have funny names, like the A.T.E.A.M, for the "ANTI-TERRORIST ECM-AUDIO MECHANISM."

A few words about the site and contest: While we are showing page view counts, there is no prize for page views this year. It was too much trouble to police last year. I will probably review and reset them any case, to keep them more or less believable. Please check out the entries with fewer page views right now, they are very deserving of eyeballs. There will be some form of public rating mechanism in October for another popular vote prize - development resources willing. Finally, if you like the home page, the flash banner of the Wright Brothers' plane with jet engines was done by an intern at SolidWorks, game design student from WPI Alex Schwartz. Awesome addition to the site.

If you have a blog and you post about the contest, I'll put your post link up on the site's press page.

Designing the Stop Sign (the Agency Experience)

Having just given a workshop on setting yourself up as a consultant with some warnings about client types, this video is especially apropos. What if a corporation asked you to design a stop sign?

In the Freelanceswitch.com list of client types, I think they missed the Appreciative Hands-On Committee of Passive Aggressive Cheerleaders client. Who test your design on their 6 year olds!

Thanks for the timely pointer to Steve at Tingilinde...

Cognitive Daily Roundup: Reputation, Gossip, Educating Children in Math

I've been subscribed to Cognitive Daily via the Kindle, and it's been a great feed on that device. [Secrets to a good Kindle feed: Full text that's well-written, not too many links because following links is slow via Whispernet, and regular updates. Ars Technica used to be a great Kindle read, until they changed their Kindle format to just a capsule intro plus link to "more." Me and a zillion others unsubbed and gave it a bad Amazon review for this. I hope it comes back as it was.]

The Kindle lets you save pages as Clippings, which makes blogging about stuff a bit easier. It's not as good as having del.icio.us, which I usually use to track things, but it's not bad.

So here's a few interesting recent Cog Sci research recaps.

How Do You Make a Reputation for Yourself? This study of business school students over time produces an unhappy conclusion. Actual cooperative behavior yields far less payoff in an impression on people than one's starting reputation and popularity. If someone starts out with a good reputation and popularity, then cooperative behavior pays off.

It turns out that your reputation for cooperativeness is only affected by your behavior if you're already popular. If you're not popular, it appears that no one takes notice of your behavior, so it has no impact on your reputation. People with lots of social connections can build a good reputation -- or a bad one -- with much more ease than people with few social connections.

This is not good news for the average workplace and the hope of objective performance evaluation. This study doesn't get at some of the root causes for reputation and popularity independent of behavior, so there's more work to be done here.

Related albeit indirectly, The Economic Value of Gossip, recapping a NY Times article, "Five Facts Prove No Match for Gossip, It Seems." People are more willing to believe others than their own eyes.

The donor was told that the source of the gossip didn't have any extra information beyond what the donor could already see for himself. Yet the gossip, whether positive or negative, still had a big influence on the donors' decisions, and it didn't even matter if the source of the gossip had a good reputation himself. On average, cooperation increased by about 20 percent if the gossip was good, and fell by 20 percent if the gossip was negative.

Now for something completely different. My brother just had a baby girl. As a woman in technology, I've spent a certain amount of time annoyed by my educational past and stereotypes about women in math and science. I'm tired of hearing about how girls aren't good at spatial and 3D tasks. (Especially since I've been working in the CAD industry for the past few years.) There's some interesting hope for new kids out there, now.

Video Games May Reduce Gender Gap in Spatial Ability, and spatial ability is key to many important math and science skills. Apparently after a few months playing Medal of Honor (but not after playing a non-combat game), both girls and boys improve in their spatial reasoning ability. The improvement lasts after game play stops, too.

Also, Children Learn and Retain Math Better Using Manipulables. Giving them blocks to count and do multiplication with helps them understand the reasoning, not just do memorization. But parents and schools need to invest in these kinds of toys.

Puffins!

From a recent trip to Maine (gallery now posted here)...

Let Your Designers Design!

We all know now that good design is a crucial element in a crowded market. But just because people in your company have strong feelings about design, doesn't make them good at it. Some of their ideas may be good, but that doesn't make them good at executing either. In the worst cases, they both think they have good ideas and think they can execute, and they can do neither. (Remember, incompetent people don't know they are incompetent.)

Signs of the problem in your org:

1. You have designers on staff, but they're demoralized and frustrated. Designers are a special breed of person, more likely to leave when they can't accomplish what makes them tick than many others; they're driven by their skills and talents more than promotion opportunity inside a company or a domain in which they work.
2. Consensus-driven culture has ground projects to a halt. You can't break out of decision-making meetings with a clear goal, and there are too many cooks involved. Because the designers aren't empowered to make the final design decision, and other (incompetent) people are weighing in or fighting with them. (See Scott Berkun's recent take on this, and an old take on why products don't end up usable that covers all this organizational stuff too.)
3. You may have a lipservice executive level belief in design as important (ever since Apple made it profitable), but you have no headcount for it, and no org process for it. There are no goals in the marketing pipeline that focus on it, there are no metrics to measure it, and it's no one department or person's job. It's handled diffusely, and not managed effectively.
4. Secretly, you or other middle-level managers think design is a technical thing, or the "fun" part for the technical folks, and it's best handled by developers as a kind of prize for the good ones. Don't bother trying to hire in this climate!
5. Final decisions about what gets in the product and what's shippable are based on criteria or opinions that don't know much about how customers respond to your stuff. Bugs that in a one-in-a-million system configuration cause a crash are prioritized about correcting a layout problem that makes you look amateurish, or a typo that makes you look like a busload of idiots.
6. You think it's all about the documentation - the customers just need to read more.
7. You outsource all of your visual design, and that's what you mean by "design" anyway.
8. You didn't realize people get degrees today in usability, human factors, interface design, interactive design, etc. In these degree programs they learn the correct ways to collect and interpret data, deliverables that communicate at different levels of fidelity, how to go from abstract to concrete, how to validate designs, and how to prototype. Corollary: You also think design is work that's "obvious" and easy, probably also because it doesn't involve writing (much) code.
9. You don't have actual project managers on your staff. You make it someone else's job, usually a development manager's; this means design as a phase and design deliverables are not scheduled and monitored in the way that code production is. Instead, it's all "where's that damn spec, we need to start making this thing."
10. Your designers are actually trying to steal the project management, so they can get some control over the process, but this is leaving them too busy to actually do design. They schedule meetings to get stakeholders together, they try to get the PM's to articulate what the heck the requirements are, they hire visual designers, they call customers... they never actually get to design, except after hours.
11. You've got innovation projects going on in your company, but there aren't any designers working on getting things right from the start. (Chances are, they are too busy with 9 and 10 to be contributing even if invited.) But basically you feel that design is "icing" to make it look pretty after the big ideas are implemented. You think the real breakthroughs come from technical ideas, not ideas that come from watching people work or new interaction techniques or novel workflows. Never mind how expensive it is to get requirements wrong up front and have to "fix" things later. (There are any number of software studies on this, drop me a note if you want refs. I've seen startups go under from this, before they even got out the door with their product.)
12. You've got internal folks like usability testers who are told they "facilitate" group processes but aren't empowered or able to make overruling design decisions. This is explicit support for consensus design or committee design, dangerous when everyone else is opinionated but incompetent.

Okay, I admit it felt good to get this list off my chest today. It's not the last time you'll see the subject cross this page. Let's hear it for design moving up the org chart; and for middle management and technical management understanding there are skills that might help with product big picture and end-game success!

Photos of Venice, April 08

I am finally getting these together - a sample from the week in Venice in April. There are a few unusual or creepy ones, because Venice can be rather weird, as well as the more typically touristy shots. Also notice how much laundry - why is it prettier in other countries?

Consulting References (How-To and Advice)

Having just finished a talk at the Boston MiniUPA conference on setting up as a consultant (an honest tell-all), I have collected a handful of references I wanted to share here. They're not necessarily the obvious books/links on consulting, but they informed me in one way or another.

• The Four Hour Work Week, a book by a crazy man that nevertheless gets right to the heart of your time usage and accounting for starting and running a business. Some good tips in it for testing out new business ideas on the Internet, and advice on kicking out your worst customers and clients who abuse your overhead.
• Getting Started in Consulting, by Tim Weiss.
• Talent is Not Enough: Business Secrets for Designers, by Shel Perkins.
• How to Be a Rockstar Freelancer, by the founders of FreelanceSwitch.com, a great resource site for design consultants. This is available as an ebook on their site for $29 too.
• An article from Salon, "What Every Freelancer Should Know." Especially the part about taxes.
• Some sample contracts for freelance work to modify, especially the engagement agreement to have a client sign.
• A few articles on borderline-bogus IT consulting pitches and firms, starting from Scott Berkun's The Problem(s) With Consultants (he is himself one, but more of a writer/speaker these days), Cringley's Truth About IT Consultants, and The Half-Truth About Consultants. Don't be one of these kinds of consultants.
• My observation on consulting is that a lot of jobs and clients are difficult, in that what they want is often not what they need or what you should do for their project success, and sometimes you need to cut that job down to manageable from a business and project perspective. Or cut it off entirely, if it's costing too much in unpaid time and stress. See the excellent (and funny) 12 Breeds of Client and How to Work with Them. Applicable to people who work inside organizations for multiple stakeholders, too - common for designers.
• FreelanceSwitch's 101 Essential Freelancing Resources.
• MOO Cards - these little suckers thrill everyone who gets one, you've got to have a lot on hand!

Finally, I've put my own slides up: "So You're Thinking About Consulting?" (pdf). They won't necessarily make full sense without the talking parts, but I'll be running a half-day workshop on how to get started in consulting co-taught with Greg Raiz of Raizlabs this summer. Stay tuned!

Mandatory Post on Twitter: A new form of MUDding?

Everyone else is doing it, so I'm posting about Twitter too. I admit I've been enjoying it, probably more so since I have less time than I used to for blogging, Bloglines, and keeping up with friends on LiveJournal.

Everyone who writes about Twitter has to compare it to other things. For me, it's most like what we did in MUDs when I used to hang out there (a kind of chat world, see MUDs and MOOs on wikipedia, and my book about one). We used to connect while working, and "idle" much of the day, but "wake up" to post links to things we thought were interesting, or to say what we were doing "in real life." We even watched TV together in a MUD group. In a MOO, you had to do something special to direct comments to someone, just like you do in Twitter (where you prepend "@name"). Voila, c'est Twitter; except that in a MUD you had to go somewhere to be in the space by connecting specially, it was less public, and a lot more synchronous. Plus not searchable from "outside" the MUD client. So, okay, it had some differences.

Other things it's like: How people change their "status" message in a chat client, and sometimes riff off other people's status messages. That's not archived in the way Twitter history is, though. And it's like SMS, in that's it's terse, but for a party. And it's like a very slow chat room, where no one really knows who's listening in or who might look at what you said later. (Watch out.)

Brief geeky research aside: There's an old paper by Clark and Brennan (1991) that's a goodie among people who study CMC (computer-mediated communication) that describes potential aspects of communication media, including whether they offer co-presence, visibility, co-temporality, and sequentiality of messages. To really consider how Twitter stacks up, you would also want to consider system features that characterize rich Internet communication tools, such as the potential for users to have private one-to-one and multi-party conversations that aren't recorded, what kind of message size is possible, availability of threading/sorting/filtering tools, ability to archive exchanges and/or prevent it, possibility of editing posts after they are made, ability to block messages from certain people.

Twitter is less synchronous so less co-temporaneous than internet chat or face-to-face or phone talk, the reviewability is possible but only fair in practice (in that you have to do some work to go back in a history to check what you missed), and interruptions between two-person exchanges are common. Threads are possibly even impolite. Private messaging is possible depending on the client used. Editing isn't possible after posting, but deletion is. The message length constraint strongly restricts the type of exchange that can happen, by design. Blocking of a kind is possible. You can filter your list of followed people to a "favorites" list if you want.

Which reminds me - all communication media allow for genres or registers of speech/writing, in which the style and topics can differ tremendously across groups of users and occasions of use. Generalizations about how people use Twitter will only be applicable to local groups of followers and their following. So I won't try. Give a look in and see what you think.

Because of the very public nature of Twitter, we get the possibility of search tools like Summize. Which means you can look up keywords or people and find out what's up with them. You can even subscribe to these searches by RSS, so thatt you can follow public chat that mentions your favorite product or TV show. (When I mentioned FIOS once, someone who works at Verizon started "following" my comments on Twitter.)

Summize also allows for interesting meta-search applications like Twitter Spectrum, allowing you to contrast word environments for two terms. Just for fun, here's a few charts of contrasts I find interesting. You can see who's talking more about what here.

Anywho, I'm enjoying Tweeting, although I still miss ElseMOO after all these years.

CHI 2008 Conf: Usability Considered Harmful

The premier human-computer interaction conference, aka CHI 2008 (pronounced "kai" not "chee") was in Florence, Italy this year. After missing last year's in Silicon Valley, I went despite the ruinous exchange rate. (Other local colleagues went to Italy for the conference, but blew it off to go skiing instead!) One of the more interesting and crowd-drawing sessions was the paper by Saul Greenberg and Bill Buxton, "Usability Evaluation Considered Harmful... Some of the Time." Following it was commentary by Bonnie John, Tom Rodden, Dan Olsen and the ever-sharp CHI attending audience. Here's Saul and Bill listening to the commentary:

An initial note: CHI as a conference has a huge percentage of academic and research attendees. How to make it "relevant" to the "practitioner" audience is a regular concern of the conference committee. Why research isn't necessarily relevant is one of the reasons for their paper, I think. (And for things I've spoken and written about in the past, too.)

The main argument was...

...We too often perceive … an unquestioning adoption of the doctrine of usability evaluation by interface researchers and practitioners. Usability evaluation is not a universal panacea. It does not guarantee user-centered design. It will not always validate a research interface. It does not always lead to a scientific outcome.

Their supporting arguments were these:

• CHI reviewers require evaluation, and usually quantitative (lab study) testing results, as a part of a submitted paper (reflected in the submissions guidelines)
• Quantitative usability studies are often the wrong type of study for certain kinds of design: such as inventions in prototype stage; other types of user study may be more correct for these.
• In an argument familiar from Buxton's book Sketching User Experiences, a focus on usability evaluation too early in a development cycle produces poorer final results than will experimenting with more design concepts (or "sketches")
• Early-stage technical innovations that are disruptive or paradigm changing may produce poor or ambiguous user testing results, which may prematurely kill them off as research topics -- when long-term these ideas might find audiences and produce large-scale social or practice change after adoption.

Greenberg and Buxton argue that CHI has too great a focus on scientific results (and poor ones at that), rather than on supporting good design and invention.

“Science has one methodology, art and design have another. Are we surprised that art and design are remarkable for their creativity and innovation? While we pride our rigorous stance, we also bemoan the lack of design and innovation. Could there be a correlation between methodology and results?”

Comments ran the gamut from polite disagreement about the counts of types of papers accepted at the conference, to observations that publication-treadmills don't allow time for disruptive risky innovation that can be studied longitudinally, especially for students in grad school. Saul asked the CHI audience to review papers differently -- after all, the audience there constitutes what gets in, and what's considered good work. What constitutes good work worthy of acceptance is in the hands of the reviewers in the room! Finally, it was noted that different, "riskier" work of a design or featuring ethnographic evaluation instead of user testing is regularly accepted at other conferences in the same ACM family: DIS, DUX, CSCW, even Ubicomp and UIST.

Most difficult, for me, is the idea that the CHI reviewing audience has the credibility and experience to review riskier design work that doesn't come along with (the right kind of) user study. With mostly academics and researchers on the reviewer list, I question whether this audience has the depth of practical design experience and credentials required to recognize and talk about "good design" with credibility. What do I require for credibility: having done a lot of real-world design, and having evaluated a lot of products from a customer-centric perspective. When I say "real world" I don't mean academic design - where it's notoriously easy to go wild and crazy. In the context of a business or large organization, the kinds of compromises that designers face are what separate the real good from the mediocre.

I would like to repeat that human computer interaction is not fully represented at CHI. The conference is just one forum. While it's true that CHI publication counts more than most others to researchers in this field, it doesn't necessarily represent the full range of activities and professional expertise in the broader field of interaction design.

Mini-UPA conference in Boston

Boston's mini-Usability conference is coming up on May 28 at Bentley. This is a reasonably priced one-day event that attracts quite a local crowd, and not a few non-locals. I had a good time at this last year, when I was a speaker on online community design. This year I am speaking about life as a consultant, and mistakes I made in my first year. Here's my abstract:

One year ago, I quit my job and started consulting full-time, after 10 years of industrial wage slavery. I was financially successful in this year, but made a lot of mistakes. I managed to fall into bad headhunter relationships, make mistakes in my accounting that required a 101 class to fix, became thoroughly confused about whether to be incorporated or not, and generally made a lot of newbie mistakes with a handful of clients ranging from garage startups to established software firms. Other local consultants gave me advice and I learned from my mistakes. I can tell you how I did it and what I could have done better; and how it compares to what other local consultants say. I will cover:

• Your use of the internet to advertise yourself (search engine optimization, job sites, Linked In, blogs, etc.)
• Portfolio work
• Branding (logo, name, etc.)
• Proposals
• What to charge (the many factors and equations; plus: "they're charging WHAT and someone is really paying it??")
• Headhunters and job offer pressures
• Basic accounting and expenses to track
• ... And other things I learned the very, very hard way, like the portable office equipment it might be nice to own because the client site is a cave with rocks to sit on.

You'll get a handout with the Top 10 Most Important Consulting Considerations in case you too want to do this!

BIO:Lynn Cherny has a Ph.D. from Stanford that she hasn't used in years, except for some statistical skills. She has 12 years of experience working at and/or managing interface design at companies including TiVo, Excite, Adobe, The MathWorks, and AT&T Labs. Her current consulting identity is Ghostweather Research & Design, LLC. She can be reached at lynn@ghostweather.com.

There are interesting names on the list of speakers, including Jared Spool and Chauncey Wilson, Beth Loring and Joe Dumas, plus a host of other local employers. The talks range from research methods to design case studies, with a bit of business thrown in (thankfully, for some of us!). It's even multi-track, reflecting how many submissions they get. And their cocktail hour is fun and well-stocked.

NASA Tech Briefs: Create the Future Contest Awards in NYC

New York City, April 2008: In New York last week, the Create the Future Contest award winners were honored in a nice ceremony. The awards were presented over a swanky dinner and drinks at the Water Club in NYC. (Good thing I changed when I got there: a classic NYC taxi driver let me off early saying, "I can't turn right here. You have to cross there and go under that overpass, past the helicopter landing, and then it's on your left.")

While I was pleased for all the qualified entrants-- almost 1000 this year, a record probably due to having a website -- I was most happy about the two student category winners. Jeremy Connell, a junior in Virginia, actually used SolidWorks for his cargo carrier design. Here he is holding the paper edition of NASA Tech Briefs, which features his winning design on the front cover! Jeremy would like to get a job designing boats. I'm also hoping he'll intern at SolidWorks if he's available and we can work out the details.

The winner for the Transportation design category was student Corban Tillman-Dick, who is actually an economics major at Johns Hopkins. He's the designer of a more efficient engine, the Internally Radiating Impulse Engine. His brothers were all present for the award; they are trying to get funding to base a company on this design. Sadly, their father, who helped with the design, died suddenly in a car accident a few weeks earlier and could not attend with them. Here is Corban and a brother with Jeff Ray, CEO of SolidWorks:

A few other winners -- Joseph Hollman designed a beacon locator for mine workers, shortly after a serious mining disaster last year. Here is Joseph receiving his award:

And Dr. Ajay Mahajan and colleagues were there to receive their Medical category prize for a 3D ultrasonic neuronavigation system for realtime image guided brain surgery.

I'm afraid my camera batteries, bought for €1 in a Venice shop, did not hold out long enough for everyone's prize.

As you may recall, I was the consultant that designed and project managed the contest site for SolidWorks. This was the first year that SolidWorks was a major sponsor, as well as the first year there was any website featuring visible entries (and featuring a frenetic, viral "page view contest" which galvanized many students, not to mention bots). Jeff Ray also accepted the SolidWorks award for "Product of the Year" given by readers of NASA Tech Briefs, entirely coincidental with the co-sponsorship of the Create the Future Design Contest. (Obviously the contest was not judged based on software used by any entrant, and SolidWorks did not participate in the judging in any way.) Instead of a boring talking shot of Jeff Ray, I like this pic of him talking over drinks to our student winner who used SolidWorks.

Apart from the chance to see the sometimes wacky but always creative inventions, I got a lot out of seeing young designers do so well in the contest up against professional engineers. And in general, there were a lot of ideas that could make the world a better place with the right exposure and funding. Providing webspace for inventions and inventors is a good thing for us to do. We'll (and I'll) be doing the site and contest again this year! Stay tuned for another June launch.

Punitive Luxury at the Marriott Marquis

I just got back from an overnight work trip to NYC, where I was booked into the Marriott Marquis at Times Square. I disliked this experience, in oh so many ways.

How about this example of a nasty use of technology? Here's a $7 bottle of Fiji water that's on a weight-sensitive stand, the kind you see in heist movies where Tom Cruise is rapelling in to help himself to something way more fun than water.

The note on this bottle says, "Your account will be charged when this bottle is off the stand for more than 30 seconds." There was dust on the stand, because even the maids are afraid to disturb this gem. [Updated to add: a friend tells me her father stayed in another Marriott in a large American city and ran into the same thing. As he was going into his room, a cleaning woman in the hall warned him, "Don't move the water, don't move the water!!"]

Note that this was a room I was paying $400 for a night. I don't know what I got for it, to be honest. The sink wouldn't drain. And they also wanted me to pay $4.99 for their "tv-on-demand" DVR episodes of "Medium." (My first response, oh so naive, was "Wow, this hotel has DVRs in their rooms, awesome! I guess it's about time since we've all got them at home!" Then I saw the price for everything on it. Give me a break. Where's that warm fuzzy -- oh yeah, this isn't a brand experience, it's a technology scam.)

I didn't bother to try the Internet. They had more neat technology where their elevator collection resided. So many floors and so many attractions in this hotel, that they had a special scheduling routine in place: you enter your floor number, and it tells you which elevator to go wait beside. Despite this clever system of crowd management, their elevators were so busy that staff were escorting the more upset customers (incl. me) to the freight elevators for more realistic timing on their people-mover service. When I got home, I came up with a few "nice" and possibly more interesting uses for their weight sensitive technology, instead of threatening their fleeced guests.

I know a lot of architects who love good hotel design -- but let me say, it's not just about architecture, it's about all the amenities and experience, including how they use their in-room technology. I'm still outraged!

Open Source vs. Organizational Code

An interesting, free article from Harvard Business School working papers: Exploring the Duality between Product and Organizational Architectures: A Test of the Mirroring Hypothesis (scroll down for PDF link). From the abstract:

Specifically, products are often said to "mirror" the architectures of the organizations from which they come. Such a link, if confirmed empirically, would be important, given that product architecture has been shown to be an important predictor of, among other things: product performance; product variety; process flexibility; and future industry evolution. We explore this relationship in the software industry by use of a technique called Design Structure Matrices (DSMs), which allows us to visualize the architectures of different software products and to calculate metrics to compare their levels of modularity. We use DSMs to analyze a number of matched-pair products--products that fulfill the same function but that have been developed via contrasting modes of organization; specifically, closed-source (or proprietary) versus open-source (or distributed) development. Our results reveal significant differences in modularity, consistent with a view that distributed teams tend to develop more modular products. We conclude by highlighting some implications of this result and assessing how future work in this field should proceed, based upon these first steps in measuring "design."

I've seen work on this subject before (including similar diagrams that show code module relationships)-- not usually in business press, although it's nice to see this get a wide audience. Recently I read Becky Grinter's essay in HCI Remixed which reflects on Parnas 1972's "On the Criteria to Be Used in Decomposing Systems into Modules" and on Conway's Law: The structure of the code mirrors the communication of the organization that developed it. Or lack thereof.

More than that, I'd say the UI design and the broader corporate outside facing design often reflects the organization's internal structure and different goals. Marketing groups that don't talk to engineers, executives who don't get along, customer support and sales who don't speak -- these things all hit heavily on the face that a customer sees for the company. All of which can be reasons why "User Experience" as a group can't live low-down in any one part of a company, especially a big one.

More personally, I've started using R, an open-source competitor to MATLAB, and wondering about this stuff as I try to track down the open-source resources I need. I've been enjoying ramping up on R despite finding the documentation available and code quality of some libraries very hit-or-miss. MathWorks's doc team and their demos are one of their strengths. Regardless, R has a growing number of books and sites, and I've learned some simple concepts faster in R than I ever did for the same concepts in M-code. In many ways, I prefer the language to M, despite my belief that open-source usability is generally very poor [here we might have a discussion about usability of the language itself, for different tasks, versus that of GUIs or tools available for programming support, but I'm still thinking about the topic].

In short, R works; plus it's free, and it's powerful and extensible. (For just how free is free: compare about $4K for what I'd need for statistics and database access plus some reporting, with $0K, and that's pretty free.) I wonder how the code compares to to MATLAB's.

Microscopic? Or Jelly?

The latter... from my new membership to the New England Aquarium, I think this is a kind of Japanese jellyfish. You can see everything it does, inside and out.

Business Week Top 50 is Out; Autodesk at TED

The "best performers of 2008" (already?) are up in a list at BusinessWeek Online. Despite what many (including BW) would call a recession, there were some healthy net incomes. Their interactive chart (sortable) is kind of fun; but in an interesting discrepancy, the sector identified for each company does not agree with their print mag's reporting, and this makes me a little suspicious of their rankings which were tied closely to sector identity. Apple (#6 this year) is called a hardware company in print, but IT online.

Handbag maker Coach is #1. Multiple good years for them. But skipping to the technology companies: Apple at 6, Cognizant Technology Solutions (an outsourcing consulting firm) at 19, Amazon at 23, Autodesk at 28, Google slipped to 34, and Microsoft is at 41. In companies not run by a white man in his mid-50's who looks distinguished and politiciany, we have just 2 women, at Avon (a company that got written up as having a "makeover" and looking "pretty") with Andrea Jung, and PepsiCo with the fantastic Indra Nooyi (Indian woman). I don't drink Pepsi because of her, but I like it better because of her.

How about that Autodesk, a company alma mater of mine! (Adobe wasn't there this year, but was last year on the strength of the CS3 release.) The writeup is especially interesting if you were there at Autodesk working on this area: "Autodesk's latest software makes architects and engineers more productive-- and injects visual oomph into their designs. Its new three-dimensional software, including Revit Architecture, lets architects model a building's face and sides in the same drawing. Even midprice PCs can run the programs, and that has expanded the [company's] market."

Autodesk had Revit (a local Boston-area acquisition) for many years, so it's hardly new. Midprice PC's are pretty peppy nowadays, so that claim may be true. For all the old-boy cronyism and management nastiness I thought it had, Autodesk does have a smashing smart CEO who cares personally about product design and usability, and now employs some of the best interface designers I've ever worked with (particularly from the Alias acquisition).

[Updated to add: Autodesk and Carl Bass were in form as sponsors at TED this year, with one of the Alias products making high-profile news too: check out how Alias's innovative Sketchbook Pro (rebranded for Autodesk of course) was used for the during-conference blogging report up at "Autodesk at TED2008". The Autodesk message is that they're about "design innovation" and sustainable design. Convincing with that great research and design team from Alias, for sure!]

Top 50 history: The BW Top 50 from 2006 (Apple at #1), and from 2007 here (Google at #1).

Netflix Contest and Recommender Systems (short history)

I'm fascinated by the Netflix challenge: Netflix is offering one million dollars for an algorithm to improve recommendations based on movie ratings. Along with this go intermediate "progress" prizes of $50,000 per year the contest runs. The prize leaderboard is interesting reading, in that you can see who is entering teams, their results, and sometimes a bit about the team. Team Bellkor is a group of researchers from AT&T Labs, my first employer out of grad school. (I don't know these particular folks.) Netflix provides an interesting example of one company "funding" research at another company. The research lab folks are getting papers out of it, of course, probably the most important thing they need to do in a research lab (money comes second; although these days, proof that their work can impact a real business domain may beat everything else).

In another AT&T Labs connection, the Netflix prize FAQ cites an excellent overview paper on evaluation of recommender systems (pdf), co-authored by a colleague of mine, Loren Terveen, from the HCI department I was in at Bell Labs. Loren worked closely with Will Hill, one of the Bellcore researchers who (co-temporaneous with Pattie Maes at MIT and Paul Resnick) kicked off the work on recommender and ratings systems that you now find implemented all over the Internet. Recommender systems as a broad theme include all user ratings on products or comment postings (such as Amazon book ratings, or ratings implemented in almost all forum software now); they're intended to help others find good quality content by aggregates of ratings from other users, not from editorial oversight which is costly and therefore scales poorly to large amounts of content. There are important tweaks you can apply to your system or your filtering mechanism, such as "ratings of people like me" versus ratings of everyone, of course. (Netflix has some version of predicted "ratings for YOU", specifically, which I haven't investigated in any detail.)

I recommend glancing through Loren et al.'s paper, for a refreshingly meta perspective on a piece of technology that now defines a lot of assumptions behind what is called "web 2.0." As a more personal note, I wander among mostly non-research types these days, and the hot topics du jour (like "social networking") tend to get dropped into web system design discussions all the time, with a kind of naive "of course we need it" mentality. I can only sigh at how old I feel sometimes. Critical evaluation and careful implementation do matter, even for all the stuff that made it out of research projects into profit-making companies and community-platform toolkits.

As another personal note, I'm generally pleased by the level of researchy savvy I detect in the Netflix prize FAQ. Hey, if you're hiring at a software company, consider investing in some serious research-minded folks for competitive advantage!