Jon Udell writes “We posted weekly.pdf to the website. Isn’t that good enough?” (via Calendar Swamp). People don’t want to and shouldn’t have to structure what they write to be legible to a computer. It is hard enough to write prose that people understand, let alone also making it independently understood by a machine. I think the secret is to make software interfaces that allow people to naturally collect information and let the computer sort and publish it to other computers. Calendars are a great example of this, as are blogs.

Weblog software took a common need, periodic publishing , and created a simple interface that provides people with the kind of media they want to generate: front page news, archives by category or date and so forth. With the advent of RSS feeds, people could enable their blogs to be computer-readable without painstaking markup. They had already structured their information in the nature by which it was generated.

Likewise, it is natural to record calendar information overlaid on a timeline with day, week, and month views that mimic traditional paper visualizations of time. This enables the software to generate structured data without people needing to think about it.

Publishing structured data with today’s software is evolving to be a fairly natural, low-tech act; however, subscribing still exposes too much of the gears in the machine. Let’s take a look at an example of generating and re-using structured calendar data.

Larry Cannell discusses critical mass syndication by applying the technology to the needs of parents. Using Google Calendar, it is quite easy to register and create a calendar with events. The software makes it possible to publish a snippet of html that can be embedded in a website to syndicate the data. This enables a PTA website to publish events in an automatic fashion.

The calendar can be maintained by someone who does not know any details of html or ics, but it still needs to be set up by the technical crew. Likewise in the blog world, you need to be exposed to XML feeds and non-human-readable gobbledygook to connect your feedreader to the right source. The next step in the evolution of the web will be to provide more usable connections between applications.

It is a dicey thing saying no to customers, especially when they pay big bucks for not only the software license, but a bus load of consultants that integrate and customize the software for their deployment. However, I believe that the same truths hold as when you hear from 50 customer in 500,000 and you really cannot give each person what they want. You need to listen them, then give them what they need, not necessarily what they are asking for. But they best way to say no is to actually convince someone of a different perspective, that they gain something by the omission of something else.

When old tricks don’t work…
People create their own myths about how a feature works. Humans naturally develop a mental model of what’s going on, of cause and effect. When an interface is well-crafted and the designers made the correct assumptions, most people will develop a mental model that is close to reality. Sometimes the best of intentions go wrong. For example, many webmail interfaces have a “Block Sender” button on the screen where people read their emails. When someone gets an offensive, unsolicited email, they think “ugh. I don’t want to get this junk from some creep,” so naturally they click the “Block Sender” button. The problem is that the spammers aren’t using their real email address — they fake something up and rarely do you receive an email twice from the same sender. Nowadays preventing spam needs to be more sophisticated, most webmail systems often offer the option to “Report as Spam” which is much more effective since there is a back-end service that develops heuristics on what is spam and what isn’t, so even if the sender doesn’t match, the new spam might be recognized and blocked. Not only that, but if people block the sender of every spam message they receive, they quickly develop gigantic blocked senders lists, which many back-end mail systems aren’t optimized to handle. So when a customer licensing email says, I want a “Blocked Sender” button on the main screen of the app for a new deployment, I tell them the back story as I understand it and explain that people really want to just prevent junk mail and we should make the options that will help with that first and foremost. So far it has worked out, the insightful product managers agree.

When something better comes along…
Knowing the what people really need is especially tricky when transitioning from an old interface to a new one. Whether upgrading a version or switching vendors, individuals always have a hard time at first adjusting. I keep running into this with the “Nickname” field in email. It’s really hard to say no to any feature that exists in Outlook. For better or worse, it is the most popular desktop email program and webmail apps have historically emulated as many features as they could. So, most webmail apps have a nickname field. Now this feature was important in the days before auto-suggest, in the early 90s when we all had 100MHz processors running Windows 3.1 and before Web pages had Javascript. Instead of looking up a contact or typing a long email, you could choose a short nickname for someone.

Ok, maybe it isn’t needed any more, but what harm is it? Aw… come on, it’s just one more field. One of the huge usability advantages of web applications over desktop applications is that they tend to be simple. This design often emerges from necessity based on technology limitations. As the technology improves to offer a more desktop-like experience, designers and product managers have an opportunity in this new space of moving beyond the cluttered desktop experience to offer a simplified interface that is no less powerful. By offering a nickname field, you are telling people they need to manage their address book, they need to go through and pick their favorite people or people they communicate with frequently and set them up. In this new age of vast information stores, software is becoming more adept and figuring out what you need and giving it to you without requiring a setup process. Auto-suggest is an innovation along these lines. You can just start typing the first few letters of someone’s name and their full name and email address pops up. By taking away a feature for some people, we make sure that they know and new people know they don’t have to rely on the old way of doing things, and we streamline how they use the application and allow the software to work for them and for them to do less work.

The art of design is making choices. We develop models of how people would be most effective in accomplishing their tasks. We need to be particularly careful when a new option replaces an old one — sometimes redundancy is a good thing and sometimes too many ways of doing the same thing make an interfaces cluttered and confusing. It is a delicate process to guide people into patterns where they will be most successful.