At Xerox Parc in the 1970′s, Alan Kay fostered the innovations that form the foundation of modern computing. Windowing, mice, object oriented languages, laser printing, WYSIWYG, and lots of other stuff we take for granted today either had its start or was fleshed out at Xerox Parc.

The venerable mouse, which enabled direct manipulation of content on the screen, was just one of a few innovations that was screen-tested as a possible heir to the venerable cursor and text terminal metaphor which had predominated since the dawn of computing.

Mice, trackballs, light pens, tablets, and Victorian-looking headgear tracking everything from brainwaves to head and eye movements were all considered as the potential input devices of the future. No doubt there were other metaphors besides windows considered as well. Hypercard, anyone?

Steve Jobs, by selecting the mouse as the metaphor of choice for the Lisa and subsequent Macintosh computers, sealed the deal.  Within a year, Bill Gates, by stealing the same design metaphor for use in Windows 1.0, finished the deed.  By 1986, the mouse was a fait accompli.

Since the dawn of the Mac and Windows 1.0, we’ve taken for granted the notion that the mouse is and will be the primary user interface for most personal computing and for most software.

However, computing is embedded in every part of our lives today, from our cell phones to our cars to games and zillions of other devices around the house, and those devices have myriad different user interfaces.  In fact, creating new user experiences is central to the identity of these technologies.  What would an iPhone be without a touch screen?  What would the Wii be without its Wiimotes?  What, indeed, is an Xbox 360 but a PC with, uh, lipstick and a different user interface metaphor?

(An aside: How awesome would it be if the iPhone, Wii, and Xbox 360 all required the use of a mouse?  People fidgeting on a cold day, taking out their iPhone, holding it in their left hand, plugging in their mouse, working it around on their pants to make a call.  Kids splayed out on the rumpus room floor, mousing around their Mario Karts. Killer, souped up force-feedback mice made just for killing people in Halo.  Mice everywhere, for the win.)

So, what’s with the rant?  Simply that the web has taken a bad problem — our over-reliance on mice — and made it even more ubiquitous than it was in the worst days of windowing UI’s.

“And then if you click here…”

No, here — not over there.  Click here first.  Scroll down, ok, then click submit.  Now click save.

See the problem?  The reliance on the mouse metaphor on the web is fraught with two hazards.

1. Mice require users to become collaborators in your design.
2. Each user only brings so much “click capital” to the party.

Catch My Disease

We’ve all had the experience of using a site or app that requires a great deal of either time or advance knowledge to fully utilize.

You know the ones — the ones with lots of buttons and knobs and select boxes and forms just waiting for you to simply click here, enter the desired date, choose the category, then get the subcategory, choose three friends to share it with, then scroll down and enter your birthdate and a captcha (dude) and then simply press “check” to see if your selection is available for the desired date; if it is, you’ll have an opportunity to click “confirm” and your choice will be emailed to you, at which point you will need to click the link in the email to confirm your identity, and you’ll be redirected back to the main site at which point you’ll have complete and total admin control over your new site.  Click here to read the section on “Getting Started”, and you can click on “Chat with Support” at any time if you have any questions.

What the hell do these sites want from you?

If these sites are trying to provide a service, why do they need you to do so much to make them work?  Sure, some stuff is complex and requires information and processes and steps to empower them, but when you ask users to participate too much as key elements in your design, you create frustration, resentment, and ultimately rage.  That’s cool if that’s your goal, but if you’re trying to get happy users, you’ve done nothing to advance that cause.  So, it shouldn’t be about “all you have to do is click here and here.” Ask less of your users.  Do more for them.  Isn’t that what service is all about?

Limited Click Capital

Sometimes, people just want to be served — even entertained or enchanted. They don’t want to become the slavish backend to a maniacal computer program that requires 6 inputs before it can continue.  Is the user in service of the computer, or is the computer serving the user?  I always thought it was the latter.

I’ll never cease to be instructed by the lessons learned from developing my sites Twittervision and Flickrvision. Both sites do something uncommon — they provide passive entertainment, enchantment, and insight in a world where people are asked to click, select, participate, scroll, sign up, and activate. It’s sit back and relax and contemplate, rather than decipher, decide and interact.  Surely there are roles for both, but people are so completely tired of deciphering, that having a chance to simply watch passively is a joyful respite in a world of what is mostly full of badly designed sites and interactions. This alone explains their continued appeal.

People come to sites with only so much “click capital,” or willingness to click on and through a site or a “proposed interaction.”  This is why site bounce rates are usually so high.  People simply run out of steam before they have a chance to be put through your entire Rube Goldberg machine.  Make things easier for them by demanding fewer clicks and interactions.

Make Computing Power Work For Your Users

Truism alert: we live in an age with unprecedented access to computing power.  What are you going to do with it?  How are you going to use it to enchant, delight, and free your users?  Most designs imprison their users by shackling them to the design, turning them into nothing more than steps 3, 6, 8, 9, and 11 of a 12 part process.  How are you going to unshackle your users by making them — and their unfettered curiosity — the first step in a beautiful, infinitely progressive algorithm?

Predict and Refine

Forms and environments that rely on excessive interaction typically make one fatal assumption: that the user knows what they want. Most users don’t know what they want, or they can’t express it the way you need to know it, or they click the wrong thing.  Remove that choice.

Do your best to help your users along by taking a good guess at what they want, and then allow them to refine or steer the process.

Remember, you’re the one with the big database and the computers and the web at your disposal: how are you going to help the user rather than asking the user to help you?  You’re advantaged over the user; make it count for something.

Don’t Think About Mice

Mice lead to widgets. Widgets lead to controls. Controls lead to forms. Forms lead to hate. How are you going to break free from this cycle and give your users something compelling and useful with the minimum (and most appropriate) interaction? What is appropriate interaction?

It depends.  What if you rely on gestures, or mouseovers, or 3 yes or no questions in big bold colors?  That’s minimal and simple.  It  may be just what you need to empower your idea and serve your users.

I’ve been working with the WiiMote and the iPhone a lot lately, and trying to use touch screens, accelerometers, and the Wii’s pitch and roll sensors to create new kinds of interaction.  Maybe this is right for your work.

Think about it and don’t assume traditional mouse/web/form interactions. Sure, sometimes they are the right and only tool for the job, but if you want to stand out and create compelling experiences, they surely can no longer be the central experience of your design.

Long Live the Cursor

Back in the early days of GUIs, there were lots of people who contended that no serious work would ever get done in a window and that the staple of computing and business would be the DOS metaphor and terminal interactions.  There have been dead-enders as long as there have been new technologies to loathe.  I’m sure somewhere there was a vehement anti-steel crowd.

The mouse, the window, and HTML controls and forms are the wooden cudgels of our era — useful enough for pounding grain, but still enslaving us in the end.  How will you use the abundance of computing power, and new user interface metaphors to free people to derive meaning and value?

I’m finally recovered after a really exhausting week that included SocialDevCamp and the wild ride of Twitter Vote Report.

SocialDevCampEast2 went off without a hitch on Saturday at University of Baltimore.  Once again, some of the best and brightest developers, entrepreneurs and social media gurus gathered to trade ideas and talk about the future of the web.

One thing we try to do at SocialDevCamp is vote on the sessions, to make sure they are things that people really want to hear about, or at least size the discussions to the right rooms.  We ran 5 rooms all day in 5 sessions plus lunch, for a total of 25 sessions! Check out the wiki to see the sessions that were held.

Personally, I enjoyed the conversation on location technology, and why location-based social networks have yet to reach critical mass.  Most folks felt that there was a technological barrier — it’s just too hard to continuously update your location with current device and battery constraints — and others questioned what incentives people have to update their locations.  We decided that those incentives probably needed to be tuned in order to see a successful location-based service emerge, and that there may also be benefit for people sharing location-related information anonymously.  Great talk, and I’m still thinking about what incentives might make LBS actually work.

We did a session on Twitter Vote Report, which was awesome because we were actually able to recruit some members of the crowd to do some work on the project!  Bryan Liles and John Trupiano contributed some great work to the codebase, some while sitting in the session!  We talked about the overall architecture of the project, and the fact that it was put together in just two short weeks of coding!

There was a good conversation about iPhone development, introducing people to the platform and answering questions about the platform.  Many seemed to be glad to get a feel for Cocoa and I wouldn’t be surprised if several of the folks there end up working on the platform!

Alex Hillman of Philadelphia’s Indy Hall helped to lead a discussion on co-working in Baltimore, and by the end of the session, we had actually launched co-working in Baltimore, with a mailing list and a set of great ideas for taking things forward.  Yesterday, we held our first “official” co-working meetup at Bluehouse in Baltimore; I’ll write more about the co-working initiative separately.

Because I wasn’t in the other sessions, I can’t say what all was said in them, but I heard good things about the conversations on data portability, source code management with Git, and crowdsourcing. If you were in one of the sessions, feel free to leave some comments here or links to your own blog!

Ann Bernard helped put together an awesome party for SocialDevCamp at Metro Gallery with great food from Tapas Teatro and an open bar.  And live music from Natasha El-Sergany, KADMAN, and Ra-Ra-Rasputin… A great way to end the day, and I can say that by the time it was all over, I had talked to a few hundred people and was completely exhausted!

This morning, Mike Subelsky, a friend and one of the organizers of the recent and fabulous Ignite Baltimore said via email, “It is not an exaggeration to say that SDCE has totally changed my life,” referring to the first SocialDevCamp held in May. Not to sound self-congratulatory, but the same is true for me.

SocialDevCamp is one of a few things sparking a renaissance here in the Baltimore/Washington area, giving rise to events like Ignite and to movements like co-working.  With the social media tools available now, this sort of thing is finally possible to do, and it’s hugely gratifying to see it happening!

See you next spring for SocialDevCampEast3!

Being busy seems to always come in spurts for me… just when it looks like I’ve got too much to do already, something cool turns up and takes things to whole new level of busy.

That would be this week. SocialDevCamp East, the barcamp-style unconference that I started with some friends last spring is back tomorrow, and that’s certainly required some coordination and planning.  That would have been plenty.  We have over 200 RSVP’s now (between the Wiki and Facebook) and we expect a truly incredible day of networking and learning.  See you tomorrow!

The other big news of the last two weeks has been the TwitterVoteReport project, for which I’ve been acting as defacto CTO since about October 18th.  This is a great project, a great cause, and an awesome idea.  The data we collect will be an archival quality primary source document for future generations to study the evolution of the election process.

We have five distinct data sources coming in about people’s experience at their polling places: Twitter, Telephone, Direct SMS, and Apps for Android and iPhone.  These are all normalized and aggregated into a single database and reviewed by humans for maximum accuracy.  The data will then be made available in real time to anyone who wants it — from the media to watchdog groups to mapmakers — to help the world understand and monitor the 2008 US elections.

Putting this project together, with all these diverse inputs, has been a monumental task and a real demonstration of what’s possible when people decide to work together.  We had over 600 phone channels donated.  We were able to think up, code, and submit an iPhone app in just 3 days.  We’ve received press coverage far and wide from sources as diverse as TechCrunch and Fox News.  Not bad for a few days’ work.

There’s plenty more to do still (between now and Monday), and I’m busy all day tomorrow at SocialDevCamp.  We’ll do a session there on TwitterVoteReport and what we’re up to… we still need more help from people good with maps!

I’ll post more here as things evolve, and a recap next week, but remember, nothing’s impossible when caring people dedicate themselves to a common endeavor.

Meantime, check out:

• http://twittervotereport.com
• http://votereport.pbwiki.com
• http://socialdevcamp.net

Yesterday I met up with Jeff Pulver to discuss some business ideas, and one of the topics we touched on was, “If you could build any iPhone app, what would it be?”

The new iPhone 3G and the imminent release of the App Store have created an amazing amount of buzz and speculation about what the next generation of mobile apps might be.

While I am unable to comment on any of my iPhone development efforts or the details of the iPhone SDK, I thought it might be interesting to ask here as well, “If you could build any iPhone app, what would it be?”

So, simple as that. What is your ideal “killer app” for iPhone? Write your idea here, and maybe we’ll build it!

I enjoy learning new skills and technologies on my own, and it occurs to me that there isn’t a lot written on the subject.

I’ve been developing this approach for about 20 years and here’s a brief summary of what I find works for me.  It may not work for you, and that’s OK.  But give this a try, refine your own technique, and share what works!

1. Choose a topic/technology outside your comfort zone.  This is self-evident; you can’t expect to learn anything new if you’re working in a sandbox you’ve already mastered.
2. Make time for yourself.  Lots of it.  You can’t expect to dig into a topic deeply if you’re distracted by email, phones, tax deadlines, bills, dinner, family, friends, and bathing.  Seriously, these things have to take a backseat, you’ll come across as a recluse, and people will hate you.  Accept it.
3. Set a goal.  It might be as simple as a “Hello World” or something more complex.  However, it should be something you think you can attain and which will make you happy to see completed.  So, choose something reasonable and within reach.
4. Code until you get stuck.  Keep pushing small, obtainable goals until you get to a point where you are baffled or sleepy.  This is the time to take a nap.
5. Before you take a nap, read something.  Your brain runs threads in the background while you’re sleeping.  Don’t waste that CPU power thinking about Angelina Jolie.  Instead, search for guidance on the thing that’s got you stuck (either with a colleague or online), or read (or re-read) a chapter in a coding book that’s relevant.
6. Sleep until you wake up.  This might be 3 hours, 6 hours or 8 hours; your brain will sleep for as long as it needs to process the information you’re trying to absorb.  NOTE: At this point the thought of having a regular sleep schedule should make you giggle.  You should sleep and code when you feel like it, which likely will not be on any particular schedule.
7. As you fall asleep, meditate on the questions you’re trying to answer.  The intense concentration available to you as you are nearing sleep will enable you to define and isolate the problems at hand, and this will provide a kind of “normalized grist” for your brain as it prepares to do your heavy lifting for you.
8. When you wake up, you will have some answers.  You may not have all the answers yet, but you should have some fresh insights that will enable you to blast past your last impasse (wow).  This should give you some encouragement and allow you to repeat the cycle (3-8) again.

I’m presently employing this technique to learn Objective C and Cocoa Touch for the iPhone, and it’s working great.  This is the sort of thing that society will not allow you to do continuously (unless you’ve evolved a significant number of support mechanisms) but you should be able to get away with it at least some of the time.  It delivers great results for me.

And for those of you to whom I owe emails, bear with me; I will get back to you shortly.

My previous post got me wondering what Apple’s EULA says about location data collected by and on the iPhone. Like most people I breezed past the 1.1.3 EULA agreement without studying it, and then found I had to dig around online to find the iPhone License Agreement, which I finally did on Apple’s site.

Section 4(b) is the relevant piece:

A couple of basic points here. First, Apple asserts that they may collect and share with its partners location data from the phone. They secondly assert that the location data is collected in a way so as not to “personally identify you.” I am not sure I agree with that statement based on my previous post, but let’s give them the benefit of the doubt for now.

Second, they go on to say that the user can “withdraw their consent at any time” by “turning off the location-based feature.” How? Where is that button in the preferences?

Third, they make the statement that “turning off or not using these features will not impact the functionality of your iPhone.” Uh, yeah it will (assuming it were possible). I won’t have location-based services or maps, which is a real reduction in the functionality of the phone.

Let’s take a look at the newly published iPod Touch January ’08 Software Upgrade License Agreement, which we would expect should address the newly-added location features specifically.

Once again, the same section 4(b) contains the same text as the iPhone Software License Agreement. So, they consider the location services in the iPhone and iPod Touch to be legally equivalent, which is interesting to note.

Seems to me Apple’s in an interesting place with this location data business. The location data that is collected is packaged in HTTPS, so we can’t inspect it. It is theoretically possible that it contains nothing that can identify a given user “personally,” but what does that mean?

Does it contain an iPhone serial number, or an IMEI number, or a phone number? How is this data stored? While that data, by itself, may not personally identify you, could it be correlated with data that does? Is that possibility covered by the SLA as written?

I will assume that Apple and its lawyers have thought this through. However, there are some interesting issues raised here. Now that the iPhone/iPod Touch has location support, we should expect Apple, and possibly third party developers, to leverage that location data in interesting ways.

The most interesting ways involve tying identity to location, so if anything is going to happen down this path, then the SLA, as written, is not going to suffice.

In the meantime, you can bet that somebody is going to consider whipping up a class action suit because there is no clearly marked way to turn off the location-based services, and because “turning off LBS” does affect functionality — your phone doesn’t know where you’re at!

And keep an eye on that SLA for future versions — you can bet that the wording on the location data is going to evolve.

When Apple announced yesterday that the iPhone would now be “location-aware” with the release of their 1.1.3 software, I was curious how they had done it.

I’ve been working with location information quite closely (see Twittervision, for example) for the last year or so and have had some conversations with different companies about how Apple might geo-enable the iPhone.

There are three options available:

• GPS
• Cell Tower ID
• Wifi Access Points

GPS is not an option at present. E911 laws in the US have required carriers to provide location information for some time, but that could be via GPS or from cell tower triangulation data. TruePosition makes this their entire business, and is the primary location information provider for AT&T and T-Mobile in the US. A pretty cozy gig, eh? They do this by way of tracking cell tower information within the network, from what I understand.

GPS may be an option later if Apple adds an AGPS (assisted GPS) chipset to the iPhone or supports external Bluetooth GPS units, but external bluetooth will never be a true mass market phenomenon, and AGPS is at least going to have to wait for the next iPhone refresh, probably not til next year.

Cell Tower ID is another option. Carriers know where their cell towers are (we hope), and by comparing the signal strength and the intersection of multiple cell tower antenna distribution patterns, you can make a pretty fair guess about where the user is. It’s not always spot-on accurate, but it’s pretty close.

Wifi AP’s are the third option. There are millions of Wifi AP radios running around the world at this point, and for the most part, they tend not to move around that much. They do, however, come and go from time to time. However, there are a lot of them, and with a modest investment in driving around populated areas, one could build up a pretty accurate database of what APs are where. Then they could sell that database to people who want to know where their Wifi client radios are.

This is exactly what my friends up at Skyhook Wireless have done. You can try out their Loki service for your laptop (Firefox/IE plugin). Suddenly, if you have Wifi, you also have a pseudo-GPS capability.

Judging by the fact that Skyhook invited me to stop in and see them today at MacWorld (which I would have loved to do, but am sadly unable due to my being at home in Maryland this week), it seems Skyhook got the contract to provide some location data to Apple. Apparently, the iPhone uses both Cell Tower ID and Wifi (Skyhook) data for location, while the iPod Touch uses Skyhook exclusively. Good Job, guys!

This explains why when I went to see Skyhook in June and said that a company like Apple might be very interested in their technology, there was a definitive “no comment.” This happens a lot; companies like to protect what might be a very early-stage negotiation, or even an intention, a lot of the time. But in this case it looks like Skyhook bagged what might be their killer deal.

Yesterday, I succumbed to the hype and “Revirginized” my iPhone (we had been engaged in some unsavory hacking) so I could safely install the new 1.1.3 software update that Steve said would be available. The revirginizing and upgrade went as clean as could be, and now my phone is running 1.1.3.

I thought I might “inspect” what the phone is doing when you do a location lookup. I have a bunch of resources on my home network, including a multipurpose Linux server, so I thought if I could pass the iPhone’s traffic through the Linux box, some tools like ngrep and tcpdump might reveal what exactly happens when the iPhone tries to position itself.

Well, turns out I was mostly right. In typical Apple fashion, though, they’re keepin’ it real with HTTPS, revealing nothing very interesting about how the location information works.

The iPhone is 192.168.1.199 and my proxy is 192.168.1.10.

Here’s what I saw:

T 192.168.1.199:49311 -> 192.168.1.10:2525 [AP]CONNECT iphone-maps.apple.com:443 HTTP/1.0.Host: iphone-maps.apple.com.User-Agent: Apple iPhone v1.1.3 Maps v1.0.0.4A93.

T 192.168.1.10:2525 -> 192.168.1.199:49311 [AP][..HTTPS DATA...]

T 192.168.1.199:49311 -> 192.168.1.10:2525 [AP][..HTTPS DATA...]

So, alas, nothing to see here, really… move along. However, we do now know that Apple is grabbing data from the phone via HTTPS, processing it network-side, and rendering a response to the phone about its position. We do not, for example, see a variety of calls to Skyhook, Google, or elsewhere, which is not inconceivable without verifying it.

After the HTTPS call, we see this unencrypted call:

T 192.168.1.199:49313 -> 192.168.1.10:2525 [AP]POST http://iphone-wu.apple.com/glm/mmap HTTP/1.1.Accept: */*.Accept-Language: en.Accept-Encoding: gzip, deflate.Cookie: s_vi=[CS]v1|46B904DB00003607-A290B210000599B[CE]; s_nr=1199572400032.User-Agent: Apple iPhone v1.1.3 Maps v1.0.0.4A93.Content-Type: application/x-www-form-urlencoded.Content-Length: 145.Connection: keep-alive.Proxy-Connection: keep-alive.Host: iphone-wu.apple.com.

...

T 192.168.1.199:49313 -> 192.168.1.10:2525 [AP]..*..m..DN..en_US..com.apple.iphone.1.0.0.4A93......@.......?...&_...>....&`...>.......&]...>....&^...>....&\...>....&_...>....&[...>....&`...>.

T 192.168.1.10:2525 -> 192.168.1.199:49313 [AP]HTTP/1.1 200 OK.Date: Wed, 16 Jan 2008 12:38:31 GMT.Server: GFE/1.3.Content-Type: application/binary.Content-Length: 113.Cache-control: private.Connection: close.

Not sure what this all is, but it looks like it has my iPhone serial number in there. It’s so nice that Apple wants to know so much about my phone, its serial number, its position. Why, if DHS ever has any doubts about me, perhaps they could simply just ask Apple? Maybe they know where I am.

What is Apple’s position (pun intended) on customer privacy, now that they seem to be in the location data business?

Other firms like Boost Mobile’s Loopt service have gone to great (ridiculous) lengths to inform their customers about location data privacy and to protect collected data. So as to avoid potential problems, Loopt does not even save a location track for its users, but instead stores only the current location of the user. (This was the case when I spoke with them in May 2007.) They figure this makes them less of a honeypot for DHS types, and keeps their customers happy.

I have never believed that consumers are as paranoid about location data as the press (and the most paranoid among us) would have us believe. Most people are willing to generate, share, and publish some limited amount of location data if it provides some value to them in return and they can control the data sufficiently.

What seems like a simple software update for the iPhone is actually the consent of millions (4M+ according to Steve) of users to potentially publishing their location information. And not just for the iPhone, but for the iPod Touch as well.

Now the question is what a theoretical 1.2.0 software release might hold: location of your iChat buddies? Location-enabled Twitter clients (using the Twittervision API)? Your friends conveniently plotted on the Google Maps client? All of this is now theoretically possible with the iPhone and iPod Touch now, and Apple holds the keys.

It will be very interesting to see how the iPhone SDK (Software Development Kit) works next month. If Apple opens up this location service to third party developers, we can expect to see some very interesting applications emerge this year.

The fact that the location service is not down to meter-accuracy is irrelevant (it put me, alternately, within a few feet of my house and across the river at the Annapolis Mall — I suspect because it was alternating between an accurate Wifi position and a more general cell tower position). To make social location services work, all we really need to know is generally where someone is (nearby) and that they are really there (device has reported location).

There are plenty of apps where approximate location is sufficient (stores nearby, friends nearby, homes for sale nearby, etc). Only for driving-direction or aviation applications do you need meter-accuracy. A later update to the iPhone hardware with an AGPS chipset will solve that problem, but even without that, this opens up an amazing array of possibilities.

Mostly, great credit should go to Apple for pushing out a technology so seamlessly, so effortlessly, that so many others have found so problematic and full of legal and perceived landmines. This is a big deal. Skyhook, Loopt, uLocate, Nokia, Navizon, and dozens of others have been grasping for this holy grail for some time, and they’ve been told variously that it’s “impossible to get the data,” or that “consumers won’t go for it”, or that “no one would fund it.”

Apple did it via iTunes with a software update. Agree? Kudos, Steve.