Compare this with how I interact with photos today. I take a pic and then can choose among any number of apps on your device that can do interesting things with it. Even better, I can manipulate the photos after the event I was taking the picture at.

I feel the whole model of checking-into a location has matured to a point where it can graduate from the app level to the platform level. I would much rather bring up some native location app and check-in to my phone. The check-in is an actual object, like pictures or music and it is now owned by me. It contains the location information as well as the time. Once checked in, I can “share” my checkin to any apps that can do something with it. So I can forward my checkin to Foursquare to inform all my friends I am there, to FoodSpotting to discover whats good to eat there and to any other app that may need that info.

This model has a number of advantages to it:

• I am building up a location history that is no longer trapped inside one app or service.
• I can choose to share my checkin with apps later (for example if my only motivation was to get some virtual points for being there, I can check into that service the next day)
• I can checkin to multiple services in poor connectivity locations by only needing to pull in map images etc once.

Of course there are certain challenges here:

• Some services like Foursquare may want to know immediately when you have checked in to present local offers etc. This could be done by the platform sending a system level event that these apps can listen to when a user checks in to a location.
• Different services have different location data, for example Foursquare has a lot of geo data but Foodspotting may have better data on restaurants so there will be the need for some standard model of annotating the location with other meta information while the user is locating himself on the map. For example, the map the user is presumably zooming in to can show pins from different services with different icons.

Hopefully platforms like Android and iOS add this capability as a core part of the OS pretty much like we use maps today. Till then, the idea of using more than one or two location services at any point is pretty difficult.

New Apple CEO Tim Cook: ‘I’m Thinking Printers’ SAN FRANCISCO-Following the resignation of Apple founder Steve Jobs, incoming CEO Tim Cook called a meeting of shareholders and members of the press Thursday morning to announce that he envisioned printers as the company’s future. “Laser, ink-jet, double-sided, color, black-and-white-the future of technology is in printers.

And yet I really do think printers need their “ipod” moment. We have for far too long been stuck with a purely utilitarian implementation that is a cause of frustration more often than not. Anyone remember this sketch by Eddie Izzard?

So I really like this printer concept that I saw last week. This may of course be overkill, but I can’t wait till I have a printer that actually is joyous to use.

Of course I feel the days of the printer may be numbered. I hardly ever use mine except to occasionally print boarding passes for the few airlines that dont yet generate emails with those as QR codes, but still if I do have to have one, I want one of those

Update:

Meanwhile there are folks at Bergcloud who are completely reimagining printers more as a toy.

Hello Little Printer, available 2012 from BERG on Vimeo.

Some Rules for Game-Based Systems (from the book Game Based Marketing):

• Favor long term loyalty not short term competitions
• Dont offer direct prizes, offer virtual points. Real world value of virtual points can be tweaked at the time of redemption.
• Virtual points can also be used for virtual goods. Virtual Goods Economy is 5.5 Billion Dollars
• Does redemption matter? Huge number of points are almost never redeemed
• Top 5% of airline customers generate 40% of the revenue
• Create opportunities for elite members to show their eliteness (like lounges in Airports open only to elite members)
• Create artificial scarcity and rewards around it.
• First reward should be soon
• Casino style *random* rewards create short cycle reinforcement
• Need both long term goals (level ups) and short term (mini games/challenges)
• All game based systems need:
  • Large community
  • Point System
  • Simple Communication platform

Types of Players (from the book Game Based Marketing):

• Achievers
  • Go to great lengths to get rewards
  • Dont care for winning in a vacuum: need an audience (leaderboards)
  • Need the Socializer
• Socializer:
  • Want to build meaningful interactions
  • Often are more about helping others win rather than winning themselves
• Explorers:
  • Need rich virtual worlds to explore
  • Love to share detailed accounts of their explorations
  • Long games with repeated actions bore them
• Killers:
  • Need simulated win & lose conditions
• The Naive Player
  • Fairly unaware
  • Need to be made aware that a game is going on

A really awesome presentation on the shallow game design that seems to be creeping into web properties by Sebastian Deterding

“Yet when I look at most gamified applications today what they do is use game elements to tie us even more tightly into our worldly toils and schemes. They are glorified report cards that turn games into work rather than life into play, and users into pawns instead of players”

Pawned. Gamification and Its Discontents

Other links:

• Scvngr‘s game dynamics playdeck
• 5 Creepy Ways Video Games Are Trying to Get You Addicted
• Can’t play, won’t play

Unlike people though, all user notifications aren’t made equal. Alerts demand immediate attention (in the case of JavaScript, they stop the entire GUI thread freezing the application, though thats not the case in other UI technologies). Recently I wanted to get rid of the Alert windows I had placed in my rush to get EspressoReader out of the door, and started looking at different notification paradigms out there.

One concept I wanted to borrow from was application logging frameworks like Log4J. Logging frameworks usually define a series of levels that you can use to define the priority of your message, for example in the case of Log4J the levels are:

1. Debug
2. Info
3. Warn
4. Error
5. Fatal

While tempting, these dont really map to any order of priority for end user notifications. Looking around the web though,  I did see some interesting ideas around notifications. For example, XUL (Firefox’s UI framework) includes a NotificationBox control:

This system seems to be getting pretty popular now, with the Chrome browser UI framework including something similar to that as well. Gmail notifications are in the same vein:

The thing with GMail notifications is that they are closer to the actual interaction that prompted the notification which works well (Fitt’s law in action!)

I guess this system is slowly becoming standard. I really wish “notify” was a built in function in JavaScript similar to “alert” but at least there is a jQuery plugin that seems to add that functionality now.

Another interesting notification system is the fading message box like discussed here, or more famously, as shown by Growl

However, the problem with such notifications is that they are pretty transient (generally fade out), which is often not what you want. I couldn’t really find an official name for these so I call them “acknowledge boxes”. On the importance scale, these seem to the ones with least importance. Another acknowledge notification is an audio clip played when an action is performed, though those need to be used with caution since they get annoying pretty soon.

So here is my sorted list of prioritized notification UIs:

1. Alert: Most severe, “deal with me now” kind of messages
2. Notify: Hey something happened. Finish whatever you are doing and then let me know
3. Acknowledge: Least important “I heard you” kind of messages

If you have any other interesting notification user interface examples, please share them here.

One thing that I think is really important — that I think is context for this, is that I generally think that most other companies now are undervaluing how important social integration is. Right, so even the companies that are starting to come around to thinking, ‘oh maybe we should do some social stuff’, I still think a lot of them are only thinking about it on a surface layer, where it’s like “OK, I have my product, maybe I’ll add two or three social features and we’ll check that box”. That’s not what social is. Social – You have to design it in from the ground up.

Off late the “social integration” tier of a lot of the new services tends to be “publish this activity to Twitter or Facebook”, and that gets old really fast. Its why I have updates from services like FourSquare set to be filtered out of my Twitter stream. Thankfully Tweetdeck makes it really easy.

The three ways he talks about are:

• Visceral: How pleasant things seem to work better.
• Behavioral: How good design lets you feel in control.
• Reflective: How people prefer design that reflects their personality.

One interesting point he makes is how a happy state of mind is puts the brain in ”breadth first search” mode and is more conducive for out of the box thinking, but tension and some pressure puts you in a “depth first search” mode (as dopamine gets added into the system). Moment of self realization here for me personally: as a programmer I have often preferred tighter deadlines (note: not to be confused with unrealistic) to open ended project timelines. I need the pressure to focus. A bunch of my programmer friends say they feel the same way. Thats why the burn down charts for closed work tickets is almost never the ideal one:

(note the change of slope as projects approach end dates = more pressure)

There is often the temptation (by me anyway) to carry the model of deadline driven development to design, but Don Norman’s talk indicates that this would be a bad idea, especially if you are concepting new experiences.  How much pressure in terms of deadlines and deliverables can anyone apply on design teams before you kill lateral thinking thats absolutely required for creative teams. However its just as easy to fall into the time sink of finding the perfect experience. Voltaire’s quote about Good being the enemy of Great comes to mind again.

So concept in breadth first mode, execute in depth first.

The concept also seems applicable to application/web design around browse and consume. Browse pages/screens, where there isn’t an end goal really and a user is out looking for “something interesting”, should put people’s brains in breadth first mode, with more emphasis on visuals, etc, but when the user is in content consumption mode, like say on video consumption pages or web search, pages, a muted design may be a better idea. It certainly explains why Google Search pages, which most of us use to get to something we need and not really browse, work so well, but on all their other applications where users are more about entertainment than work, their designs feel awful.

As a developer, I am not a big fan of the direction Apple is going with the new locked down OS and I completely echo Alex Payne’s sentiment where he talks about the iPad and the Tinkerer’s sunset:

The thing that bothers me most about the iPad is this: if I had an iPad rather than a real computer as a kid, I’d never be a programmer today. I’d never have had the ability to run whatever stupid, potentially harmful, hugely educational programs I could download or write. I wouldn’t have been able to fire up ResEdit and edit out the Mac startup sound so I could tinker on the computer at all hours without waking my parents. The iPad may be a boon to traditional eduction, insofar as it allows for multimedia textbooks and such, but in its current form, it’s a detriment to the sort of hacker culture that has propelled the digital economy.

However that said, there does seem to be some grain of truth to the idea that I dont really know what half the folders in my file system are. Or, well, I may know theoretically what they are meant for but I dont ever use them myself so do I really need the clutter when I open Finder or Windows Explorer. For example, a while back I went from writing different text files at different locations for different reasons to writing them all in EverNote and tagging them appropriately. I dont care where EverNote is placing my files but I know to find anything I just need to launch it and search either on the text or tag.

I think we need to differentiate the concepts of the file system and the visual file system browser though. An available file system is essential for applications to write sharable data even if as an end user I may never need to see those locations. The problem of the iPad/iPhone OS is that the data produced by an application is not really sharable between applications, except for data produced by (some of) Apple’s own applications which are available as frameworks. Some developers have managed to enable inter application communication using custom URL registrations like Innerfence and their Credit Card Terminal application, but that definitely is a hack. In the linked post, the author mentions:

By registering to handle a URL scheme, an iPhone app becomes a de facto web app, subject to many of the nasty attacks that work on the web. Apps implementing this scheme must be careful to validate any parameters they get from the URL lest they be vulnerable to old friends like SQL injection. Another one to be careful of is unsolicited response attacks.

So locking down the OS seems to make my data even more vulnerable to being compromised since an application developer could have a bug in this code. The available file system enables inter application in a much better way in the Android OS, where an application can write to a location and then trigger another application passing it a reference to that location. That’s how Photoshop for Android allows developers to leverage it as an image editor in their own applications. This seems to be the exact translation of the Unix Philosophy in the mobile space and the philosophy has been validated in the Unix space over time already.

So my points are:

• The file system itself is not an outdated concept. Applications should still have a file system to write sharable data to.
• The visual file system showing references to rarely used locations or locations only needed by developers can be evolved to one that doesn’t show those to regular users and only shows items relevant to them (my photos, my videos, etc).

Even more, such a mechanism that could be easily evolved to do this is already available in Windows and Mac OS’s, which involves preceding the file’s name with a period. Such files are not visible to the end user but a developer can enable the “show all” behavior.

[Update] David Shoemaker also talks about Death to filesystems and notes that the Google Chrome OS is also going the same way with no filesystem the user can browse (ink via Karl’s blog), though in that case, the data is all stored on the cloud and can be made accessible via the web service’s APIs. Another aspect of that that would be really cool is that chrome browser extensions could even add custom actions to such files: For example, Picnic could create a browser extension that adds menu items to the browser’s chrome when the user is on Picasa or a new photo service and then when that is clicked on, can pull the data from the Picasa using the web service.

Of course the iPhone native app camp had to respond and I am sure there are a few responses now online. The one I found that Aral Balkan linked to was by Faruk AteÅŸ made some points around why the App Store in all its craziness is still worth the pain, but they centered around JavaScript performance (which I dont think is as bad esp for the apps that constitute 90% of the app store), HTML layout issues (which I dont agree with really) and making your application available at a place where users are actually looking for applications (some merit here).

Similar discussions also seem to be happening on the Google Chrome OS front (except that in that case there isnt a real option except web apps). For example, after Chrome’s public demo, in a followup Q and A session, Google’s Sergey Brin responded to a question saying that Chrome OS will not support any native application at all. Apple had encouraged developers to write web apps for the iPhone before the native app SDK was announced, but Sergey seemed to indicate that one reason may have been that Apple’s own native apps seemed to fragment user experience since the native apps felt different than the web ones.

I have to say I have yet to be convinced of the web-apps as native-apps concept. This week I have been halfway in the process of transitioning from one computer to another at work, and I was surprised at how much of my data is already on the cloud, between Google Docs, EverNote, DropBox, Flickr, etc, I had very little actual data to move across. That part of the dream is awesome. But using that data in apps is a different story. For one thing, there are very few guidelines for how web apps should look and work making the look and feel widely different and something that we learn from scrach on every new application. And network latency is often very painfully apparent, and I am not even talking for the data, its probable as you switch from one state of an app to another, you are looking at a blank screen for quite a few seconds before the UI gets loaded in, and then tries to load the data.

In a recent labweek project at CIM, we wrote a web application optimized for the iPhone for browsing Comcast On Demand content. The application, while functional, did not work nearly as elegantly as a native iPhone app especially on a device with spotty connectivity. I shudder to think what would happen if my Google NetBook was on a saturated network like AT&Ts right now. I imagine it would only take a few instances of “waiting…” messages to do something that traditionally was instantaneous to piss of a fair number of users (including me). Add to that html’s behavior of rendering incomplete content which then pops into the final look once images and icons get loaded, poor javascript animation (even if they are because of a poorly written piece of JavaScript code) would make the experience a far cry from what I have gotten used to in native applications like that on OSX or (even) Vista.

Perhaps part of the problem remains that we are trying to overload the browser metaphor. The web browser was written to browse documents, and HTML5 continues to move it in that direction. Maybe what is really needed is what I call an Application Frame, a browser that has no concept of a page. There are a number of features that this would need:

• A concept of state changes that dont involve the entire page to reload, nor rely on crazy JavaScript dom manipulation. Something that looks, for example, similar to Flex’s States metaphor. The application frame should automatically handle transitions by default unless the developer overrides that.
• The ability to proactively cache an entire application at the application startup, not just page 1 of a 5 page application
• Ability to add launch icons to the desktop/start menu (I think JNLP does this right now)
• Ability to override close action of the window that sends it into a windowless background process mode
• Notification APIs that allow the application that was set as a background process to be recalled into the window mode
• Ability to leverage system icons without having to package them into the app

I am sure there are more but these are the ones that come immediately to mind. Note that all this happens without an install process. The end user requests the application from a URI and the server can send back a new HTTP Header (something like Content-Type:Application/FrameContent) and then proceeds to send markup and javascript that defines the app UI. The Application Frame can even keep some browser behavior, like history of recently invoked applications, bookmarks, etc. Also the markup should include html and also higher order markup similar to widgets in, say, XUL or Flex.

Couple these with things that are now becoming part of HTML5 like built in databases and web workers and we could finally realize the dream of a “real” application sent to the end user by a webserver at the time of launch. But until that, I still think the web-application may not do it for me. Chrome may prove me wrong, but thats something time will tell.

Update: PPK has a new post up responding to the avalanche of passionate native app folk. Pretty fair points there.