ИконописIsn’t that little blue iMessage button on the iPhone the greatest thing?  It changes from green to tell you that the person you are about to text also has an iPhone running iOS5, and that the text message you are about to send will cost you nothing more than a kilobyte or so against your data plan, if that.

Unlimited texting instantly changed my habits.  No more wondering how many texts I had left and where I was in my billing cycle.  No more concern about abbreviating words to squeeze the message into 140 characters, or for the cost of texting people internationally.  The freedom to send photos or videos, especially from WiFi zones.  When it’s free, communication becomes less like a precious telegraph message, and more like a free flowing instant messaging conversation.

It was surprising at first that Apple added this feature, threatening as it is to the mobile carriers’ SMS cash cow.  But with Blackberry offering a similar service for a while and mobile apps doing the same, it became legitimate.

So now that text message is starting to gain its freedom, what about voice calls?

In landscape photography you often want to have both near objects (like foliage or people) and distant objects (such as a bridge) in focus at the same time.  To achieve the widest depth of field you have to focus at the hyperfocal distance.

But it’s not trivial to figure out what that distance is.  It depends three inputs: the current aperture, focal length (zoom) and sensor size.  You can either look it up using a table or an iPhone app and hope that your lens has distance readings.  Or if you have substantially better eyes than mine you can locate it using depth-of-field preview button on your SLR camera.

But why should you have to?  The camera knows all three of the input values.  They’re present in the EXIF data of dSLRs.  Why shouldn’t you be able to issue a command to the camera to just focus on the hyperfocal distance right now?

Or, you could enter a mode where it continually adjusts to that hyperfocal distance as you vary the aperture and focal length.

It could even provide a schematic diagram on the LCD showing the nearest distance that things are in focus and hyperfocal distance, so you can learn the relationship between the inputs and results.  (This would be valuable for all kinds of other shots, not just huge depth of field shots.)

It seems like such camera features would make sharp landscape shots a lot easier to attain, and would help make the abstract math of hyperfocal distance intuitive for photographers.

18 months ago I proposed a way for streamlining the search engine searching process.  Google recently implemented something like it:

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.

Apple has had very good videoconferencing on Macs for years.

They have FaceTime video conferencing in iPhones and, soon, iPads.

The $100 AppleTV, which runs the same iOS, has a USB port.

Hmmm, I wonder what could be plugged into that USB port to make the system act as a living room videoconferencing system.  A camera+mic perhaps?

That would be more than a little disruptive to the office videoconferencing world, also.

So the new AppleTV a.k.a. iTV will “stream” video from an iPhone or iPad.

But will it really?  For video that is resident on the device, yeah, okay.  (I wonder how well an HD signal streams over today’s WiFi).

But for internet-based video, wouldn’t it make a whole lot more sense to hand off the streaming to the iTV?  i.e.: Click play on the iPhone.  Click stream to the living room iTV.  The iPhone tells the iTV, “Play this stream, would you?  Starting from this point in the program?”  (The iTV fetches its own data… it doesn’t stream from the iPhone.)  User clicks Pause on the iPhone, and it tells the iTV that the user clicked Pause.

Wouldn’t that make more sense?

Back in October 2008 I wrote, regarding doing HDR in-camera with one click:

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?

One of my first reactions upon seeing the iPad rollout was, “Oh great.  It’s hard enough to keep track of my information across my laptop and iPhone… now I have a third platform to worry about.”

Sure enough, when I got my iPad last week this quickly emerged as a pain point.

Apple decided in its noble quest for simplicity that the file system should be kept invisible.  Simple, right?  Just don’t worry your pretty little head about it.

It’s a great idea until you actually need to transfer files.  Then it amounts to a really bad idea.

What happens is that each file transfer and remote document viewing app (Air Sharing, GoodReader, DropBox, iBooks, Stanza, etc.) has no choice but to reinvent its own UI for transferring and managing files.  The resulting user experience is massively inconsistent.

And, all of these buckets of files are siloed.  No app can see see another’s contents.  The user is left having to remember what PDF is accessible from which app.

The iOS (was iPhone OS) needs to expose the file system to people who need it.  There should be a clear, obvious way of transferring files among the devices.

Here is the demo I’d like to see some day:  The iPad or iPod “desktops” show up as an extension of the PC’s desktop.   The user drags a file or folder from the PC to the iPad’s “desktop”.  Yes, the mouse cursor extends off your screen and onto the iPad* (*there’s already an app for this).  Boom… file transferred and accessible to all apps.

For bonus points: let the user indicate that changes to the files or folders should be kept in sync across all media.

If you do a lot of photographic touch-up, you’re familiar with the drill for cropping: select the tool, draw a rectangle within the image, squint and try and picture the photo alone, drag the rectangle or target one of its corners to resize it, apply the crop, and then judge the results.  Repeat if necessary.  Do this for dozens of events, dozens of times a year.

Within a few moments of playing with the iPad’s photo browser, two things became apparent: 1. there is a better way to crop, and 2. multi-touch, despite the hype, really does have some advantages over the mouse.

The iPad’s photo browser lets you grab an image with two fingers to both pan it and resize it with a single fluid motion.  On the iPad you are merely zooming into a picture to check out your friend’s pores.  But it’s clearly a faster and more fun way to crop images.

I haven’t yet seen cropping done this way, so it constitutes today’s idea to steal.

[Researchers: It would be interesting to validate this claim by comparing the time to crop between using the mouse vs. multi-touch method.]

This scenario also exemplifies a sweet advantage of multi-touch over mouse, which is that it lets you do multiple direct manipulation operations at once.  Cropping is one fluid operation, as opposed to many micro-interactions to do the same task with a mouse:  targeting edges and corners of the crop rectangle with a mouse and dragging them.

That said, you can potentially accomplish a similar fluid crop operation with today’s mouse.

1. User selects the crop tool.  A crop rectangle appears at the largest possible size.
2. User presses turns the mouse wheel to enlarge the photo within the frame.
3. User drags the image around within the frame

This method eliminates the picky targeting of edges and corners in regular cropping.

Since the dawn of man, keyboards have had little protruding nubs on the home row.

On Macs the nubs are on the F and J keys.  On PCs they are typically on the D and K keys.  Either way, they help the touch-typist to get their fingers in the right place without having to divert attention from what they are looking at on screen.

The strange thing is, these are the only keys with nubs.  This helps with the heavily used keys.  Our muscle memory helps our fingers find other letters around this center.  But it’s difficult to accurately stretch those digits up to the digit row.  It’s error prone and slows typing as one must carefully check typed numbers for accuracy.  And typing numbers with accuracy is critical.  It could mean the difference between a $6000 and a $7000 request.  And unlike typing words, numerals cannot be assisted by automated spell checkers.

I’ve long wished for nubs up there on the number row to help me out.

Exactly which keys deserve nubs is a good university research project.  The 5-6-7 keys I find difficult to get right without care.   The 9 and 0 I find difficult also.  So offhand I would guess that the 1, 6 and 0 would be good candidates.

By the way, did you notice the little in-joke on the onscreen keyboard on the iPad?  Yes, you guessed it – the images for the F and J rows have little nubs on them. It’s surprising this one got through given Apple’s extreme discipline for minimalism.  Har har.  Yes, Apple, you’ve reduced us 60 wpm typists to hunting and pecking amateurs, and here’s the salt thrown in the wound in the form of nubs that can be seen but not felt.  Good one.

Someone at Apple has a sense of irony.

If you are a startup, please steal and adapt this excellent advice from my friend and iPhone developer Mark Johnson.  It’s about  applying the principles of customer development, A/B testing, AARRR metrics and the sales funnel to market your iPhone app.  But it applies to any product that will have a name.

you can see from the graph what a huge effect changing the name and icon had on downloads. [..] For this app, we saw 20x difference in download rate for the best app listing vs the worst. Wow.

Click here for the scoop.

In the world of human-computer interaction, we’re seeing more action on multitouch and gestures and accelerometers with the upcoming iPad. We’re seeing augmented reality with built-in cameras and compasses.   We’re seeing competition heat up in the phone space with the next round of Android / Nexus phones.  And we’re seeing Google put voice everywhere, transcribing voicemail, automatically captioning YouTube and more.

The ingredients are all in place.  And yet I still haven’t seen a strong play to command our smartphones by voice.  It should be easy pickin’s at this point, nay?

I’ve been digging through my digital archives for things, and I am struck by how outdated Spotlight is on Mac OS X.

By now, we’re all used to Googling things, which means typing something approximate into Google and having it read your mind and come back with what you meant, without you having to say it properly.

Spotlight, on the other hand is old skool computery.  The results are not ranked.  There is no separation between close hits and distant hits.  Typos lead to null results (Google corrects them for you).  There is no preview of context.  You cannot interactively view the context from the search results UI.

When will Spotlight get a refresh?

When I first tried out Google apps I was aghast at the user experience.  Basic editing was clunky, long-established platform GUI standards were violated, you couldn’t directly drag or paste images, and more.  Interactivity had been set back ten years compared with the slick, quick UI’s of the modern era.

But increasingly I found myself depending on these tools.  Why?  Because of the new paradigm of collaboration that they enable.  No longer must you sit in a cave and perfect a document before tossing over the wall.  In the new era, you don’t have to wait for a document to be finished to get feedback on it; multiple people can collaborate on it simultaneously, and everyone always has the latest version at all times.  It’s a better way to work.

But we are still stuck with that clunky browser-based user experience, that is now 12 years old and not much better than it was two years ago.  It’s usable, yes, but let’s be clear: Google Spreadsheets cannot hold a candle to Excel in the tightness of the user experience.

So when Microsoft announced over a year ago that it was going to match Google Apps I thought, that’s kind of nice.  The documents will be accessible from any web browser, and Google could use some competition.

But why are they racing to give up their evolved user experience?  It really is a pain to use web apps within a web browser; there are countless little user experience compromises that we must still live with.  Why must we have either cloud-hosted documents or a modern user experience?

After all, it’s not the web browser that makes web apps special.  It’s the fact that the apps and data are available everywhere and are shared in real time.

Vision to steal: Why doesn’t Microsoft let you browse, open and edit cloud-stored documents directly from within Office apps?  Users would have the best of both worlds: ubiquitous access (even from a web browser when needed), continuous publishing, and the most comfortable and responsive UI.

If you and I are co-editing a document, we’d see each others edits in Word or Excel or PowerPoint in real time (as in Google Wave).  This is not just a parlor trick; it’s a fantastic way to work collaboratively over distance while on speakerphone.  (We can expect to see much more of this.)

As a bonus idea to steal, cloud-hosted documents can be kept in sync with local copies (which is what Google Gears does).  Opening a desktop .DOC or .XLS that you have shared on the cloud would keep all edits synched to both places whenever possible.  The user could do offline editing and have the changes propagated when their Internet access is restored.

If the competition is zigging, you should be zagging, because by the time you catch up to where the competition is today, they will be somewhere else.  Don’t make it easy for customers to continue to pick the leader.  Add some enticing benefits that catch the customer’s attention and make them make a choice.  Then, over time, fill in the parts where you are behind.

Wow, the upcoming Chumby has an incredibly simple and intuitive UI for adjusting volume: just turn the dial.

No unlocking to make the volume UI available.  No having to ensure that you are in the right mode.  You can feel for it and operate it without even looking, with instant response. What a great idea!

Hmmm… come to think of it, I think my 1979 Walkman had a similar UI.  Maybe other products should steal that idea.

I don’t know what happened with the stationery / templating system in Mac OS X but it got broken a few versions ago.

Today, if you mark your beautiful template as stationery, when you subsequently open it it creates and saves a copy of the file under the same name with the word “Copy” appended, in the same directory.

This so does not make sense.  First, people often to store templates a central repository of tools, outside any project.  That is not where you want your new project-related instance to be.  Moving it to the right location is an added, unnecessary step.  Secondly, the name of the template is never going to be the right name.  If the user doesn’t think to change it immediately it will cause confusion and make it hard to find the document.  That’s more unnecessary work, including closing the document you just created to move and rename it and then reopening it.  These required steps make the stationery worse than useless — it’s less work to just manually copy a template file to the destination.

The better behavior (to steal) is to instantiate a new, unsaved, untitled document when the stationery file is opened.  Later, when the user saves, it  she can give it the right name and put it in the right location the first time.  In other words, just like how untitled documents have always worked.

[Didn't stationery once work like this?  Anyone have insight into how and why it went astray?]

Here is the workaround I’ve been using for a while.  Never use the Stationery bit.  Do mark templates as Locked bit.  This will have almost the correct behavior.  When you open it, it will look like you are editing the template.  But it will prevent you from saving over it, instead prompting you for a save location and name.

[Bonus idea to steal #1: why can't the File Save dialog give instant access to the Finder windows that are already open?  These are the most likely save destinations because they relate to the current project.]

[Bonus idea to steal #2: When you do Save As, why must it give you what amounts to an arbitrary default save location?  Why not default to the current folder?  This would match the scenario of retaining an old version of a document while branching it for further editing.]

Today, Apple did something ironic. It introduced the Magic Mouse, a mouse that integrates the usual motion of the mouse with a trackpad and multi-touch capability.

To understand the irony we have to go way back through the annals of user interface history, a history that is unkind to Apple’s repeated efforts at improving the mouse.

In the early days of GUI computing, it was common for mice to have three or buttons. The problem was there was no standardization for what each button should do. As a result, various apps used different buttons for the same basic operations.

Sun's 3-button mouse, circa 1987

I remember programming on a Sun workstation that had one of these three buttons mice.  It was extremely difficult to master the basic tasks of clicking, dragging, selecting and opening.  One app would train your fingers to do it one way, and another app would train them in a different direction.

Apple’s 1984 Macintosh (and the Lisa before it) avoided this confusion by limiting the mouse to just one button. Users never clicked the wrong button because there was no other button to click. Click to select. Click and drag to move something. To open an icon on the desktop, use issue a bit of Morse code, and double-click it.  Dot dot.

1984 Apple Macintosh Mouse

In the early 90s, Microsoft and Apple one better. They reintroduced a second mouse button.  But this time they avoided the foibles its predecessors by establishing a rock-solid standard for what the second button would do.  The button would invoke a context menu on the clicked object and never anything else.

It was a welcome innovation in the progression of object-oriented UI’s that we now take for granted.  You could now right-click on any object to pull up a tailored list of actions that can be done on just that object.  It was a lot faster than hunting through all the menus for items commands that became available by the existence of the selection.  And it brought the most used tasks to the forefront, right under the cursor.

A 2-button Mouse by Microsoft (there was a plainer white mouse that came before this model, but I couldn't find an image of it)

[The unsung hero who pushed this standard through deserves a place in the User Experience Hall of Fame.  Anyone know the responsible party?]

Apple resisted this convention. Actually, different parts of Apple reacted differently.  The industrial design part of Apple resisted it, never dedicating a button to context menus.  But the OS software side supported the PC convention.  Right-clicking worked on the Mac with third party USB mice since before the dawn of Mac OS X.  It was a quirky position for Apple to take: it’s okay to have a mouse with two buttons, as long as it doesn’t have an Apple logo on it.

Apple’s hack for giving access to in-place menus was to have the user hold down the Control key and click menu.  It’s always been pretty clumsy for such a common task.

Even more clumsy was the little gear sprocket button that showed up in the button bar area, introduced a few years ago. This gave the hitherto invisible context menu a visible affordance, which sounds good in theory.  In practice I don’t know if people use it much.  And unlike in-place menus, it’s dissociated with the object it relates to.

Apple's context menu sprocket button

Innovation in mice continued its march forward without Apple. Around 1997, in the early days of the Worldwide Web, Microsoft introduced the scroll wheel between the two buttons.  You could now scroll a web browser or a word processing document without having to mouse over to the little scroll bar widget.  You could keep your gaze on the article you were reading and scroll the page almost telekinetically.  We’d never had to scroll so much before the web was invented, and the scroll wheel was a welcome advancement.

Microsoft mouse with scroll wheel

The right mouse button and the scroll wheel are so critical to basic productivity that any serious Mac user simply needed to buy a third-party mouse. Buying a Mac?  Buy a functional third party mouse to go with it.

In the late 90′s an apparent error in Apple’s lab led to the inadvertent release of a mutant puck mouse, which must have scampered through a door left ajar.  The puck mouse was perfectly round.  So round that you couldn’t feel which way was up.  It was very common for it to be at a slight angle when you moved it, causing the cursor to go careening off in a diagonal direction.   Luckily for the puck mouse, it had a cord, so defenestration was hard to achieve.

Apple's painfully symmetric puck mouse

(Later models added a little indent so you could feel which was was up.)

So Apple stuck to its guns, suffering from its ongoing affliction of button-phobia.  Form continued to triumph over function.  True simplicity lost out to the appearance of simplicity (as it does on the iPhone).

I suppose a second mouse button would mean that they surrendered. Or that they were desecrating the clean lines of their laptops or and mice with another button. Never mind that brining up a context menu is such a frequent operations.  (And please put out of your mind the fact that the keyboard already has about 76 other buttons for typing.)  That second mouse button would kill.  We’re trying to think different(ly) around here, people!  (See also: Apple’s Revolutionary Laptop With No Keyboard)

Apple continued its buttonphobic ways.  They even went backwards, to no visible buttons.  Instead of clicking a button with your finger, you apply pressure to the top part of the housing and the whole thing rocked forward as a click.

Apple's zero button mouse

Beautiful, right?  And that clear outer shell never got scratched up, because it was always kept in a desk drawer.  It didn’t help that the USB cable on this mouse was only long enough to reach the port on the (also functionally challenged but also transparent) keyboard.  It would not reach the USB port on the back of the noisy G4 tower under the desk.  Oh, yeah, and the (transparent) wire frayed easily.  Anyone with actual work to do put the mouse away and desecrated Apple’s sculpture by using a functional, ergonomic, ugly Logitech mouse.

Then came Apple’s Mighty Mouse. It too used the whole housing as one physical button switch.  It had a touch sensitive area under the fingertips, and you could bring up context menus by clicking on the right side with your middle finger. If, that is, you dug into preferences and activated the feature.  That’s right, at this point right-clicking is still not acknowledged as a mainstream thing.

There was just one catch: the touch panel would only register a right-click if you lifted your left (index) finger off the left area of the mouse.  Without knowing this critical piece of information, and practicing it enough to be automatic, right clicking was haphazard.  This was fatally unintuitive and aggravating.

Apple's Mighty Mouse

The Mighty Mouse was and is also loathed for its miniscule built-in trackball.  This innovation was supposed to allow for scrolling in all directions, but would jam up with dirt after a few weeks’ use.  Later Mighty Mice were cordless, so there was no saving the poor things from windows left open.

Which brings us to today, Tuesday October 20, 2009.

Apple has been adding gestures on its laptop trackpads for the last few years.  Those gestures were nice refinements, but not earth-shattering.  And they only worked when you were actually using the trackpad.  At a desk, if you use an external mouse, the trackpad and its fancy gestures are irrelevant.  On this date, Apple introduced the Magic Mouse, with, lo-and-behold, a trackpad built in.  You can still drag it around like a regular mouse, but you can also twiddle your fingers on it to do other tasks.

Apple's Magic Mouse, 2009

And here we finally arrive at the irony.  25 years after the 1984 Macintosh mouse – belligerently endowed with just one button for the ostensible sake of simplicity — we have a sleek little wireless mouse that lets you not only click, not only right-click, but also scroll, pan, zoom, and swipe using invisible gestures.

Simple, right?  :-)

But is it crazy enough to work?

I’m curious about how usable this integrated touchpad/button is going to be.  The video certainly looks compelling. Did they solve the Mighty Mouse’s right-click problem?  Will all these gestures be inadvertently triggered during regular clicking and dragging?

If it licks these problems, Apple will have, finally, trapped a better mouse.

[Update 10/22/09: Alas: "Right clicking requires a lifting of the left click finger, just like the Mighty Mouse".  Oh well.]

Requisite idea to steal

Why is it that web apps don’t get to use right-click events? This goes both for AJAX-style apps such as Google Wave, and Flash and Adobe Air web apps. That’s right, you cannot right click on an object to bring up its properties.  This a serious productivity limitation for SaaS apps, which are striving to catch up to the evolved usability of  desktop apps. [11/17/09 Update - I'm wrong wrong wrong.  Per the comments below, it is possible for AJAX and Flash/Air apps to tailor the context menu.  It's just that many apps just fail to do so.]

And here is an older idea to steal a different way to pan and scroll without resorting to gestures: make use of an accelerometer.

See also

• Panning & scrolling with a mouse by tilting
• Apple makes the trackpad a mouse button

—–

Philip Haine has been using Macs continuously since the original 128k model in 1984, for the most part as a fan boi. He is founder and principal of Product Vision Associates, an innovation consultancy that helps product leaders and their teams envision and build products that are even better than Apple’s mice.  He also writes the Product Vision Blog.  To follow him on Twitter click here.

Okay, computer. You should know my monitor-switching habits by now.

Most of the time you will see that I have the big monitor plugged in to my laptop.  When I do, I have things arranged a certain way. I put my e-mail on the laptop monitor. I tell the Dock to stay visible and not recede into the edge, because I can afford the screen space. I want my palettes in various productivity apps to be arranged so as to make efficient use of the big display while leaving plenty of real estate to do my work.  Scrivener and Inspiration need lots of space, so I want them to be maximized on the big screen. I want my instant messaging app to be down on the laptop monitor.

On other occasions, you will notice that the big monitor is not plugged in. It’s just me and a 15″ laptop screen.  You see me hide the Dock to free up precious space. Scrivener and Inspiration will still be maximized, but that of course means smaller height and width on the smaller screen.  You see palettes in my power tools arranged just so, to make best use of my smaller on-the-go set up.

You see me switch between these two configurations pretty regularly.  You should know now how I like things in each case.

So please, when I come and go and switch my workstation around, take care of these details for me so I can concentrate on my work.

This implies that:

• Each application needs to be aware of the various display configurations that are actually in use.  And each should keep track of UI layout so it can recreate it automatically when I move about.  The first few switches will still require the user to move things about.  But the UI will be trainable and it will learn over time.  This will save a lot of time diddling around with UI elements every time I move around.
• The Dock should learn (possibly with repetition) that you prefer it to be hidden on small screens and always visible on large screens.
• Treat “maximized” as a special state.  When the machine awakens to a smaller display, don’t put a 1900-pixel-wide window on a 1400-pixel-wide laptop display without resizing it.  And vice-versa: if a window has been told to be maximized, then make it maximized when moving to a larger display.
• When the configuration changes, put windows in reasonable locations.  (In moving to smaller displays, I find many windows stuck along the bottom edge, with only the title bar showing.)

This will also help in the future, when our world is in the cloud, and our workstation is any computer, anywhere.  Those workstations can come in any shape and it will behoove the software to arrange the workspace accordingly.

See also:

• Making efficient use of big displays (from almost four years ago)

—

Philip Haine is principal of Product Vision Associates, a product innovation consultancy that helps product leaders and their teams envision new, breakthrough products and reboot older ones.  He also writes the Product Vision Blog.  To follow him on Twitter click here.

Reader Doug Abdelnour has posted an insightful 3-way usability comparison between Palm Pre, the iPhone and the old Palm Treo.

Money quote:

I am also praying that some genius from the late 90’s can help Apple develop a user friendly calender with an alarm.

I hate to break it to you Palm fans.  It’s officially true, the Palm Pre has thrown the usability baby out with the bathwater in its reinvention of the Palm platform.  Let’s hope this is just a growing pain for the new Palm.

We’ve entered a world where computationally-intense tasks can be offloaded to the cloud.  Why build out and manage a computing farm when you can just ask Amazon to do it for you?  Heavy duty computing is becoming just another utility.

That “cloud” is actually made up of racks and racks of servers. Those servers are not actually in the clouds, where it is quite cold, but down on the earth, where it’s warm and getting warmer.  Those racks of servers generate heaps of thermal energy, which requires yet more energy to keep cool.  Otherwise they melt onto one another like Hersheys in the glovebox.

The software architecture that makes these clouds of servers work is modular, and fault-tolerant and distributed.  They allow plug-and-play expansion when more capacity is needed.  They are built to withstand any node failing (with thousands of servers, several will break down every day).

And those nodes can be anywhere, since everything is connected.  But given a choice, it’s preferable to put them close to where they are needed, because things are faster that way.

The purpose of a space heater is to generate heat.  Heaters are pretty dumb.  That’s all they do.  They have an electric heating element, maybe some oil to circulate through and some fins to radiate the heat, a thermostat and that’s it.

What if a space heater instead had a bunch of cheap, older generation, heat-generating CPUs and a wireless connection?  You could crank up the number of processors and their clock speed for a nice cozy hearth, or turn them down a few GHz if you just needed to keep your nose from freezing overnight.

The cloud computing companies could even give you a few cents for each MIPS-hour your heater burns.

At a larger scale, an entire office floor could have computers built into its HVAC system.  Even our desktop computers could be enlisted for the job.  They are ridiculously overpowered for what we need them for most of the time anyway.  The building’s climate control system could instruct all those idle CPUs to do something productive with their downtime, while warming the office in the winter.  Those computers could even monitor the local temperature and provide more heat where it is most needed.

All of this would:

• do something productive in the process of heating your home or office
• reduce the cost of cooling servers
• distribute computing closer to where it is needed
• maybe control temperature in a breezy office to a finer degree
• maybe subsidize heating costs by donating cycles to the cloud

My wife, tactfully: “I think you have an idea that is ahead of its time.”

Yes, it could be a while before this idea is stolen.  [This would be a fun and compelling research project for some engineering & system design students.  Anyone?]

—

Philip Haine is principal of Product Vision Associates, an innovation consultancy that helps guide product leaders and their teams to generate ideas even more important than the Network Heater.  To follow him on Twitter click here.