iPhone, Blackberry, Apps – Models for Business and Use Needed
If you write applications for the iPhone, Blackberry or other smartphones, you likely know a lot about object oriented programming. This way of thinking about writing software code, developed in the 1960′s but not widely used until the 1990′s, treats software as sets of cooperating objects, each of which exist as a kind of independent machine able to receive messages, do something with those messages, and send new messages on to other objects. Seems like a sensible approach. The cells in your body operate more-or-less along the same lines. The pattern of how these objects relate to each other is called the object model.
But what many software developers know so well in terms of their code is forgotten on the humans that ultimately use their applications.
Take the recent news about the upcoming iPhone 3.0 update and Google’s Latitude location system. It allows you to see where your friends are on a Google map, and by many accounts, the code is beautiful. But beyond the obvious feature of seeing where other people are at any given time, what is the object model behind the use? What will real people use this feature for…and when?
Timing is one of the essential frameworks behind object oriented programming. An application needs to know what triggers a certain event, when, and in what context.
So regarding Latitude, I ask: What triggers my need to see where other people who I may or may not know are? What prompts me to broadcast my position for others to see? And what prompts me reliably to turn off this function when I want privacy (assuming I’m not someone oblivious to living in a privacy-free environment)?
An engineer’s answer may be, “Well, we give you all this granular functionality to decide who sees where you are and when.” But in my view this ignores the human context in a day-to-day setting, where one is overwhelmed by a constant stream of messages and tasks which we must perform to maintain any number of other objects spinning in our lives. We feel often as though we work for our machines, rather than the other way around.
Loopt is a similar application to Latitude, and my friends and I – mainly early-adopter tech geeks – tried frequently to use the app to find each other. It was fun…once or twice. But without an event in my life that prompts, “Use Loopt (or Latitude) now or you can’t do something you really need to do,” these apps are like a gun without a trigger. And they join the long list of untouched icons on the back pages of my iPhone.
Software developers need to remember that the object model doesn’t end with the code.
Stay tuned for the green transportation application UpStart is building. I hope you’ll agree that we take this object lesson seriously.
Shared Secrets – Entry #7: Searching for Intent
This is the seventh in the series on managing collaborative innovation. Click here for the Beginning of the Series
In 1998, I met a Stanford student who had written a paper called “The Anatomy of a Large-Scale Hypertextual Web Search Engine.” The paper described an invention he called the PageRank algorithm. At the time, IBM had published findings on a similar technology, which it called ‘Clever’. Both inventions did, in a very general sense, the same thing: crawl the World Wide Web, index web pages, and generate better search results based on the number and sources of hyperlink references to each page.
It was suggested that this student come to work for IBM and get a job in research on the Clever team. But he and his colleague had other ideas. They decided to build a web site on their own, something they could afford to do at that early stage in their careers on the back of a little seed money. They intended to create a self-standing resource for organizing the world’s information and making it universally accessible. As the last section of their paper indicated, they also intended to overcome the problem of clutter and conflict-of-interest caused by the dominant advertising driven model of the day’s search engine web sites. For this, they got seed money and collaboration from some of the smartest venture capitalists in Silicon Valley.
In the meantime, IBM remained unclear what to do with Clever. The problem involved a key organizational gap. The researchers working on Clever intended to get the technology used in IBM products and services. But the most obvious market play, to create a web search site, did violence to a much deeper IBM intention: avoid direct competition with companies that buy IBM technology – like search engine companies. For a time, spin-offs were discussed, and IBM remained open to licensing Clever. But ultimately there was no stomach for an IBM search engine company, and several researchers wound up working for, among others, those two Stanford students, Google’s Larry Page and Sergey Brin. If you believe that Google has changed the world, it is undoubtedly not simply their inventions but their innovative intentions that should be credited. Their technology was only ‘table stakes’. Their intention to build a real business with a novel perspective on search – something you can not patent or protect – got them to a place that Big Blue could not approach even with much more ‘technology’ in their pocket at the time.
Disclaimer: Others may remember things differently or have a different interpretation of events. The account above is how I remember the experience and what I learned from it.
Click here for the Previous Entry.
[Click here for Entry #8.]
leave a comment