I’ve owned one cell phone in my life – This Motorola something or other. I bought it in 2003 when I quit my job. Back then, I bought it mostly because my wife got the same one – she’s smart, and on average copying what she does works out well.
When the recharge jack died and the phone overheated after a long plane trip, it was time to shop. I knew I needed the following things in a new phone:
Dead simple ease of use for my 75% usage: calling and talking to people.
High durability. I never want to worry about dropping something I carry in pocket. Look at the scars on the above photo: that’s the mark of a well used, well built piece of technology.
Any fancy features never get in my way.
I spent 4 months looking at phones in person and developed the following simple test, knowing it represented 90% of what I’d use one of these things for:
Make a phone call
Send a text message
Add a contact
Type in a url, view it and add it as a bookmark
Look up the map for an address
Add an appointment
Sync to my desktop PC
If any of the above took more than 30 seconds to figure out, or seemed like it would take 30 seconds to figure out every time, I gave the phone a failing grade. I looked at dozens of phones and 95% of them failed this simple test for me.
The only phone that passed, was the one I bought last month – The Palm Centro:
I’ve had the phone nearly a month and I’ve been very happy. It’s slightly bigger than the Motorola, but still fits easily in my jeans pocket. The phone doesn’t have some of the latest super cool features and whatnot, but I really do not care – for what I actually do, its been great. Simple, simple, simple, with many thoughtful UI design elements. Hopefully the phone will last me, like the last one, another five years. While it lacks GPS, there’s a google maps update that gives you 300 yard accuracy by pinging cell phone towers, good enough for every situation I’ve been in so far.
Many friends point me to the Blackberry, but even the latest models were larger than the Centro, much harder to use, and their UI was downright ugly. The Palm UI, from fonts to layouts, has a superior level of care. As much as I wanted to like the Blackberry, by my standard above it wasn’t close.
I did look at the Apple i-phone, and while it looks great and has some excellent design aspects, it totally failed #2 above. I’d scratch that screen in a day, and drop the phone in a week, and after killing two apple nano i-pods (call me the screen destroyer), I wasn’t convinced it would survive my travels. I also had problems with the touchscreen keyboard: I just don’t like typing on touch screens (YMMV). It seemed designed well, but Centro’s keyboard, despite all my instincts against mini-keyboards, worked super well even with my extra-large hands.
Bill Verplank sketching and talking at same time. Had the pleasure of seeing him speak at UIE last week, and talking to him for awhile. This short video of him in action is easily worth the 4 minutes, especially if you are a designer of any kind. Among his credits: working on the Xerox Star, coining the term ‘interaction design’, and much more.
I wish I had this view. Sleek platform on mountain edge gives an amazing view over the mountains of Austria. Reminds me of my trip to the Jungfrau.
Best game of the month: World of Goo. It seems silly and pretty at first, but gets addictive fast. Download the demo version here (hard to find on the site).
Gladwell’s article, titled Late bloomers: Why do we equate genius with precocity?, makes one major mistake in not addressing the questions researchers have about the notion of genius. Entire books have been written with the premise that there really is no such thing as a genius in the sense most people use it, and that the distinctions of ‘prodigy’ and ‘genius’ are so abused and misunderstood as to be useless.
This essay uses the idea of ‘the young genius’ as a point of leverage for late bloomers, suggesting that you are either one or the other (this is the core thesis of economics professor David Galenson’s book, Old Masters and Young Geniuses, whom Gladwell quotes in the article). Dualism of this kind is dangerous and nearly always misleading. It brings to mind that old joke: there are two kinds of people in the world, those that think there are two kinds of people in the world, and those that don’t.
The more I’ve studied creative thinking the more convinced I am these sweeping categorizations are 1) supported by selective research 2) not the best tools for those who want to follow creative paths themselves.
Gladwell wrote:
Picasso was the incandescent prodigy. His career as a serious artist began with a masterpiece, Evocation: The Burial of Casagemas produced at age twenty. In short order, he painted many of the greatest works of his career, including Les Demoiselles at the age of twenty-six. Picasso fit our usual ideas about genius perfectly.
But what are those ideas? He doesn’t say. I think most people imagine young Pablo, if he were a genius, learning to paint largely on his own. I think it’d be a surprise to learn his father was a painter, and taught Picasso to draw and paint from a very young age, sent him to an excellent art school as a youth, and encouraged his trips to Paris, where he quickly made an amazing assortment of connections in the art scene before he was 25. Similar family and community support can be found in the story of Mozart (his father was also a musician who trained him early). Who your parents were is hugely significant in the history of prodigies and geniuses.
Another fact that doesn’t usually fit our idea of genius: at the time Picasso painted Evocation, he was basically starving in Paris, in a situation similar to Van Gogh’s a few decades earlier, faced with the choice on many mornings of buying food or buying paint. Picasso had been working seriously, by most definitions, for years before Evocation was finished. We don’t think of people with prodigious, gifted talents starving and struggling, but there he was. Another counterpoint is that Picasso had a ridiculously vibrant painting career that spanned decades – one of his greatest works, Guernica, was made at the age of 56. The passage from Gladwell hints that his 20s were his best work, but that’s not true. It was an intense time of productivity, but not the only productive time in his life.
Gladwell continues:
Prodigies like Picasso, Galenson argues, rarely engage in that kind of open-ended exploration. They tend to be “conceptual,†Galenson says, in the sense that they start with a clear idea of where they want to go, and then they execute it. “I can hardly understand the importance given to the word ‘research,’ †Picasso once said in an interview with the artist Marius de Zayas. “In my opinion, to search means nothing in painting. To find is the thing.†He continued, “The several manners I have used in my art must not be considered as an evolution or as steps toward an unknown ideal of painting. . . . I have never made trials or experiments.â€
This is an outright contradiction of Picasso’s performance in the documentary The Mystery of Picasso, where he spends 70 minutes revealing his creative process as a series of experiments, risks and gambles. Over the course of an amazing hour we see him take risks, make mistakes, and continually reinvent and change individual paintings. It’s a rare and amazing thing for any artist to expose themselves in this way, much less the difficult and reclusive Picasso, but he seems, on camera to take deep pride in his creative experimentation.
Nothing can stop Picasso from having contradicted himself, but if he did, both ends of the contradiction have value in this discussion.
More to my point, there is a huge inventory of creators who have been called geniuses who mention experimentation as a critical to their creative process. They include Frank Lloyd Wright, Hemingway, David Byrne, Miles Davis, Paul Simon, and on it goes.
But what is not mentioned is the amazing social network that enabled and supported young Picasso to do what he did. Dependence on the effort of others is not a factor exclusive to late bloomers. On his first trip to Paris, he quickly met Max Jacob, who taught him French and French culture – they’d share a room for years. He had many friends in the art scene in those early years, including Andre Breton (founder of surrealism), Gertrude Stein, and Henry Matisse. Not a bad crowd to get advice from for an artist in his 20s. He also befriended artist George Braque, and through collaboration they would develop a little thing called cubism together.
This is what politics is to me. Someone tells you all the trees on your street have a disease. One side says give them food and water and everything will be fine. One side says chop them down and burn them so they don’t infect another street. That’s politics. And I’m going, Who says they’re diseased? And how does this sickness manifest itself? And is this outside of a natural cycle? And who said this again? And when were they on this street? But we just have people who shout, “Chop it down and burn it” or “Give it food and water” and there’s your two choices. Sorry, I’m not a believer.
– John Malkovich, Esquire Magazine, Nov 2008
Why designers succeed and fail in organizations is mostly a matter of opinion as there’s little data to support theories or make claims. To help ground discussions on this subject I ran a research study on why designers fail – exploring the psychological, skill and organizational reasons why designers, and people who work with designers, believe designers don’t achieve the results they desire (PDF of survey questions here).
The survey consisted of 41 issues, divided into three categories: Psychological, Skill and Organization. Each participant ranked each issue on a scale from 1 to 5, with 5 meaning the issue was highly significant in explaining why designers fail, and 1 meaning least significant (3 was identified as a neutral value).
The 389 survey respondents self identified as (rounded up #s):
Designer
34%
Project manager
17%
Programmer / Tester
12%
Usability engineer
10%
Group manager
7%
Business / Marketing
4%
Documentation
1%
Other
17%
The top 16 issues, ranked by average scores were:
People in non-design roles making design decisions
4.18
Managers making design decisions w/o design training
4.14
Designers don’t seek enough data before designing
3.92
No time is provided for long term thinking
3.81
Not receptive to critical feedback
3.69
Lack of awareness of the business fundamentals
3.66
Only lip-service is paid to “User centered design”
3.64
It’s never made safe to fail or experiment
3.62
Designer’s power diluted by too many cooks
3.60
Over-reliance on one kind of design style
3.54
Poor collaboration skills
3.51
Poor persuasion / idea pitching skills
3.49
Poor communication skills
3.49
Poor understanding of domain
3.48
Pressure to use first solution, not a good solution
3.45
Big Ego / Expects others to cater to their whims
3.41
Average scores per grouping
The average scores for groupings showed little different in weightings: there was no single grouping of issues that proved to be significantly more important in explaining why designers fail.
Organizational issues:
3.37
Skill issues:
3.15
Psychological issues:
3.11
Managers vs. Individual contributors
(Note: these charts are quick and dirty. If you’d like the raw data to generate better ones, just ask).
One research question of the study was to see how individual contributors and managers varied in their thinking on failure. 49% of those surveyed identified as playing a lead or management role.
The results showed extremely high correlation between the opinion of individuals and managers.
Designers vs. non-designers
Another research question was how designers and non-designers results would compare. The results showed only minor variance in how designers and non-designers view causes of failure.
The results showed extremely high correlation between the opinion of designers and non-designers on why designers fail.
Conclusions
Many top reasons for failure are not typically considered design issues, such as collaboration skills, persuasion skills, and receiving critical feedback.
General consensus on top issues: managers, non-managers, designers and non-designers all had highly similar scores.
Nearly half of all respondents took time to write in additional issues and thoughts. There was a great deal of interest in discussing this topic further.
Background and Disclosures
This survey was designed primarily for qualitative use and as a basis for further discussion and research. I’m sure there are flaws and bias in the study design but I believe this study is valuable anyway.
The issue list was based on 3 things: my own experiences managing UX design training for Microsoft from 1999-2002, many years of debating this question at drunken design conference receptions, and this discussion on a previous blog post.
The issue descriptions listed above were modified to fit in the post – see the actual survey if you’re suspicious of leading questions or other survey bias issues.
I’m looking for folks to help continue this research. If you’re interested leave a comment.
One question that came up at my session on Leading breakthrough projects at UIE 13 last week was how to design an office for a team of designers.
I’ve been asking around but haven’t found either a well written description of what a manager decided and why, or some research into how to structure spaces for creative teams.
Joel Spolsky’s writeup on the Bionic office comes close, but it’s written about designing an office for programmers, not creative types in general. This is a great start but I’m looking for more.
If you know of other writeups of office redesigns (including how to design a design studio), or research into how to design a workspace for creatives, please leave a comment. Cheers!
After a most interesting thread and side e-mails, I’ve developed a survey to more deeply explore the reasons why designers fail. There are now over 40 specific causes offered, and I need 5 minutes of your time to better understand how these causes relate to the real world.
Details:
The survey is open to designers and non-designers.
Goal is to better understand both causes and perception of causes of failure.
Prizes: $100, $50 and $25 Amazon.com gift certificates.
Survey has 7 questions, all multiple choice, and should take less than 5 minutes
You can be anonymous, but it you want a shot at prizes, put in your email.
Results will be presented at UIE13 next week – and on this site
(Note: If you try to take the survey twice on the same computer, it wont let you. You’ll get a “Thank you for taking the survey” page).
I’m finishing up my slides for a talk next week at UIE 13 in Cambridge, MA. The title is “Why designers fail and what to do about it”.
I’m sure there are a zillion reason’s designers, like any professionals, fail. What I’m looking for are habits you’ve identified in designers you think sets them up not to achieve what they seem to want to (making great, easy to use, things).
Here’s a sample of the long list I’ve identified:
Assuming other people understand design and care about good design
Not seeking power when power is required to deliver on an idea
Being shy / passing opportunities to pitch ideas
General incompetence (not as good at designing things as they think they are )
My goal isn’t to bash designers here, and in the talk I offer solutions & positive examples.
Instead here’s what I’m hoping for: there are many proffessional designers in the world, but not many things we can buy that are designed as well as i-phones and Porsches – why is that? How do designers fail, whether it’s their fault or not, to bring great things to the world?
I’m thinking there are 3 categories: Failures of the designer’s psychology, Failures of the designer’s skill, and failures of the organization.
Love to hear your opinions – thanks.
Probably the best single website for explanations, background and summaries on what happened, what it means, what might happened next. Includes comparisons to previous crises.
For a few hours today my nice little RSS Feed, with close to 20k subscribers, was replaced by a pile of ads for some record label called True Tiger Recordings.
As much as I often consider ditching the whole writing/speaking career to be a lead singer in a rock band, that’s not what happened today.
A few kind folks, Peter, Kirill, Dave, Adam, Neil, Greg, Meh (hey, that’s the name you left) – let me know almost immediately that something strange was up, and as I don’t check my own RSS Feed often, and they saw it well before I did. Thanks guys, I’m in your debt.
Running a bug bash is a dirty secret of software development. You won’t read about them in software engineering classes, or in agile method workshops. But some managers, when overwhelmed with undocumented bugs and not sure what else to do, demand the whole team stop what they’re doing and get as many bugs into the bug database as possible. This is what’s known as a bug bash, and often they’re a waste of time.
It’s true that a proper QA effort, or test-driven development, minimizes the need for this sort of thing, but few software organizations truly qualify. Hell, many so called “first class” organizations don’t have any testers, or a quality assurance plan at all. I bet bug bashes are one of the most common QA techniques used in the world.
And they can be useful – but the most common mistake is doing them by half. A half-assed bug bash sends the message software quality is lip-service. But doing it the right way can turn a project around, raise morale and sharpen a team’s ability to find and manage issues.
How to run a successful bug bash:
Don’t create panic. If you say “Tomorrow! Everyone find bugs! Aaaah!” You are creating a panic and look like an idiot. You should know a week or more in advance that the bug counts are soft, or the database needs scrubbing, and line up leads and key players to support the effort.
Freeze the build. You can not do a bug bash on a moving target: you invalidate repro cases and bug findings. Pick a build, freeze it, and make sure no one, NO ONE touches the live codebase during the bugbash. This should go without saying, but you never know. If it’s your first team wide bugbash make sure the entire programming team understands this basic rule.
Show what good bug reports look like. Remind everyone crappy bug reports create extra work. Provide two bug report examples: one good, one bad. In the good example show well written description, clear repro steps, and a search for duplicate bugs. In the bad, show incomprehensible descriptions, impossible repro steps, etc. If you don’t provide examples, don’t expect people to magically know what you’re looking for. Finding 1000 crappy bugs that need to be heavily cleaned up is a waste of everyone’s time.
Have an area or type of bug to focus on . Saying “find bugs” is a shot in the dark. It shows you have no clue what’s going on in your project. Think through what the weakest areas are, or what types of bugs you are most afraid of, and designate them the primary goals of the bug bash. Or offer bonus points (e.g. bugs in area 6 are worth x2) for people who find the specific type of bug most valuable to you.
Clear the afternoon from everyone’s schedule. A bug bash should be an entire team activity and a half-day is the perfect amount of time. Everyone should be working on the same goal: getting good data into the bug database, and getting that database in shape. If it’s voluntary, or only half the team is asked to do it, the bash will fail. People will smell you’re not serious about the effort, and will contribute accordingly. Get permission to reschedule all team meetings for that afternoon to later in the week, and send out a new meeting invite to the team for the entire bug bash time slot. Include details (see below) on where bug bash HQ is, what the prizes are, etc.
Get support from big shots. Brad Silverberg, my VP on Internet Explorer 4.0, used to file bug reports regularly. When bug bashes started he’d set the tone: everyone gets involved. With the support of leaders it sets the tone of how important the activity is, and eliminates the BS excuses people find not to participate (“If Fred, our best programmer is doing it, I should be doing it too”). Find the key players on your team, either key leaders or the star programmers, and get them to help promote and contribute.
Have a bug bash HQ. Finding bugs can be a social activity: have a bug bash headquarters. Grab a conference room, order pizza and beer, and invite people with laptops to hang out and find bugs together. This invites people to help each other find repro-cases, share knowledge and bug database tricks, makes keeping a scoreboard easy, and makes the bug bash a proper morale event. A case of beer and few pizzas costs $60. Well worth it.
Keep score and have real prizes. Geeks are competitive. Use this to your advantage. Any bug database allows queries for open bugs by date: Get this up on a website or hallway monitor and show it in real time. Buy some nerf weapons, dinner gift certificates, or even some X-box video games, and have them visible at HQ – give them away as prizes, or set up a betting pool: $10 per person, and the winner gets the pot. You can get fancy and have special prizes for most twisted bug, the bug least likely to ever get fixed, etc.
Create rival teams. If you are totally poor, use ego prizes. Have the designers challenge the programmers, or the marketing team challenge the management team. Throw down: “I’ll bet the whole marketing team dinner at Ruth Chris’ my 3 reports can find more bugs than your whole team can”. If you don’t have cash, bet embarrassment: loser shaves their heads, has to dress in costume the next day, has to wash the opponents cars, etc. Get two sets of people who have some built in animosity or rivalry, especially if it’s well known, to openly challenge each other. This rivalry will draw more people in, if only to follow along. Do this once and you’ll have a tradition to build on for the next bug bash.
When Making things happen came out in March, I did a few talks here and there to help promote the new edition, including a stop at a little place called Microsoft, in Redmond, WA. They videotaped the talk and it’s now available online.
You need to be running IE, or using the IE plugin for firefox, for the video to play. Sadly it appears to run on Windows only (I know, I know – its not my choice):
Title: How to make things happen
Description: What are the secret tactics used by successful project managers? How can people in any role, from development to management to design, benefit from their playbook?This fun, fast-paced, and interactive talk, loosely based on the bestseller Making Things Happen (formerly known as The Art of Project Management), explains how to make good things happen, and how to triumph over powerful people who are annoying and frustrating. Bring your toughest questions and situations for the Q and A, where Scott gives away signed copies of the brand-new, updated edition of Making Things Happen.
Every artist was first an amateur. ~ Ralph Waldo Emerson
I get hundreds of comments and emails in response to the post on how to write a book. Here’s another interesting, and life-grounding, question from the mailbag:
I found your website hand thought it was awesome. I watched your videos and decided I could use some advice from you.
My house burnt down 3 weeks ago in Burnsville, Minnesota. I lost a 38 foot RV, a 69 Plymouth Fury Convertible, and monster truck and trailer in the driveway and my 16 years old sons car he worked on so hard and never got to drive. I also lost 5 animals in the fire and that really hurts. I still have my 3 children ages 23, 16 and a 10 year old daughter who is having night mares with all this life changing overnight experience. Guess what? I want to write a book about my life and how it changed so quickly. I am very grateful we are all alive and ok. Like everyone else I dont know where to start. I am living my worst night mare in a hotel gong on a month. We have nothing but the cloths we were wearing that day. Any advice would be greatly appreciated. Please contact me.
Very sorry to hear about your loss. I do hope there are local government agencies or non-profits that can offer you some assistance. Books aside, I do wish you and your family well.
On starting: there is no single easy way. Everyone is different. There are tricks I list in this essay on writing hacks, but some or one will work for you. The truth is how you start doesn’t matter, but if you wait for a perfect way you’ll never get started. If that essay doesn’t help, here’s additional advice:
Plan to write every day. Writing a book is a marathon. It’s more important than you work a little every day, than how much you work on any particular day. Are you good with self discipline and forming new habits? If yes, great. If not, that is likely the real skill you need to learn.
Plan to come back. One trick is to remember that the real work in writing is editing, something that only begins when you finish a first draft. I plan to come back later and revise, cut, rewrite and do all kinds of work for the second draft. The “writing” part is just the beginning. Having faith in the next draft has a freeing effect. There’s no pressure to get things right, or even to make them good, on the first draft.
Go chronological. In your case you’re writing about things that have happened, or are happening to you. Great. Pick a date, say a week before the fire, and write about what happened every day from them to now. It could be as simple as two or three facts per day, or memories per day, or your recollection of your thoughts on those days, whatever you like. But anchor on time as the spine of your writing. It creates an easy way to divide up your memories, and to trigger thoughts or recollections. You then might choose to go to your family and friends and get their stories and recollections on every day, giving you even more material to work from.
Draft an outline. An outline can be one page long or fifty. It depends on how much detail you feel you need to get going. If it’s your first book, I’d strongly recommend writing a two page outline that covers, at a high level, all of the major events or points you want the book to cover. It’s a good test: if you can’t write two pages, you probably won’t be able to write a book. If you can write a two page outline, put it aside for a day or two and then come back and re-read the whole thing. Is there a better order to explain events? If so revise. And then pick one of the chapters and get to work. Repeat.
Keep a notebook with you. Have a place to write down ideas and thoughts about your experience and keep it with you all the time. Your rule should be whenever a thought crosses your mind, no matter how strange or personal, you write it down. Worry later if its good or interesting, but in the moment, commit yourself to writing something down. I have piles of old notebooks, and go through one every few weeks.
Read books like the one you want to write. Learn from other writers by reading their work. For every “how can I?” question you have go find a book and see how a successful writer solved the problem. If your book is a memoir, many great writers have written books about their personal experience with tough times. Check out Joan Didion’s The year of magical thinking, about her experience with having two loved ones become seriously ill at the same time. It can help to see how other writers have tackled the same type of writing you’re going through.
Write every day. Even if it’s just for 5 minutes, even if it’s just a sentence or a few words, sit down and write every single day. You have to get used to how it feels to sit there and that only happens if you put your ass in the chair every single day. Find a slot in your schedule that you can protect (early mornings or late nights often work) and ask family to respect that time.
Have a plan for staying motivated. A book will take 500-1000 hours of work to write. That sounds scary, but most people watch 1000 hours a TV every year (4 hours a day).Writing is straightforward to do, but you have to keep showing up. Think about your reasons for staying motivated. Create a writing calendar where you can leave a note, or a mark, every time you sit down to work. This will help get some positive feedback every time you put in some effort, even if you’re not very productive on a given day. Your output from any writing session doesn’t matter much provided you continuing to work on it day after day.
Work towards a complete first draft. You can only write one draft at a time, so focus on the one in front of you. Don’t worry about how many drafts you’ll need. A draft needs to be complete enough that someone can read it and give useful feedback to you. If an entire draft is too, work towards having a complete chapter. Then two. Then more. Ask for feedback from people whose opinions you trust. And with that feedback you’ll be able to decide how to revise for your next draft.
What is Project 10100? Project 10100 (pronounced “Project 10 to the 100th”) is a call for ideas to change the world, in the hope of helping as many people as possible.
Why is Google doing this? The short answer is that we think helping people is a good thing, and empowering people to help others is an even better thing. Here’s the long answer.
How many ideas are you funding? We have committed $10 million to fund up to five ideas selected by our advisory board.
As best I can tell you don’t need to execute the idea or even have a plan. They are paying for the idea itself. A creative thinkers dream! Except of course you likely lose control over the idea after you win your cash.
Hadn’t heard of this before, but there’s a design unconference here in Seattle this weekend: InfoCamp 2008.
$50 gets you in for two days of DIY sessions on information architecture, user-centered design, librarianship, and information management. According to their description, It features an egalitarian, community-driven format in which presentations are designed and delivered by attendees.
I can’t say how accurate this thing is, but it’s both a great piece of design (By Terry Colon, formerly of Suck), and a polarizing commentary on immigration policy: this will either anger you or make you happy. I know for sure my great grandparents would never have made it through this – Instead of being here writing this, I, like they were, would probably be a peasant farmer somewhere in Eastern Europe.
What I’d like to see are: 1) similar flowcharts for other first world countries. 2) Similar flowcharts for 50, 100, and 150 years ago in the U.S.
45 days to go. We’ve got wars, bailouts, and natural disaster zones galore. What’s the best way to decide how to vote? Here’s my take on advice for how to pick a president in 1400 words.
Microsoft’s Outlook may be the world’s Rolodex, but they have not figured out how to link up all the latent connections that sit inside our Outlook address books. Put another way, they have the ends of the network, but don’t know how to tie them together!
In your email is a latent network of most of the people you know, and how often you talk with them. The Outlook add on – not made by Microsoft – called Xobni (pronounced ZOBNEE, and named for Inbox spelled backwards) looks through all the mail on your machine and figures out who knows whom by who is copied on which emails. In other words, your emails naturally contain your social network. It would be easy for Microsoft to simply ask your permission to contact the people in your email list, and Outlook contact database, and ask them if they were willing to join your Microsoft social network.
There is a ton of social network data in our cell phones (who do you call/text most often? Talk longest with?) and email applications, and a simple app could mine that data and build, or at least enhance, networks from it.
The problem is that for many people Outlook is no longer the primary contact list. Anyone using Linked-in or Facebook depends on those sources as virtual contact lists. Facebook wisely offers to import contacts from many sources when you create your account.
The surprising thing to me is that there isn’t a wikipedia, or craigslist, of social networks. A free, non-corporate, social network that protects it’s users by charter against the pressures of corporate raiding of personal social information.
