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.

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

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.

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.

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"]
<script src="/webintents.js"></script>
<intent
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"]
<script src="/webintents.js"></script>

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"]
<script src="/webintents.js"></script>

<script>
attachEventListener(window, "load", function(e) {
var output = document.getElementById("output");
if(intent.data instanceof Array)
setText(output, intent.data[0]);
else
setText(output, intent.data);

intent.data.postResult(intent.data);
}, false);
</script>
[/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

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:
[sourcecode language="javascript"]
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);
[/sourcecode]

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.

[sourcecode language="html"]
<a href="http://www.delicious.com/save?v=5&noui=&jump=close&url=http%3A%2F%2Fbbc.in%2Fiert2M&title=BBC%20News%20-%20Public%20sector%20strike%20hits%20services%20and%20schools"
data-verb="share"
data-type="bookmark"
data-url="http://www.bbc.co.uk/news/uk-13967580"
date-text="Public sector strike hits services and schools">Bookmark link</a>
[/sourcecode]

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.

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
]]> http://glennjones.net/2011/08/the-page-and-the-desktop/feed/ 0 http://glennjones.net/2011/04/small-snippits-of-shinny-ideas-and-tests/ http://glennjones.net/2011/04/small-snippits-of-shinny-ideas-and-tests/#comments Wed, 27 Apr 2011 09:31:25 +0000 Glenn Jones http://glennjones.net/?p=515 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.

]]> http://glennjones.net/2011/04/small-snippits-of-shinny-ideas-and-tests/feed/ 0 http://glennjones.net/2011/04/semantic-form-mark-up-discussion/ http://glennjones.net/2011/04/semantic-form-mark-up-discussion/#comments Thu, 14 Apr 2011 08:34:42 +0000 Glenn Jones http://glennjones.net/?p=498 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"]
<fieldset class="adr">
<input class="locality" name="city" type="text" />
<input class="country-name" name="country" type="text" />
</fieldset>

<div class="tel">
<input class="value" name="telephone-number" type="text" />
<select class="type" name="telephone-type" multiple="multiple">
<option value="none">Select phone type</option>
<option value="home">Home</option>
<option value="work">Work</option>
<option value="pref">Pref</option>
<option value="fax">Fax</option>
<option value="cell">Mobile</option>
<option value="cell">Pager</option>
</select>
</div>
[/sourcecode]

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"]
<input class="p-tel l-cell" name="mobile-number" type="text" />
<input class="p-tel l-fax" name="fax-number" type="text" />
[/sourcecode]

Example used for the discussion:
[sourcecode language="html"]
<input class="tel cell" name="mobile-number" type="text" />
<input class="tel fax" name="fax-number" type="text" />
[/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"]
<div class="tel repeat">
<label for="tel">telephone</label>
<input class="value" name="tel" type="text" />
</div>
[/sourcecode]

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"]
<form>
<div class=" vcard repeat">
<label for="name">Name</label>
<input class="fn" name="name" type="text" />
</div>
…
</form>
[/sourcecode]

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"]
<input class="title role or" name="job-title" type="text" />
<input class="extended-address street-address or" name="address1" type="text" />
<input class="extended-address street-address or" name="address2" type="text" />
<input class="extended-address street-address or" name="address3" type="text" />
[/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"]
<input class="category comma-space-delimited" name="tags" type="text" />
[/sourcecode]

The group’s solution:
[sourcecode language="html"]
<input class="category multiple" name="tags" type="text" />
[/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"]
<p class="tel repeatable">
<label for="telephone">Phone: </label>
<input id="telephone" name="telephone" type="text" />
</p>
[/sourcecode]

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
]]> http://glennjones.net/2011/04/semantic-form-mark-up-discussion/feed/ 0 http://glennjones.net/2011/04/contact-extensions/ http://glennjones.net/2011/04/contact-extensions/#comments Tue, 05 Apr 2011 22:45:19 +0000 Glenn Jones http://glennjones.net/?p=432 The extensions below allow you to copy, store and then later paste contacts into forms. They are proof of concept prototypes taken from a larger project. I have released the extensions now to help inform the discussion at the upcoming mircoformats meetup.

You need either Firefox 4.0+ or the latest Chrome browser.

Download Firefox extension (0.1.2 updated 16 Apr 2011)

Download Chrome extension (0.1.2 updated 16 Apr 2011)

2 minute video overview

How the extensions work

Copying contact details

Navigate to a page which contains a contact marked-up in hCard and right click on it. The context menu should then contain an item “Copy [Name] contact details”. Selecting this menu item will store the data in the browser.

Pasting the contact details

Navigate to a page which contains a form for contact details and right click on it. The context menu should then contain an item “Paste contacts…”. Choose a contact from the submenu and the extension will paste the data into the form for you.

Design considerations for the future

Issues of discoverability

The largest problem for the copy and paste of semantic data embedded in web pages is discoverability. It is difficult to indicate where and what data is available without over complicating the browser interface. I think the solution lays within joining the copy and paste functionality with other forms of interaction and/or visual flagging that will provide discovery.

Forms need to be marked-up semantically

At the moment most applications that auto fill web forms do not work very well. The common approach of “guessing” what data goes in which field is error-prone. Often the browsers/extensions use regular expressions to match the form field name.

Matching rule for a job title looks like this (?:occupation)|(?:job)|(?:title)

There are more sophisticated approaches which record matching rules from users, but even these are not perfect. What we really need is a way to semantically mark-up forms so there is little or no ambiguity. I have done some conceptual work on how microformats could be used to mark-up forms.

Labelling UX

Although the extensions currently work by parsing hCards I have used the terminology ‘Contacts’. This is for two reasons the first is that users do care about underlying schemas. The second is that a future interface design may abstract the data and display it differently to how it’s parsed from the page. For example, how do we deal with hResumes, do we just extract one contact or several based on work or educational history. If an hCard contains both a work and home address is it displayed as two contacts. Re-displaying the data in its raw form may not give the most intuitive interface.

Data source has to be comprehensive

Contacts found on the web are often just constructed of a few elements and not comprehensive enough to auto-fill a range of forms. The data may need to come from another more fully structured source than a web page for auto-fill to work relatively well. I also believe the user would need to be able to view what was to be copied, what is in the data store before making copy and paste choices.

]]> http://glennjones.net/2011/04/contact-extensions/feed/ 0