Ian Hickson was kind enough to point me to this post after I asked about consolidating the itemscope and itemtype attributes into item.
See: 
Here are my comments on their conclusions which you may find helpful:
Conclusions
>>Some interesting things came out of this study. First, as mentioned above, the term "about" turns out to be highly non-intuitive. I originally took the word from RDFa, on the principle that they knew more about this than I did, but our participants had a lot of trouble with that term. When we changed it to "itemid", there was a marked improvement in people's understanding of the concept.
Me: Agreed as a newcomer to RDFa and Microdata, itemid was far more clear.
>>Second, people were much less confused about types than I thought they would be. In preparing for this study I discussed microdata with a number of people, and I found that one major area of confusion was the concept of types vs the concept of properties. This is why variant 3 has no types: I wanted to find out whether people had trouble with them or not. Well, not only did people not have problems with types, several participants went out of their way to specify the type of an item, for example using the attribute name "type" instead of "item" in variant 1.
It seems that while reasoning about types at the theoretical level is somewhat confusing, it isn't so confusing that the concept should be kept out of the language. Instead, types should just be more explicitly mentioned. This is why we renamed "item" to "itemtype".
Me:Ok I can see that more concrete attribute name actually helping publishers fill the right thing in.
>>Third, people were confused by the scoping nature of the "item" attribute. Some of our participants never understood scoping at all, and most of the participants who understood the concept were still quite confused by the "item" attribute. We were encouraged, however, by one variant 1 participant's sudden enlightenment when they saw variant 3's "itemscope" attribute, and by the reaction of the variant 3 participant to the "itemscope" attribute compared to the reactions that the other two variants' participants had to their "item" attributes. This is why we split "item" into "itemtype" and "itemscope", instead of just using "itemtype".
Me: I can see that making it easier for newcomers to grasp however once you are familiar you do yearn for the shorthand. In addition, I found that current parsers struggle with boolean attributes like itemscope.
>>We found that people who understood microdata's basic features also understood "itemfor", but while we were doing the study, it was pointed out on the WHATWG list that "itemfor" makes it impossible to find the properties of an item without scanning the whole document. This is why we tested the
In general, the changes we made for variant 4 were all quite successful. With one exception, that's what HTML5 now says. The one exception is that I hoisted the "itemid" property to an attribute like "itemtype", based on the argument that if people want to scan a document for the item with a particular "itemid",
One thing we weren't trying to test but which I was happy to see is that people really don't have any problems dealing with URLs as property names.
Me: Excellent. I was curious about that
>>In fact, they didn't even complain about URLs being long, which reassured me that microdata's lack of URL shortening mechanisms is probably not an issue.
Overall, this was a good and useful experience. I hope we can use usability studies to test other parts of HTML5 in the future.
Me: Nice what we now need are multiple users writing parsers so we can go through their pain points if any. But overall I am very impressed with the clarity of this spec.
No comments:
Post a Comment