Google’s design is a little different from my quick mockups.  Google’s approach lets you see a thumbnail of the page by hovering over a magnifying glass.  That’s a little lower friction than the button click I had proposed.  But you can’t do too much with that miniature of the page since you can’t read it. You still have to click in and hope that the result is what you need.

In my approach you have to click to see the preview.  You get to see the full-size content, and so you may never have to actually click in to find your answer.

My mockup also highlights the matching text and scrolls to it, which reduces the work of making sense of the hit.

The Goog never sleeps and I am sure they will exceed both these ideas sooner or later.

is there anything to stop the camera from capturing multiple exposures and doing this stitching for you within the camera?  Then you could have Ansel Adams shots at the touch of a button

Today, MacRumors reports Apple building HDR into iOS 4.1:

High Dynamic Range photos are photos created using 3 separate photos captured in quick succession at varying exposure levels. The photos are then combined using some complex algorithms to create an enhanced composite photo.

Good question to ponder: why did it have to be Apple to have come up with this, and not Nikon or Canon or anyone else with imaging as its lifeblood?

A while back, I wrote:

“[The only way an iPod has communicates with you] is with its display, and that is useless when your eyes are on something else.  You already have the earphones in.  Why shouldn’t the iPod use them to speak with you? [..]

“[The system could]  pre-render text-to-speech of the tracks on the desktop before syncing to the device. The device would declare the names of the songs as you skip around: “Alicia Keys track three superwoman. (forward) four: No One. (forward) five: Like You’ll Never See Me Again.  [This verbal approach would also bring] badly needed playlists to the Shuffle.”

Over a year later, Apple make quite a hoopla over just this type of features to its third generation iPod Shuffle.  Check out its resemblance to the excerpt above:

“VoiceOver also tells you the names of your [songs and your] playlists, so you can easily switch between them to find the right mix for your mood. Without having to take your eyes off your run, your ride, or whatever you’re doing. [..]

How is this possible? First, iTunes reads your song information, then [generates] the announcements for the songs, artists, and playlists [on the computer]. Just sync your iPod shuffle with your computer and it really speaks to you.”

My original article provided details about other elements of the sonic design, including sound effects to convey how fast you were skipping between tracks, and how quickly you were rewinding.  I don’t have a recent Shuffle.  If you do, I’d appreciate if you could compare my original write-up with how Apple’s implementation really behaves.

Now that they are starting to speak to us, the next step is for our mobile electronics to listen to our verbal commands.

See also:

• Audio UI for Audio Players
• Using gestures and voice for access to key tasks on a mobile device

With a high contrast scene like a face against a bright daytime sky, you have to choose between detail in the shadows — your friend’s face — and highlights in the bright areas — like the cool billowy clouds.  [..] Is there anything to stop the camera from capturing multiple exposures and doing this stitching for you within the camera?  Then you could have Ansel Adams shots at the touch of a button

A team at Stanford has demonstrated this feature (see the video halfway down the page).

Plus those idea robbers also stole another idea straight from my head: the ability to program the camera for all kinds of tricks.

However, their model is open-source software, and so it will be limited in use to real programmers.  This is nice, but I want Nikon and Canon to let any computer-literate person write – or visually snap together – scripts to be executed by the camera. (That’s the new idea to steal.)

This is an enabling technology that would let the end-user do all kinds of tricks:

• Adjust settings & preferences according to your rules (If it’s in Manual mode, fix the ISO.  If it’s in Aperture priority mode, use Auto-ISO.  If the flash is on, drop ISO to 100.)
• Set up a lightpainting program: blink the light for 3 seconds to indicate the start of the program, then open the shutter for 60 seconds while you paint, then beep for 5 seconds so you can pose, then take a flash image to capture you.
• Baby or lightning capture: With the camera on a tripod pre-bufferring video, and when a spike in lighting happens or the baby finally laughs, let the user press the remote to begin capture a few seconds earlier
• Wildlife capture: Pre-buffer video, and when motion is detected, start recording it from a second earlier.  Then capture stills every 10 seconds for the next minute, then wait for motion
• so much more

The scripts would be sharable and rated online among the community.  Serious photographers are a techie, enthusiastic bunch and this creative capability would go over nicely.

Photographers, what tricks would you teach your gear if it were easy and fun?

(They were probably working on this when I published my article, but I’ll take credit anyway.)

Wired wrote:

Isn’t it about time your portable player had Heart and Ban buttons on it for personalizing customized radio stations that update with a single click via WiFi? We thought so.

I think so too!

There are several other interesting variants of the Heart/Ban or Thumbs Up/Down concept back in my original posting that the Slacker design doesn’t represent, so check it out.

It’s great to see so much innovation happening in the digital music space.  The one thing I crave is higher fidelity streaming stations.  It wasn’t until I dusted off the turntable I used to DJ with, and dropped the needle into the grooves of a 25-year-old album that I realized what I had been missing.  After listening to MP3′s and 128k-160kbps streaming audio for so long, I had forgotten how much better music can sound.

So here is a follow-up idea to steal: for $4 per month (what Slacker charges for the ad-free version of its service) raise the audio fidelity that will make my ears and my hifi happy.

Looks like someone implemented this concept on the iPhone.  Click in to see a video.

Now we need a mouse manufacturer, or a university lab to design a mouse which does the same thing.

(By the way, when I say ideas documented here are “stolen” I’m kidding.  Different people walking down the same exploratory path will arrive at similar ideas.)

iPod touch

[Update 12/2/09 - two years later, the iPod Touch does not really suck very much anymore.  See the comments for some of the profound improvements since its introduction.  I am sure Apple read this blog to figure out what needed fixing.  - ed.]  [Haha, just kidding - ed.]

Here are some initial reactions to the iPhone touch based on the guided tour. I have not personally tried the device, so please forgive and let me know of any errors!

(By the way, anyone else find the guided tour a bit creepy? Something about the jovial, disembodied face and flailing hands…)

• The iPod touch is not highly optimized for playing music. It has poor capacity for a full-size device (8GB) requiring users to spend more time managing music. You cannot access key functions like pause and volume up/down from the outside of the device. The buttons are on a touch-screen, so you cannot just feel for the them and must look at the device to do these fundamental tasks. The device has to be in the right mode for you to pause music or turn the volume down. A music-optimized device would have physical buttons for these topmost tasks on the exterior. The big screen drains battery capacity, so you have to concern yourself with turning on and off the display. The touch-screen is easily pressed by accident, so you have to be concerned with locking and unlocking input. Despite some nice interaction design, this device is not a great conceived-from-scratch music player; it’s the design of a cut-back iPhone.
• The iPod touch is also not a great video player, again because of the limited capacity. What a waste of a large, sharp display. Would it have killed Apple to include a flash memory slot?
• The consolation is that the iPod touch is only $50 more than the iPod Nano of the same capacity. You get a lot for that 50 bucks. (Who will buy the 8GB nano?)
• Is it just me, or is Cover Flow a crappy way to navigate a music collection? The concept seems to be inspired by the vinyl & CD world of albums, where browsing a collection of music could be done visually. However the modern world of MP3s is largely a world of singles. This results in a stack of album covers, many of which represent one song. It’s pleasant seeing album covers, but flicking album covers back and forth is a pretty poor interaction model for finding music. While Cover Flow demos well, it strikes me as gratuitous eye candy with little user benefit. Such UIs tend not to hold their own over time. I expect that sooner or later a more functional paradigm will be invented for visually navigating music.
• Now that the iPod has a way of entering text, can you search for songs by typing? Or must you navigate a huge scrolling list? Navigating list of hundreds of items was always a major pain in the click-wheel iPods. (Good riddance, click wheel!)
• The iPod touch will make a sweet PDA. It has a calendar app and a contacts app, the two core apps of the classic PalmPilot PDA. iPods have had applets for these functions from the beginning, but they were nearly useless due to the lack of proper input on the iPod. If you think of the iPod touch as a PDA with music and internet surfing, it’s suddenly a much better product.


PIM features of the iPod touch

• But boy, could Apple have downplayed the PDA functions any further? It’s subdued in both the UI and the marketing. Calendar and contacts are highly frequent tasks for a PDA. Palm devices have always granted these tasks top-tier status, devoting physical buttons to them. On the iPod touch, these same tasks didn’t even make the cut on the iPod touch’s little dock. (Is this dock configurable?) There is scarcely a mention of these capabilities on Apple’s site, and it didn’t make the demo. [Update 9/11/07 Apparently they could have downplayed the PDA functions further, and may have: by crippling them. The word is that Apple disabled entering new calendar events on the iPod touch. Readers are, rightfully, screaming bloody murder at the prospect. Say it isn't so, Apple!] [Update 9/13/07: It is so.] [Update 11/26/07: It is not so any longer. Apple added calendar editing back to the iPod touch. Steve Jobs was somehow involved.] [Update 11/12/09: too bad the calendar UI remains so crummy.]
• We welcome the era of mobile, WiFi web browsing. When traveling it will save us many pilgrimages to Internet cafés. (Too bad the Palm Foleo got cut. Hopefully they will incubate it further and introduce an inexpensive, light laptop alternative.)
• iPod touch is crippled as an Internet device. It has a web browser but no maps or mail or widgets. It’s hard to see a good reason for these to be omitted, other than to protect the iPhone’s thunder. Pity. It’s unlike Apple to hold back on making a product the best it could be.
• Doesn’t the YouTube app require an active Internet connection? We’d hope that it would automatically pre-cache subscriptions to YouTube content to have available offline. The service is far less useful if only available when you are within WiFi range.
• Connecting to Starbucks for free access to iTunes store? Ho-hum. So much has to line up for this to give benefit to Apple or Starbucks or the user. It seems scarcely worth the investment or complexity. Perhaps if Starbucks threw in a free hour of surfing for buying one of their tracks it could get some traction.
• Wouldn’t it be interesting if the iPod touch could connect to any Bluetooth phone and use it to access the Internet? You could have the iPhone goodness without foregoing your tiny, inexpensive cellphone and your carrier of choice. Apple will probably never do this since it would cannibalize iPhone sales and the lucrative monthly contracts.

Despite its beautiful industrial design and truly innovative UI, the iPod touch is, ironically, not very well optimized for media playback. It is derivative of the iPhone, and a transitory product. Greater capacity, and physical, tactile, modeless buttons for controlling volume and playback would vastly improve the product for its stated purpose.

[Update 9/13/07 - We are also hoping that the device will subsume the role of PDA by restoring existing editing functions into its hobbled calendar. Further we hope that it fulfills its mission as mobile Internet device by restoring the Internet capabilities culled from the iPhone.  Most of all, we are hoping Apple does not squander its considerable goodwill by overplaying its hand with such consumer-unfriendly practices.]

[Update 8/13/08 The iPod touch did get calendar functionality.  It's just a shame it's so much less efficient than the PalmPilot.  It's also a much better music device now that it can stream from Pandora!]

I ended with a vision to steal:

please come up with a consumer-grade way to let users of standalone desktop computers run web apps locally

With Gears, vendors like Google and Dabble may now offer “Either/Or Apps” — applications that are either hosted, or run locally, or both, according to the user’s desire.

One small step for the web, one giant leap for webkind

App developers today face the dilemma of whether to write new apps for the desktop or for the web. Each carried significant pros and cons. They can how have it both ways, building web apps now with the intention of allowing the app to work partially or completely offline once the technologies mature.

Some applications, like Google Calendar, sat in an awkward space between “nice to have on any browser” and “need to have when offline”. Those applications can now exist with neither limitation. Soon, browser-based email will be available to you for offline processing while on an airplane, isolated from the series of tubes.

Hopefully Gears does not preclude apps that are 100% local — where no Internet connection is needed and where no data is ever stored remotely. As the scenarios show, this is and will remain a separate, legitimate need.

Architects and engineers of hosted apps should start thinking through the implications of Either-Or-Apps — allowing sensitive information to be stored locally, allowing apps to be used completely offline, leveraging client-side storage for caching and increased response times. Understanding these tricky problems will be important skills in the years to come.

By Google’s own admission Gears is immature. There are many more important technologies to build out. One example: having the platform own the problem of keeping the two data stores in continuous sync.

Security will also be a concern. Today, web pages have a strict restraining order and may not come within 500 yards of our precious local data. By relying on Gears, our precious data is moving closer to the dangerous part of town.

But Gears represents more than an evolution in Web technologies. It is another crack in the dam for desktop-based apps. While rich native apps will never disappear as a whole, reasons for clinging onto any one of them are falling away one by one.

Local vs. Hosted Computing

This goes to the old debate between local versus hosted computing. The debate started in the mid-90′s with Sun and Oracle trying to battle Microsoft’s dominance by replacing “fat clients” — full-featured PCs with their own storage — with “thin clients” that left most of the computing and all of the storage up to the servers.

That was in the early days of the web and it didn’t stand a chance at that time. None of the infrastructure could support the quality of user experience that was taken for granted with desktop apps. All the software industry had to do was wait for those massive initiates to run out of breath and money.

Fast forward a decade. Now we have fast, cheap, nearly ubiquitous connectivity, super fast servers and local machines, cheap gargantuan hosted storage. And we finally have a nascent medium for distributed applications: web browsers with AJAX (and friends).

So the debate is back, argued this time by the likes of Google and Yahoo with hosted productivity applications that are walking and talking more and more like desktop apps. Applications like Google’s spreadsheet, Yahoo’s rich email client and now DabbleDB, a rich online database app (which I am sure someone will snap up for big bucks very quickly).

And so the pendulum appears to be swinging back to something that kind of looks like the days of yore: mainframe computers that knew and did all and dumb terminals that channeled them.

Will the pendulum swing all the way back to a fully hosted world? Should it? Let’s review the debate.

What’s good about hosted apps

A future of hosted apps are great if you travel, if you need to travel light, if you aren’t good for managing your own system or if you have to share computers. Here are the arguments for hosted apps laid out neatly as SSNiF scenarios:

What’s bad about hosted apps

Connected computing certainly has its place, but there will always be reasons for needing to have your apps and your data local. Here are the SSNiFs:

No wonder we have a dilemma. Those are some pretty strong needs on both sides of the equation. Choosing either direction trades off the other.

Vision to Steal

Meanwhile, we still wish we could consider DabbleDB but we can’t because it’s a hosted app. The same goes for other apps like Google Calendar or Intuit’s useful QuickBase. Wouldn’t it be nice if those vendors could just sell me a standalone version for my own use, or for my private workgroup’s use, without me having to be a webmaster?

Operating systems vendors: Can you please come up with a consumer-grade way to let users of standalone desktop computers run web apps locally?

Consumer-grade here means:

• No thinking about Apache or security concerns or being concerned about installing the latest version of MySQL or Perl or PHP or chron jobs.
• Install, uninstall and upgrade apps the Mac way, by dragging and dropping a single icon. Withstands operating system upgrades.
• Launch the local web app by double-clicking it. It opens into the browser.
• Allow the app normal access to the hard drive once it’s been welcomed in. Reads and writes the same types of documents as any other app.
• Let me switch on the app for others who can see my machine on the network. This way, selling into small workgroups would not require an IT specialist managing a server. It would be equivalent to the old pre-Web FileMaker Pro approach. Run it on anyone’s machine and turn on multi-user mode.

There are technical and standards hurdles to achieving this. But we need to get from here to there somehow, there being the place of convergence where we don’t care if an app is “native” or “hosted”… whether it runs as a Mac app or a Windows app or just a web app, whether the app is right here or out there. And where developers don’t have to fret over which platform to support.

Maybe someday, hosting computing will be the norm. The cost- and hassle-reduction benefits suggest that it will win out for casual users like Mom, students, information workers and by those who cannot afford their own machines (that’s a prediction). But the scenarios calling for local computing are also strong and will persist for the foreseeable future.