lesscode.org

You lead many lives. You’re a spouse and a parent. A soccer coach and a scout leader. A volunteer and an activist. You are an employee and an entrepreneur. Why do the systems you use not understand this? It’s like somebody out there just doesn’t care.

If you’re like me, and I know I am, you’ve got about a hundred accounts to keep track of on various systems — systems on the Internet, systems running in various corporate data-centers accessible only via VPN. You’ve got a slew of credentials to manage and no ability to leverage all that information at once. You spend your day duplicating and copying information between these systems, like some sort of freaking acolyte — serving The System — when The System should be serving you.

Meanwhile a million Web 2.0 startups are blooming. All DIY’ing for attention-equals-users-equals-dollars. Many of those startups are trying to tap both the consumer market and the corporate one too. It ain’t easy though since consumer buzz or even adoption does not always lead to access to fat corporate accounts.

What would it mean to you if you could use your favorite set of Web Apps all day and never have to log in twice regardless of which life you were leading moment-by-moment? How much more effective would you be if for each application, all your information in that application was available at once instead of walled off in separate accounts?

What would it mean to a Web Application provider if it was able to paint that picture for you? Would you be more loyal to that brand? Would you induce your employer, your client, your scout troop to use/purchase that brand?

I think there is a way and if you’ll lend me a few more minutes of your precious attention I’ll spin it out.

Imagine

The prevailing identity model in information systems arose around the enterprise system deployment model. In an enterprise system deployment, substantially all of the users of the system are employees of the enterprise. The enterprise itself is not represented at all in the model since each system serves only one enterprise.

This identity model has been carried forward to Internet-based applications. Just about all Internet-based applications offer accounts. An account represents a contract between the service provider and an individual. As such, most Internet-based applications are modeled like one big enterprise. Web Applications that offer corporate contracts offer separate identity systems for each corporate entity. At the end of the day, each of these identity systems — the “consumer” space ones and the “corporate” ones are separate.

Now let’s imagine a future where all applications are Internet-based. It’s easy if you try. Further, lets imagine that the market for some key Web Applications has settled down and consolidated a bit. So instead of a hundred wiki providers maybe there are three very popular ones. Kind of the way things were five years ago on the desktop with Word/Excel/Powerpoint/Outlook but this time, Internet-based.

Now let’s take a look at a knowledge worker, “Jessica” using say a wiki service, “WikiGood”. In the morning Jessica spends a few minutes in WikiGood writing out her plans for the day and reviewing progress against yesterday’s. Jessica has consulting engagements with two clients, “BigBoxCorp” and “NowYouSeeIt” but she’s in luck — both of her clients have standardized on the WikiGood service and use it heavily for day-to-day operations. As the day progresses she will interact with both of these corporate wikis as well.

In the first usage instance, Jessica is working on her own behalf, and wishes to keep the content private. What happens when she decides to do some work for BigBoxCorp? Well she logs out of WikiGood and logs back in with the identity assigned to her by BigBoxCorp. No problem. Other than the fact that she has two sets of credentials for WikiGood, oh snap, hang on — three sets of credentials because she’ll also be doing work for NowYouSeeIt.

There is a proliferation of accounts and credentials, but that’s not the worst of it. The deeper problem is that each WikiGood account is an island — even though all of the accounts are Jessica’s. Her preferences, her usage history, in short, everything associated with her in the system is divided, walled off, in three separate spaces. When Jessica is logged in under her NowYouSeeIt account and issues a search for instance, she will not find results for any of her personal wiki pages since the system knows her only (at the moment) as jessica@nowyouseeit. What if WikiGood is using Google AdWords to present Jessica with targeted advertisement? Is she a different Jessica when she’s logged in to her personal account than she is when she is logged in to her BigBoxCorp account? Google would like to think not.

Relate this scenario (personal account, and two corporate accounts) to other applications you use every day like email, contact list, calendaring, meeting scheduling, blogging, idea management, note taking, project management, personal task list, IM, VOIP, search. As these applications learn more about you, and you invest more time creating information in each application it rapidly becomes unacceptable to switch systems or even to switch accounts on the same system.

People increasingly expect and need the systems they use to learn more about them and to provide enhanced service based on that knowledge. Systems architected ignorant of the multiplicity of lives people lead force people to waste time repeating themselves (to systems) and copying information (between systems). More generally users of these systems fail to realize the full potential benefit of the knowledge they have shared. This is not a new problem, but it is certainly seems like a more pronounced missed opportunity in the age of Internet-based applications.

The situation is problematic. Users of systems would like to minimize the proliferation of credentials they must carry. Also they would benefit greatly from the ability to connect their accounts in a single system in such a way that they have visibility across all their content at once, and in such a way that they wouldn’t have to spend time re-entering profile, preference and other information into each account. Corporations seek these same benefits for their workers because it makes the workers, and hence the corporation, more efficient. On the other hand, corporations still have a desire to limit access to information (e.g. to employees only), and to monitor employees activities (shudder) if not for pure evil purposes, for regulatory ones.

But what of the service provider’s interests? WikiGood would like to continue to offer free or cheap service to individuals and premium service to corporations. The logic goes something like “we’ll attract consumers and that will lead to corporate customers”. But from the foregoing it should be clear that WikiGood is missing the opportunity to activate those very consumer-users, by failing to provide a vision for Jessica that looks substantially better than the walled-off nightmare. Users have little incentive to induce employers to switch to gmail for instance, if that would lead to each user having two gmail accounts instead of one. That situation is not appreciably better than the situation where the user has a gmail account and a corporate Exchange account. Contacts are still separate. Searches still fail to find results across accounts. The tags created for one account are completely separate (and return separate results) from the tags created in another account.

Many Lives — Just One You

The key missed opportunity is for WikiGood to acknowledge that users often act as agents for other legal entities. I’m using agency in the legal sense here. First from the American Heritage Dictionary:

One empowered to act for or represent another: an author’s agent; an insurance agent.

And now from the Agency (law) entry in Wikipedia:

The Agent’s primary fiduciary duty is to be loyal to the Principal. This involves duties:

• not to accept any new obligations that are inconsistent with the duties owed to the Principal. Agents can represent the interests of more than one Principal, conflicting or potentially conflicting, only on the basis of full and timely disclosure or where the different agencies are based on a limited form of authority to prevent a situation where the Agent’s loyalty to any one of the Principals is compromised. For this purpose, express clauses in the agreement signed by each Principal with the Agent may identify specific types or categories of activities that will not breach the duty of loyalty and so long as these exceptions are not unreasonable, they will bind the Principals.
• not to make a private profit or unjustly enrich himself from the agency relationship.

In return, the Principal must make a full disclosure of all information relevant to the transactions that the Agent is authorized to negotiate and pay the Agent either the commission or fee as agreed, or a reasonable fee if none was agreed.

If WikiGood introduced the concept of agency into its system, it would enable Jessica to have a consistent identity over time as she worked in her own interest, or in the interest BigBoxCorp or NowYouSeeIt, yet retain full visibility across all her content.

The core concept, is that within each application, a person has the ability to act as an “agent of” some identifiable “interest” or “principal” — think “employer” or “customer” or “client”. But the person retains her identity — the system always knows the person’s identity. There is one set of authentication credentials. Knowledge expressed to the system by the person is retained by the system and associated with that person — regardless of which “principal” they represent moment-to-moment.

In this way, principals can have (purchase) rights in the system, and those principals can assign their agents limited rights in the system too. The user switches between agencies as she operates. She expresses this switch through the user interface. If you’ve used a mail client that lets you select from multiple “from” addresses when sending mail you have the basic idea, only you’d make a “working for” selection each time you changed tasks. Perhaps you could “work for” more than one principal at a time — why not?

Instead of requiring the user to do this switching, perhaps smart systems could infer agency on-the-go based on time of day or content or physical location of the user. These smart systems could prominently display their guess and the user could change it if it was wrong.

In this way, no “closed system” like VPN is required to protect a principal’s interests. The principal contracts with various service providers the terms under which its agents can act. Principals then assign rights to their agents. But principals create no identities — they just assign rights/trust levels to identities. In this way one identity can serve many principals. There may be a notion of the “public domain” principal, so an individual has the ability to do work for the “public domain” or in the public domain.

What it Would Mean

The Agency-Aware Identity Model gives rise to a new business model where consumer accounts and consumer loyalty can be parlayed into corporate accounts. Each consumer-customer of a Web Service will now be highly motivated to induce each of the principals on whose behalf they work, to also become (corporate) customers of that same Web Service. Corporations (principals) would retain the important security and control capabilities they have today with their enterprise identity model: a) the right to assign and revoke privileges/trust to individuals (agents), b) the right to protect (privacy) information produced by their agents c) the right to eaves drop and monitor the activities of their agents for e.g. regulatory compliance, sexual harassment violations, EEOC etc. An individual, by agreeing to operate on behalf of an agency (for a period of time, or for a particular task) is potentially forfeiting some privacy or future access rights to her work product.

So what do you think? What would it be like to use WikiGood or your-favorite-web-app-here and never have to log out regardless of which client/principal you were working for moment by moment? How much more effective would you be if for each application, all your information in that application category was available at once? Would you be able to remember to click the drop down list of agencies as you switched between tasks during the day? Would you want that switching integrated with your web SSO system like OpenID? Do you believe that by adopting an Agency-Aware Identity Model, WikiGood could effectively turn its non-corporate customers into a rabid enterprise sales force? I do.

I wonder if it’s time to adopt a variation of Gandhi’s famous formulation: “First they ignore you, then they laugh at you, then they fight you, then you win”. It goes something like “First they ignore you, then they keep on ignoring you but you win anyway”. One nice thing about the new formulation is you get to skip the whole fighting part. I think Gandhi would approve.

On March 7, in his talk at the O’Reilly Emerging Technology Conference, Ray Ozzie, CTO Microsoft, demonstrated (short screencasts, live demo page) a method by which users can cut/copy/paste structured content between web applications and between web applications and Windows ones. Alert lesscode readers will notice that Ray’s blog post describing his inspiration and motivation for the idea bears a striking resemblance to my own post from last October. A deeper look at the screencasts, the live demo and the technical introduction remove any doubt that what Ray demonstrated, and in fact what Microsoft is offering under the Creative Commons Attribution-Share Alike license (you heard me right) is in fact the Web Application Clipboard as described in that original lesscode post and followup.

This is in no way meant to diminish the Microsoft folks’ brilliant implementation. The portable trick used to actually hook the browser’s built-in cut/copy/paste functionality is inspired. The design tradeoff resulting in a visible representation (scissors icon) of every clipboard-capable element is all their own, and quite frankly, is probably a necessary tradeoff if the Web Application Clipboard is to actually get traction. There’s a more technical analysis posted on my personal blog, but the executive summary is:

Live Clipboard (Microsoft’s name for Web Application Clipboard) is awesome and I believe sites will adopt it. I wish the name weren’t “infected” with the Windows Live brand but that won’t matter a whole lot so long as the specification is good and open. Right now though I can’t find any specification at all but I’m keeping hope alive on that front anyway (you listening Gandhi? MLK?)

What I find more interesting than that technical stuff though is the amount of mindshare this thing got “all of a sudden”. First off, note that Ray’s March 7 blog post on this subject comprises the only thing he’s blogged since the end of January. A whole month of the Microsoft CTO’s time — how many dog-years is that? Now realize that the good guys over at the Gillmor Gang podcast spent a full 48 minutes on this single topic on March 16 (Ozzie Gang I, Ozzie Gang II), most of which was spent interviewing Ray Ozzie himself. They were downright effusive. From Ozzie Gang II:

• Mike Arrington, 4:45

  Does this signify any sort of shift organization where people in microsoft who have ideas that can help the Web… that they can also get things through the politics and through the system fast enough so it doesn’t take and years?

• John Udell, 17:52

  Ray this is great. I just personally want to thank you for doing it. I think it’s a tremendous step.

• Steve Gillmor, 17:57

  Yeah, and I think that everybody is knocked out that somebody with your intuition is in such a powerful position at Microsoft. You know, bringing Microsoft into the community has been very difficult to do and you seem to be doing it.

• Dan Farber, 18:31

  I think as everybody on this call has said, we’re quite impressed with this very simple little notion that seems to be well executed and that it comes from Microsoft now really injecting itself into the big old Web community. It’s cool!

• Dan Farber, 19:13

  If you go to the desktop and you consider cut and paste, copy and paste, you know it’s everywhere… to be able to do that on the web… it’s like a big gift — it’s a contribution to the Web.

• Mike Arrington, 22:18

  I think the big story here is that we’re starting to see with Ray’s leadership that Microsoft is able to do things that seem selfless and simply good for their own sake and SSE is one example and (Live Clipboard) is another stunning example…

• Steve Gillmor, 24:05

  I think that Microsoft may well be on the threshold, whether they fully realize it or not at all levels of the organization, of winning by accepting a part in the community, and I think that’s a huge story.

Strange and wonderful times indeed.

David Janes and friends over at microformats.org have written an inspiring greasemonkey script that will find microformat structures on web pages. They include some links to pages with hCard and xFolk content.

When content in a supported microformat is encountered on a page, the script embeds a visual indicator like this one for hCard which when clicked produces a context menu. The functions on on the context menu depend upon the microformat. The menu for an hCard includes an “add to address book” item that will invoke Microsoft Outlook to create a contact.

Perhaps the most interesting thing though, is the menu item to map the vCard address with Google Maps. How many times per week do you grovel around the web for some physical coordinates only to then select-copy-paste into the browser search box, the first line of the address, then select-cut-copy-paste the second line in order to generate a map page? The “show on Google Maps” item does it all in one swell foop, taking you directly to the map!

dschud’s COinS-PMH shares with microformats the ability to embed into a static page, sufficient metadata and structure, to support extended processing without any need to re-invoke the web application that produced the content. But what does “extended processing” mean in this context? It means doing something with that content that the originator could not foresee. In the case of the microformats example it means a greasemonkey script. In the case of COinS-PMH the primary example is a “hacked ‘COinS Details’ sidebar”.

So repurposing content, conveniently, in ways unforeseen by its originator is what its all about. The greasemonkey script and the sidebar provide a glimpse of what’s in store. How much unforeseen functionality do the browser add-ons really provide though? In terms of scalability of functionality, should we expect the plug-ins to keep growing to encompass more functionality? For instance, should the hCard script grow to support mash-ups with more web applications beyond Google Maps? How about adding a function to send hCard holder a gift from Amazon?

The beauty of the hCard-Google-Map-mashup-script is that it didn’t require Google’s web app to understand hCard. The script-mashup did the translation. But that translation is at the heart of the scalability shortcoming. If the script has to contain mappings from each microformat to each way I want to use content conformant to that microformat then the opportunity for explosive functionality growth is missed. If on the other hand, the target web application understood the microformat in question, and we had a way to feed the target app conformant content then the scalability bottleneck would be broken. The wheels would be greased.

In a previous post I proposed the notion of a web app clipboard. The basic idea was that AJAX could be used to request content from a source application. The content would land on the operating system clipboard in a simple format (the web app clipboard format) and could then be transmitted to a destination application. Now I’m thinking that the original proposal was overbold. As Ryan Tomayko intimated, there ought to be a way to marry the microformats approach with the web app clipboard. Perhaps its profitable to think initially in terms of the source content being scraped directly off the page, without requiring the additional request to the sourcing web app. We’ve got that functionality in hand. With that in hand we could focus on the other side of the equation — where to send the content. The effect would be that we would no longer have to create both producing and consuming applications — we could start with just consuming ones. Anything that increases the likelihood that two web apps will communicate is a Good Thing. I’m with Phil Bogle and others who’ve pointed out that we need to bootstrap by finding those first two applications.

If a menu item called “copy” was added to the hCard context menu of the greasemonkey script, and that item caused the hCard to land on the operating system clipboard in a simple standard format, then it would just be a question of where the content could be pasted. Then our task is reduced to inducing a few web apps to support the paste action. A really simple first approach to paste support doesn’t even require XMLHttpRequest at all. A receiving web app could simply provide a text box wired to understand the web app clipboard format wrapping an hCard for instance. Paste into a text box works “out of the box” with all browsers. It’s not all that elegant, but it would work.

Giving microformats a place to go (destination applications) and a simple way to get there (the web app clipboard) will break a key bottleneck hindering broad interoperability.

The Web Standards Project holds as a fundamental truth: that document structure should be separated from presentation or visual style. This two-tier division is embodied by the XHTML standard for document structure and the CSS standard for visual style specification. Adoption of this strict separation of concerns provides revolutionary opportunities for the economical production of highly accessible, aesthetically pleasing web sites. At the same time huge strides are being made by AJAX innovators like 37signals to provide web application user interfaces on a par with those of desktop applications.

Concurrent with these breakthroughs in web user interface technology and practice, there is a an explosion of XML vocabularies, exemplified by OASIS, OPML, Microsoft Office XML, Open Office XML. A zillion XML vocabularies are blooming. These vocabulares are not presentational in nature like CSS, nor are they addressing document structure like XHTML. These vocabularies represent various other domains, commerce domains like order management, personal collaboration domains like calendar and contact management, media distribution and syndication domains, and myriad technical domains such as remote procedure call, database query, spreadsheet structural model. These vocabularies constitute a huge and growing, free, “domain model” for our world. Development, refinement and adoption of these shared, free domain models presents an unprecedented opportunity for both producers and users of information systems.

Enter web applications. Not static content-oriented websites, but honest to goodness web applications. Think email, calendaring, authoring, supply chain management, customer relationship management. These web applications are manipulating at their core, domain models. Sure, these applications have to present an interface to the user, but the bulk of what the application does is manipulate and manage domain-specific information.

While these web applications are manipulating domain-specific information they are doing precious little to expose that information in interoperable form. At best a web application may support download or upload of files. A contact management web application may for instance support bulk import or export — but where is the ability to conveniently “pick” an address from that application and use it as a “ship to” address at an online buying site?

Each web application is an island. This monolithic approach to web applications favors those product vendors who can make big bets — vendors who can tackle and deliver huge applications. Mash Ups provide a glimmer of hope — but only for developers — not really for end users.

It is not a new situation, that applications manipulate domain-specific information — information that users need to share with other applications. It has ever been so. So what’s the difference with web applications? The difference is that in the case of web applications, the world of document structure and presentation has not been bridged to the world of domain models. If Web 2.0 truly represents a new platform then perhaps we should consider whether there is anything to be learned from the older platforms in this regard. Where was presentation bridged to domain model for instance on the Macintosh, Windows and X-Windows platforms?

Remember Me — I Sat Behind You in Freshman English

On those predecessor platforms, the clipboard paradigm was one very important bridge. In the clipboard paradigm a platform-wide set of gestures is supported by all applications. Those gestures enable a user to designate content, to copy that content to a clipboard, and to later “paste” that content into a different location — either in the original application or in a separate application. The range of gestures was expanded on some platforms to include drag and drop with added semantics at the drop location to support the notion of linking in addition to the traditional copy-paste and cut-paste a.k.a. “move”.

Fundamental to the notion of clipboard is the idea that there are potentially many representations for a given piece of content. This is where the bridging between presentation and domain model takes place. The clipboard can capture many representations at once — allowing the receiving application, in concert with the user to select precisely the level of presentation versus domain meaning desired. When pasting a circuit diagram (model) into an engineering report a presentational representation may be chosen, whereas when pasting the same content into a circuit simulation tool, a domain-specific (circuit modeling) representation may be chosen.

Could the original notion of the clipboard be updated to fit the Web Application architecture? Clearly the benefits would be significant. A new model, allowing web applications to leverage one another under user control means that smaller bets and therefore more bets can be made (by product vendors). More bets means more vendors, more applications, and more functionality delivered sooner to the 2.0 Web. While less can certainly be a competitive advantage to a product vendor, that advantage is only amplified in an environment where users can combine the functions of multiple products. If cut and paste and even Compound Documents were useful in the old platforms then they’re potentially much more useful now given the explosion of open, standard XML vocabularies. The opportunity for interoperability is greater than ever. Yet here we all sit, uploading and downloading files between applications.

Some will say, “but my browser supports cut and paste”. Well yes, the browser does support a limited form of cut and paste. But without access to the domain model, the browser is incapable (without help) of providing a cut and paste capability that goes deeper than document structure. Since the browser sees only the style sheet and the document — and not the underlying domain objects, it has no way (on its own) of loading a clipboard with a RDF vCard for instance, because that RDF vCard structure is never seen in its native form by the browser at all. At best an XHTML representation of that RDF vCard is seen at the browser.

Even if the RDF vCard could make its way onto the clipboard somehow, perhaps along with an XHTML representation and maybe a styled representation as well — there is no standard for presenting the multifaceted contents of the clipboard to the receiving web application. Is there a way to bridge the gap between domain structures and document structure?

What Are We Waiting For

Hang on… doesn’t AJAX provide a way out? Doesn’t AJAX allow various gestures to be captured and acted upon? Doesn’t AJAX allow arbitrary requests and responses between the browser and a web application in response to those gestures? Well sure it does!

If a source application could somehow get a standard “web application clipboard” structure onto the desktop clipboard, and if that structure could be sent by the user to a destination web application then the opportunity would arise for users to create “on the fly” Mash Ups. Users would recapture their lost ability to bridge applications requiring various levels of meaning (remember the circuit diagram example?) Web Applications could be combined by mere mortals in ways unforeseen by the original designers.

So what do we need to do to make it happen? Do we need to form a technical committee in a standards body? Do we need to go make a pitch to the software industry Old Guard? Sounds like it could take a long time and involve a lot of risk.

No I don’t think we need to do anything so heavy weight. Who’s in charge here anyway? We don’t have to ask anyone’s permission, and we really don’t have to ask for anyone’s help. Here’s how I see it going down:

1. we agree on a standard, almost trivial, vocabulary for describing the clipboard itself. http://www.lesscode.org/clipboard/v0p1
2. ECMAscript for capturing the cut and copy gestures (in a source application), sends an XMLHttpRequest to the source web application, along with the current “selection” and a command verb — one of “identify”, “copy” or “cut”. Here “selection” is a URI ending in an XPointer identifying the XHTML designated by the user. http://www.lesscode.org/clip-source-request/v0p1
3. The web application returns a clipboard structure. The structure may contain multiple representation elements. The elements have a well-defined order so that the receiving application knows where the most “presentational” representations are and where the most “domain specific” ones are. Note that the source application may choose in the case of “copy” to place content in the representations either “by value” or “by reference”. The latter necessitates subsequent communication between the destination application and the source application. In the case of “cut”, the content is always returned by value. In the case of “identify” it’s always returned by reference. The “identify” verb is for future expansion to support drag and drop gestures. schema: http://www.lesscode.org/clip-source-response/v0p1 and sample instance document: http://www.lesscode.org/clip-source-response/sample-1
4. ECMAscript for capturing paste gesture (in destination applications), sends an XMLHttpRequest to the destination application along with the current destination selection (a URI ending in an XPointer) and the current web application clipboard structure and a command verb — either “paste” or “link”. In the case of “paste” the destination application will either paste the content directly from the clipboard (if the content is provided by value) or will acquire the content from the source application (if the content was provided by reference). http://www.lesscode.org/clip-destination-request/v0p1
5. The destination web application returns a status code. http://www.lesscode.org/clip-destination-response/v0p1

This basic scheme will support copy/paste and cut/paste gestures today and set the stage for drag with drop-copy, drop-move and drop-link later. By focusing first on “by value” cut/copy and paste we avoid thorny issues of distributed trust. The user is in control of the clipboard and there is no direct application to application communication required. Let Big Brains working on things like SAML tackle federated identity management issues. Addressing the clipboard now, and composite applications later constitutes walking before running — or flying. We leave the door open, however, for eventual application to application communication — both for simple efficiency, i.e. avoiding unnecessary routing content through the browser, and for composite application construction.

What Could Happen After That

Picking up what was lost with the move to the Web platform sets the stage for going beyond the predecessor platforms:

• bridge desktop platform clipboards to web application clipboard - this sounds like a job for the Firefox folks!
• browser gesture standards for drag and drop including copy, move, link between applications
• deployment of federated trust standards to support cross-linking of content between web applications
• A pragmatic approach to exposing the domain model to the browser is to use the class attribute in XHTML to attach semantic or domain meaning to what would otherwise be solely a representation of document structure. This is the approach taken by microformats.org. In fact there is even an XHTML alternative to RDF vCard called hCard. The microformats.org approach unifies document structure with domain models by merging the two. Will XHTML with class tags obviate the need for a web application clipboard protocol? Will microformats make the browser all knowing?