Thursday, April 29, 2010

UIE Web App Master Tour, day 2

Sitting at the airport waiting for my flight home this morning, I thought that I'd checkin on the second and last day of the Web App Master Tour in Minneapolis.

The bar was set high after the first day I was pumped to hear more. Bill Scott started us off by stating that designing interactions is like performing magic on stage. It is in the details and in the performance. The slightest mistake destroys the illusion. And then he covered examples of what were those details that you have to pay attention to if you want the delicacy of the illusion to be preserved.

Then, Ken Kellog spoke about the path that his research team took to bring change to the marriott.com online reservation system and main page. How you have to ensure that you do no harm to the cash cow and the importance of negotiation. Also the fact that even if you have 100 stakeholders in a project. Each one is still a person.

After lunch, Luke Wroblewski shared results from his research regarding web forms. Most notably, how to handle validation and get better input from the user. He then went on to conclude that the best form might be no form at all. Discussing things like Facebook connect for registration and using alternate methods of input like GPS, camera and the like.

Mark Trammel from Twitter then proceeded to walk us through the latest redesigns to the sign-up process of Twitter and how it was driven by the model of engagement that they have constructed through their own user research. He explained the concept of the magnet, the hook and the glue. Which is used to take users through the engagement ladder from curious to casual and finally, to a committed user.

And finally, Jared Spool closed the circle by finishing up the concepts that he had introduced in the very first talk by discussing about the importance of having a vision that you can articulate. That their research concluded that it is an essential component of the recipe for companies that were successful at creating compelling user experiences.

In short, 2 days of interesting talks and discussions. Well worth my time.

In addition, this was my first time in Minneapolis and I felt right at home. I had the whole evening to soak in the city and I am glad that I did. I walked to a restaurant by the river called Ginger Hop and mingled with the locals. Had a really good vegetarian curry and a local beer called Farm Girl. Traded baseball storied (always useful to have one of those handy) and finished the evening catching a movie at the MSP International Film Festival. (the movie was called The bone man and it was very good. Got a little weird at the end)

Awesome time and I am really looking forward to the next time I come back to Minneapolis or the next time I cross paths with someone I met this week.

Wednesday, April 28, 2010

UIE Web App Master Tour, day 1

Just thought that I would write a little something before I walk into the second day of the UIE Web App Master Tour in Minneapolis.

So far, it has been a really fun and interesting experience. Lots of interesting people and really great presentations.

Jared Spool opened with an interesting presentation about some of the research that he and his team have been working on to try to define what the required skills that a design team needs to have to solve the difficult problems that today's application can bring to the table.

Stephen Anderson also shared his work on the psychology of the user and how what is known about psychology can help make applications more seductive. He walked us through the process of using mental notes cards to help with brainstorming. (I want a deck of those cards)

In the afternoon, Hagan Rivers spoke about navigation hell. That is a really large topic that seems a little dry. No worries, the presentation was pretty interesting and had 2 little gems in it: Navigation is its own application and Navigation is like storytelling.

Christian Crumlish spoke about social media. He broke it down into its basic components and the patterns that make things social. With simple examples and a few anti-patterns to be aware of.

The day ended with Jason Fried that walked us through the redesign of the project overview page of the Basecamp application. He even joined the conversation with his team live from the stage to comment on an iteration of the design that had just been posted on their chat. (he didn't like it)

Looking forward to today's presentations, I'll check in again tonight or tomorrow.

Wednesday, April 14, 2010

The geeks don't matter

Oh yes, I said it, the geeks don't matter. Or maybe I should be more nuanced: As a consumer group, the geeks don't matter as much as they used to.

After the latest round of announcements from Apple about the iPhone, All over the internet, on blogs, FaceBook, Twitter and wherever you choose to point your browser, you'll find a whole lot of angry geeks. That is, if you are yourself a geek. Otherwise, you're probably not reading those articles.

People are angry that Apple is further building their closed system. That they are removing user's freedom to choose. That they are forcing developers to write Apple specific code by blocking cross-compilers and all that. They vent online making all sorts of arguments about how they won't use Apple products and how they have lost their trust in apple that has finally become as bad as Microsoft.

Vent and rant all you want. Rest assured however that it doesn't matter. It will not change Apple's decisions. You, me, the geeks, are not the main customer group for Apple. See, we never were. This is perfectly consistent with Apple's past behavior and strategy.

And geeks all over should be ready to suffer even more and get angrier. Not only are geeks not the main customer group for Apple. But they are bound to loose their status as the main customer group of most other technology companies as well. The biggest accomplishment of Apple over the past few years, culminating with this week's announcement, is to demonstrate that if you don't aim your technology product to a technologically savvy audience, you end-up making bucketloads of money.

This means that other technology companies will also realize that they can stop caring about the requests for openness from the technology elite. They can safely ignore this because it is much more lucrative to sell to the normals than it is to sell to the geeks.

Some will argue that this is not the best for the consumer. But then again, companies rarely do things because they are best for the consumer. They do things because they are best for themselves. (tobacco, agro-industry, oil companies, etc...) Why would a company like Apple (or Microsoft, or Google or Amazon) voluntarily limit the amount of revenue they can extract from their customers just to preserve their rights to choose the content that they consume or the way they consume it.

Consumers will continue to purchase proprietary devices with arbitrary limitations because they are not interested in how it works or why it works in a particular way. They just want to get something that satisfies their needs, that works and that they can afford.

I guess us geeks should get used to this. The era of large technology companies run by geeks building products for geeks is over.

Hey... we had a good run, it was fun while it lasted.

Monday, April 12, 2010

An exchange program for employees

A few weeks ago, I read an interesting post from Darren Barefoot who was asking What if we traded employees like hockey teams trade players?

It is an interesting concept but I think it might be too much of a culture shift to be practical.

As someone already pointed out in the comments, large companies already do this between departments. However, I work for a smaller company and there are no other departments to shift the employee to.

Although my employer is not big enough to do this, the company is old enough to have employees that have been there for more than 7 years. Some are choosing to leave. Not necessarily because it is not a fit or are unhappy but because they don't want to stagnate. There's an urge to see elsewhere.

What if we sort of went half-way? What if companies were setup to participate in an employee exchange program? Take 2 software companies in the same town. One is specialized in iPhone development and the other is specialized in writing software for medical devices. Both are staffed with a mix of programmers that are competent but some of them need a change of pace and are feeling the need to keep their knowledge fresh. They could swap one or 2 programmers from each side for 3-6 months.

As an employee, it seems like a good situation. Your employment status doesn't change, you get to satisfy your wanderlust and you get to learn new skills.

As an employer, you benefit from having people trained in the other company's specialty and in addition, you get to learn a little bit from how the other company works. There might be an opportunity to streamline your own practices. Since you're trying to involve employees with similar skill level, they will contribute to your own projects. Maybe not as much as a fully ramped-up employee but it is like getting some training for a lesser cost.

There is always a risk that, after the exchange, the employee might want to stay with the other company. It is probably possible to mitigate this contractually. Through a no-hire clause or through some compensation agreement. But I feel that the openness of the exchange program would make it easier for companies to be better prepared for these unplanned departures.

I have been working 12 years in the same company. I like my job, I don't want to quit. But if I had the opportunity, I would be interested in seeing how it is done somewhere else. If just to satisfy my curiosity and possibly learn a thing or two.

Monday, April 05, 2010

After the gold rush

Recently, a colleague of mine was cleaning his desk and found a copy of After the gold rush (the book, not the album) that he had borrowed from me years ago.

This reminded me of how I felt about that book. When I first read this book, I was just starting my career and I was very impressed by that book. It is one of those books that I would have put on the must-read list for any software developer.

I really liked the idea of software being thought of as an engineering discipline. I wanted software companies to make better software and the process to become more predictable. I used to work for a company that made shrink wrap software and that was known for the death-march style of software development.

Well, the gold rush came and went, and came and went. Software development had changed but I have also changed. More than 10 years later, I don't think the same way at all about programming. In the past 10 years, we have tried to formalize, productize and normalize software development. And as much as we tried, it pushed back and wanted to go back to its true nature.

I think that software development is a craft. Something that skilled, trained people do. There is still a category of software that is purely engineering; like software that runs nuclear power plants and the space shuttle. But that is a tiny fragment of the software that gets written in the world. In the past few years, software has become so entrenched in our lives that it has become very personal. Software is not about machines but more about people.

People don't like to consider software as a craft because they associate craftsmen with the old guy making custom vintage furniture replicas in his workshop. But there are other large-scale human endeavours that are also run by craftspeople. Movies are one great example. Movies have been compared with software development before but I'm looking at it from the point of view of the skill required. Movies involved large budget, tight schedules and lots of specialized, highly technical labor. In many cases, actual engineering is involved. But in the movie industry, engineers that work on a movie set are considered craftsmen and there is no negative connotation to this.

Like software, there is a method to the creation of movies and there are ways to manage these large projects even if it is not all guesswork and gut feel. So I think that, after the gold rush, we should embrace the craft of software development. We should learn to deal with it as such and learn to manage it properly. Instead of trying to force-fit an engineering or manufacturing process that will never really fit.