[uf-discuss] hCalendar spec- no specification included!

Mike Schinkel mikeschinkel at gmail.com
Wed Oct 18 16:04:01 PDT 2006


>> Actually this is already done.  There are
generators/creators/___-o-matics or whatever the current term is for
hReview, hAtom, hCard, and hCalendar, AFAIK.  I believe they are all linked
to from their respective wiki page.

The point is there isn't necessarily one for a new spec. Until someone
builds one.  So my point was I wouldn't see a generators/creators as the
entry point for a microformat, that's all.

>> I think we all agree that some parts of the wiki have room for a lot of
improvement.

I was addressing Andy's point, not the group in general.

>> Yahoo is much more used than Google :-).  However, that's irrelevant.

But you use Gmail.  Why not Yahoo mail?  ;-)

>> I believe the landing page for each format should answer the big
questions common to all readers when they arrive at a landing page, and then
quickly and thoughtlessly funnel readers into the sections most relevant to
their interests.  

My point was simply to be careful not to overwhelm the user with text on a
intro page as it has been proven people scan  web pages instead of reading
them[1]. Less will be more here. Justin presents this[2] as an example, but
I find it to be far too much information on an intro page. This is a general
principle, of course, not true in all cases but likely true for an intro
page.  Os I would highly suggest that whoever is involved in creating intro
pages first read this[1]; it was eye opening when I first read it.

>> This includes information how authoring, principles of creation, what the
format is suited for, and of course the spec itself.  I don't mean that
these resources are on the landing page, but rather that the landing page
should act as a funnel, quickly allowing the reader to sort out which
direction has the scent of information they are looking for.

I completely agree.

>> Let's be careful to not exclusively talk about the specs.  The wiki
contains many kinds of information. While the specs are arguably the most
important kind, they aren't the only kind.  There is a lot of supporting
material, including web authoring tips, faqs, principles, community
information, discussions of goals...
>> I want to make sure we can identify what's on the wiki in terms of larger
categories, AND organize the specs.  The two categorization efforts should
inform each other.

Again I agree. I think specs are *the most important thing* to one class of
people, i.e. those specifying the spec. As such it's no surprise that the
spec gets primary focus, at least initially. But it needs to be balanced
because there are many classes of people and for each of them there is
potentially a different "most important thing."  So it needs to all be
easily accessible and findable understanding how users read web pages[1]. 

And sorry if I'm overstating that which everyone may already be agreeing on.
:)

-Mike
[1] http://www.useit.com/alertbox/9710a.html
[2] http://www.w3.org/WAI/intro/wcag 







-----Original Message-----
From: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] On Behalf Of Benjamin
West
Sent: Wednesday, October 18, 2006 5:06 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

On 10/18/06, Mike Schinkel <mikeschinkel at gmail.com> wrote:
> A form would be nice, but it takes time to develop and we can't expect 
> they will be developed before people are interested.

Actually this is already done.  There are generators/creators/___-o-matics
or whatever the current term is for hReview, hAtom, hCard, and hCalendar,
AFAIK.  I believe they are all linked to from their respective wiki page.


>OTOH, most people can't
> read a spec and make heads nor tails of it (I know that I struggle 
>with W3C  specs), so there is "the spec" and then there is the 
>"tutorial" (or
> similar.)  All can be clearly linked from the mini-home page.
>
> This is just like Creative Commons where they have the human readable 
> license and then you can see the lawyese if you really want. I've 
> never even looked at the lawyered one, have you?  I don't need to; the 
> simple version works much better for me and is all I need. Something 
> that tells the average Joe how to author in simple language with good 
> examples is what will be most beneficial for most people.

I think we all agree that some parts of the wiki have room for a lot of
improvement.


> >> Reasonable, but it needs some content, so as not to appear dry and
> unwelcoming.
>
> Not to be contrary, but see "How Users Read on the Web[1]."  Content 
> for content sake is less than useful.  Google's home page is dry but 
> it's used by more people than any other (or if not, I don't know what 
> is) because it meets people's needs better than the alternative (or 
> they would switch.)

Yahoo is much more used than Google :-).  However, that's irrelevant.
I believe the landing page for each format should answer the big questions
common to all readers when they arrive at a landing page, and then quickly
and thoughtlessly funnel readers into the sections most relevant to their
interests.  This includes information how authoring, principles of creation,
what the format is suited for, and of course the spec itself.  I don't mean
that these resources are on the landing page, but rather that the landing
page should act as a funnel, quickly allowing the reader to sort out which
direction has the scent of information they are looking for.

Let's be careful to not exclusively talk about the specs.  The wiki contains
many kinds of information. While the specs are arguably the most important
kind, they aren't the only kind.  There is a lot of supporting material,
including web authoring tips, faqs, principles, community information,
discussions of goals...

I want to make sure we can identify what's on the wiki in terms of larger
categories, AND organize the specs.  The two categorization efforts should
inform each other.

Now that we've got a few suggestions on how the "spec space" should be
organized, can we work on classifying the other kinds of materials on the
wiki?

Ben
_______________________________________________
microformats-discuss mailing list
microformats-discuss at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss



More information about the microformats-discuss mailing list