Sunday, October 3, 2010

The Worst Parts of Meatspace

Meatspace, noun. a term, originating from cyberpunk  fiction and culture, referring to the real (that is, not virtual) world, the world of flesh and blood.  ... The opposite of cyberspace.

In July, I caught a breathless article on CNN about a telepresence robot.  Imagine, if you will, being able to attend meetings and peer over your drones' shoulders, all without subjecting your bed-sore-covered carcass to sunlight.  It's $15,000 worth of technology that makes a Segway look like a wise and life-affirming investment. 

Your wage slaves get to interact with your wheeled robot stand-in through a tiny little screen, to enforce the message that being spoken to by this contraption is holding the muddy end of the stick.  As the power player, you're at home, dressed somewhere between Hugh Hefner and Howard Hughes, driving from a monitor bigger than their cube wall.

So, this manages to project both poor taste and intense disdain for those around you, like an indoor Hummer.  But I also thinks it solves a vast, interesting problem in a way that deftly preserves all the worst parts of physical reality in a shiny new digital shell.  The robot can't operate doors or stairs or even elevators.  When it joins a meeting at a normal conference room table, it has to swivel left and right to "see" who's talking.  The driver has to choose between steering it room-to-room throughout the day or making all the meetings come to him (which will kick off a territory-marking contest if ever two powerful honchos in the same company own robots).  A battery life of "up to 8 hours" also means your plastic servant is likely to need a pit stop in the middle of the day.

All of these problems were solved by video conferencing 20 years ago.  You update a room with a monster TV, a wall-mounted camera that can see everyone in the room, and plug the whole rig into the wall for power and network.  Time for the next meeting?  Hang up and call another room!

All hatin' aside, Anybots isn't the first company to just not get that they could be using digital technologies to solve meatspace problems instead of faithfully preserving them.  This appears to be the whole premise of Second Life.  Imagine how fun it would be if you had to walk from Amazon to Flickr!  Imagine clumsily steering your avatar into a meticulous recreation of a drab conference room, to watch a presentation blocked by the head of the guy in front of you, at a faithfully recreated slightly-to-one-side angle!  Oh, and can we import assholes, too?  You bet!  (Second Life defenders will note that now your Avatars can fly and teleport.  Keep going guys, you're a few patches away from being Star Trek Online.)

David Weinberger gets it.  Virtual stores are better than physical stores.  I can sort, I can filter, I can leap from cameras to chocolates without a 20 minute hoverchair ride around the Buy n Large.  Check out David's story about the big pile of clothes, start near the 15:00 mark if you're impatient. 


What about online classes?  On the one hand, I get to take them from the comfiest chair in my house (an overstuffed, closeout sale, C3PO-colored monstrosity), on a screen just the size/distance/font-size that I like, after putting on the baby's pyjamas (and my own).  On the other hand, I ask fewer questions, I don't grow my personal or professional network, and I don't get my knuckles rapped with a ruler when I doze off.  Maybe online classes take a good thing too far, maybe they need a little meatspace infusion.

Meatspace and cyberspace are different, no matter what you learned from Tron and Hackers.  Meatspace is really good for some things (hello, reproduction!) but don't think that everything in cyberspace should aspire to be like its older brother.  And if your product can be thwarted by a doorknob, you may not be solving the right problem.

Tuesday, August 3, 2010

Bounce Rate Sucks? Blame Journalism Class.

I love long blog posts.  Stevey's Blog Rants, Joel on Software, Paul Graham, I just eat them up.  I hope you do, too, but more likely you're one of the 88% of visitors who is going to read part of this then browse away never to return; in the web analytics biz, that's called my Bounce Rate.

Some curmudgeons will tell you that you're browsing away because you have a child-like attention span, growing ever more attenuated by Google and Hacker News and that newfangled Rock and Roll.  I'd like to give you a bit more credit than that.

I believe that you are a highly discerning informavore: knowledge is your prey, and you are merciless in its pursuit.  You don't browse away because you have a tiny magpie brain—you are locked on to the "information scent," and you will follow its lead until the Nature Channel-tastic end.

This is where the journalism lesson comes in.  Remember the Inverted Pyramid?  The concept is that you lead with the important part of your article because your reader may abandon you at any time—it's proof positive that people have had short attention spans for at least as long as there's been writing.  The basic Inverted Pyramid story goes something like this:

Thing you need to know.
Supporting material.
Cute anecdote.
Drivel. 

So here's my big idea, the one I would have put at the top if I hadn't slept through that J-class:  The Inverted Pyramid is actively driving away your users.  The further you read into an IP article, the weaker the information scent gets.  This probably mattered less in the heyday of newspapers, because the fastest way to get more information about a topic, assuming that you cared at all, was still to read the article in its entirety.  What else could you do, drive to the library?  Put on your weight lifting belt and crack the Encyclopedia Britannica?  Even if you were certain that better sources existed, the best value-for-effort was still to finish that article, diminishing returns and all.

On the web, everyone knows where to pick up the trail to better information the moment they lose the scent.  And maybe that's ok!  Let's face it, lots of blog posts contain just one good idea, which could have been stated succinctly.  Then its just the author typing because he likes that clicking sound.  Heck, plenty of blog posts contain zero ideas, just a link bait title followed by backpedaling, trolling, or fanboyism.  Your information senses are serving you well...

...until they aren't.  The dark side of this is that we're all building up habits that support the one-idea article.  When a really intricate idea needs to be transmitted, the author is likely to lead with the (not yet supported) core, and the reader is likely to expect that if that core doesn't make sense on first contact, it's all down hill from there.

I did wake up for the part of the class about "you need to tell 'em what you told 'em" so here's my formulaic conclusion:  The Inverted Pyramid is actively driving away your users (and maybe that's ok!).  If you've really got one clear idea, lead with it and people will leave when they get full, or when they think they're more likely to find the next big idea somewhere else.  If you've got something complicated to get across, you're better served with a format that feels as little like the Inverted Pyramid as possible so you can build the scaffolding before you drop your ton of knowledge.  Either way, your audience will thank you.

Saturday, April 24, 2010

How to Get Your IT Guy Excited about the iPad

I'm excited about the iPad.

For me, it starts with the iWork suite being rewritten for the iPad as multitouch-flavored productivity candy.  For an extra $30, the iPad supports the entire "knowledge worker" software stack: email, calendar, word processing, slides, and spreadsheets.  That gives an IT guy an excuse to be excited about the iPad at launch that I didn't have for the iPhone.  (Remember, useful corporate email support came about a year after the iPhone originally hit the streets.)

But before I get into how the iPad can change the game for IT, let me tell you about the game we're playing now.  These are the requirements my IT shop imposes on a computer (especially a laptop) to make it a "supported corporate asset":

1) Access to local files and programs is limited to trusted operators.
2) The theft of the physical device does not lead to loss of intellectual property.
3) Malicious code is prevented from executing or spreading.
4) Portable devices can access the corporate network remotely.
5) IT-mandated patches to the OS, browser, and applications are applied promptly.
6) IT-curated applications are licensed and paid for centrally.
7) Work is backed up.
8) Status on all of the above is reported to IT automatically.

For this post, I'll divide that list into things the iPad already does right, and things I'm only hopeful about.

Done Right
1) Local access control
Given that the iPad is running an improved version of the increasingly inaccurately named "iPhone OS," we're able to enforce the PIN protected login once the user connects to ActiveSync to get their email.  Unfortunately, there's no real mechanism to have more than one local user with differentiated access.

Counterpoint:  It's $500, get your own.

2) Theft Protection
The iPad has full disk encryption (so did iPhone, starting with the 3GS) and remote wipe (via ActiveSync).  The jury still seems to be out at this writing whether the iPad has the same vulnerabilities as the iPhone in it's disk encryption.

3) Malicious Code Protection
I know it’s popular (and fun!) to bash the App Store approvals process, but IT is getting a lot out of it. Apple is making it their business to guarantee that “iFart HD” is not going to do something awful to my device or file system.  There is much in the Store that is tacky or worthless, but no one has found trojans or malware.

I’m a little taken aback by the outcry for background applications. People seem to take this rosy view of how well behaved their Twitter and IM apps are going to be, but have they forgotten what the task bar looks like in a year-old Windows system?  The upside to the sandboxed, no-background-process state of Apps is that there is no iPad blue-screen-of-death.

As a result, we're willing to forgo the antivirus and app-whitelisting requirements we impose on our laptops and desktops. Which is just as well, since no one makes one, and it's not obvious that it's even possible to.

4) Access to the corporate network
Between ActiveSync and the VPN client, the iPhone OS already has the tools we need to connect up to the mother ship. 


Hopeful
5) Patching
If Apple really wants the iPad to be the only computer for certain types of user, they're going to need to lose the notion that some things can only be done via iTunes.  First up: upgrades to the OS currently require a "bigger brother" computer to download and force feed it over USB.  If an iPad is a computer, and not just an accessory, it has to take this part of its destiny into its own hands.

On the bright side, once we figure out OS patching, browser patching gets solved as a side effect.  And on top of the base browser, on a full-operating-system laptop we've also got to worry about the patch level of Java, and Adobe Reader, and Flash -- it's a relief for me to not have that class of crap as a possibility with Mobile Safari.

6) IT-curated Apps
I'm lucky to work for a company with a pretty laid back attitude, so we're not interested in blocking any Apps that Apple has been willing to permit.  We're also delighted that the App Store puts the cost of Doodle Jump and Bookworm onto the user, which contrasts nicely with Blackberry users' ringtones showing up on the corporate bill.

But when Photoshop or AutoCAD or some other pricey-yet-critical application launches, we certainly don't expect the user to expense it, and we do expect to be able to reclaim and reassign that license when the user leaves the company.  Ideally I'd like dual financial responsibility: the company will pay for and retain ownership of these n Apps; for everything else you're on your own.

7) Backups
For email and contacts, I'm already confident that ActiveSync is covering my data -- I don't need email backups from the iPad's point of view because I've got the "original" on the server, and the server goes to tape.  Some Apps also shoulder backups themselves: my Yelp bookmarks and Kindle books are synced to the appropriate "big computer in the sky." 

It is staggering to me how bad the file management is in all the iWork apps. There are more ways for me to organize my pictures than my documents, versioning is missing, the trash can (a Mac feature since... well since it was a Xerox feature) is missing. The only comfort I have is that it's so bad users will instinctively use email to store and share, so I'm back in the protective arms of our Exchange filers.

8) Monitoring device status
Our IT shop needs to know when an iPad starts to get into trouble.  There will be exploits against the base OS; how can we make sure our users upgrade promptly?  I'm putting a lot of faith in Apple's approval process for Apps; how can I detect jailbroken iPads?  Documents and presentations and paintings are all going to be born on the iPad; how can I make sure our users have good backup habits (at least to iTunes)?

This kind of central thinking seems to be totally absent in the current iPhone OS.


So, why are you so excited again?
I'm excited because we know the device launched with about half of my requirements met, in the operating system, for the base price.  I've got a further expectation that most of what's missing is under consideration in Cupertino (comparisons between my wish list and iPhone OS 4 are left as an exercise to the reader).

For comparison, to hit these same requirements, my Mac laptop contains six third-party "management" applications, all running as background apps, each dragging down my productivity a teeny bit.  That's before I load up any software I use to do my actual work.

The vision of a clean slate -- with all of IT's requirements baked in, and the whole processor devoted to what the user wants to achieve -- should excite even the most jaded IT guy.

Friday, March 19, 2010

An iPad, a decal, and the future of learning

I preordered an iPad about an hour after the form opened.  Apparently, so did about 120,000 of my closest friends

In an effort to convince myself that I'm not just a member of this herd, I started pondering personalization.  When I had a similar crisis with my iPhone, I designed a custom decal for the back with a WWII nose art motif.  (I hate cases, but a decal adds zero bulk and absorbs some wear and tear.)  For the iPad I'm leaning toward something that makes more of a statement about why I'm excited about the device. 

I'm a science fiction nut (thanks Dad!) so I started by considering if there was something from SciFi that I could pay homage to.  Jonathan Ive says that the iPad is "magical," but Arthur C Clarke taught me that's just another word for "sufficiently advanced technology."

The first thing that came to mind was the Hitchhiker's Guide to the Galaxy, a bottomless computerized travelogue that guides Arthur Dent through zany adventures in space.  That's how I'd like to think I'll be using my iPad (instead of reading Fark on the throne).  On the other hand, as much as I like the "Don't Panic" sentiment, I think the eyeless green mascot is creepy, and every part of the 2005 movie (except Zooey Deschanel) makes me hesitate to identify with this franchise for a few more years.

What other inspiring references are there?  In my head, the "desk" computers in Ender's Game look just like iPads, but I don't know how other Battle Schoolers imagine them.  I dig Cryptonomicon, but I'm not a security wonk, so that's likely to become a conversation piece for conversations I'm not interested in.  My favorite Star Trek is the skinny-Shatner era, but I don't think that boxy blinkenlights look is iPad-compatible.  Do people even read in Star Wars?

Finally, the object that jumped out at me was the Young Lady's Illustrated Primer from Diamond Age.  The Primer is a nanotech-powered book that teaches the main character, Nell, in subjects from reading to self-defense to nanotechnology.  It combines written stories with narration and video and interactive games to teach a gestalt lesson. 

This got me thinking about what's missing in the world to make the Primer a reality.  What's holding us back from a device that can teach reading as easily as particle physics? 

I think multimodal teaching is critical.  The Kindle seems like a rockstar for textbooks and simple diagrams, but I personally thrive on lectures and lab work, both of which require a frame rate that digital ink seems a long way from fulfilling.  The very best way to solve this problem may be a constellation of devices: Steve Jobs wants to convince us that the iPad belongs next to a $200 cell phone and a $1200 laptop, maybe there's room for a really great reader there, too.  But I think one cross-functional "good enough" device is going to outsell a stack of best-of-breed tools.

I originally thought some of the Primer's features like speech recognition and human narrators were a bit of fantasy overkill, but now I'm not so sure.  Certainly at the very young end, having almost no artificial interface is a beautiful affordance.  I'm still unconvinced of its utility in adult education; I work in a cubicle and live with two other people, I've got very little time where I can talk to a computer without driving someone else nuts.

I'm worried about the state of educational software, I don't think it aims high enough.  I grew up with Carmen Sandiego, and my wife fondly remembers Oregon Trail, but I think they each represent only a part of "teaching."  Carmen Sandiego feels like the same class as every IT course I've ever logged into: trivia memorization.  And Oregon Trail seems to do the same job as the Giant's game in Ender's Game: making an academic lesson visceral.  I can't come up with any software that has taught me the entirety of a new task, at least nothing deeper than Mavis Beacon Teaches Typing.

I think there's more that software can be doing that is both needful (trivia in the age of Google seems extra pointless) and that brings cheap CPUs to bear on the problem of teacher:student ratios.  When I'm watching the SICP lectures, the examples could follow along in a REPL I can play with.  When I'm learning guitar, the guitar could be jacked into the computer, so the software can comment when my sloppy fingering causes fret buzz.  Why isn't there an App to teaches me how to braid or fold origami using touch?

So I'm delighted that I've got some time to figure my iPad out for myself before my 6 month old daughter, Valentine, is ready to learn more than how to get her feet in her mouth.

Oh, by the way, for the decal, I'm working on something that looks like the leather-and-gilt cover of a book, with "A Young Lady's Illustrated Primer, by John Percival Hackworth" embossed.  I'm hoping the fact that I'm not a young lady is going to give me a chance to introduce a great book to new people, and to pitch these ideas about improved educational tools.

Monday, March 15, 2010

Keynote from IT Expo

My keynote from IT Expo/Digium Asterisk World is now available on the TMC website.

http://www.tmcnet.com/tmc/videos/default.aspx?vid=1976

The topic is how Yahoo! decided to use Open Source Telephony (specifically Asterisk) as our standard phone system.  There's some history, guidelines for choosing supporting technologies, and trivia about the space shuttle.  Don't miss it!

Thursday, January 7, 2010

Three Prongs and a Shelf Full of Parts

Recently, I was in a meeting with another technologist and two managers, none of whom were pointy-haired.  We were working on a problem that, in outline, sounded easy to resolve.  After recapping the problem description (yep, still sounded "easy") the manager who was responsible for the troubled area dropped his recommendation on us: he needed 6 months to research a solution, pilot it, negotiate a contract, get hardware approved and ordered, and implement it.  In the most respectful way possible, the rest of us called bullshit and tried to pick apart the one-page schedule he'd brought.  In the end, while we could have nickel-and-dimed him, the broad strokes were unassailable.

The other technologist left the meeting, spent half an hour between a search engine and our internal documentation store, and scoped a solution by taping together elements we already had on our corporate shelf.  His approach was implemented in a week.

Holy cow!

Collaborative tools -- email and wikis and databases -- make it possible for firms to be well run at larger sizes.  Coase talks about this in his 1937 Nobel Prize-winning paper The Nature of the Firm, and he hadn't seen nothin' yet.

But as companies get bigger, they secrete a nautilus shell of protective practices that slow down projects.  Anyone who has ever interacted with a big company -- working at one, selling to one, servicing one -- has seen the endless paperwork, review committees, and RFPs.  On the face of it, these things suck, so why do companies do them? Companies hate to make the same mistake twice.  (Which reminds me of a darkly funny story about monkeys.)  Companies hate mistakes more than they hate soul crushing paperwork, so they'll erect a mountain of paperwork to head off a molehill of mistakes.

The problem I'm describing lives in the intersection of these two tendencies.  Collaborative tools increase the possible size of companies, but big companies demand lengthy product evaluation and contract negotiations... which raises the costs of getting these tools in the first place.

This is not a completely original line of thought, and I'll pause here to acknowledge a debt to Joel Spolsky who got this far with camels instead of monkeys.  Joel's solution (fly under the minimum-noticeable-mistake barrier) is appropriate to the problem of selling to big companies.  My problem is watching the big company I work for piss away an unaccounted fortune trying to avoid technology purchase mistakes.  So I need a different solution.

The solution I've come up with takes three prongs.  They're not steps, they're not tips, they're prongs, and you can't buy a fork without getting all the prongs at the same time.  That said, you gotta write things in some order, so here's the order you'd want if you were building a brand new IT shop.
  1. Stock your Shelf with a few flexible Parts.
  2. Know thy Parts in depth.
  3. Duct Tape holds the universe together.

Of course, that order doesn't help you at all if you're not building a new shop -- and your team has been around since OS2 Warp looked promising.  So I'm gonna describe them to you backwards, because you have projects you have to start tomorrow, and you're about to stop reading, and I need to tell you something right now that at least slows down the death spiral.

3) Duct Tape holds the universe together.
Lets pretend that you actually have requirements from your customer for that project you're starting tomorrow.  First things first, get a big fat Sharpie and strike out all the places where they describe the solution instead of the problem.  You're the expert here, if you wanted pushy ignorant consumers second guessing you, you'd have gone into medicine.

Look at the requirements again, in that inky sea of redaction.  This has two advantages: (a) it'll be considerably shorter, and (b) it'll be possible to spot places where this problem sounds awfully like things you've already solved.  Maybe it's about tracking documents as they change, maybe it's about working better with distant teammates, maybe it's about shepherding a workflow -- but it's going to sound eerily familiar.

Now try to sketch out a solution as a centaur-style amalgamation of Parts you already have.  "It's like our project management tool, if the data entry was more like our wiki tool." "It's like our free-busy tool, but with the search capabilities of our web-based personnel directory." "It's like every CRUD database application ever written, except with a cornflower blue style sheet."

How could you make that centaur sketch a reality?  We're living in the age of the Mash Up, and even the very worst Enterprise Bloatware seems to come with an API of some kind.  This is where the duct tape comes in. 

I don't mean duct tape in the negative sense, I just mean to evoke a substance that can bind two of anything together.  Of course the binding code needs to be itself robust, documented, and supportable.  It needs to be created by a professional, and cared for as a new Part itself.  After all, the binding is the product that you're producing now, instead of buying new Parts.

But in order for the binding to succeed, you have to understand the two (or more) surfaces that you're bringing together, and that brings me to my previous point...

2) Know thy Parts in Depth
For every Part you're taping together, you need an expert that knows, in his bones:
  • What is this Part excellent at?  What is it bad at?
  • How big can this Part scale? 
  • What demands does this Part place on supporting systems like storage and network?
  • How do I make this Part fault tolerant?
  • What APIs does this Part have?
  • How much care and feeding does this Part require?  Is it brittle?
These are all deep questions, and they're not answerable by scanning the Part's web site.  Some of them would be answered in professional training, but some of them can only truly be grokked by a live-in expert.  A Part without the tender loving care of a full time expert is not likely to be strong enough to be a vital component of what you're building.

And that leads to the first prong...

1) Stock your Shelf with a few flexible Parts.
It's not enough to say "we buy the most excellent parts that meet our budget."  Everybody does that.  In order to have the expertise that you need in Prong 2, to build the solutions that you're dreaming up in Prong 3, you have to have a manageable few Parts.

How few?  Well lets start with the maxim "One tool for each job."  If you have several different Parts that perform exactly the same function, migrate all the responsibility to your favorite, and kill all the others.  Even MBA's know this stuff; it's an unalloyed good and you'll get the easiest bonus of your career.

The hard part is when you have two tools that do similar jobs, or a tool that is excellent at one thing and mediocre at a jillion other things.  I agree with the MBA's that there is inherent value in having fewer tools, but I say that out of love for engineers, not Cost of Ownership.  Fewer tools will let the same staff achieve greater mastery.

But under what criteria would you give up (or avoid in the first place) an excellent point solution for a good-enough extension of a system you've mastered?  For one thing, consider how completely your expert believes he can cover the true requirements, at this time.  Resist the urge to buy a point solution that can do really shiny things that you don't need right now.

Flexibility is also an important criteria for picking a generalist over a specialist.  A good Part is broadly configurable, with API surfaces that are easy for your duct tape to adhere to.  Over time, inflexible specialist systems will always be overtaken by programmable generalist systems, it's a question of speed versus acceleration.  Moreover, picking the flexible Part today increases the breadth of tasks you can take on in the future with Prong 3.

Why is this a good idea?

The chief advantage of this approach is to speed up the delivery of solutions to new problems.  Taping together Parts already on your shelf does not wake your big company's fear of risk, and it flattens your learning curve.  This is where the money is, this is how you sell it to your boss.

A subtler good is that you create more experts, instead of a legion of mediocre staff looking after a gob of systems they don't deeply understand.  Experts are more edifying to work with, and they breed more experts.

Also, solutions built in this way get designed explicitly to solve the problem at hand.  They're not grown in some focus group, they're not jealous of market share or cannibalizing existing products, they're here to serve you.  They take on some of the flavor of Situated Software, and that's got its own set of virtues.

I'd also like to make explicit that the Parts you choose should reflect the character of your team.  Maybe your shelf contains Twiki, Zimbra, and MySQL; but it could as easily be SharePoint, Exchange, and SQL Server.  I dig Open Source, but it's not fundamental to this model.

So try it out!  Especially the Sharpie on the requirements doc, that's just good clean fun.