From brian.suda at gmail.com Thu Oct 1 02:46:21 2009 From: brian.suda at gmail.com (Brian Suda) Date: Thu Oct 1 03:22:27 2009 Subject: [uf-new] hlisting and quick intro In-Reply-To: <41E46AEE-9B48-47A8-B5F6-F2B40D147DE2@spiritquest.co.uk> References: <41E46AEE-9B48-47A8-B5F6-F2B40D147DE2@spiritquest.co.uk> Message-ID: <21e770780910010246u17590403p99216aa371c5aff2@mail.gmail.com> On Wed, Sep 30, 2009 at 9:36 PM, Ket K Majmudar wrote: > Hi everyone, --- Hello and welcome to the list. > If I can help anyway with hlisting development please let me know. --- the best way to help is simply start using it. With any microformat, we can discuss all day what should/shouldn't be added/changed, but until people are marking-up their HTML we won't find those pain points. Real-world experience and expertise with hListing would be great. Please add any and all example URLs you find on the wiki. That will really help move things forward. -brian -- brian suda http://suda.co.uk From metafeather at gmail.com Thu Oct 29 06:35:04 2009 From: metafeather at gmail.com (Liam Clancy) Date: Thu Oct 29 06:35:12 2009 Subject: [uf-new] New proposal - replace custom web analytics markup with microformat(s) Message-ID: <5FD9C7BC-63A0-4D43-81BE-642C5331D557@gmail.com> Hello ?F community, I have been working on a particular problem and believe that the creation or adoption of microformats would not only solve it, but be of benefit to a great many web developers and help push the adoption of microformats within enterprise companies. The generic use case I have is quite simple: 1. Large company buys an expensive Web Analytics type product from a vendor such as WebTrends, Omniture, Coremetrics or other (there are lots of smaller vendors in the EU) 2. As part of the implementation the large company must add good quality metadata to *every web page* on their site(s) to provide the purchased product with enough information to exercise its many features. Currently the common means of adding metadata to the web pages is through proprietary and custom JavaScript mark-up that is time consuming, error prone, opaque and expensive to manage for the large company in question, e.g. WT.pn = 'Homepage'; // WebTrends markup s.pageName = 'Homepage'; // Omniture markup pageTracker._trackPageview('/Homepage'); // Google Analytics Until recently there was little incentive for the vendor companies to improve on this, as the custom mark-up and its implementation provided a barrier to product switching and generated revenue through implementation consulting. I've been lurking here for quite a while, and 18 months ago I was able to start working full-time on better solutions for these product implementations and soon came to the conclusion that microformats were the way to go. I have a post outlining this thinking in more depth here: We setup to promote this and other ideas to improve quality of data collected on web sites, and also to put the declaration of this data back into the hands of the content creators, avoid side-channels and establish new best practices in a similar way as current SEO and Accessibility techniques evolved. The idea here is to encourage the publishing of semantic content that is measurable by design. One of our primary projects at jsHub.org is to establish a vendor neutral format for the data mark-up (and the Open Source tools to support it) and we have received very favourable feedback from all the vendors we have met with, including the biggest vendors (WebTrends, comScore, Coremetrics, Google) on the use of microformats. As part of this consultation we published a draft microformat we called 'hPage' (not to be confused with an earlier proposal to this list by the same name): This proposal was developed using the published microformats process as much as possible, and it has always been our intention to share it with the microformats community for review and refinement and develop a final specification that can be adopted. I apologise in advance for the initial unilateral development and labelling of this draft as a 'microformat', our circumstances have been very much the same as that of hNews, and I would like to ask for any and all feedback on the current proposal, and to start transferring our research and other content to the official microformats wiki for further development. There are a number of initial questions that I believe I can anticipate: 1. We understand that this may never be a 'proper' microformat - our usecase is rather generic, but the implementation of a solution has specific constraints to be commercially viable. I and the other members of the jsHub.org team have a lot of experience in this due to previous work for the vendors (which we will be sharing), however I would like to point out the 'Design principles' section of the spec where we attempt to address some of the conflicts in approach and how we try to mitigate them: 2. Its called 'hPage' to create an association with the Web Analytics vendors measurement of a 'Page View', which is the primary use of the proprietary mark-up it is intended to replace. May vendors have an enormous number of potential variables that can be set for use across a large product range and we don't believe that one microformat can replace all of these, only a common subset. We expect that there will be additional proposals needed, but we are starting with the most obvious current practice and trying to address the next required development in the Web Analytics industry - that of tracking multiple pages of content in one document (AJAX updates). This is covered in the section: 3. As with hNews we suspect that there are potential benefits to integrating with or extending hAtom and other microformats and would like to first start with seeing how we can revisit our initial in-the- wild examples using your collective experience. Our objective is to establish 'a' microformat, not necessarily 'our' microformat for use by clients and vendors alike. We are working full-time on this and other related projects at jsHub.org and I appreciate your time and am very much looking forward to hearing your opinions. [If anyone is London, UK based I am generally out and about if you would like to meet up] Liam Clancy -- http://jshub.org/ http://metafeather.net/ From scott at makedatamakesense.com Thu Oct 29 07:54:20 2009 From: scott at makedatamakesense.com (Scott Reynen) Date: Thu Oct 29 07:54:31 2009 Subject: [uf-new] New proposal - replace custom web analytics markup with microformat(s) In-Reply-To: <5FD9C7BC-63A0-4D43-81BE-642C5331D557@gmail.com> References: <5FD9C7BC-63A0-4D43-81BE-642C5331D557@gmail.com> Message-ID: <31C4B374-7EF3-43B8-9DE5-370E8F35F55C@makedatamakesense.com> On Oct 29, 2009, at 8:35 AM, Liam Clancy wrote: > As part of this consultation we published a draft microformat we > called 'hPage' (not to be confused with an earlier proposal to this > list by the same name): > > > We are working full-time on this and other related projects at > jsHub.org and I appreciate your time and am very much looking > forward to hearing your opinions. I see several problems with hPage. Unfortunately, it looks like you've gone too far to correct these problems without a complete overhaul. > This proposal was developed using the published microformats process > as much as possible Can you maybe clarify how you accomplished each step of the process? For example, where are the real world examples? You've published some microformat principles, but you seem to have violated nearly all of them: - Solve a specific problem hPage explicitly models two different types of data: HTML pages and dynamic content fragments. The former is already modeled by HTML itself, and the latter is often not published within HTML documents. - Design for humans first, machines second. The data you're modeling is primarily for machines. - Reuse existing building blocks, such as semantic HTML and existing microformats You've circumvented , among other existing building blocks. - Modularity / embeddability You've declared definitions for incredibly generic terms like "name" and "type" as specific to the context(s) of hPage, which would make them unusable by any other microformat. These are large enough problems that I'd suggest revisiting the beginning of the microformats process and walking through it all again. Let's talk about just the first step: what exactly is the problem you're trying to solve? I know you've stated this already, but it'll be hard for anyone to focus on the problem as long as you're stating it in the context of a specific solution. -- Scott Reynen MakeDataMakeSense.com From metafeather at gmail.com Thu Oct 29 10:16:49 2009 From: metafeather at gmail.com (Liam Clancy) Date: Thu Oct 29 10:17:01 2009 Subject: [uf-new] New proposal - replace custom web analytics markup with microformat(s) In-Reply-To: <31C4B374-7EF3-43B8-9DE5-370E8F35F55C@makedatamakesense.com> References: <5FD9C7BC-63A0-4D43-81BE-642C5331D557@gmail.com> <31C4B374-7EF3-43B8-9DE5-370E8F35F55C@makedatamakesense.com> Message-ID: <A7D98FFA-BD35-46BD-A6F0-E16F64A48353@gmail.com> Hi Scott, thanks for your response, I've added my comments inline below. On 29 Oct 2009, at 15:54, Scott Reynen wrote: > I see several problems with hPage. Unfortunately, it looks like > you've gone too far to correct these problems without a complete > overhaul. That's no problem for me, the draft we put together was for the web analytics vendors discussion and illustration of an alternative mark- up syntax, and it has been very persuasive, however we realised the more we worked on it that there was no way we could complete the spec to an acceptable level without proper input from the community. I really wish we have been able to avoid calling this a 'microformat' but it was needed to explain the concepts behind microformats in general before introducing a proposal. >> This proposal was developed using the published microformats >> process as much as possible > > Can you maybe clarify how you accomplished each step of the > process? For example, where are the real world examples? I found the process published on the microformats wiki and adopted it internally to establish the need for HTML based mark-up solution, we have examples and analysis to share and I will be putting it on the wiki asap. In the meantime the work we have done has been written up here as an introduction to the vendors which may help: <https://jshub.org/projects/markup/introduction.html> > You've published some microformat principles, but you seem to have > violated nearly all of them: > > - Solve a specific problem > hPage explicitly models two different types of data: HTML pages and > dynamic content fragments. The former is already modeled by HTML > itself, and the latter is often not published within HTML documents. > - Design for humans first, machines second. > The data you're modeling is primarily for machines. > - Reuse existing building blocks, such as semantic HTML and existing > microformats > You've circumvented <title>, among other existing building blocks. > - Modularity / embeddability > You've declared definitions for incredibly generic terms like > "name" and "type" as specific to the context(s) of hPage, which > would make them unusable by any other microformat. > > These are large enough problems that I'd suggest revisiting the > beginning of the microformats process and walking through it all > again. Let's talk about just the first step: what exactly is the > problem you're trying to solve? I know you've stated this already, > but it'll be hard for anyone to focus on the problem as long as > you're stating it in the context of a specific solution. That's good feedback and I'll do my best with the Problem Statement to address these, although as I have already admitted it may be that we won't be able to settle on a 'proper' microformat, however the process will be enormously beneficial in seeing how web analytics products can make use of microformat data published by content creators in a standardised way. Liam Clancy -- http://jshub.org/ http://metafeather.net/ > _______________________________________________ > microformats-new mailing list > microformats-new@microformats.org > http://microformats.org/mailman/listinfo/microformats-new