Let me start by saying the good friend is an API. Google have decided to close down the Social Graph API (SGAPI) on the 20th April 2012. I have spent the last couple of months thinking of a measured response, although I do somewhat agree with Jeremy Keith’s sentiment.

/> /> “Dear Google, Fuck you. Signed, the people who actually use your APIs”

The API provides two main features the first of which lists our distributed identities across the web. So if I give it the URL of my Twitter profile it returns a list of profiles I have on other sites. I wrote an in depth List Apart article about how this feature works. The second feature tries to find links to profiles of people you have listed as friends/followers on social media sites.

Let’s be pragmatic about its true value

Brad Fitzpatrick built this API as a Google 20% project and it has never really lost its experimental roots. From the outset I was not a fan of the social graph friends listing. It’s too problematic, a lot of friend’s data is private and it’s too complex to mark-up and extract from web pages well. I personally wrote off using the social graph element of the API from the beginning. Evan Prodromou also made a good point that developers want to get authentication and social graph data together. I think lanyrd.com is a good example of this approach.

The identity aggregation element of the API was impressive if not a little too raw to be use on commercial sites. The results needed a degree of post processing to increase the quality. Although I would love to say increasing the quality of the results could be completely done by parsing open standards like hCard or FOAF, you do need to connect to some sites proprietary APIs to get profile data.

Google never tackled the quality issue or put the API on a commercial footing, both of which help stop most people using it beyond experimental hacks.

Panda, schema.org and identity based authority in search

In the last couple of years I have lost my faith a little in the ideas which gave birth to the SGAPI. Development of the semantic web and distributed open web, which seem to have drifted with the growth of monolithic services like Facebook, but things are changing.

Google’s recent changes to search have breathed new life into the semantic web concept. As Google tries to increase its search quality it is moving towards identifying entities (the blocks of structured information within a page). The SEO industry is now adding vast amounts of semantic mark-up to the web. This is being done not because it is the right thing to do, but because of the enhanced click through rates providing the right commercial motivation.

More importantly part of Panda’s new ethos is the promotion of identity authority. We can see this, both in Google’s search listing that displays recommendations from your friends and authorship profiles. They are attempting to link people to other entities such as articles by using mark-up like rel=me and rel=author. Profiles and how they are interlinked is a small part of the Panda concept but still important.

/>

The future – Getting the food chain right

Today’s web apps are often more about building ecosystems of service relationships than technology. These relationships are often chained together and always need each actor to be rewarded for their part.

Web authors or at least the SEO wing of our industry are now seeing a real return for adding semantic structures for entities such as products and reviews. The mark-up of people and organisations entities still have rogue claim issues and still may not become a strong part of Googles search listing. Let’s hope Google continues to support rel=me for identity authority and it drives them to resolve these issues. At the moment them seems to be moving towards a wall garden approach.

Unfortunately, although Google may have the ability now to build a much better API based on its latest developments parsing semantic information for search, it unlikely it will be created. Google is now bringing together its services into a coherent whole and focusing on building its own monolithic social network Google+. It just does not make commercial sense for it to support the open web without financial return.

Other companies have started to provide successful services in this area. Qwerly.com by Max Niederhofer was one of the most impressive identity aggregation APIs I have seen, it’s now part of fliptop.com. Products like rapportive.com and thesocialcv.com use the same technique under the hood. These companies are providing the next generation pay-as-you-go APIs blending together the semantic web and snowflake APIs.

Let’s hope we see on-going development of this new generation of APIs.

So on 20th April I will have a drink and say goodbye to SGAPI

I would like to thank Brad for giving us the SGAPI and everyone else who has worked on it. Although I can understand the commercial rationale that has driven Google to murder my friend, I am not sure I can forgive them for it.

After giving a talking at UXCamp Brighton about Web Intents, I ended up talking to a few designers about it and how they would love to help with its development and adoption. In fact we all felt that the design community was sometimes left out of the development process, when it has a lot to offer.

So, for the past couple of months I have been working with two of Brighton’s leading UX people Danny Hope and Andy Dennis to organise a UX design event. We are trying a slightly new format that we’ve coined a “design push”. The idea is to take a current technology or topic and focus a group of UX designers on a day of open collaboration with the aim of positively adding to its traction by the wider community.

Web Intents Design Push, 25 February 2012 – Brighton, UK

The first “design push” will be on Web Intents, an idea about how to standardise buttons such as Tweet, Like, Share, etc. on the web. My last few posts will give you some background. I have also created a brief screencast introduction to Web Intents.

I had some fun creating the screencast, I built a presentation using HTML for the first time. It’s worth a play as I built the demo’s of Web Intents directly into the presentation. Best use Chrome if you want to play with the demo’s.

Well what an amazing experience fullfrontal was this year. Had lots of fun doing the talk once I got my computer to display the slides (sorry about that). Big thank you to Remy for giving me the opportunity to speak and for putting on Fullfrontal.

Drag and drop demo’s from the talk

Web Intents /> I had lots of positive feedback about web intents, I am trying to put together a UX/design workshop in early January to help build community involvement in its development. I will be posting and tweeting more information about that in the near future.

The Web Intents demo

PeopleStore /> Quite a few people asked me about PeopleStore, am I going to make it into a product or open source it? At the moment it is still a just side project and a playground for new ideas, so sorry it’s not public. That said, after such a lot of interest I am rethinking what to do with this project. If you’re interested in code examples from PeopleStore take a look at the codebits section of this site, a lot of features are explored there.

My hi-lights from this year’s talks:

You gotta do what you gotta do /> Was lucky enough to sit with Marcin Wichary during the speakers meal and hear first-hand about his work at Google. I loved the slide deck built completely in HTML and the fact that he linked Safari and Chrome together over sockets to get accelerometer data he needed for just one small part of his presentation. I think the most interesting thing about Marcin’s talk was all the small insights he gave about the design process needed to come up with ideas for the Google search page.

CoffeeScript Design Decisions /> Jeremy Ashkenas talk on CoffeeScript really made me want to try it out. I have a fundamental dislike of any language/abstraction that is designed to write another language. Jeremy’s overview of the architectural ethos of CoffeeScript made me believe it could be a possible exception to my rule. Some of the features they have added to CoffeeScript go to the heart of everyday problems I have with JavaScript. The talk also pointed out how much room there is for improvements to JavaScript itself.

Excessive Enhancement – Are we taking proper care of the Web? /> Phil Hawksworth talk focused on the central issue of just because we can do something does not mean we should. One of his other main themes is something I often talk about with designers/developers which is having a respect for the medium we work in. At art college we used the term “go with the grain” in its widest sense this meant to fully understand the properties of a medium and work to bring them out to their full potential. ubelly.com have done a write up of Phil’s talk which is worth a read.

Brendan Dawes has infectious passion /> I have seen Brendan speak at a few events over the years and he has an infectious passion for innovation and experimentation that just has to be admired. It’s so interesting to see his love for the design of physical objects move him in new directions. I hope I get to see him talk again as I never seem to get bored of hearing about his adventures in design. ubelly.com also interviewed Brendon

Scalable JavaScript Application Architecture /> Nicholas Zakas took us all on a tour of the concepts of module code architecture and how to loosely-couple JavaScript. These ideas are so important to any complex project, yet the nature of JavaScript use on the web today means we often cut many corners in our code design. Note to self: review this slide deck again before starting large JavaScript projects.

Code editing /> Marijn Haverbeke and Rik Arends both did talks on the various aspects of online code editing. I cannot even begin to imagine the effort that it takes to develop one of these code editing environments, they look very impressive. Might be time to put down Visual Studio and move over to a hosted application for code editing. Hope they have drag and drop support />

Links

• Mark Kirby’s write up
• Paul Downey doodles and notes
• Michael Mahemoff’s live blogging
• Phil Hawksworth’s write up
• Chris Price’s write up
• Christian Heilmann’s write up
• Mairead Buchan’s write up
• Dumitru Glavan’s write up
• Peter Bowyer’s notes

This Friday I gave small talk on microformats and SEO at the web agency Fresh Egg. They focus heavily on SEO as part of their offering and have become interested in marking up semantic data in web pages. This year Googles rich snippets have brought a whole new group of web authors to microformats. Taking a look at Googles new recipe search I can see why microformats has become a hot topic in the SEO industry.

Rather than just provide a general overview I decided it would be fun to mark-up a Yorkshire Pudding recipe. You never know, one day it may appear at the top Googles recipe search.

I ran a small session at UXCampBrighton last weekend about Web Intents. At the end of the session I was hoping for a discussion about the use of verbs in Web Intents, but the questions where a lot more wide ranging.

As people grasped the concept they rightfully asked some questions of it. I thought it would be useful to document an aggregation of these conservations and my answers.

• Will social media companies let go of branded buttons
• Users will never get the concept
• Why don’t we just let Facebook/Twitter dominate – do users really want choice?
• In page UI vs chrome UI
• Common iconography and verbs

The slides

Will social media companies let go of branded buttons?

We discussed the value to companies of having buttons that both advertise and endorse a brand through the use of logos and trademarked phrases. I was asked the question; would social media companies provide services through Web Intents if it meant letting go of this visual branding?

The network effect of sharing social media outweighs any value gained from the promotion of visual identity on buttons.

That’s to say Twitter, Facebook etc. have expanded by linking people as they share social media objects (text, images etc.). Traditional visual branding is not as important as engaging users in the experience of using a service, in this case sharing social media objects.

In a small way we can already see this effect in action as the social media/networking sites allow publishers to re-work their visual identities by removing the terminology and phrases they’ve carefully crafted and promoted. In the BBC example below, the designers did not use the buttons provided by the services, instead they have greyed out the logos and removed the terms ‘tweet’ and ‘recommend/like’.

/>

Most large companies have strict visual guidelines for the legal use of their logo’s and trademarks. Take a look at the Twitter and LinkedIn guidelines as an example. I would suggest in this context that these companies don’t care about small infringements of their visual identity as long as people are encouraged to share using their networks.

The caveat here is that the speed of visual recognition and trust engendered by some of these buttons/logos may help increase traffic to these services. Web Intents would need to create the same or greater levels of traffic to these services while using generic iconography and terminology. If it did not, I am sure the social media companies will not be as happy to embrace Web Intents.

Users will never get the concept

At one level Web Intents can be seen not as a new idea but the standardisation of a pre-existing design pattern into the UI of the browser

Earlier this year the StumbleUpon “Stumble” button passed 25 billion clicks. On AddThis network StumbleUpon has 1.69% marketshare (2 Oct 2011) across all the services it offers. This gives you some idea of the level of interaction which can be mapped to the type of design pattern Web Intents is trying to capture. As long as the user experience developed for Web Intents does not add a lot more complexity, it should be widely understood by the current users of services such as StumbleUpon.

Why don’t we just let Facebook/Twitter dominate – do users really want choice?

Yes, the AddThis statistics make stark reading with 67% of market share in the hands of Facebook and Twitter. Even in light of this, there is a long tail of hundreds of other services that fit the design pattern of Web Intents. Maybe it is the inability to provide choice that defines the current usage patterns not the other way around.

The current status quo has publishers coalescing around a handful of the biggest services, because they have no means of knowing which services are the ones an individual user would prefer. If a site could deliver individualised button/links based on a user’s choice, there should be a substantial gain in utility to the user and traffic for the publisher and the service. This change may not inevitability reduce traffic to large service providers, but instead, increase traffic to smaller ones.

You need also to consider that different communities around the world embrace different services and that sharing a web link is only one type of many services.

The level of choice. /> Hick’s Law or Hick–Hyman Law, roughly states that the time it takes to make a decision increases with the number and complexity of choices. As the decision time increases, the user experience suffers.

Satisfaction curve

/>

I am interested in finding out how publishers define the optimum number of services to display to the user. What factors are foremost; is it purely about screen space; the market share of services or is it Hick’s Law playing a part in these design decisions? More importantly, what results would I get if I could test user choice vs decision complexity in this context?

In page UI vs chrome UI

I believe that keeping the complexity of interactions to an absolute minimum will be a deciding factor in the success of Web Intents

A browser is split into two heavily defined surfaces. There is the web content/page and the chrome. Building interactions that span these two areas is not easy. Building any type of browser UI that overlay’s the HTML content brings up some security concerns.

Taking into account all the above, I still think keeping all the UI contextual to the original area of interaction in the web content is very important. Popping windows away from the original click event or navigating between full pages will cause more mental load for the user. There are already working models we should look to such as current proprietary buttons for sharing and the OAuth UI flow. These have been heavily researched and tested in the real world and should form a starting point for any UI design. In the end it will be the browser development teams that frame the main UI flow.

Common iconography and verbs

I think it is obvious to most people that a common iconography and language is needed for Web Intents. The calls to action need to be both understandable and recognisable as their proprietary counterparts i.e. Twitter ‘tweet’ and Facebook ‘like’

It is unlikely that all the elements of language/ iconography will be fully developed in the API specification process being undertaken by the Chrome and Mozilla teams as they will be surfaced in the HTML of the publishers of sites.

I would like to see a two phased approach. Engage the UX community in an open process to quickly define the visual language for calls to action i.e. the buttons. Then create a simple wizard on webintents.org to generate the code for people to use. Guidelines and wizards for site publishers are fundamental to generating up-take.

In conclusion

Although I was asked many questions the overall response to Web Intents was positive. I was even approached by some UX designers about getting together a workshop/design meet-up to look at the whole UX flow.

The answers above are written from a personal view point. If you’re new to the topic, I would recommend reading the discussion forum to gain a broader insight.

There is a new concept forming at the moment called Web Intents. The name is a reference to the Android feature which allows applications to register their “intent” to handle certain types of actions.

/>

The screenshot above shows all the options for sharing an image on my Android phone. The underlying application does not have the ability to share images itself, so it asks the OS to list the applications that can. The user is then presented with the choices above and the two applications exchange the data required for the feature to work.

Intents work in a similar way to how applications on a desktop register their ability to open and modify a particular file type. An Intent takes things one stage further registering not just a content type, but also a verb to describe an action i.e.

• Post a Status
• Edit an Image
• Share a Bookmark
• Reply to Post
• etc

We already have perfect examples of this pattern in use today in the shape of the many social media buttons which are proliferating across the web. At the moment they are not built using the concept of Intents, but they could be.

/> Tweet /> etc. /> /> /> On web sites we are often presented with a collection of buttons for services we do not use and more importantly not presented with the ones we do. Erin Jo Richey called these types of sites “button sluts”. There are some unsatisfactory user interface fixes for this issue such as “AddThis” which extend the user’s choice by extending a broken pattern. I don’t think these really solve the underlying problem.

Web Intents could provide a whole new generation of interactions on the web which would complement how it already works. They could give more user choice and de-clutter the web of the visual and mental load created by all these buttons. If widely implemented it would allow large publishers and individuals to provide services on an equal footing.

Two driving forces for the adoption of Web Intents

Social buttons /> We already have multiple use cases for Web Intents in the shape of the many social media buttons. At the moment these buttons are a jumble of proprietary iframe code, which seems set to reinforce the NASCAR problem.

Currently, Twitter’s Web Intents is the most progressive implementation of social buttons. Twitter’s Web Intents API is not the same as the Web Intents API being developed by the Chrome and Mozilla teams, but it is an interesting architecture in its own right. I admire how they used a simple HTTP Get request to form a powerful API and then deployed JavaScript to hijack HTML links to create the buttons.

Web app/service discovery /> The second driving force comes from the search to create a simple discovery mechanism for web app/services. Michael Hanson of Mozilla Labs wrote a post at the beginning of this year about the growing need for a new way to glue web functionally together. The theoretical work around web app/service discovery and social buttons have the same architectural patterns. Mozilla have called their approach “Web Activities” and you can see a demo in a video they posted in July.

Building it into the browsers

Paul Kinlan from Google conceived the idea of Web Intents. He has started documenting their development at http://webintents.org/. Most importantly the Mozilla Lab and Chrome teams have started to work together on a common API to implement Web Intents into their browsers.

User interface and experience ideas

Having a design background I tend to think visually and built an early mental picture of what the user interface for Web Intents could look like. I visualised this before Paul Kinlan published the http://examples.webintents.org/ site and Mozilla Labs posted their video. In doing so I made some assumptions which I thought would be interesting to share; especially as they vary from Paul’s initial demo. It is also worth taking a look at Erin Jo Richey mock ups which provide a slightly different perspective to the user interface design.

Registration of Web Intents /> As a user I would like to be prompted about the registration of a service, if nothing else to make sure I only register with services from sites I trust. The closest model for prompting the user to allow data/service access is the Geo API. It would not take much to reuse the pattern to provide a Web Intents acceptance prompt.

/>

The question of registering multiple services at once would need to be considered. I personally think site authors should be encouraged to create URLs where multiple Web Intents could be registered at once.

Managing Web Intents

/>

Over time our preference for which services we use on the web will change, so browsers will need to provide an interface for us to manage this. In the wireframe above I used a 2-tier-tree navigation. The first tier represents the action verbs like” share” and the other tier content types such as “link”. Technical names such as “mime-types” should not be used and exchanged for more friendly language.

I would also expect some fine grained controls such as the ability to enable and disable services and to change their order of display. With all of these controls we end up with a user interface not too dissimilar to those used to manage our browser plug-in/extensions.

Using a Web Intent

/>

Where a page subscribes to a Web Intent such as sharing a link, I believe the most functional interface would be button with a drop-down menu. This would allow the user to quickly choose from a set of options. Any service which requires further input from the user, like the assignment of tags, would be done through secondary windows.

At first sight the drop-down looks like we are recreating the NASCAR problem. What has to be remembered is that these options were chosen and curated by the user. It follows that they will be limited in number and always be meaningful options for that individual.

Silent registration – the most complex UX problem /> The interface could either silently register the Intents or prompt the user. The designers of Andriod’s OS took the decision to silently register so my wish for more control may not be what the majority of users want.

The Web Intents architecture

The user interface for Web Intents really needs to be built into the browser, but for the time being Paul Kinlan has built a temporary JavaScript library which allows us to experience Web Intents. The code examples below are based on using that library. There are three parts to the architecture.

/> /> Registering a web intent (Site A) /> Registering a new service is simple. Once you have included the webintents.js from the JavaScript library, you add an Intent tag into the header of a page. /> [sourcecode language="html"] /> /> action="http://webintents.org/share" /> type="text/uri-list" /> href=" http://examples.webintents.org/intents/share/sharelink.html" /> title="Kinlan’s Link Share" /> /> [/sourcecode]

/> /> Subscribing to a web intent (Site B) /> Again you need to include the webintents.js file from the JavaScript library and also build an Intent object. This object describes the type of Intent and also passes the data. /> [sourcecode language="javascript"] />

var intent = new Intent(); /> intent.action = "http://webintents.org/share"; /> intent.type = "text/uri-list"; /> intent.data = [ url ];

window.navigator.startActivity(intent); /> [/sourcecode]

/> /> Collecting the data at the end point URL (Site A) /> At the service endpoint you need a small piece of JavaScript to collect the data. The magic bit is how Web Intents passes the data between the windows as they are opened. The sites at both ends of this interaction do not need to know anything about each other. The browser or in this case the JavaScript library negotiates this for the two parties. /> [sourcecode language="javascript"] />

/> [/sourcecode]

The API is still in flux as the Chrome and Mozilla teams align their work. The code examples above will change as this happens. You should visit the webintents.org site for the most up-to-date reference. If you wish to keep informed of how the development of the API is going I would suggest registering to the Google Group.

The Future

I think the future is bright for Web Intents, as it seems to have support from the Chrome and Mozilla teams. There are a number of technical issues outstanding, but none that should derail the project.

The role of brand equity /> I have not heard many people talk about the role of brand equity in the rise of social buttons. I have no idea how much it would cost to put my company’s logo on all the sites that host the Tweet or Follow button – it would be a lot.

Even considering social buttons as a form of advertising underplays their true value. In fact they are more like an endorsement from one brand to another. The Guardian newspaper carrying the tweet button on all its articles is the equivalent to it saying, “we believe that Twitter is the premium sharing service”. One has to ask how interested some service providers will be in a feature which hides this type of brand promotion, even if it is in the best interests of their users.

Although I am wary of the commercial issues and the user experience has yet to be proven in the real world, Web Intents has compelling properties. I think it is well worth promoting.

Useful Links

Reference Sites /> http://webintents.org/ /> http://examples.webintents.org/ /> http://usecases.webintents.org/ /> https://groups.google.com/group/web-intents

Blog Post /> Paul Kinlans – Web Intents a fresh look /> Tantek Çelik – Web Actions a new building block (Google+ comments) /> Erin Jo Richey – Button Sluts and Web Actions /> Tom Gibara – Reservations about the Web Intents system

Chrome – Connecting Web Apps with Web Intents /> Mozilla Labs – Web Apps Update – experiments in Web Activities, App Discovery

IndieWebCamp /> Chris Messina  – Session: Standardizing Web Intents /> Ben Ward – Sessions: How the Indie Web Hooks into Hosted Communities

Reference Technologies /> Android Intents /> Web Introducer /> Activitystreams /> Twitter Web Intents API />OpenService Accelerators

In June 2011 I made the journey to IndieWebcamp in Portland where Web Intents became quite a big topic. For an introduction to Web Intents read my last blog post “Web Intents – Gluing web functionally together”

On the first day Chris Messina led a discussion that started with the architecture and focused in the possibilities of hijacking social buttons and turning them into Web Intents. Ben Ward carried on the discussion in another session.

The Web Intents could possibly fix the unwanted button issue and also allow large publishers and individuals to provide services on an equal footing. It’s this property which was so interesting to the people at IndieWebcamp.

Brainstorm user experience

At the end of IndieWebcamp Tantek Çelik and Erin Jo Richey brainstormed the current social sharing user experience and Web Intents. Erin posted a blog entry which has her thoughts on a possible user interface design. Tantek also posted a thoughtful piece that tries to give a historical context and future path for development through the studying of current use cases. There are some interesting comments on Goggle+ about Tantek’s post. Erin and Tantek have also put forward a talk for SXSWi on the subject.

Declarative mark-up for current social button patterns

Some of the discussion at IndieWebcamp was focused on whether we could use a browser extension to hijack current social buttons and overlay the Web Intents concept. The question asked was could we change a Facebook ‘Like’ button into a share button that used the registered Web Intents instead?

At the hacking session I started to build a prototype browser extension. It was primarily aimed at exploring the use of declarative mark-up as social button design pattern.

You need three elements to make Web Intents work the first is a browser based management interface. In this case I created a Firefox extension, a method to register the intent and a method to subscribe to the intent.

Web Intent registration

Ben Ward codified a hypothetical manifest structure for the Twitter Web Intents. It contains concepts for property name mapping and proprietary requirements. He based it on his experience of the Twitter Web Intents API. I have since added to the structure a little.

The registration of a service or group of services using JavaScript would typically look like this: />

function init(){
    window.intents.register({
        ‘vendor’: ‘Twitter’,
        ‘intents’: [
            {
                'name': "Tweet Link",
                'verb': 'share',
                'type': 'url',
                'required_params': ['url'],
                ‘url’: ‘http://twitter.com/share’},
            {
                ‘name’: "Retweet",
                ‘verb’: ‘share’,
                ‘type’: ‘status’,
                ‘required_params’: ['tweet_id'],
                ‘url’: ‘http://twitter.com/intent/retweet’,
                ‘param_map’: {‘object_id’: ‘tweet_id’}
            }
        ]
    });
}

window.addEventListener(‘load’, init, false);

Subscribing to a Web Intent

I built the subscription around the use of HTML5 ‘data-‘ attributes. This type of attribute can be used to provide all the additional information for a Web Intent. Its use would allow for progressive enhancement of a standard HTML link.

There are two distinct groups of attribute. The first group contains ‘data-verb’, ‘data-type’ and ‘data-url‘ which would be mandatory. Providing all the data needed to define a Web Intent.

Bookmark link

The ‘date-text’ attribute is an example of an optional data type. Supplying additional data would help the services to pre-fill forms that are presented to the user and improve the user experience.

Conceptually this design would use an agreed set of attributes for each verb/content-type combination, with a parameter mapping system so pre-existing URL end points would not have to be changed. We also added a proprietary naming scheme for extensions of optional data e.g. ‘data-v-twitter-via’

The Firefox extension

Although only half finished it is possible to try out some of the prototype functionality. /> You can register a Web Intent

• Allows for basic management through an interface
• Finds the declarative HTML mark-up for subscriptions

To try this out, download the extension. It should install directly into Firefox then view the registration page and select “Allow” in the dialog

/>

There should be a small blue “in” icon in the Add-on bar at the bottom of the browser. Clicking this will bring up the management interface.

/>

Finally, navigating to the subscription page will show you an alert for each of the Web Intent subscriptions it discovers in the HTML. That’s as far as I got (it was only a few hours of hacking !).

Why have I not finished the prototype?

If we map out the approaches taken to implement the current social buttons you find 3 distinct models. They all use a URL endpoint for each service, but vary in how they exchange data.

1. Uses the query string parameters which are pre or dynamically populated
2. Extracts data from the referring URL. The service parses the HTML
3. Exchanges data hidden behind a JavaScript interface

In practice you can see a combination of the above being used in a single implementation. Each model has different strengths and weaknesses. What is important is that all the current common use cases for social buttons are captured and that the Web Intent design has the widest coverage.

The design I envisaged passed data using the URL query string. This follows the design of Twitter’s Web Intents API and a lot of the other social button APIs. The Chrome and Mozilla teams are taking another approach still using a URL endpoint for each service but passing data as JSON objects through the context of the browser. This is arguably much more flexible.

Having read Tom Gibara’s post Reservations about the Web Intents system I do not agree with most of the points, but I can see the possible need to delegate URLs endpoints.

“…allows one web application to hijack an “intended” link to another. Example: an intent to view a Flickr photo by linking to its URL could be delegated to an application that displays Flickr photos in a way that is more to the users liking.”

Twitter has taken the approach of supporting just about every way of defining the data for a social button. They have also prioritised the order in which they discover it. The list below is taken from their button API documentation:

1. Look for url in the share link query string.
2. If not found, look for the data-url attribute of the Tweet Button anchor tag
3. If not found, look for the rel=”canonical” link tag in the head of the document
4. If not found use the URL of the webpage

If you added delegated URL endpoints to Twitter’s data entry this would be an extremely flexible solution. The question is whether this level of flexibility adds too much complexity. Only reviewing the use cases can give this answer.

I would like to spend some time considering this and as the Web Intent API is still in major flux while the Chrome and Mozilla teams align their work, I think this project is best left a while.

IMPORTANT /> The examples/code in this document are different to both Paul Kinlan webintents.org API and Mozilla Labs Web Activities API. In the past couple of months a lot has happened in this area and I now consider this work to be at a tangent to the main body of development taking place.

A couple of weeks ago I gave a talk at Brighton Skillswap called “The page and the desktop”. With some of the newer HTML5 APIs it is now possible to redesign how your web pages interact with the desktop. Web pages are all too often little islands that fail to interact well with the wider user interfaces of our devices. The talk tries to explain how the new Drag/Drop and File APIs could make web pages more equal in the world of applications.

The talked started with a series of demos that show what is currently possible. I have recreated the demos in a short screencast, hopefully it will give more context to the slides.

Example code

• The Firefox Virtual File Hack />A hack to create virtual file download using the anchor tag type attribute and the JavaScript window object
• DownloadURL and Data URL support />A test using the DownloadURL type and Data URL together
• DownloadURL support />A test using the DownloadURL type for a drag and drop method setDate
• Enterbox Idea />An experimental UI component that accepts HTML drop and paste

As I build projects I often try out new ideas, these sometimes get lost as I move on to other things. Codebits is a place for small snippits of shinny ideas and tests of all things web. I am going to use it to remind myself of how things work, but hopefully it will be helpful to others.

The first set of code sketches are all on the subject of copy and pasting. Over the next few weeks I will try and post up more stuff on ‘drag and drop’ and file APIs.

As part of the mircoformats meet up in Brighton this week a group of us took some time to discuss the semantic mark-up of forms. This was based on my previous thoughts on the subject. We also look at this issue in light of Tantek’s proposal for the version 2 of microformats.

Please forgive that fact that I have not noted everyone’s name who took part. The main people contributing were; Aral Balkan, Glenn Jones, Jeremy Keith, Josh Emerson and Tantek Çelik. The session was broken down into 7 small discussions of specific problem areas. I have summarised below.

Using the class attribute and hierarchies

There was full agreement for the use of the className attribute instead of the form field name attribute. The name attribute can only take a single value and does not give enough flexibility to the author of a form as the name maybe dictated by the server side code.

For the current version of microformats, the use of hierarchical structures was agreed upon. The structures will be flattened in version 2 of microformats. In principle, form mark-up should follow the hierarchical structure of the microformat. /> Examples used for the discussion:

[sourcecode language="html"] />

Defining types in the className attribute

There is a problem adding ‘type’ information i.e. home, work and pref to inputs that take telephone numbers or email addresses. There are many use cases where the author wants to define a specific ‘type’ of a property, such as a mobile telephone number, to a single input. To accommodate this we somehow have to add the ‘type’ metadata as well as the property name.

In the current version of microformats, most people at the meeting were happy with the type information being added into the className attribute. For version2 of microformts, Tantek suggested adding a prefix of ‘l’ standing for label.

There was some discussion of using the HTML label element to define the microformat property. But it was dropped as we could not think of an authoring use case and it would add complexity.

Tanteks microformats v2 idea: /> [sourcecode language="html"] /> /> /> [/sourcecode]

Example used for the discussion: /> [sourcecode language="html"] /> /> /> [/sourcecode]

Repeating microformat properties

This was generally agreed between everyone except Tantek. There are a large number of use cases where we find repeating patterns. These patterns allow a user to add multiples of one item. The most common example in hCard is the URL property. We discussed the use of a “repeatable” class that would cause an auto-fill application to duplicate the whole DOM node and append it as a sibling underneath the original.

The word “repeatable” was preferred over “repeat”. Although there are use cases to back up this type of functionally Tantek thought it broke the layers of abstraction and we could never be a 100% sure it would not damage the layout designed by the author. Tantek rejected this as a possible solution. No agreement/conclusions were reached about this point.

Example used for the discussion: /> [sourcecode language="html"] />

Repeating microformat structures within one form

This item is similar to the previous item and as such everyone took a similar point of view. Jeremy believed that he could see good real world uses for this pattern of mark-up. Again “repeatable” would be a better className. Tantek’s previous objections were carried forward to this pattern.

Example used for the discussion: /> [sourcecode language="html"] />

Logical operator “or”

There are times where an author may wish to use more than one property if it’s available. If we were to use this pattern the “or” is not required. Tantek pointed out that there is no order to the className attribute and we should not force one artificially to enable this feature.

Example used for the discussion: /> [sourcecode language="html"] /> /> /> /> /> [/sourcecode]

String concatenation

There are a number of circumstances where concatenating a plural microfromats property into a single string is required. The best example of this is a number of individual tags into a single string.

Jeremy suggested using the multiple attribute or a className multiple. As the multiple attribute can currently only be applied to a file input or a select element we will have to use the word ‘multiple’ in the class attribute. There was some discussion about dropping the formatting instructions.

Example used for the discussion: /> [sourcecode language="html"] /> /> [/sourcecode]

The group’s solution: /> [sourcecode language="html"] /> /> [/sourcecode]

Additional – Inputs inheriting parent className values

As we talked, it became apparent that it would be useful for a form element to inherit its parent className value. The form field would have to be the only form field of the parent. This type of structure would be required to ease the authoring of the ‘repeatable pattern’.

The group’s solution: /> [sourcecode language="html"] />

/> Phone: /> />

Related microformat wiki documents

• http://microformats.org/wiki/hcard-input
• http://microformats.org/wiki/hcard-input-examples
• http://microformats.org/wiki/hcard-input-formats
• http://microformats.org/wiki/microformats-2