But it ain’t necessarily so. What if everybody had two inboxes – email for essential communications, the must-reads; and something else, the inbox for non-essential information, for dipping into and serendipitously discovering something useful or entertaining.

I can think of multiple ways to implement this. I think, ultimately it will have to be built in a backwards compatible manner, on top of email (maybe Raindrop can lead here?). But since everybody’s on Twitter these days I thought I should poke them in the right direction.

From my Twitter bug report:

What I want to be able to do is to send a tweet that will only be seen by one user but which doesn’t cause them to receive an invasive notification. For example, imagine if my bank tweeted me every day about any credit card transactions on my account. That would give me the chance to spot fraudulent transactions but it wouldn’t overload my email inbox.

To me, it seems like one of the biggest hurdles for most people in terms of social search or networking tools is the cost of building up their networks, so this would provide a quick and easy way around that.

from The Rise of GoogVark

Hmm. Really? Aardvark already had Facebook Connect and Gmail contact importing. Is clicking one button and maybe typing your password too much for most people?

If so then XFN and things like the Google Social Graph API are the way to go.

I think a bigger hurdle for companies trying to get into the search game is the extra cognitive effort it takes people to decide if they want to do a Google search or an Aardvark Search (or hey, a MrTaggy search). One assumes the acquisition will at least address that issue for Aardvark. We still don’t have a good answer for companies that don’t get acquired by Google though.

PS: look at that, I’m blogging again!

Adobe’s first big Apollo app is an Internet video application codenamed Philo. The pervasiveness of Flash Player created multi-billion dollar Internet video startups powered by the Flash video format. The Philo team hopes to expand the display size and quality of distributed videos and get publishers encoding using the latest Flash video encoders. Publishers can brand the entire video player, delivering MTV content in what looks like a MTV video player, or a Rocketboom-themed player…

Great!! thats just what I want – an MTV branded video player to play MTV videos and a Rocketboom branded video player to play Rocketboom videos. Awesome!

This is not the future of the web people, and it certainly isn’t the future of the desktop. Please try to resist.

If, as it seems, the iPhone’s software will all come from Apple then all the development fun will happen in the browser, in particular in whatever version of Safari the shiny little device ships with. And it will be fun if Apple give us, as developers, access the right information. I’m talking here about that information coming from the user’s fingers. After all, who wouldn’t want to create the kind of effortlessly intuitive interfaces the Jeff Han showed off in his TED talk?

Will they let us though? There are a few directions Apple could go here.

1. Be scrooges and filter out multiple touches before they get to us, only letting the user interact with web pages one finger at a time, the others controlling scrolling probably. Web Dev Chorus: Booooo!
2. Give us the raw events from all touches but leave it up to us to do the hard lifting of working out which mousedown/mousemove/mouseup events came from the same finger. Web Dev Chorus: Grumble, Grumble, even huger javascript libraries, Grumble
3. Generously preprocess the input data for us and label mouse* Events with unique “device” identifier. Web Dev Chorus: Yaaay!! Go Apple!

The iPhone definitely has javascript (and may have flash), but that’s not enough. Javascript’s current way of getting information from pointing devices like a mouse, what’s called the DOM API, has no way of distinguishing between clicks from multiple sources (nor does Flash for that matter). Neither DOM 3 nor Web Apps 1.0 has added any properties to the event object to deal with multiple pointing devices. At a minimum it would be nice to standardize on a new field of the event object that uniquely identifies the input device for the duration of a mousedown/mousemove/mouseup cycle.

I would imagine Apple will not be that pushed to let javascript know about multi-touch. It will only detract from their own installed apps and introduce potentially low standard interfaces that would nonetheless be associated with their brand. However the problem will certainly come to the fore as other companies follow Apple into the multi-touch field. We might as well think about what we’d like now.

Update: Dave Hyatt from the Safari team replies…

I’ll have much more to say about this in the coming months.

…which makes me cautiously optimistic. It must be pretty exciting to be him right now.