to-do: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(moved add microformats to advocacy)
(added some process to-dos)
Line 154: Line 154:
** avoid using two names to mean the same thing
** avoid using two names to mean the same thing
** seek to keep the microformats vocabulary minimal, memorable, and usable.
** seek to keep the microformats vocabulary minimal, memorable, and usable.
* update and add details/simplifications to [[process]] given the past several months of experience. in particular:
** clarify requirement (MUST rather than SHOULD) of *-examples, *-formats, before any *-brainstorming. 
** Add details of encouragement to experiment with simple semantic class names from *-brainstorming proposals to gain real world experience with real world content.
** note SHOULD prerequisite of use of all relevant microformats on real world web pages, along with documenting such use in respective "Examples in the Wild" sections, before proposing any new microformats.


Create the following pages and document/fill them with content from other pages, email lists, and [[presentations]].
Create the following pages and document/fill them with content from other pages, email lists, and [[presentations]].

Revision as of 22:39, 21 October 2006

To Do

This page is for posting microformats related shared to do items. If you want to use this page for your microformats related to-do items, create a section with your name on it. The reason we are keeping these all on the same page is to make it easier to tell when people are working on similar things, and to make it more obvious when people help out with other people's tasks. In theory this probably won't scale, but let's first see how it does in practice. :) - Tantek

Lazyweb

Just some nice things, feel free to do any of these.

for all microformats

  • quick and easy "how to" pages for each microformat. use is a good overall start.
  • brief summary statements for each microformat that explain why it matters, what does it accomplish for the publisher.
  • write up mailing-list questions and answers in the appropriate faq pages.
  • validators. See the hReview section below as there has been a request for an hReview validator in particular. See Norman Walsh's blog post "Validating microformats" for some valuable analysis and validation pseudo-code (prose description), which are useful steps towards building microformat validators.
  • Create a microformat (based on hCalendar?) for marking up the opening hours of stores and restaurants. Some people seem to believe hCalenders repeating event support isn't good enough for this and needs to be amended first.

hReview

  • hReview support in Ecto (hey Adriaan!), requested by Andy Smith
  • an hReview validator.
  • a semantic, clean css star rating picker (e.g. a UI widget to rate from 1-5 stars)

hCard

hCalendar/hCard/hReview editor

  • onblur in the URL field (e.g. on hCalendar), goes out and tries to retrieve an object of same time (e.g. an hCalendar vevent) from that URL and uses it to autofill the form, same thing if the creator is loaded with that URL prefilled (e.g. due to a ?url=http://example.com/ in the URL that loads the creator).

WordPress patches for microformats

  • submit patches for WordPress code/templates for microformats improvement
  • Wordpress plugin for microformats, specifically hReview and hCalendar

Yahoo Open Source Library Patches

Several of these could very much be improved with a little microformats markup. Do we just make patches and submit them? Contact Nate Koechley at Yahoo (see Tantek for contact info) to follow-up.

Drupal patches for microformats

  • submit patches for Drupal code/templates for microformats improvement
  • Drupal modules for microformats, specifically hReview and hCalendar

Adding Microformats to Existing Pages

Geotagging on Wikipedia

Somebody familiar with the "geo" microformat might want to add details, and a link to the relevant page on this Wiki, to the Wikipedia page on Geotagging.

Tantek

I'm keeping a few microformats related to-do items here both for my own convenience, and for folks looking to help out with small tasks. If so, just create a new section with your name, and and maybe copy the item there, and put your name next to the item in my list. We'll figure this out as we go along. Thanks, Tantek.

*-authoring microformats wiki pages

  • Add some tips to hcard-authoring
    • a tutorial on creating an hCard for your site
    • specific instructions for common blogging platforms
    • instructions for more properties (match at least the set that is in the hCard creator)
  • Create hreview-authoring - a tutorial on how to blog reviews so that they'll be aggregated.

for all microformat specs

update specification section organization

In particular, the introduction/boilerplate/headers. hResume has an experimental abbreviated intro/headers section, and links to more details further below, based on some ideas that Ryan King and I had for improving the readability of the microformats specifications. hReview has some similar improvements, but different. We need to:

  1. Figure out if the new intro/headers structure in hResume and/or hReview is an improvement, and if it could be better. Perhaps figure out the requirements for an intro/header section
    • Shorter tends to be better
    • Must be comprehensive enough to "print and read"
    • Must detail authorship/editorship
    • Must detail copyright/patent statements
  2. Write up a template - make it self-documenting per the requirements
  3. Update existing specifications with the new intro/headers structure.
    1. hCard
    2. hCalendar
    3. hReview

reorganizing Implementations sections

  • sort implementations by authoring/creating/publishing, browsing/viewing, converting/importing, indexing/searching.

Hmmm... I like: Authoring, Browsing, Converting, Indexing, Libraries (for developers), and Potential (for open source projects we want to add support to). Anybody have alternative suggestions for this vocabulary? I don't have a particularly strong preference so I'm going to go with these four until I find examples that don't fit, or someone suggests something better.

See: hCalendar Implementations for a first attempt at this. Assuming folks like that, we can go ahead with categorizing the implementations sections of other microformats specifications.

reorg Examples in the Wild sections

  • include more *key* details per example, e.g. precise or estimates of counts for services
  • collate/sort examples in the wild by
    • hosting services - where users/people actively contribute to the growth (e.g. Flickr profile hCards)
    • publishing services - where lots of data is published from some datasource/database (e.g. Yahoo! Local)
    • companies/groups/organizations member pages (and their own) - pages for a group's site where they list members or employees (e.g. Technorati staff page)
    • individiual companies/organizations contact info pages
    • individual people's contact info pages
  • of course at some point this won't scale, but that will be a very good problem to have, and by then I'm sure we'll have services to point to that provide queries and search results for all this data.

summary Examples in the Wild page

  • need to create a summary / overall examples-in-the-wild page
    • parallel the summary/overall implementations page.
    • use newly reoganized content from the above "reoganizing Examples in the Wild" task

iterate on current microformats

hReview

  • Write hReview 0.3 XMDP profile, and reconcile with hcalendar-profile and hcard-profile. Makes sense to have a combined profile of all three for hReview, since hReview normatively depends on hCard and hCalendar.

hCalendar

hCard

  • hcard-examples
  • Examples in the wild - need to create a new page for them!
    • Group examples in the wild according to:
      • Individuals - one card per person, perhaps sort alphabetically
      • Organizations - one card per organization, alphabetical again
      • Institutions (which list more than one person), with a count estimating the # of hCards, e.g. 40k for Avon. Also indicate complexity of information supplied, eg. just name+number vs. complete details
      • Online Profiles (which host profiles for more than one person) with a count estimating the # of hCards, e.g. 3.5m for Flickr.com
      • Online Venues (which provide listings for businesses or organizations) with a count estimating the # of venues, e.g. ~10k for Upcoming.org
      • Speakers Listings (lists of speakers on conference sites) with a count estimating the # of speakers, e.g. ~300 for SXSW 2006.
    • help dglazkov markup: http://glazkov.com/blog/archive/2003/12/17/147.aspx

introduction / community

  • microformats-discuss
    • introductory email sent to new subscribers needs to direct people to process and how-to-play
  • Need to add more to the naming-principles, to cover in particular:
    • avoid using the same name to mean two things
    • avoid using two names to mean the same thing
    • seek to keep the microformats vocabulary minimal, memorable, and usable.
  • update and add details/simplifications to process given the past several months of experience. in particular:
    • clarify requirement (MUST rather than SHOULD) of *-examples, *-formats, before any *-brainstorming.
    • Add details of encouragement to experiment with simple semantic class names from *-brainstorming proposals to gain real world experience with real world content.
    • note SHOULD prerequisite of use of all relevant microformats on real world web pages, along with documenting such use in respective "Examples in the Wild" sections, before proposing any new microformats.

Create the following pages and document/fill them with content from other pages, email lists, and presentations.

profiles

  • update XMDP with new required features:
    • ability for one profile to include/import another (rel="import" ?)
    • ability to reference an XMDP via rel="profile" (similar to XHTML2 rel value by same name)
    • ability/suggestion to reference an XMDP using <a href> in addition to <link>

microformat parsing documentation

create microformats wiki pages for

  • *-authoring for all microformats
  • *-parsing for all microformats

improve usability and automation on the site

  • figure out how to get wordpress to autopost blog posts to the microformats-announce list
    • ideally use the from address of the author of the blog post
    • maybe photomatt knows how to do this.

help with microformat implementations

  • wordpress improvements
    • WP admin for new profiles
      • should simply read blog URL
      • look for hcards and parse them
  • XFN Creator localizations
  • Conference Schedule Creator
    • We need to ASAP build a simple conference schedule creator (and editor?) that builds upon the hCalendar creator. We should make it *trivial* for conference organizers to build/edit/publish an hCalendar schedule for their conference, including auto-generated "Subscribe..." link which produces the proper "webcal:..." link with X2V. Note: see the "axis" and "header" attributes in HTML4, specifically in the section on Tables.

help with microformat examples in the wild

Go over all "common" pages (both logged out and logged in states) of the following sites which have some microformats already, and verify each page is as microformatted as it can be with high fidelity hCalendar and hCard etc. Document full support of each implementation's microformats on the implementations page (perhaps create a separate page for each implementation, e.g. flickr, upcoming, eventful etc.) Document any exceptions as needed. In no particular order:

  • Flickr.com (3.5m hCards)
  • Upcoming.org (100k hCalendar events, 100k hCard venues)
    • home page
  • Eventful.com (100k hCalendar events, 100k hCard venues)
  • Yahoo! Tech (300k products with hReviews)
  • JudysBook.com (???k hReviews)
  • ... lots more, get from "Implementations" and "Examples in the Wild" sections of specs.

help with new microformat requests

Ryan

hCalendar/hCard/hReview creator improvements

  • get all creators working in IE/Win, IE/Mac, Safari/OSX.3

other

rel-payment

  • update rel-payment to reference the IANA registry [1]

hcalendar

  • make sure we explicitly disallow 'vjournal'

Dimitri Glazkov

  • Figure out REST/Microformats thing
  • Work on result set idea
  • Implement h-creators using Web Forms 2.0

Chris Messina

  • Work on a microformat for play-lists (is it just a XOXO ordererd list of play-items?)
  • Work on a microformat for play-item (take a look at media-info-examples)
  • Work on microformats tutorial for designers

Wishlist

  • Microformat for "buyable items" (see listing-examples and related documents)
  • Location MF -- right click "map this" (see geo and adr)
  • Better hCard support in the browser -- right click "IM this person...", "Add to contacts" (see Flocktails)
  • Better hCal support -- support many views of same hCal data on one page using XSLT
  • We need something that a designer/web programmer can come to and leave w/ 2 examples of each microformat that they can apply right away... a "microformats styleguide for designers", if you will.
  • invoicing microformat
  • better microformats wiki theme

Robert Bachmann

hCard Creator

hAtom2Atom

Some ideas for features which could be implemented :

(If you are interested in one of this features, add "+1 Your Name")

  • Join all hfeed's inside a page (or a fragment thereof) into one feed using atom:source semantics.
  • Extraction of atom:content, atom:summary and atom:title:
    • atom:content and atom:summary as HTML
    • atom:content and atom:summary as plain-text
    • atom:title as XHTML
    • atom:title as HTML
  • Support for other XSLT engines:
    • MSXML
    • .Net System.Xml
    • Sablotron
    • Oracle XSLT
    • XT
  • Support for other output formats: (hAtom2xyz.xsl)
    • RSS 2.0 (meanwhile use hAtom2Atom.xsl and atom2rss.xsl)
    • RSS 1.0 (meanwhile use hAtom2Atom.xsl and atom2rss.xslt)
    • AtomOWL (meanwhile use hAtom2Atom.xsl and atom2rdfxml.xsl)
    • JSON?
      • Does it make sense to consider a canonical representation of microformats (either case by case, or in general) in JSON? E.g. so that a JSON API that returned contact information could return an hCard-equivalent chunk of JSON. - Tantek.

(singpolyma 01:02, 9 May 2006 (PDT) -- Not XSLT, but see http://xoxotools.ning.com/hatom2rss.php for hatom to RSS2.0 conversion)

Brian Suda

Citation Microformats

  • Add all my notes to the Wiki
  • Start the process of naming the properties using existing names

X2V

Make changes and update site (almost stable) Get ATTENDEE and other strange attributes working

WARNINGS and ERROR

work on the warnings and error output for the pre-check in X2V

FAQ

  • clean-up the MF FAQs
  • clean-up FAQs from the major microformats
  • pull Questions from the mailing list and document them to the FAQs and example

Mark Rickerby

Current Tasks

Wishlist

  • hmmm

Ernest Prabhakar

Wiki-Thon Proposal

Set aside several hours (probably a Friday night US PST) for focused work on the Wiki, including both physical (e.g., a room in the Bay Area) and virtual (IRC/iChat) participants.

Goals

  1. Improve understanding of what needs to be done for Wiki
    • IMHO - this should be done here, in to-do incrementally. -Tantek
  2. Tackle larger projects (~1-2 hours) than people usually have time for
    • I'd like to see these projects *documented* first on to-do before we spend 1-2 hours of a bunch of folk's collective time to go through them. -Tantek
  3. Motivate community to have fun with otherwise tedious "housecleaning" chores

Agenda (Wishlist)

In parallel:

  • Coalesce/prioritize existing To-Do items (above)
  • Review/revise desired pathways for:
    • New users learning about microformats
      • e.g., intro, about, explore, tutorials, etc.
      • cf. Rails front page
        • Get Excited (Why, background, motivation)
        • Get Started (What, downloads, getting started)
        • Get Better (How, tutorials, )
        • Get Involved (Who)
    • Microformat lifecycle
  • Review existing specs for completeness and consistency
  • Identify areas of 'bitrot' or 'hole-filling'
  • Do it!

Dan Connolly

DanC hopes to sync up on these tasks in irc roughly weekly, during Wednesday afternoon (Chicago time) "office hours". See also my esw todo list and someday pile.

  • from WWW2006
    • follow up on GRDDL as escape valve for microformats proposals, much like CSS was an escape valve for HTML tag proposals.

DanC 15:39, 31 May 2006 (PDT)

Chris Casciano

ChrisCasciano

  • get around to updating hatom-issues with some multi feed rules/exceptions.
  • Update textpattern plugin with simple hreview support and get a new release out
  • Redesign placenamehere.com and include hatom
  • Follow up with technorati folks on pingerati reviews getting lost (note: this will require publishing more reviews and theen watching them through the update process)
  • prototype a NetNewsWire microformat extractor (CSS+AppleScript)

Drew McLellan

DrewMcLellan

  • Build an hReview profile for hKit and test
  • Update the Dreamweaver extensions to mirror recent changes in the online builders
  • Publish an hCard to JSON service on tools.microformatic.com using hKit.
  • Further develop blog comment form hCard collection ideas.
  • Version of hReview creator using hKit to import business details from an hCard

Christophe Ducamp (french localization)

Christophe Ducamp

  • translate exploraty discussions (red links on to-do-fr
    • find experts for peer-reviewing
  • localize an french version of the official website
    • find out the original versions of pictures (in SVG ?)
    • find out french skills resources to adapt the original webdesign

Frances Berriman

Frances Berriman

  • Work on styles for zen-garden project.
  • Style HTML cheatsheet to match Brian Suda's PDF.
  • Write simplified help/implementation documents (how tos) for all finalised Microformats.
  • Re-organise general FAQ and simplify
    • (Feel free to add suggested tasks to my list below:)
      • Help converge on organization efforts ~bewest :-)

Ben West (bewest)

bewest

Creators

  • Start hatom creator. http://dichtomize.com/uf/hatom/creator.html
  • Code Reuse. These creators are downright handy, and I’ve reimplemented the vcard one on my own site. Instead, let’s make these widgetized. Let’s decide on a more or less canonical html structure and create some javascript that will create the desired microformat. Something as easy to use as new Microformat.hCard($('mycontainer')); would be awesome. Right now, if someone makes an improvement to the hCard creator, the other creators don’t get the benefit. Spec this out!
  • About Section. Is there an official creator page? If so, let’s point to that. The about paragraph is getting longer and longer with phrases like “which is based on…” repeated over and over.
  • Default all dates to “right now”. Provide an easy to use calendar type widget to change dates.
  • hAtom creator: Add multiple. It’d be nice to add an arbitrary number of entries.
  • hAtom creator: Optional feed enclosure. Check box to wrap the entry/entries in an hfeed.
  • Edit URI: Allow someone to enter a URI and edit whatever microformat is found on the page.
  • Optionals. If the format requires, say, a vcard, the creator can defer to an external URI or can trust the user to fill it in later.
  • Common stylesheet. I suppose this goes with the reuseable code idea… we have many great coders, we should be reusing eachothers’ work.
  • Use Amazon's ECS to pull in information about products when there is an ASIN in the item URI.

Information Architecture

Help Welcomed! Please leave your name Add complaints to wiki-feedback! Helping to make the wiki easier to use. I'd like to see the main page more towards a format like http://simile.mit.edu/solvent/ with the big questions right out front:

  • What Is This?
  • What can I do here?
  • Is there a demo?
  • Where can I learn more?

I'd like to change the front page to this kind of design.

Support Pages

There are several categories of things in the wiki. Can we enumerate them?

  • About the Community
    • Where to find information.
    • Who are the stake holders?
    • FAQs
  • Web/Architectural Philosophy
    • Community Principles
    • Why are we doing this?
    • XML and Namespaces
    • Semantic XHTML
    • Common Misconceptions
    • Concession and Disposition of Criticism
    • FAQs
  • Specs
    • Examples
    • Discussion
    • Exploration
    • Use Cases
    • Implementations
    • The spec itself.

Can others agree and or refine this list? Should I take it to the -discuss list? How do we create consensus on how the wiki should be organized in order to make it more usable? And how can we turn that consensus into actionable changes?

Considering that the wiki page named with the microformat (i.e. /wiki/hcard) is the one that people will mostly likely look to first for learning about a particular format, I'd think it'd make more sense and create a more welcoming feel to convert these pages to an intro page introducing the format for the beginner and linking to resources like tutorials and creators. Spec pages would then be relocated to wiki/*-spec -- Cgriego 13:25, 16 Oct 2006 (PDT)

Mike Schinkel's Comments

My suggestion on the list was for us to use a convention that the entry page (i.e. http://microformats.org/wiki/hcard) would be an index into a list of (psuedo) standardized sub pages so that it would be very people to find what is important to them. For example, is a list of potential sub pages:

  • Microformat
    • Specification
    • Tutorial
    • Examples
    • Use cases
    • Reference
    • Discussion
    • Brainstorming (might be combined w/Discussion)
    • Implementations
    • Related Pages
    • Further Reading
    • All (Uses Mediawiki's "includes" to create a page including all sub pages; very useful for printing & reading offline)

These pages would be located respectively at

Please note I am suggesting an architecture not a specific list of sub pages. The list of sub pages should be defined by both reviewing existing information during site reorganization, and then via discussion on the list in an attempt to discover and extract which sub pages are needed for most/all microformats.

NOTE: This differs from above in that the spec if not viewed as a top level structure but instead the microformat itself and the spec would be under the microformat. In this context "microformat" is a more abstract concept and "spec" is a more concrete thing. Another way to think about it would be that each microformat would have it's own mini home page and then things like "spec" are the pages listed on its home page.

New Person 1

etc.