If I could be Steve for a day….

Don’t take this too seriously, okay?

But since Guy and I were talking about stuff, and it turned into a little chat about blueskying future technologies, I finally told him I’d take some time to tie toegether some of the stuff I’ve been thinking about. And somewhere along the way, that turned into a couple of blog entries — this one about things I’d love to see Apple do to take advantage of emerging technologies, and a second (still to be writen) that focusses more on my server-service-running side, sort of as a bluesky of the kind of things I hope to do with Hockeyfanz some day.

Don’t take this too seriously, okay?

But since Guy and I were talking about stuff, and it turned into a little chat about blueskying future technologies, I finally told him I’d take some time to tie toegether some of the stuff I’ve been thinking about. And somewhere along the way, that turned into a couple of blog entries — this one about things I’d love to see Apple do to take advantage of emerging technologies, and a second (still to be writen) that focusses more on my server-service-running side, sort of as a bluesky of the kind of things I hope to do with Hockeyfanz some day.

But first, the superspecial disclaimer: None of this has anything to do with any project that might or might not be happening over at the Mother Ship. If I know of something, or even heard a rumor about it — I won’t talk about it here. If I talk about it here, adn it actually happens, then I’ll look like a miracle worker, but in reality it’s probably because other people have figured this out, too. none of this, period, is based on information I know, just stuff I’m making up because it’s fun to talk about. Okay? okay… Onward.

If I could be Steve for a day, here are some of the things I’d like to do, or set in motion. There are three technologies I’m watching very closely — and I expect them to converge such that we don’t think of them as separate things, but as aspects of our on-line experience. There shouldn’t be visible seams or arbitrary barriers here — they’re legacies we need to grow beyond.

First, e-mail is my key technology. It is what many of our lives revolve around to a greater or lesser degree. E-mail, web, and to a lesser (but growing) extent Instant Messaging are the primary ways people interact with the Internet.

E-mail, however, is challenged, and to a good degree threatened. E-mail also isn’t always the right protocol to use for communicating — it’s the convenient one. For e-mail to survive and thrive, those challenges need to be dealt with.

First issue is e-mail’s consent model, or more properly, lack of one. Unfortunately, the spammers and other miscreants have taken advantage of the net’s historical openness and screwed it up for everyone. On the other hand, why is anyone surprised this happened? It always happens, so proper controls should be built in from the beginning. We didn’t do that with USENET, and USENET was basically killed by it. We had a chance to learn from that with e-mail, and didn’t. So now, we’re going to have to backfill it.

This means, simply, putting the control of access to a user’s mailbox in the hands of the user. Right now, the model is I can/will email you unless you stop me – if you can. that has to change, to I will ask permission to email you, but unless you grant it, I can’t.

I can already see some of you twitching and mutting challenge/response — and yes, that’s one component of it. But it goes well beyond challenge response. In reality, it’s consent management.

In consent management, I can issue tokens that can be used to access my mailbox. I have the ability to add limitations to those tokens, such as only works from this acccount, or only works for 48 hours. I can create a token that says the first time I see this token, store it’s source and accept mail from it, so that I can hand a token to, say, a vendor, and the vendor can e-mail me — but nobody else the vendor gives the token to can. Imagine having a phone number your bank can use, but can’t sell.

This kind of system includes a whiteist of accepted addresses, a blacklist of known bogus addresses. It needs to have some kind of challenge/response as well, as one tool to help manage the unknown. For this to work, though, there has to be some way to reliably and unambiguously embed these tokens in e-mail, too, so they can be carried around and recognized.

The ability to build a kick-ass consent management system is something Apple could do with some commitment — because Apple controls both the mail application and the address book and they can be tightly coupled, they have the ability to create very easy-to-use versions of these tools — but adding the consent management to a person’s address book, and having mail.app manage the consent.

The second aspect of email is the push aspect. Every time you send someone e-mail, you generate an interrupt. that’s one of the reasons e-mail spam is so annoying, where paper “junk mail” is so much less annoying. You deal with paper e-mail on your schedule. you deal with e-mail on my schedule. OR his schedule. On anyone’s schedule but yours.

Many people think of e-mail as paper mail, only done in electrons instead of ink. Many marketing groups that have moved to e-mail have come out of the print marketing world. To some degree, that makes sense; the creation of collateral is similar to some degree — but there’s a significant difference. If you don’t recognize and manage that difference, you will almost guarantee piss off your users.

And that difference is that, to the receiver, e-mail is like a phone call. it’s interrupting, it’s distracting, and it’s unplanned. So while content can be treated like print collateral, contact should be treated like telemarketing. Miss that distinction, and you’ll regret it.

So the second thing I want to see happen to e-mail is integration of an RSS aggregator. The aggregator is something the user has under control (consider the e-mail/RSS decision to be another aspect of the consent model — it’s up to the receiver to decide WHEN to accept your message, and one way to control that is to let the user decide email or RSS for reception), but once the message is accepted, there is really little difference between an RSS message and an e-mail message, especially given the increasing move to HTML e-mail.

So what I want is a single application that combines my e-mail, an RSS aggregator, and my safari browser, since increasingly, all three technologies are going to deal with HTML and/or XML, and there’s no reason to separate them out because of arbitrary differences in delivery. I’d even argue that safari’s bookmarks ought to be integrated into the address book, because increasingly, all of this contact info is converging, and the differences between a URL to a web page, an e-mail address, and a URL to an RSS feed are increasingly arbitrary.

So Address book is your control panel to the internet, managing your contact info, how you interact with them, and what access you’ve given to them. And the combined RSS/e-mail/browser beast is how you interact with them.

The second technology is blogging. Apple’s done a good job of enabling Apple customers to communicate and share — look at filesharing, web sharing, mac.com. All very useful tools, and combined with quicktime, iMovie, iPhoto and other tools, make it easy to share content for the non-technical user.

So why do none of the tools encourage written communication? Writing tools are, at best, primitive (mac.com’s home page templates…).

What could Apple do here? How about Buy iBlog. It’s a great little tool for writing to mac.com, or to local sharing systems. It imports from iPhoto. It’s a very nice blogging tool like one Apple could write — Apple just didn’t write it. so buy it, and give it away as part of the mac.com account. enable mac.com users to blog overnight.

Apple has the pieces to really take a strong leadership position in the emerging blogging world. But AOL is already beta testing their blogging universe, and it’s clear Microsoft is working on blogging tools for MSN. it bothers me that Apple-the-innovator seems to have missed this one. But I don’t think it’s too late; it’s just that Apple would join the parade, not lead it.

Giving blogging tools to mac.com would give blogging tools to Apple. All that’s needed then is a standard policy on what Apple people can and can’t do. Microsoft seems to have figured it out. Are there risks of leaks? Sure. But are your employees mature and professional, and do you trust them to follow the rules? (hint: if you don’t, you have bigger problems in your organization). lay a set of ground rules on what you can and can’t do. Enforce them fairly and humanely. and watch what happens when your employees become your unpaid evangelists, and your spare time tech support.

(hint: many Apple employees already are. they just do so from under cover. Isn’t it better to have it out in the open where it’s easier to monitor, and people aren’t afraid of losing their jobs for trying to help? — it is in Redmond!)

The third technology I’m watchign closely is Instant Messaging. IM is a weird beast. At one level, it’s e-mail for people in too much of a hurry for e-mail There are very few intrinsic differences between e-mail and IM, except for the way they’re delivered. They’re used differently, but frankly, these technologies should converge, and the difference becomes transparent. We have e-mail in one App, and IM in another, because different groups wrote them. At some point down the road, IM is simply another tool.

All of this needs to merge: IM, e-mail, HTML, XML, RSS. It’s all different flavors of the same thing. We’re not even talking about hammers and nails vs. screw drivers and screws, we’re talking about flat vs. phillips. Or #2 phillips vs. #1 phillips.

So it all belongs in a single App, using a single coherent interface. You control it via your Address Book, which manages who you know, how you contact them, and what your consent tokens are. it also grants consent tokens to those you know, so they can contact you. And whether you use IM or SMTP to send the message, or you read your iMap box or an RSS feed, it dosn’t matter. Most users don’t care about those technical issues and don’t want to. And increasingly, those issues don’t matter. Content is one thing, how that content gets frmo point A to point B is another, and the consent that governs whether it gets through and when is a third. But it all ties together into one single thing.

It’s not e-mail, it’s not IM, it’s not RSS, or XML, or HTML, or IP, or PPP, or any of those things.

it’s communication. And the rest are details that simply don’t matter. So let’s stuff them in the back closet with the other techno-geek things we’ve already realized don’t matter to the average user, and simply give them the environment they want to use the way they want, and quit forcing them to learn different tools for doing things that are different only because we used to think they were — but they really aren’t.

You might also want to read:

1. My thoughts on Steve in the Guardian Since I’ve written about Apple for the Guardian in the past, they reached out and asked if I would again. It’s now live on their...
2. Thanks, Steve. I  happened to be having coffee today with an old friend today, someone who’d worked with me back at Apple. I got the news on...
3. Steve, Please Buy Us A Carrier! Steve, Please Buy Us A Carrier! | Monday Note: The idea came up during a “what if” conversation with my wife Brigitte, while walking along...
4. Will Steve Blog? Picking up on a comment that I think deserves a bit more discussion: Chuqui 3.0: Welcome Guardian readers!: ” Don’t expect Steve ever to blog,...
5. Watch Steve pull a rabbit out of his hat! (again?) Okay, like every other mac geek out there, I was off watching the keynote. I didn’t know (exactly) what was going on — any advantage...