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

2006-10-16 Thread Tantek Çelik
On 10/16/06 10:38 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> 
> I've just been introducing a colleague to the concept of hCalendar; and
> referred her to:
> 
>   http://microformats.org/wiki/hCalendar
> 
> She was baffled; not lest because, though the page had a treatise on
> "Semantic XHTML Design Principles", it didn't list the hCalendar fields,
> let alone say which are mandatory and which are optional!
> 
> I have started to rewrite the page, but welcome contributions.

Andy, it is actually a bit inappropriate to jump-in and rewrite a spec that
is that well established without at least discussing how to rewrite it
first, or emailing the editor at a minimum.

There has already been work towards making the specifications more
readable/approachable etc. and I've documented this task on the to-do page
here.

http://microformats.org/wiki/to-do#update_specification_section_organization

I'm going to revert the reorganizational changes you made to both hCard and
hCalendar for now, and would ask that you please refrain from doing so
single-handedly.

Please raise suggestions here on the list first and let's discuss them.  For
established specifications in particular (and perhaps any with an "editor"),
we really should respect that role until/unless it actually proves to be a
hindrance (which it hasn't so far).

Thanks much for your understanding,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Justin Thorp
I think the pages the way they are presented now are a bit hard to process and 
understand.

I remember for me it took some time to initally dig through the specification 
to find what I was actually looking for.  I just wanted to figure out how to 
write an hCard.

Andy, I look forward to seeing the fruits of your labor.

Cheers,
Justin




**
Justin Thorp
Contractor - Library of Congress
e - [EMAIL PROTECTED]
p - 202/707-9541

>>> [EMAIL PROTECTED] 10/16/06 1:38 PM >>>

I've just been introducing a colleague to the concept of hCalendar; and
referred her to:

http://microformats.org/wiki/hCalendar 

She was baffled; not lest because, though the page had a treatise on
"Semantic XHTML Design Principles", it didn't list the hCalendar fields,
let alone say which are mandatory and which are optional!

I have started to rewrite the page, but welcome contributions.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org 
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Tantek Çelik
On 10/16/06 10:49 AM, "Justin Thorp" <[EMAIL PROTECTED]> wrote:

> I think the pages the way they are presented now are a bit hard to process and
> understand.

Justin, your feedback on this is greatly valued.  If you can be specific
about *which* pages, and what about them are hard to understand, that would
be very helpful.


> I remember for me it took some time to initally dig through the specification
> to find what I was actually looking for.  I just wanted to figure out how to
> write an hCard.

The way to write a hCard is documented in the hCard-authoring page:

 http://microformats.org/wiki/hcard-authoring

which is linked to right there at the top of the hCard specification:

 http://microformats.org/wiki/hcard

"
Want to get started with writing an hCard? Use the hCard creator
(http://microformats.org/code/hcard/creator) to write up some contact
information and publish it, or follow the hCard authoring tips
(http://microformats.org/wiki/hcard-authoring) to add hCard markup to your
current contact page.
"


To be clear, the purpose of a specification is not a tutorial - that's for
other documents.

Thanks,

Tantek



___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>On 10/16/06 10:38 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
>
>>
>> I've just been introducing a colleague to the concept of hCalendar; and
>> referred her to:
>>
>>   http://microformats.org/wiki/hCalendar
>>
>> She was baffled; not lest because, though the page had a treatise on
>> "Semantic XHTML Design Principles", it didn't list the hCalendar fields,
>> let alone say which are mandatory and which are optional!
>>
>> I have started to rewrite the page, but welcome contributions.
>
>Andy, it is actually a bit inappropriate to jump-in and rewrite a spec
>that is that well established without at least discussing how to
>rewrite it first,

Really? I thought that was the whole point of a Wiki. Note also that I
"rewrite a spec", I reordered the preamble to it and attempted to
clarify it.

> or emailing the editor at a minimum.

And ether was me thinking that you'd disclaimed ownership of uFs.

>There has already been work towards making the specifications more
>readable/approachable etc.

It's well hidden.

>and I've documented this task on the to-do page here.
>
>http://microformats.org/wiki/to-do#update_specification_section_organiz
>ation

You did so *after* I made the changes referred to above.

>I'm going to revert the reorganizational changes you made to both hCard
>and hCalendar for now,

Suit yourself.

>and would ask that you please refrain from doing so single-handedly.

I haven't dome anything "single-handedly". You quote me asking for
contributions!

>Please raise suggestions here on the list first and let's discuss them.
>For established specifications in particular (and perhaps any with an
>"editor"), we really should respect that role

And where is that role defined?

>until/unless it actually proves to be a hindrance (which it hasn't so
>far).

It just has. HTH.

>Thanks much for your understanding,

Once again, your tone is objectionable.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Justin Thorp <[EMAIL PROTECTED]> writes

>I think the pages the way they are presented now are a bit hard to
>process and understand.

I think they're an unreadable, inaccessible and arrogant mess.

>Andy, I look forward to seeing the fruits of your labor.

You'll have to look at the history of the page which Tantek Celik has
just reverted, then.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Tantek Çelik
On 10/16/06 11:30 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

> In message <[EMAIL PROTECTED]>, Tantek Çelik
> <[EMAIL PROTECTED]> writes
> 
>> On 10/16/06 10:38 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
>> 
>>> 
>>> I've just been introducing a colleague to the concept of hCalendar; and
>>> referred her to:
>>> 
>>>   http://microformats.org/wiki/hCalendar
>>> 
>>> She was baffled; not lest because, though the page had a treatise on
>>> "Semantic XHTML Design Principles", it didn't list the hCalendar fields,
>>> let alone say which are mandatory and which are optional!
>>> 
>>> I have started to rewrite the page, but welcome contributions.
>> 
>> Andy, it is actually a bit inappropriate to jump-in and rewrite a spec
>> that is that well established without at least discussing how to
>> rewrite it first,
> 
> Really? I thought that was the whole point of a Wiki.

In general yes it is the point of a wiki.  But surely you can appreciate
that some pages are more "stable" than others and have such expectations
(implied or otherwise).  Wikipedia provides many good examples of such
pages.


>> or emailing the editor at a minimum.
> 
> And ether was me thinking that you'd disclaimed ownership of uFs.

I'm unclear what you mean by this.  This has nothing to do with ownership.


>> There has already been work towards making the specifications more
>> readable/approachable etc.
> 
> It's well hidden.

It is better to assume that someone has thought of something first, than to
assume you are the first to think of it.

Thus it is better to ask about making the specifications more
readable/approachable than to just do it.


>> and I've documented this task on the to-do page here.
>> 
>> http://microformats.org/wiki/to-do#update_specification_section_organiz
>> ation
> 
> You did so *after* I made the changes referred to above.

Right, your actions made it clear that I had neglected to do so.


>> and would ask that you please refrain from doing so single-handedly.
> 
> I haven't dome anything "single-handedly". You quote me asking for
> contributions!

And you have made excellent contributions.

But asking for contributions on new subjects is very different than inviting
mass edits of existing pages.

Imagine what would happen if everyone attempted to do so (or even just a
dozen people).  There would be a lot of thrash, and worse still, the pages
that are stable and reliable would become less so to the readers of those
pages.


>> Please raise suggestions here on the list first and let's discuss them.
>> For established specifications in particular (and perhaps any with an
>> "editor"), we really should respect that role
> 
> And where is that role defined?

It was right there at the top of the specification.  If you are looking for
a formal definition of "editor" then it is reasonable to both use a
dictionary reference, and to look at what other standards organizations
define the editor's role to be, e.g. W3C, IETF.  The W3C site contains lots
of such useful resources.


>> until/unless it actually proves to be a hindrance (which it hasn't so
>> far).
> 
> It just has. HTH.

Sorry about that.  Could you be more specific in what has been hindered?


>> Thanks much for your understanding,
> 
> Once again, your tone is objectionable.

Andy, as has been noted by others, discussions of tone in email are usually
not very productive.  My only suggestion is that you try to assume that we
are all trying to do the right thing and make positive progress and help
each other out.

Thanks again,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

> If you can be specific about *which* pages, and what about them are
>hard to understand, that would be very helpful.

Here's a hint: most people new to hCalendar (some of them, it will
apparently come as a surprise to you, not bloggers) are likely to want
to know from what components an hCalendar consists of, before they read
your name twice, view two links to your day-job, or see you bigging-up
your friends; you appear to believe that the opposite is the case.

Neither are they likely to want to re-read a tedious and barely-relevant
essay on XML, complete with misleading advice.





BTW, I'm now asking you for the *fifth* time, to answer my question
about "species" examples.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Andy Mabbett
<[EMAIL PROTECTED]> writes

> Note also that I

didn't

>"rewrite a spec", I reordered the preamble to it and attempted to
>clarify it.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Tantek Çelik
On 10/16/06 11:53 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

>> If you can be specific about *which* pages, and what about them are
>> hard to understand, that would be very helpful.
> 
> Here's a hint: most people new to hCalendar (some of them, it will
> apparently come as a surprise to you, not bloggers) are likely to want
> to know from what components an hCalendar consists of,

That is very reasonable, the right thing to do then is to add a section
similar to the section in hCard which serves that purpose, *without doing
any other changes*.


> before they read
> your name twice, view two links to your day-job, or see you bigging-up
> your friends; you appear to believe that the opposite is the case.

Andy, please reread:

http://microformats.org/wiki/to-do#update_specification_section_organization

for what my current thoughts are on section organization, rather than
implying/inferring from a single instance.

As far as the default order of editor, author, copyright etc., I *strongly*
recommend you read some W3C specs to get an understanding of what "typical"
web standards specifications look like.  As with many things, with
microformats we have re-used some of the organizational/sectional ordering
of what others' have done rather than invent our own.  Start with the W3C's
Technical Reports page and just read some of the documents there:

 http://w3.org/TR/

E.g. http://w3.org/TR/html401 or http://w3.org/TR/CSS21


> Neither are they likely to want to re-read a tedious and barely-relevant
> essay on XML, complete with misleading advice.

Please note that specifications are not tutorials, and attempting to make
them into tutorials is very bad for precision and interoperability.

If you have specific issues about the semantic XHTML section, please raise
them in a separate thread.


> BTW, I'm now asking you for the *fifth* time, to answer my question
> about "species" examples.

I for one have not had the time to read through your species examples in
order to answer your question.

Perhaps consider kindly asking the list what the community as a whole thinks
of your work on species, but I ask that you first wait for the discussion of
what new list to create for "new microformats" concludes.  In the meantime,
please add your opinion on the name of the list to the proposal:

 http://microformats.org/wiki/mailing-lists#new_list_proposal

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>>> and would ask that you please refrain from doing so single-handedly.
>>
>> I haven't dome anything "single-handedly". You quote me asking for
>> contributions!
>
>And you have made excellent contributions.
>
>But asking for contributions on new subjects is very different than inviting
>mass edits of existing pages.

You quote me asking for contributions to making a specific, existing
page workable.

>Imagine what would happen if everyone attempted to do so (or even just a
>dozen people).  There would be a lot of thrash, and worse still, the pages
>that are stable and reliable would become less so to the readers of those
>pages.

I'm not really interested in discussing your unfounded assertions.

>>> Please raise suggestions here on the list first and let's discuss them.
>>> For established specifications in particular (and perhaps any with an
>>> "editor"), we really should respect that role
>>
>> And where is that role defined?
>
>It was right there at the top of the specification.

No, it is not.

>  If you are looking for
>a formal definition of "editor"

No, I'm looking for a definition of that role, in the sense you use, in
the context of this Wiki, and which mandates that my actions were. as
you claim, "inappropriate".

>>> until/unless it actually proves to be a hindrance (which it hasn't so
>>> far).
>>
>> It just has. HTH.
>
>Sorry about that.  Could you be more specific in what has been hindered?

Progress.

>>> Thanks much for your understanding,
>>
>> Once again, your tone is objectionable.
>
>Andy, as has been noted by others, discussions of tone in email are usually
>not very productive.

Nonetheless, yours is objectionable.

>  My only suggestion is that you try to assume that we
>are all trying to do the right thing and make positive progress and help
>each other out.

I prefer to work on evidence, rather than naive assumptions.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Tantek Çelik
On 10/16/06 12:30 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:

>> Imagine what would happen if everyone attempted to do so (or even just a
>> dozen people).  There would be a lot of thrash, and worse still, the pages
>> that are stable and reliable would become less so to the readers of those
>> pages.
> 
> I'm not really interested in discussing your unfounded assertions.

Andy, the point is, that if everyone acted as you do, the wiki would be a
mess with thrashing back and forth based upon everyone's different opinions
of what makes usable/accessible content.

Please consider what would happen if everyone acted the way you do before
you do such actions.


 Thanks much for your understanding,
>>> 
>>> Once again, your tone is objectionable.
>> 
>> Andy, as has been noted by others, discussions of tone in email are usually
>> not very productive.
> 
> Nonetheless, yours is objectionable.

Your perception and assertion of an objectionable tone is likely flawed and
not true to the intended conveyed tone.  This is common in email, has been
noted by others on this list, and therefore not worth asserting, especially
repeatedly, as you have done so.


>>  My only suggestion is that you try to assume that we
>> are all trying to do the right thing and make positive progress and help
>> each other out.
> 
> I prefer to work on evidence, rather than naive assumptions.

The existence of the community and incredible growth/adoption that
microformats has seen in the year+ of existence of microformats.org is
sufficient evidence.

That being said, I find that community interactions work better when
everyone is assuming everyone else is also trying to do the right thing and
make positive progress and help each other out, and I think that most people
here would say the same thing.

If you have found otherwise, perhaps in other communities, then that's why I
suggested you at least consider for this community.

Thanks for your consideration,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>On 10/16/06 11:53 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
>
>>> If you can be specific about *which* pages, and what about them are
>>> hard to understand, that would be very helpful.
>>
>> Here's a hint: most people new to hCalendar (some of them, it will
>> apparently come as a surprise to you, not bloggers) are likely to want
>> to know from what components an hCalendar consists of,
>
>That is very reasonable,

Then why did you revert my change from "Bloggers can both embed hCards
directly in their web pages..." to "People can both embed hCards
directly in their web pages..."

And why did you remove the list of hCalendar properties which I'd
started?

>the right thing to do then is to add a section
>similar to the section in hCard which serves that purpose, *without doing
>any other changes*.

Who says that's the "right" thing to do?

>> before they read
>> your name twice, view two links to your day-job, or see you bigging-up
>> your friends; you appear to believe that the opposite is the case.
>
>Andy, please reread:
>
>http://microformats.org/wiki/to-do#update_specification_section_organization
>
>for what my current thoughts are on section organization,

I could hardly have read that, before I made the changes which you
reverted, since you hadn't posted it then.

Having since done so, it's little better than what's there now, and
shows no regard for the convenience of new users. I would have thought
that we want folks new to microformats to feel welcome.

>rather than implying/inferring

Please learn the difference; then say which you mean.

>from a single instance.

I have not done anything, based on a single instance.

>As far as the default order of editor, author, copyright etc., I *strongly*
>recommend you read some W3C specs to get an understanding of what "typical"
>web standards specifications look like.

I already know what they look like, but thank you for attempting to
patronise me anyway.

I note also that what you refer to, on the uF wiki, as a
"specification", is no such thing.

Then again, neither was the new section which I created on the hCalendar
page, which you have removed.

>> Neither are they likely to want to re-read a tedious and barely-relevant
>> essay on XML, complete with misleading advice.
>
>Please note that specifications are not tutorials, and attempting to make
>them into tutorials is very bad for precision and interoperability.

Please note that I have neither claimed nor implied that specifications
are tutorials, and attempting to imply that I have is vary bad.

>If you have specific issues about the semantic XHTML section, please raise
>them in a separate thread.

I can no longer be bothered. Congratulations.

>> BTW, I'm now asking you for the *fifth* time, to answer my question
>> about "species" examples.
>
>I for one have not had the time to read through your species examples in
>order to answer your question.

!

>Perhaps consider kindly asking the list what the community as a whole thinks
>of your work on species

Since you specifically made the criticism, and you specifically
requested further evidence, I feel entitled to specifically ask you
whether the evidence I have since supplied has satisfied your specific
concern.

I note that you once again fail to answer that simple question..

>, but I ask that you first wait for the discussion of
>what new list to create for "new microformats" concludes.

You seem to be inventing new hurdles.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Benjamin West

Quick Summary:
* Lots of interest in wiki improvement
* Work I've done
* Please Help!

I've noticed there are lots of people interested in changing the wiki
in various ways.  Perhaps it would help if can converge around some
common goals to rally our work around.  I don't think anyone has any
objections to the claim that the wiki is hard to read.

Let's move forward:
I've outlined some of my ideas at
.  There
seem to several categories of stuff on the wiki.  I've outlined them
in my to-do list and would greatly appreciate commentary and
refinement.  Andy and all others interested in this effort: would you
mind adding your ideas to your own section on the to-do page?  Also
feel free to comment inline with my ideas.  Here's part of my
categorization to provoke you a bit:
-
There are several categories of things in the wiki. Can we enumerate them?

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

Perhaps different categories of things need different approaches for
refinement.  Anyone see any problems with  my categorization?
Anything missing/wrong?

I'd love to see Andy, Phae, Scott, Tantek, and anyone else interested
in improving the wiki start to use the to-do list so I can align my
organizational thoughts with everyone.  Perhaps we can even run some
kind of virtual card sort to help establish how things should be
organized.  Anyone have any ideas on how to do this?

Ben

On 10/16/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:

In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>On 10/16/06 11:53 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
>
>>> If you can be specific about *which* pages, and what about them are
>>> hard to understand, that would be very helpful.
>>
>> Here's a hint: most people new to hCalendar (some of them, it will
>> apparently come as a surprise to you, not bloggers) are likely to want
>> to know from what components an hCalendar consists of,
>
>That is very reasonable,

Then why did you revert my change from "Bloggers can both embed hCards
directly in their web pages..." to "People can both embed hCards
directly in their web pages..."

And why did you remove the list of hCalendar properties which I'd
started?

>the right thing to do then is to add a section
>similar to the section in hCard which serves that purpose, *without doing
>any other changes*.

Who says that's the "right" thing to do?

>> before they read
>> your name twice, view two links to your day-job, or see you bigging-up
>> your friends; you appear to believe that the opposite is the case.
>
>Andy, please reread:
>
>http://microformats.org/wiki/to-do#update_specification_section_organization
>
>for what my current thoughts are on section organization,

I could hardly have read that, before I made the changes which you
reverted, since you hadn't posted it then.

Having since done so, it's little better than what's there now, and
shows no regard for the convenience of new users. I would have thought
that we want folks new to microformats to feel welcome.

>rather than implying/inferring

Please learn the difference; then say which you mean.

>from a single instance.

I have not done anything, based on a single instance.

>As far as the default order of editor, author, copyright etc., I *strongly*
>recommend you read some W3C specs to get an understanding of what "typical"
>web standards specifications look like.

I already know what they look like, but thank you for attempting to
patronise me anyway.

I note also that what you refer to, on the uF wiki, as a
"specification", is no such thing.

Then again, neither was the new section which I created on the hCalendar
page, which you have removed.

>> Neither are they likely to want to re-read a tedious and barely-relevant
>> essay on XML, complete with misleading advice.
>
>Please note that specifications are not tutorials, and attempting to make
>them into tutorials is very bad for precision and interoperability.

Please note that I have neither claimed nor implied that specifications
are tutorials, and attempting to imply that I have is vary bad.

>If you have specific issues about the semantic XHTML section, please raise
>them in a separate thread.

I can no longer be bothered. Congratulations.

>> BTW, I'm now asking you for the *fifth* time, to answer my question
>> about "species" examples.
>
>I for one have not had the time to read through your s

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

2006-10-16 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>On 10/16/06 12:30 PM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
>
>>> Imagine what would happen if everyone attempted to do so (or even just a
>>> dozen people).  There would be a lot of thrash, and worse still, the pages
>>> that are stable and reliable would become less so to the readers of those
>>> pages.
>>
>> I'm not really interested in discussing your unfounded assertions.
>
>Andy, the point is, that if everyone acted as you do, the wiki would be a
>mess with thrashing back and forth based upon everyone's different opinions
>of what makes usable/accessible content.

That's a baseless assertion and an insult.

>Please consider what would happen if everyone acted the way you do before
>you do such actions.

We'd have a far more readable, usable and welcoming Wiki.

> Thanks much for your understanding,

 Once again, your tone is objectionable.
>>>
>>> Andy, as has been noted by others, discussions of tone in email are usually
>>> not very productive.
>>
>> Nonetheless, yours is objectionable.
>
>Your perception and assertion of an objectionable tone is likely flawed and
>not true to the intended conveyed tone.  This is common in email, has been
>noted by others on this list, and therefore not worth asserting, especially
>repeatedly, as you have done so.

Your tone is objectionable. Frequently.


>I find that community interactions work better when
>everyone is assuming everyone else is also trying to do the right thing and
>make positive progress and help each other out

Yet you assert that "if everyone acted as [I] do, the wiki would be a
mess with thrashing back and forth based upon everyone's different
opinions of what makes usable/accessible content".

>If you have found otherwise, perhaps in other communities, then that's why I
>suggested you at least consider for this community.

I can't parse that; I don't believe it's meaningful English.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Andy Mabbett
In message
<[EMAIL PROTECTED]>, Benjamin
West <[EMAIL PROTECTED]> writes

>Quick Summary:
>* Lots of interest in wiki improvement
>* Work I've done
>* Please Help!
>
>I've noticed there are lots of people interested in changing the wiki
>in various ways.  Perhaps it would help if can converge around some
>common goals to rally our work around.  I don't think anyone has any
>objections to the claim that the wiki is hard to read.

The pages on hCard and, especially, hCalendar are harder to read now,
than they were ~5 hours, ago, before the recent reversions.


>Andy and all others interested in this effort: would you
>mind adding your ideas to your own section on the to-do page?

I don't have such a section, nor do I desire one.

>   * Specs

> o Discussion

Discussion is not part of a spec.

>I'd love to see Andy, Phae, Scott, Tantek, and anyone else interested
>in improving the wiki start to use the to-do list so I can align my
>organizational thoughts with everyone.

I'm no longer convinced that there's a Wiki in anything but name.

Tantek is fond of citing the W3C as an organisational model. compare
what one sees at the first (home page) and second  (i.e. a link from the
home page, to, say, "HTML") levels, compared with the second level of
the microformats Wiki (linking to, say hCalendar).

There also seems to be a presumption that "newbies" will initially be
interested in "authoring", that is almost certainly fallacious, and at
best unsupported by evidence.

cgriego's suggestion that "wiki/* (where people are mostly likely to go)
should be the intro page and it should link to wiki/*-spec" is far more
sensible.

>  Perhaps we can even run some
>kind of virtual card sort to help establish how things should be
>organized.  Anyone have any ideas on how to do this?

What do you mean by a "virtual card sort"?

>> --
>> Andy Mabbett
>> Say "NO!" to compulsory ID Cards:  
>>
>> Free Our Data:  
>> ___
>> microformats-discuss mailing list
>> microformats-discuss@microformats.org
>> http://microformats.org/mailman/listinfo/microformats-discuss
>>
>___
>microformats-discuss mailing list
>microformats-discuss@microformats.org
>http://microformats.org/mailman/listinfo/microformats-discuss

Please fix you software to remove sigs when replying; or do so manually.
Thank you.
-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Justin Thorp
Ben, I really like your idea of giving the wiki a better sense of organization.

Is it possible within MediaWiki to have some type of sidebar navigation with 
this site organization on it?

I think this would help users to better find the information that they are 
looking for. For example, I am a user who could care less about the 
specification and cares more about how to write an hCard or hCalendar.  I want 
to see whats possible and some examples.  

I didn't even see that there was a page on authoring within the pages and pages 
of specification.  Even with it at the top of the page.  I glanced right over 
it.

It seems like most tutorials on hCard or hCalendar point people to the spec to 
get more information.  Should we be encouraging people to point to the 
authoring page?  I think a newbie would be very very very intimidated being 
pointed right to the spec.

Cheers,
Justin


**
Justin Thorp
Contractor - Library of Congress
e - [EMAIL PROTECTED]
p - 202/707-9541

>>> [EMAIL PROTECTED] 10/16/06 4:16 PM >>>
Quick Summary:
* Lots of interest in wiki improvement
* Work I've done
* Please Help!

I've noticed there are lots of people interested in changing the wiki
in various ways.  Perhaps it would help if can converge around some
common goals to rally our work around.  I don't think anyone has any
objections to the claim that the wiki is hard to read.

Let's move forward:
I've outlined some of my ideas at
.  There
seem to several categories of stuff on the wiki.  I've outlined them
in my to-do list and would greatly appreciate commentary and
refinement.  Andy and all others interested in this effort: would you
mind adding your ideas to your own section on the to-do page?  Also
feel free to comment inline with my ideas.  Here's part of my
categorization to provoke you a bit:
-
There are several categories of things in the wiki. Can we enumerate them?

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

Perhaps different categories of things need different approaches for
refinement.  Anyone see any problems with  my categorization?
Anything missing/wrong?

I'd love to see Andy, Phae, Scott, Tantek, and anyone else interested
in improving the wiki start to use the to-do list so I can align my
organizational thoughts with everyone.  Perhaps we can even run some
kind of virtual card sort to help establish how things should be
organized.  Anyone have any ideas on how to do this?

Ben

On 10/16/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]>, Tantek Çelik
> <[EMAIL PROTECTED]> writes
>
> >On 10/16/06 11:53 AM, "Andy Mabbett" <[EMAIL PROTECTED]> wrote:
> >
> >>> If you can be specific about *which* pages, and what about them are
> >>> hard to understand, that would be very helpful.
> >>
> >> Here's a hint: most people new to hCalendar (some of them, it will
> >> apparently come as a surprise to you, not bloggers) are likely to want
> >> to know from what components an hCalendar consists of,
> >
> >That is very reasonable,
>
> Then why did you revert my change from "Bloggers can both embed hCards
> directly in their web pages..." to "People can both embed hCards
> directly in their web pages..."
>
> And why did you remove the list of hCalendar properties which I'd
> started?
>
> >the right thing to do then is to add a section
> >similar to the section in hCard which serves that purpose, *without doing
> >any other changes*.
>
> Who says that's the "right" thing to do?
>
> >> before they read
> >> your name twice, view two links to your day-job, or see you bigging-up
> >> your friends; you appear to believe that the opposite is the case.
> >
> >Andy, please reread:
> >
> >http://microformats.org/wiki/to-do#update_specification_section_organization 
> >
> >for what my current thoughts are on section organization,
>
> I could hardly have read that, before I made the changes which you
> reverted, since you hadn't posted it then.
>
> Having since done so, it's little better than what's there now, and
> shows no regard for the convenience of new users. I would have thought
> that we want folks new to microformats to feel welcome.
>
> >rather than implying/inferring
>
> Please learn the difference; then say which you mean.
>
> >from a single instance.
>
> I have not done anything, based on a single instance.
>
> >As far as the default order of editor, autho

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

2006-10-16 Thread Benjamin West

Andy,

Thanks for the prompt response; apologies if my own aren't so prompt.


There also seems to be a presumption that "newbies" will initially be
interested in "authoring", that is almost certainly fallacious, and at
best unsupported by evidence.


Ah, that's interesting.  Mind if I quote you on this in my to-do list?
What are newbies interested in?  How are they finding our content?
Ryan, are there any particularly interesting referrers in the logs?


cgriego's suggestion that "wiki/* (where people are mostly likely to go)
should be the intro page and it should link to wiki/*-spec" is far more
sensible.


Yes, I agree.  I like how  and friends
do this.  The big questions are right out front to help guide you to
the information you are interested in.  I happen to think that they
are "What is this?" "What can I do here?" "How can I learn more?" "Are
there examples"?  Is this what you envision as well?  I may add a
skeleton-type of example to my to-do list (help is needed with this).

Regarding the specs bit, I meant to refer to the various stages of the
process.  The spec landing page might contain the big questions, with
a status section pointing to pages dedicated toward how the spec is
moving through the process, and with the "learn more" section pointed
at the spec itself.  I suppose there might be more than one way to do
this: one choice might be to rename pages.  Another choice might be to
reorganize existing spec changes.  Another choice might be to create
newly named new landing pages that conform to some structure we work
to converge on.  There might be other choices I'm not considering.



>  Perhaps we can even run some
>kind of virtual card sort to help establish how things should be
>organized.  Anyone have any ideas on how to do this?

What do you mean by a "virtual card sort"?


I'm not sure. All I'm sure of is that I would like to align my desire
to improve the state of affairs with others.  I also believe that the
first step is to converge around some organization scheme.  I've been
asking around for specific sticking points on the site, hCard and
hCalendar have risen to the top.  Card sorts are useful to learn how
people expect things to be organized, but I'm having trouble picturing
how this would work as this is a virtual community and whatnot.



Please fix you software to remove sigs when replying; or do so manually.
Thank you.

Oops, sorry!  gmail hides these automatically for me.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Benjamin West

On 10/16/06, Justin Thorp <[EMAIL PROTECTED]> wrote:

Ben, I really like your idea of giving the wiki a better sense of organization.



Justin, thanks, but this isn't my idea.  Many others have expressed
their ideas and desires as well.


Is it possible within MediaWiki to have some type of sidebar navigation with 
this site organization on it?


Interesting idea.  Would you mind suggesting this on the to-do page?
You can create your own section or feel free to put it under mine.  If
enough people comment in my section, I'll split the whole section off
as it's own Wiki Improvement section. Please add this to
http://microformats.org/wiki/to-do#Ben_West_.28bewest.29 under
information architecture.  Be sure to leave your name.


I think this would help users to better find the information that they are 
looking for. For example, I am a user who could care less about the 
specification and cares more about how to write an hCard or hCalendar.  I want 
to see whats possible and some examples.


So your first inclination is authoring?  What kind of websites do you
author?  Are you more of a graphic designer or a web developer?

If there were a landing page for a specific microformat (as Andy and
cgriego have suggested.  I beleive I'm hearing more and more consensus
on this.) that had large items such as:
* What is this?
* What can I do here?
* Show me a demo.
* Create an hCard

Which one would look most promising?  If create an hcard went to the
hcard creator, would this suprise you?


I didn't even see that there was a page on authoring within the pages and pages 
of specification.  Even with it at the top of the page.  I glanced right over 
it.

It seems like most tutorials on hCard or hCalendar point people to the spec to 
get more information.  Should we be encouraging people to point to the 
authoring page?  I think a newbie would be very very very intimidated being 
pointed right to the spec.



Call me sick, but this is exactly the kind of thing I'm looking to
collect.  I've added it to
.  Can everyone add their
favorite complaint?

Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Mike Schinkel
I agree that the current layout is confusing. After reading several of these
email I would like to make a suggestion that is smaller scope than an entire
reorganization (which still might be a good idea.) 

Tantek suggests that "the specifications are not tutorials" and others have
said that they (think newbies would be) interested in authoring, not the
specification and I concur.

What if we 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:

* 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 

* http://microformats.org/wiki/hcard/Specification
* http://microformats.org/wiki/hcard/Tutorial
* http://microformats.org/wiki/hcard/Examples
* http://microformats.org/wiki/hcard/Use_cases
* http://microformats.org/wiki/hcard/Reference
* http://microformats.org/wiki/hcard/Discussion
* http://microformats.org/wiki/hcard/Brainstorming 
* http://microformats.org/wiki/hcard/Implementations
* http://microformats.org/wiki/hcard/Related_Pages
* http://microformats.org/wiki/hcard/Further_Reading  
* http://microformats.org/wiki/hcard/All 

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.

Hope this is useful...

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Monday, October 16, 2006 5:29 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

On 10/16/06, Justin Thorp <[EMAIL PROTECTED]> wrote:
> Ben, I really like your idea of giving the wiki a better sense of
organization.
>

Justin, thanks, but this isn't my idea.  Many others have expressed their
ideas and desires as well.

> Is it possible within MediaWiki to have some type of sidebar navigation
with this site organization on it?

Interesting idea.  Would you mind suggesting this on the to-do page?
You can create your own section or feel free to put it under mine.  If
enough people comment in my section, I'll split the whole section off as
it's own Wiki Improvement section. Please add this to
http://microformats.org/wiki/to-do#Ben_West_.28bewest.29 under information
architecture.  Be sure to leave your name.

> I think this would help users to better find the information that they are
looking for. For example, I am a user who could care less about the
specification and cares more about how to write an hCard or hCalendar.  I
want to see whats possible and some examples.

So your first inclination is authoring?  What kind of websites do you
author?  Are you more of a graphic designer or a web developer?

If there were a landing page for a specific microformat (as Andy and cgriego
have suggested.  I beleive I'm hearing more and more consensus on this.)
that had large items such as:
* What is this?
* What can I do here?
* Show me a demo.
* Create an hCard

Which one would look most promising?  If create an hcard went to the hcard
creator, would this suprise you?

> I didn't even see that there was a page on authoring within the pages and
pages of specification.  Even with it at the top of the page.  I glanced
right over it.
>
> It seems like most tutorials on hCard or hCalendar point people to the
spec to get more information.  Should we be encouraging people to point to
the authoring page?  I think a newbie would be very very very intimidated
being pointed right to the spec.
>

Call me sick, but this is exactly the kind of thing I'm looking to collect.
I've added it to <http://microformats.org/wiki/wiki-feedback>.  Can everyone
add their favorite complaint?

Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-16 Thread Benjamin West

Mike,

Thanks for you suggestion.  I believe this is exactly what cgriego and
Andy and I have just suggested.  Would you mind confiming this on the
to-do page under my name [1]?  If it somehow differs from the
suggestions there (under information architecture) would you please
explain how it differs?  Also please list your specific suggestions,
as well as, if possible, where content for the pages you suggest may
be gleaned, and which pages would need new content that doesn't yet
exist.

I think you may have illuminated the intent more clearly than it has
been explained so far, and so your refinement on the wiki would be
very helpful.

Thanks,
Ben

[1] <http://microformats.org/wiki/to-do#Information_Architecture>


On 10/16/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

I agree that the current layout is confusing. After reading several of these
email I would like to make a suggestion that is smaller scope than an entire
reorganization (which still might be a good idea.)

Tantek suggests that "the specifications are not tutorials" and others have
said that they (think newbies would be) interested in authoring, not the
specification and I concur.

What if we 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:

* 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

* http://microformats.org/wiki/hcard/Specification
* http://microformats.org/wiki/hcard/Tutorial
* http://microformats.org/wiki/hcard/Examples
* http://microformats.org/wiki/hcard/Use_cases
* http://microformats.org/wiki/hcard/Reference
* http://microformats.org/wiki/hcard/Discussion
* http://microformats.org/wiki/hcard/Brainstorming
* http://microformats.org/wiki/hcard/Implementations
* http://microformats.org/wiki/hcard/Related_Pages
* http://microformats.org/wiki/hcard/Further_Reading
* http://microformats.org/wiki/hcard/All

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.

Hope this is useful...

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Monday, October 16, 2006 5:29 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

On 10/16/06, Justin Thorp <[EMAIL PROTECTED]> wrote:
> Ben, I really like your idea of giving the wiki a better sense of
organization.
>

Justin, thanks, but this isn't my idea.  Many others have expressed their
ideas and desires as well.

> Is it possible within MediaWiki to have some type of sidebar navigation
with this site organization on it?

Interesting idea.  Would you mind suggesting this on the to-do page?
You can create your own section or feel free to put it under mine.  If
enough people comment in my section, I'll split the whole section off as
it's own Wiki Improvement section. Please add this to
http://microformats.org/wiki/to-do#Ben_West_.28bewest.29 under information
architecture.  Be sure to leave your name.

> I think this would help users to better find the information that they are
looking for. For example, I am a user who could care less about the
specification and cares more about how to write an hCard or hCalendar.  I
want to see whats possible and some examples.

So your first inclination is authoring?  What kind of websites do you
author?  Are you more of a graphic designer or a web developer?

If there were a landing page for a specific microformat (as Andy and cgriego
have suggested.  I beleive I'm hearing more and more consensus on this.)
that had large items such as:
* What is this?
* What can I do here?
* Show me a demo.
* Create an hCard

Which one would look most promising?  If create an hcard went to the hcard
creator, would this suprise you?

> I didn't even see that there was a page on authoring within the pages and
pages of specification.  Even with it at the top of the page.  I glanced
right over it.
>
> It seems like most tutorials on hCard or hCalendar point people to the
spec to get more information.  Should we be encouraging people to point to
the authoring page?  I think a newbie would be very very very intimidated
being pointed right to the spec.
>

Call me sick, but this is exactly the kind of thing I'm looking t

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

2006-10-16 Thread Mike Schinkel
>> Would you mind confiming this on the to-do page under my name [1]? 

I added, see if it is what you were wanting...

>> If it somehow differs from the suggestions there (under information
architecture) would you please explain how it differs?  

Okay.  Note I did not change anything outside my comments, I just added my
comments.

>> Also please list your specific suggestions, as well as, if possible,
where content for the pages you suggest may be gleaned, 

The current microformat pages (i.e. http://microformats.org/wiki/hcard/) and
any they reference. I think this will become obvious during reorganization.

>> and which pages would need new content that doesn't yet exist.

I think any list I create on my own (beyond my first list, which is just a
starting point) will be ill-conceived and incomplete.  They need to be
gleened during the process of reorganization as a collective effort.  

>> I think you may have illuminated the intent more clearly than it has been
explained so far, and so your refinement on the wiki would be very helpful.

Thanks for the ack.

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Tuesday, October 17, 2006 12:12 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

Mike,

Thanks for you suggestion.  I believe this is exactly what cgriego and Andy
and I have just suggested.  Would you mind confiming this on the to-do page
under my name [1]?  If it somehow differs from the suggestions there (under
information architecture) would you please explain how it differs?  Also
please list your specific suggestions, as well as, if possible, where
content for the pages you suggest may be gleaned, and which pages would need
new content that doesn't yet exist.

I think you may have illuminated the intent more clearly than it has been
explained so far, and so your refinement on the wiki would be very helpful.

Thanks,
Ben

[1] <http://microformats.org/wiki/to-do#Information_Architecture>


On 10/16/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:
> I agree that the current layout is confusing. After reading several of 
> these email I would like to make a suggestion that is smaller scope 
> than an entire reorganization (which still might be a good idea.)
>
> Tantek suggests that "the specifications are not tutorials" and others 
> have said that they (think newbies would be) interested in authoring, 
> not the specification and I concur.
>
> What if we 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:
>
> * 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
>
> * http://microformats.org/wiki/hcard/Specification
> * http://microformats.org/wiki/hcard/Tutorial
> * http://microformats.org/wiki/hcard/Examples
> * http://microformats.org/wiki/hcard/Use_cases
> * http://microformats.org/wiki/hcard/Reference
> * http://microformats.org/wiki/hcard/Discussion
> * http://microformats.org/wiki/hcard/Brainstorming
> * http://microformats.org/wiki/hcard/Implementations
> * http://microformats.org/wiki/hcard/Related_Pages
> * http://microformats.org/wiki/hcard/Further_Reading
> * http://microformats.org/wiki/hcard/All
>
> 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.
>
> Hope this is useful...
>
> -Mike
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Benjamin West
> Sent: Monday, October 16, 2006 5:29 PM
> To: Microformats Discuss
> Subject: Re: [uf-discuss] hCalendar spec- no specification included!
>
> On 10/16/06, Justin Thorp <[EMAIL PROTECTED]> wrote:
> > Ben, I really like your idea of giving the wiki a better sense of
> organization.
> >
>
> Justin, thanks, but this isn't my idea.  Many others have expressed 
> their ideas and desires as well.
>
> > Is it possible within MediaWiki to have some type of sidebar 
> > navigation
> with this

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

2006-10-16 Thread Benjamin West

Mike, this is great.  I really like it.   Remember to check back and
make sure progress is happening.  Feel free to give me a nudge if I'm
unresponsive.

Ben

On 10/16/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

>> Would you mind confiming this on the to-do page under my name [1]?

I added, see if it is what you were wanting...

>> If it somehow differs from the suggestions there (under information
architecture) would you please explain how it differs?

Okay.  Note I did not change anything outside my comments, I just added my
comments.

>> Also please list your specific suggestions, as well as, if possible,
where content for the pages you suggest may be gleaned,

The current microformat pages (i.e. http://microformats.org/wiki/hcard/) and
any they reference. I think this will become obvious during reorganization.

>> and which pages would need new content that doesn't yet exist.

I think any list I create on my own (beyond my first list, which is just a
starting point) will be ill-conceived and incomplete.  They need to be
gleened during the process of reorganization as a collective effort.

>> I think you may have illuminated the intent more clearly than it has been
explained so far, and so your refinement on the wiki would be very helpful.

Thanks for the ack.

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Tuesday, October 17, 2006 12:12 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

Mike,

Thanks for you suggestion.  I believe this is exactly what cgriego and Andy
and I have just suggested.  Would you mind confiming this on the to-do page
under my name [1]?  If it somehow differs from the suggestions there (under
information architecture) would you please explain how it differs?  Also
please list your specific suggestions, as well as, if possible, where
content for the pages you suggest may be gleaned, and which pages would need
new content that doesn't yet exist.

I think you may have illuminated the intent more clearly than it has been
explained so far, and so your refinement on the wiki would be very helpful.

Thanks,
Ben

[1] <http://microformats.org/wiki/to-do#Information_Architecture>


On 10/16/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:
> I agree that the current layout is confusing. After reading several of
> these email I would like to make a suggestion that is smaller scope
> than an entire reorganization (which still might be a good idea.)
>
> Tantek suggests that "the specifications are not tutorials" and others
> have said that they (think newbies would be) interested in authoring,
> not the specification and I concur.
>
> What if we 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:
>
> * 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
>
> * http://microformats.org/wiki/hcard/Specification
> * http://microformats.org/wiki/hcard/Tutorial
> * http://microformats.org/wiki/hcard/Examples
> * http://microformats.org/wiki/hcard/Use_cases
> * http://microformats.org/wiki/hcard/Reference
> * http://microformats.org/wiki/hcard/Discussion
> * http://microformats.org/wiki/hcard/Brainstorming
> * http://microformats.org/wiki/hcard/Implementations
> * http://microformats.org/wiki/hcard/Related_Pages
> * http://microformats.org/wiki/hcard/Further_Reading
> * http://microformats.org/wiki/hcard/All
>
> 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.
>
> Hope this is useful...
>
> -Mike
>
> -----Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Benjamin West
> Sent: Monday, October 16, 2006 5:29 PM
> To: Microformats Discuss
> Subject: Re: [uf-discuss] hCalendar spec- no specification included!
>
> On 10/16/06, Justin Thorp <[EMAIL PROTECTED]> wrote:
> > Ben, I really like your idea of giving the wiki a better sense of
> organization.
> >
>
> Justin, thanks,

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

2006-10-16 Thread Mike Schinkel
Thanks. I subscribed to the page. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Tuesday, October 17, 2006 1:28 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

Mike, this is great.  I really like it.   Remember to check back and
make sure progress is happening.  Feel free to give me a nudge if I'm
unresponsive.

Ben

On 10/16/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:
> >> Would you mind confiming this on the to-do page under my name [1]?
>
> I added, see if it is what you were wanting...
>
> >> If it somehow differs from the suggestions there (under information
> architecture) would you please explain how it differs?
>
> Okay.  Note I did not change anything outside my comments, I just 
> added my comments.
>
> >> Also please list your specific suggestions, as well as, if 
> >> possible,
> where content for the pages you suggest may be gleaned,
>
> The current microformat pages (i.e. 
> http://microformats.org/wiki/hcard/) and any they reference. I think this
will become obvious during reorganization.
>
> >> and which pages would need new content that doesn't yet exist.
>
> I think any list I create on my own (beyond my first list, which is 
> just a starting point) will be ill-conceived and incomplete.  They 
> need to be gleened during the process of reorganization as a collective
effort.
>
> >> I think you may have illuminated the intent more clearly than it 
> >> has been
> explained so far, and so your refinement on the wiki would be very
helpful.
>
> Thanks for the ack.
>
> -Mike
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Benjamin West
> Sent: Tuesday, October 17, 2006 12:12 AM
> To: Microformats Discuss
> Subject: Re: [uf-discuss] hCalendar spec- no specification included!
>
> Mike,
>
> Thanks for you suggestion.  I believe this is exactly what cgriego and 
> Andy and I have just suggested.  Would you mind confiming this on the 
> to-do page under my name [1]?  If it somehow differs from the 
> suggestions there (under information architecture) would you please 
> explain how it differs?  Also please list your specific suggestions, 
> as well as, if possible, where content for the pages you suggest may 
> be gleaned, and which pages would need new content that doesn't yet exist.
>
> I think you may have illuminated the intent more clearly than it has 
> been explained so far, and so your refinement on the wiki would be very
helpful.
>
> Thanks,
> Ben
>
> [1] <http://microformats.org/wiki/to-do#Information_Architecture>
>
>
> On 10/16/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:
> > I agree that the current layout is confusing. After reading several 
> > of these email I would like to make a suggestion that is smaller 
> > scope than an entire reorganization (which still might be a good 
> > idea.)
> >
> > Tantek suggests that "the specifications are not tutorials" and 
> > others have said that they (think newbies would be) interested in 
> > authoring, not the specification and I concur.
> >
> > What if we 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:
> >
> > * 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
> >
> > * http://microformats.org/wiki/hcard/Specification
> > * http://microformats.org/wiki/hcard/Tutorial
> > * http://microformats.org/wiki/hcard/Examples
> > * http://microformats.org/wiki/hcard/Use_cases
> > * http://microformats.org/wiki/hcard/Reference
> > * http://microformats.org/wiki/hcard/Discussion
> > * http://microformats.org/wiki/hcard/Brainstorming
> > * http://microformats.org/wiki/hcard/Implementations
> > * http://microformats.org/wiki/hcard/Related_Pages
> > * http://microformats.org/wiki/hcard/Further_Reading
> > * http://microformats.org/wiki/hcard/All
> >
> > Please note I am suggesting an a

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

2006-10-17 Thread Stephen Paul Weber

For myself, I mostly just skip to the 'examples' section... but that's
because I learn by reading code better than reading english ;)

On 10/16/06, Justin Thorp <[EMAIL PROTECTED]> wrote:

I think the pages the way they are presented now are a bit hard to process and 
understand.

I remember for me it took some time to initally dig through the specification 
to find what I was actually looking for.  I just wanted to figure out how to 
write an hCard.

Andy, I look forward to seeing the fruits of your labor.

Cheers,
Justin




**
Justin Thorp
Contractor - Library of Congress
e - [EMAIL PROTECTED]
p - 202/707-9541

>>> [EMAIL PROTECTED] 10/16/06 1:38 PM >>>

I've just been introducing a colleague to the concept of hCalendar; and
referred her to:

http://microformats.org/wiki/hCalendar

She was baffled; not lest because, though the page had a treatise on
"Semantic XHTML Design Principles", it didn't list the hCalendar fields,
let alone say which are mandatory and which are optional!

I have started to rewrite the page, but welcome contributions.

--
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss




--
- Stephen Paul Weber, Amateur Writer


MSN/GTalk/Jabber: [EMAIL PROTECTED]
ICQ/AIM: 103332966
NSA: [EMAIL PROTECTED]
BLOG: http://singpolyma-tech.blogspot.com/
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-17 Thread Andy Mabbett
In message
<[EMAIL PROTECTED]>, Benjamin
West <[EMAIL PROTECTED]> writes


>Thanks for the prompt response; apologies if my own aren't so prompt.

None needed. Such is e-mail!

>> There also seems to be a presumption that "newbies" will initially be
>> interested in "authoring", that is almost certainly fallacious, and at
>> best unsupported by evidence.
>
>Ah, that's interesting.  Mind if I quote you on this in my to-do list?

Of course not.

>What are newbies interested in?

I can only speak for myself, and imagine what others want, but I would
have thought a mixture of general information and information on ho to
"read" uFs on pages which already have them (and thus what tools, FF
extensions, etc. to use).

IIRC, Jacob Neilsen's recent works suggests a 90-9-1 percentage mix of
"readers" "publishers" and "developers".

> How are they finding our content?

Mostly, I suspect, by following links on pages/ sites which use, or
discuss, uFs

for example, respectively:





>I like how  and friends
>do this.  The big questions are right out front to help guide you to
>the information you are interested in.  I happen to think that they
>are "What is this?" "What can I do here?" "How can I learn more?" "Are
>there examples"?  Is this what you envision as well?

Pretty much.

>Regarding the specs bit, I meant to refer to the various stages of the
>process.  The spec landing page might contain the big questions, with
>a status section pointing to pages dedicated toward how the spec is
>moving through the process, and with the "learn more" section pointed
>at the spec itself.

If the "spec itself" is on a secondary page, then the "landing" page
isn't the spec.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-17 Thread Andy Mabbett
In message
<[EMAIL PROTECTED]>, Benjamin
West <[EMAIL PROTECTED]> writes

>* Show me a demo.
>* Create an hCard

Between those two should come the formal specification.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-17 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Mike Schinkel
<[EMAIL PROTECTED]> writes

>others have
>said that they (think newbies would be) interested in authoring, not the
>specification and I concur.

I don't think anyone has said that. I certainly don't think people
should be encouraged to begin authoring before first understanding what
the are nad are not "allowed" to do (unless by "authoring" you mean
"fill in a form and let a machine do the authoring for you")

At the very least they should be given the option of reading the spec
before they begin authoring - as is NOT the case with hCalendar, at
present.

>What if we 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.

Reasonable, but it needs some content, so as not to appear dry and
unwelcoming.

> For example, is a list of potential sub pages:
[...]
>* Brainstorming (might be combined w/Discussion)

Once they standard is set, the brainstorming (and related examples) is
only of archival interest.

I note that your list does not include an explanation of Semantic
XHTML...


-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Justin Thorp
I really like this idea.  What if the landing page for the microformat wasn't 
the spec but it was some warm and fuzzy intro for newbies?  It could then link 
to the spec for those that were interested to it.

A good example of this would be the W3C WAI's intro for WCAG that they give you 
before you get sent right into WCAG 1.0.
http://www.w3.org/WAI/intro/wcag 

I would expect that a lot of newbies start off hearing about microformats on 
tutorials like:
http://www.digital-web.com/articles/microformats_primer/
http://www.thinkvitamin.com/features/design/how-to-use-microformats 

Or from presentations like:
http://tantek.com/presentations/2006/09/microformats-practices/

They get linked to the spec and then get offly confused.

-justin thorp

**
Justin Thorp
Web Services - Office of Strategic Initiatives
Library of Congress
e - [EMAIL PROTECTED]
p - 202/707-9541

>>> [EMAIL PROTECTED] 10/17/06 3:39 PM >>>
In message
<[EMAIL PROTECTED]>, Benjamin
West <[EMAIL PROTECTED]> writes

>Regarding the specs bit, I meant to refer to the various stages of the
>process.  The spec landing page might contain the big questions, with
>a status section pointing to pages dedicated toward how the spec is
>moving through the process, and with the "learn more" section pointed
>at the spec itself.

If the "spec itself" is on a secondary page, then the "landing" page
isn't the spec.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org 
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Benjamin West

Justin,

Would you mind visiting
 and
adding your support?

While we're on the subject of newbies, if they first hear about
microformats from the sources you mentioned, what kind of people are
they? Are they graphic designers? Web developers?  Business people?
It appears that microformat newbies are the kind of people that go to
conventions.

What do these people expect when they visit for the first time?  Most
web browsing is task-oriented.  Do they want to find out how to author
microformats?  Learn more about what they are?  Find out why they
exist?

Ben

On 10/18/06, Justin Thorp <[EMAIL PROTECTED]> wrote:

I really like this idea.  What if the landing page for the microformat wasn't 
the spec but it was some warm and fuzzy intro for newbies?  It could then link 
to the spec for those that were interested to it.

A good example of this would be the W3C WAI's intro for WCAG that they give you 
before you get sent right into WCAG 1.0.
http://www.w3.org/WAI/intro/wcag

I would expect that a lot of newbies start off hearing about microformats on 
tutorials like:
http://www.digital-web.com/articles/microformats_primer/
http://www.thinkvitamin.com/features/design/how-to-use-microformats

Or from presentations like:
http://tantek.com/presentations/2006/09/microformats-practices/

They get linked to the spec and then get offly confused.

-justin thorp

**
Justin Thorp
Web Services - Office of Strategic Initiatives
Library of Congress
e - [EMAIL PROTECTED]
p - 202/707-9541

>>> [EMAIL PROTECTED] 10/17/06 3:39 PM >>>
In message
<[EMAIL PROTECTED]>, Benjamin
West <[EMAIL PROTECTED]> writes

>Regarding the specs bit, I meant to refer to the various stages of the
>process.  The spec landing page might contain the big questions, with
>a status section pointing to pages dedicated toward how the spec is
>moving through the process, and with the "learn more" section pointed
>at the spec itself.

If the "spec itself" is on a secondary page, then the "landing" page
isn't the spec.

--
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Mike Schinkel
>> I don't think anyone has said that. I certainly don't think people should
be encouraged to begin authoring before first understanding what the are nad
are not "allowed" to do (unless by "authoring" you mean "fill in a form and
let a machine do the authoring for you")

A form would be nice, but it takes time to develop and we can't expect they
will be developed before people are interested.  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.

>> 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.)

>> Once they standard is set, the brainstorming (and related examples) is
only of archival interest.

Note that I said my list was just a set to start discussion, but...
Certainly the link can be removed, although it might be of interest to
people wanting to understand why decisions were made.  I don't have a strong
opinion to argue for it either way.

>> I note that your list does not include an explanation of Semantic
XHTML...

Again, as I said, my list was just a set to start discussion...


-Mike
--
[1] http://www.useit.com/alertbox/9710a.html
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy
Mabbett
Sent: Tuesday, October 17, 2006 3:48 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

In message <[EMAIL PROTECTED]>, Mike Schinkel
<[EMAIL PROTECTED]> writes

>others have
>said that they (think newbies would be) interested in authoring, not 
>the specification and I concur.

I don't think anyone has said that. I certainly don't think people should be
encouraged to begin authoring before first understanding what the are nad
are not "allowed" to do (unless by "authoring" you mean "fill in a form and
let a machine do the authoring for you")

At the very least they should be given the option of reading the spec before
they begin authoring - as is NOT the case with hCalendar, at present.

>What if we 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.

Reasonable, but it needs some content, so as not to appear dry and
unwelcoming.

> For example, is a list of potential sub pages:
[...]
>* Brainstorming (might be combined w/Discussion)

Once they standard is set, the brainstorming (and related examples) is only
of archival interest.

I note that your list does not include an explanation of Semantic XHTML...


--
Andy Mabbett
Say "NO!" to compulsory ID Cards:  <http://www.no2id.net/>

Free Our Data:  <http://www.freeourdata.org.uk>
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Justin Thorp
Ben,

I will try and get to the IA page tonite and see if I can add some comments and 
thoughts.

I think the people reading the articles about microformats and jumping into the 
spec cold are the early adoptor web developers.  My uneducated opinion is that 
microformats is a fairly new movement.  

Regardless, it seems like it would be in the best interest of what we are 
trying to do to write all of our stuff and organize it so that it also works 
for the 50 year old web systems programmer who may be slow to adopting 
(stubborn) new technologies but was told by his boss he has to look at the 
business applications of adopting microformats.

If I land on Microformats.org for the first time, just wanting to learn, I am 
going to be looking for something that says intro or new or tutorial.  It needs 
to answer the who, what, when, where, why, and how.  It shouldn't use jargonny 
language.

If I am new and reading about hCard or hCalendar for the first time.  I want to 
figure out BRIEFLY what the background is.  I don't need a history of vCard.  
I'd want some examples.  Id want to know about what sites use them.  I'd want 
tools to help build them.  Id want a list of all the different class names and 
where I can and can not use them (the rules).  I'd leave semantic principles in 
a doc that you can link to. Maybe mention it briefly.

Hope this helps.

Cheers,
Justin Thorp


**
Justin Thorp
Web Services - Office of Strategic Initiatives
Library of Congress
e - [EMAIL PROTECTED]
p - 202/707-9541

>>> [EMAIL PROTECTED] 10/18/06 12:59 PM >>>
Justin,

Would you mind visiting
 and
adding your support?

While we're on the subject of newbies, if they first hear about
microformats from the sources you mentioned, what kind of people are
they? Are they graphic designers? Web developers?  Business people?
It appears that microformat newbies are the kind of people that go to
conventions.

What do these people expect when they visit for the first time?  Most
web browsing is task-oriented.  Do they want to find out how to author
microformats?  Learn more about what they are?  Find out why they
exist?

Ben

On 10/18/06, Justin Thorp <[EMAIL PROTECTED]> wrote:
> I really like this idea.  What if the landing page for the microformat wasn't 
> the spec but it was some warm and fuzzy intro for newbies?  It could then 
> link to the spec for those that were interested to it.
>
> A good example of this would be the W3C WAI's intro for WCAG that they give 
> you before you get sent right into WCAG 1.0.
> http://www.w3.org/WAI/intro/wcag 
>
> I would expect that a lot of newbies start off hearing about microformats on 
> tutorials like:
> http://www.digital-web.com/articles/microformats_primer/ 
> http://www.thinkvitamin.com/features/design/how-to-use-microformats 
>
> Or from presentations like:
> http://tantek.com/presentations/2006/09/microformats-practices/ 
>
> They get linked to the spec and then get offly confused.
>
> -justin thorp
>
> **
> Justin Thorp
> Web Services - Office of Strategic Initiatives
> Library of Congress
> e - [EMAIL PROTECTED] 
> p - 202/707-9541
>
> >>> [EMAIL PROTECTED] 10/17/06 3:39 PM >>>
> In message
> <[EMAIL PROTECTED]>, Benjamin
> West <[EMAIL PROTECTED]> writes
>
> >Regarding the specs bit, I meant to refer to the various stages of the
> >process.  The spec landing page might contain the big questions, with
> >a status section pointing to pages dedicated toward how the spec is
> >moving through the process, and with the "learn more" section pointed
> >at the spec itself.
>
> If the "spec itself" is on a secondary page, then the "landing" page
> isn't the spec.
>
> --
> Andy Mabbett
> Say "NO!" to compulsory ID Cards:  
>
> Free Our Data:  
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org 
> http://microformats.org/mailman/listinfo/microformats-discuss 
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org 
> http://microformats.org/mailman/listinfo/microformats-discuss 
>
___
microformats-discuss mailing list
microformats-discuss@microformats.org 
http://microformats.org/mailman/listinfo/microformats-discuss
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Benjamin West

On 10/18/06, Mike Schinkel <[EMAIL PROTECTED]> 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@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Benjamin West

Justin,

Great input.  Let me see if I can summarize it in bullet form:


* Bleeding Edge Adopters
 * Looking for new things
 * Might be looking/adopting things for the sake of coolness/newness
   * uF's seem new and cool?
 * Probably little exposure to uF (did they see it mentioned in a
blog, search, or conference?)

* Veteran Experts
 * Fulfilling obligations from above
 * Trusted expertise for business decisions
 * Referred from a non-expert source to check viability

First Experience:
 * Quick Background/Overview
 * Short Salient Examples
 * Cheat Sheet for Authorship
 * Tools
* Authoring
* Parsing
 * More Resources
   * Authoritative Spec
   * Examples

Something like that?

Ben

On 10/18/06, Justin Thorp <[EMAIL PROTECTED]> wrote:


I think the people reading the articles about microformats and jumping into the 
spec cold are the early adoptor web developers.  My uneducated opinion is that 
microformats is a fairly new movement.

Regardless, it seems like it would be in the best interest of what we are 
trying to do to write all of our stuff and organize it so that it also works 
for the 50 year old web systems programmer who may be slow to adopting 
(stubborn) new technologies but was told by his boss he has to look at the 
business applications of adopting microformats.

If I land on Microformats.org for the first time, just wanting to learn, I am 
going to be looking for something that says intro or new or tutorial.  It needs 
to answer the who, what, when, where, why, and how.  It shouldn't use jargonny 
language.

If I am new and reading about hCard or hCalendar for the first time.  I want to 
figure out BRIEFLY what the background is.  I don't need a history of vCard.  
I'd want some examples.  Id want to know about what sites use them.  I'd want 
tools to help build them.  Id want a list of all the different class names and 
where I can and can not use them (the rules).  I'd leave semantic principles in 
a doc that you can link to. Maybe mention it briefly.

Hope this helps.

Cheers,
Justin Thorp


**
Justin Thorp
Web Services - Office of Strategic Initiatives
Library of Congress
e - [EMAIL PROTECTED]
p - 202/707-9541

>>> [EMAIL PROTECTED] 10/18/06 12:59 PM >>>
Justin,

Would you mind visiting
 and
adding your support?

While we're on the subject of newbies, if they first hear about
microformats from the sources you mentioned, what kind of people are
they? Are they graphic designers? Web developers?  Business people?
It appears that microformat newbies are the kind of people that go to
conventions.

What do these people expect when they visit for the first time?  Most
web browsing is task-oriented.  Do they want to find out how to author
microformats?  Learn more about what they are?  Find out why they
exist?

Ben

On 10/18/06, Justin Thorp <[EMAIL PROTECTED]> wrote:
> I really like this idea.  What if the landing page for the microformat wasn't 
the spec but it was some warm and fuzzy intro for newbies?  It could then link to 
the spec for those that were interested to it.
>
> A good example of this would be the W3C WAI's intro for WCAG that they give 
you before you get sent right into WCAG 1.0.
> http://www.w3.org/WAI/intro/wcag
>
> I would expect that a lot of newbies start off hearing about microformats on 
tutorials like:
> http://www.digital-web.com/articles/microformats_primer/
> http://www.thinkvitamin.com/features/design/how-to-use-microformats
>
> Or from presentations like:
> http://tantek.com/presentations/2006/09/microformats-practices/
>
> They get linked to the spec and then get offly confused.
>
> -justin thorp
>
> **
> Justin Thorp
> Web Services - Office of Strategic Initiatives
> Library of Congress
> e - [EMAIL PROTECTED]
> p - 202/707-9541
>
> >>> [EMAIL PROTECTED] 10/17/06 3:39 PM >>>
> In message
> <[EMAIL PROTECTED]>, Benjamin
> West <[EMAIL PROTECTED]> writes
>
> >Regarding the specs bit, I meant to refer to the various stages of the
> >process.  The spec landing page might contain the big questions, with
> >a status section pointing to pages dedicated toward how the spec is
> >moving through the process, and with the "learn more" section pointed
> >at the spec itself.
>
> If the "spec itself" is on a secondary page, then the "landing" page
> isn't the spec.
>
> --
> Andy Mabbett
> Say "NO!" to compulsory ID Cards:  
>
> Free Our Data:  
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
___
microformats-discuss 

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

2006-10-18 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Mike Schinkel
<[EMAIL PROTECTED]> writes

>>> I don't think anyone has said that. I certainly don't think people should
>be encouraged to begin authoring before first understanding what the
>are nad are not "allowed" to do (unless by "authoring" you mean "fill
>in a form and let a machine do the authoring for you")
>
>A form would be nice,

It might be; note that I wasn't calling for one.

> but it takes time to develop and we can't expect they will be
>developed before people are interested.

We can't expect people to use something for which there is no spec!

[...]
>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?

Yup.

>  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.

Agreed. Did I say otherwise?

>>> 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]."

What, again?

>  Content for content sake is less than useful.

Indeed. Did I ask for "content for content's sake"?

>>> Once they standard is set, the brainstorming (and related examples) is
>only of archival interest.
>
>Note that I said my list was just a set to start discussion

Note that I was discussing it.

>>> I note that your list does not include an explanation of Semantic
>XHTML...
>
>Again, as I said, my list was just a set to start discussion...

Note that I wasn't criticising you for omitting it.
-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Justin Thorp <[EMAIL PROTECTED]> writes

>I would expect that a lot of newbies start off hearing about
>microformats on tutorials
[...]
>They get linked to the spec and then get offly confused.

Not least, as I have soda previously, because what is labelled as the
spec is no such thing.

Where is the hCalendar spec? Has anyone seen it?
-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Justin Thorp <[EMAIL PROTECTED]> writes

>the 50 year old web systems programmer who may be slow to adopting
>(stubborn) new technologies but was told by his boss he has to look at
>the business applications of adopting microformats.

There's nothing like a bit of ageist stereotyping.

(Apart form the post quoted, which is exactly like a bit of ageist
stereotyping.)

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Andy Mabbett
In message
<[EMAIL PROTECTED]>, Benjamin
West <[EMAIL PROTECTED]> writes

>* Bleeding Edge Adopters
> * Looking for new things
> * Might be looking/adopting things for the sake of coolness/newness
>   * uF's seem new and cool?
> * Probably little exposure to uF (did they see it mentioned in a
>blog, search, or conference?)
>
>* Veteran Experts
> * Fulfilling obligations from above
> * Trusted expertise for business decisions
> * Referred from a non-expert source to check viability

>Something like that?

You forgot:

* Veteran Experts
 * Looking for new things
 * Might be looking/adopting things for the sake of coolness/newness
   * uF's seem new and cool?
 * Probably little exposure to uF (did they see it mentioned in a
blog, search, or conference?)

* Bleeding Edge Adopters
 * Fulfilling obligations from above
 * Trusted expertise for business decisions
 * Referred from a non-expert source to check viability

HTH
-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Benjamin West

On 10/18/06, Andy Mabbett <[EMAIL PROTECTED]> wrote:


You forgot:


Actually, I was summarizing and synthesizing, not forgetting.


* Veteran Experts
 * Looking for new things
 * Might be looking/adopting things for the sake of coolness/newness
   * uF's seem new and cool?
 * Probably little exposure to uF (did they see it mentioned in a
blog, search, or conference?)

* Bleeding Edge Adopters
 * Fulfilling obligations from above
 * Trusted expertise for business decisions
 * Referred from a non-expert source to check viability

HTH


I'm not sure this helps.  This essentially washes out the picture of
two types of users.  Perhaps we should continue coalescing to include
humans in general, because looking for new things is in the nature of
the human spirit.

My approach to this is to identify differences, although subtle,
between users in order to better understand what kinds of resources
would be most helpful.  To do that, I'm attempting to build consensus
using synthesis and simple questions.

I'm a little confused about what you are suggesting.  Can you
elaborate?  My current thoughts are that you meant either to say that
there is only one type of new user, or that the list proffered is
useless.  Then again, I'm not a mind reader, so feel free to correct
me.

Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Mike Schinkel
Benjamin:

As one data point, I learned about Microformats[1] at a conference[2]. When
I came to the site I wanted to learn how to author them.  In addition, I
wanted to learn how to get involved in the process of specifying new ones
(although I doubt only a small percentage will be interested in that.)

-Mike
[1] http://www.mikeschinkel.com/blog/MicroformatsHCard.aspx
[2]
http://www.mikeschinkel.com/blog/CarsonWorkshopsFutureOfWebAppsConferenceWas
Incredible.aspx


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Wednesday, October 18, 2006 1:00 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

Justin,

Would you mind visiting
<http://microformats.org/wiki/to-do#Information_Architecture> and adding
your support?

While we're on the subject of newbies, if they first hear about microformats
from the sources you mentioned, what kind of people are they? Are they
graphic designers? Web developers?  Business people?
It appears that microformat newbies are the kind of people that go to
conventions.

What do these people expect when they visit for the first time?  Most web
browsing is task-oriented.  Do they want to find out how to author
microformats?  Learn more about what they are?  Find out why they exist?

Ben

On 10/18/06, Justin Thorp <[EMAIL PROTECTED]> wrote:
> I really like this idea.  What if the landing page for the microformat
wasn't the spec but it was some warm and fuzzy intro for newbies?  It could
then link to the spec for those that were interested to it.
>
> A good example of this would be the W3C WAI's intro for WCAG that they
give you before you get sent right into WCAG 1.0.
> http://www.w3.org/WAI/intro/wcag
>
> I would expect that a lot of newbies start off hearing about microformats
on tutorials like:
> http://www.digital-web.com/articles/microformats_primer/
> http://www.thinkvitamin.com/features/design/how-to-use-microformats
>
> Or from presentations like:
> http://tantek.com/presentations/2006/09/microformats-practices/
>
> They get linked to the spec and then get offly confused.
>
> -justin thorp
>
> **
> Justin Thorp
> Web Services - Office of Strategic Initiatives Library of Congress e - 
> [EMAIL PROTECTED] p - 202/707-9541
>
> >>> [EMAIL PROTECTED] 10/17/06 3:39 PM >>>
> In message
> <[EMAIL PROTECTED]>, 
> Benjamin West <[EMAIL PROTECTED]> writes
>
> >Regarding the specs bit, I meant to refer to the various stages of 
> >the process.  The spec landing page might contain the big questions, 
> >with a status section pointing to pages dedicated toward how the spec 
> >is moving through the process, and with the "learn more" section 
> >pointed at the spec itself.
>
> If the "spec itself" is on a secondary page, then the "landing" page 
> isn't the spec.
>
> --
> Andy Mabbett
> Say "NO!" to compulsory ID Cards:  
> <http://www.no2id.net/>
>
> Free Our Data:  <http://www.freeourdata.org.uk> 
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Andy Mabbett
In message
<[EMAIL PROTECTED]>, Benjamin
West <[EMAIL PROTECTED]> writes

>> You forgot:
>
>Actually, I was summarizing and synthesizing, not forgetting.

The "you" was collective.

>>* Veteran Experts
>>  * Looking for new things
>>  * Might be looking/adopting things for the sake of coolness/newness
>>* uF's seem new and cool?
>>  * Probably little exposure to uF (did they see it mentioned in a
>> blog, search, or conference?)
>>
>> * Bleeding Edge Adopters
>>  * Fulfilling obligations from above
>>  * Trusted expertise for business decisions
>>  * Referred from a non-expert source to check viability
>>
>> HTH
>
>I'm not sure this helps.

I'm sure it does.

>This essentially washes out the picture of two types of users.

Perhaps; though it chiefly avoids the useless labelling of them. Or do
you have evidence that "veteran experts" never look for new things, or
"bleeding edge adapters" never fulfil obligations for above?

For that matter, do you have evidence that "veteran experts" cannot also
be "bleeding edge adapters"?

>My approach to this is to identify differences, although subtle,
>between users in order to better understand what kinds of resources
>would be most helpful.

Then don't lump them together under stereotypical headings.

>I'm a little confused about what you are suggesting.

I'm suggesting that there's no need for ageist (or any other form of
unfounded-, and discriminatory-) stereotyping.

>Can you elaborate?

See my reply to the same post, by Justin Thorp, to which you were
replying.

>My current thoughts are that you meant either to say that
>there is only one type of new user, or that the list proffered is
>useless.

Of the two, the latter is closer to the mark, but not very.

>Then again, I'm not a mind reader,

I knew you were going to say that.

>so feel free to correct me.

I always will ;-)
-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Mike Schinkel
>> 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: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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 

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

2006-10-18 Thread Benjamin West

>
>I'm not sure this helps.

I'm sure it does.


heh


>This essentially washes out the picture of two types of users.

Perhaps; though it chiefly avoids the useless labelling of them. Or do
you have evidence that "veteran experts" never look for new things, or
"bleeding edge adapters" never fulfil obligations for above?

For that matter, do you have evidence that "veteran experts" cannot also
be "bleeding edge adapters"?


No need.  No such claims were made.


>My approach to this is to identify differences, although subtle,
>between users in order to better understand what kinds of resources
>would be most helpful.

Then don't lump them together under stereotypical headings.


Huh? This doesn't make any sense.


>I'm a little confused about what you are suggesting.

I'm suggesting that there's no need for ageist (or any other form of
unfounded-, and discriminatory-) stereotyping.


Now I'm more confused.  No one claimed for such a need.


>Can you elaborate?

See my reply to the same post, by Justin Thorp, to which you were
replying.


There was no content in that post.


>My current thoughts are that you meant either to say that
>there is only one type of new user, or that the list proffered is
>useless.

Of the two, the latter is closer to the mark, but not very.


Then try building consensus or synthesizing new ideas.  Otherwise this
is a tremendous waste of time.  What actions should we take from your
"suggestion?"  If we are ageist as you claim, then we desparately need
your help and guidance, not just accusations.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Tantek Çelik
On 10/18/06 4:04 PM, "Mike Schinkel" <[EMAIL PROTECTED]> wrote:

> 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 is an excellent point Mike, and one I strongly agree with.  I have
taken it to heart and will seek to simplify/reduce the text on intro type
pages as much as possible without losing meaning/utility.

> Again I agree. I think specs are *the most important thing* to one class of
> people, i.e. those specifying the spec.

That's actually not true.  The spec is the most important thing to people
*implementing* the spec.  Implementers need to be able to read very precise
descriptions of what they are implementing in order to maximize the chances
of them implementing it correctly and interoperably.

> 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].

Strongly agreed.

Thanks for this feedback Mike - you make very good points.

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Mike Schinkel
>> We can't expect people to use something for which there is no spec!

And we can't expect a form to be developed when there isn't a spec either.  

>>>>  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.
>> Agreed. Did I say otherwise?

My memory was that you did.  If you didn't, then forgive me for bringing it
up.

>> Indeed. Did I ask for "content for content's sake"?

Honestly, as we are now spending more time on discussing our discussions, I
am starting to think we are just debating for the purpose debate. I think
it's time to wind down (my participation in) this thread.

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy
Mabbett
Sent: Wednesday, October 18, 2006 5:40 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

In message <[EMAIL PROTECTED]>, Mike Schinkel
<[EMAIL PROTECTED]> writes

>>> I don't think anyone has said that. I certainly don't think people 
>>> should
>be encouraged to begin authoring before first understanding what the 
>are nad are not "allowed" to do (unless by "authoring" you mean "fill 
>in a form and let a machine do the authoring for you")
>
>A form would be nice,

It might be; note that I wasn't calling for one.

> but it takes time to develop and we can't expect they will be 
>developed before people are interested.

We can't expect people to use something for which there is no spec!

[...]
>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?

Yup.

>  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.

Agreed. Did I say otherwise?

>>> 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]."

What, again?

>  Content for content sake is less than useful.

Indeed. Did I ask for "content for content's sake"?

>>> Once they standard is set, the brainstorming (and related examples) 
>>> is
>only of archival interest.
>
>Note that I said my list was just a set to start discussion

Note that I was discussing it.

>>> I note that your list does not include an explanation of Semantic
>XHTML...
>
>Again, as I said, my list was just a set to start discussion...

Note that I wasn't criticising you for omitting it.
--
Andy Mabbett
Say "NO!" to compulsory ID Cards:  <http://www.no2id.net/>

Free Our Data:  <http://www.freeourdata.org.uk>
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Benjamin West

The point is there isn't necessarily one for a new spec. Until someone
builds one.

No worries here.  I'm commited to doing this.  See my todo list.  Is
there any that are missing?


So my point was I wouldn't see a generators/creators as the
entry point for a microformat, that's all.


Ah, ok.

Summary:
* Support Scanning
* Don't overwhelm with resources/text
* Provide strong scents for where relevant information lives.


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


Building consensus and making sure we understand one another isn't a
waste of time.  But now that we all agree, let's please start taking
notes and mentally sifting through everything.  Do you think you can
do a refinement of your categories on the to-do list?  Can you also
enumerate the categories of content generally available on the wiki?

I'm thinking:
* Advocacy of Best Practices
( Do we really want to do this? there are other places that do this)
* FAQ
( Both general and specific to each format.  how do we present this?)
* Spec Materials
(Landing page, getting started, guides, and spec.)

Can we somehow fit all the content on the wiki into these areas? Would
it address the concerns on the wiki-feedback page?  Are there
categories missing?

Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Mike Schinkel
Justin:

Very good organization!
JMTCW.

-Mike 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Justin
Thorp
Sent: Wednesday, October 18, 2006 4:57 PM
To: microformats-discuss@microformats.org
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

Ben,

I will try and get to the IA page tonite and see if I can add some comments
and thoughts.

I think the people reading the articles about microformats and jumping into
the spec cold are the early adoptor web developers.  My uneducated opinion
is that microformats is a fairly new movement.  

Regardless, it seems like it would be in the best interest of what we are
trying to do to write all of our stuff and organize it so that it also works
for the 50 year old web systems programmer who may be slow to adopting
(stubborn) new technologies but was told by his boss he has to look at the
business applications of adopting microformats.

If I land on Microformats.org for the first time, just wanting to learn, I
am going to be looking for something that says intro or new or tutorial.  It
needs to answer the who, what, when, where, why, and how.  It shouldn't use
jargonny language.

If I am new and reading about hCard or hCalendar for the first time.  I want
to figure out BRIEFLY what the background is.  I don't need a history of
vCard.  I'd want some examples.  Id want to know about what sites use them.
I'd want tools to help build them.  Id want a list of all the different
class names and where I can and can not use them (the rules).  I'd leave
semantic principles in a doc that you can link to. Maybe mention it briefly.

Hope this helps.

Cheers,
Justin Thorp


**
Justin Thorp
Web Services - Office of Strategic Initiatives Library of Congress e -
[EMAIL PROTECTED] p - 202/707-9541

>>> [EMAIL PROTECTED] 10/18/06 12:59 PM >>>
Justin,

Would you mind visiting
<http://microformats.org/wiki/to-do#Information_Architecture> and adding
your support?

While we're on the subject of newbies, if they first hear about microformats
from the sources you mentioned, what kind of people are they? Are they
graphic designers? Web developers?  Business people?
It appears that microformat newbies are the kind of people that go to
conventions.

What do these people expect when they visit for the first time?  Most web
browsing is task-oriented.  Do they want to find out how to author
microformats?  Learn more about what they are?  Find out why they exist?

Ben

On 10/18/06, Justin Thorp <[EMAIL PROTECTED]> wrote:
> I really like this idea.  What if the landing page for the microformat
wasn't the spec but it was some warm and fuzzy intro for newbies?  It could
then link to the spec for those that were interested to it.
>
> A good example of this would be the W3C WAI's intro for WCAG that they
give you before you get sent right into WCAG 1.0.
> http://www.w3.org/WAI/intro/wcag
>
> I would expect that a lot of newbies start off hearing about microformats
on tutorials like:
> http://www.digital-web.com/articles/microformats_primer/
> http://www.thinkvitamin.com/features/design/how-to-use-microformats
>
> Or from presentations like:
> http://tantek.com/presentations/2006/09/microformats-practices/
>
> They get linked to the spec and then get offly confused.
>
> -justin thorp
>
> **
> Justin Thorp
> Web Services - Office of Strategic Initiatives Library of Congress e - 
> [EMAIL PROTECTED] p - 202/707-9541
>
> >>> [EMAIL PROTECTED] 10/17/06 3:39 PM >>>
> In message
> <[EMAIL PROTECTED]>, 
> Benjamin West <[EMAIL PROTECTED]> writes
>
> >Regarding the specs bit, I meant to refer to the various stages of 
> >the process.  The spec landing page might contain the big questions, 
> >with a status section pointing to pages dedicated toward how the spec 
> >is moving through the process, and with the "learn more" section 
> >pointed at the spec itself.
>
> If the "spec itself" is on a secondary page, then the "landing" page 
> isn't the spec.
>
> --
> Andy Mabbett
> Say "NO!" to compulsory ID Cards:  
> <http://www.no2id.net/>
>
> Free Our Data:  <http://www.freeourdata.org.uk> 
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mailman/listinfo/microformats-discuss
>
___
microformats-discuss mailing list
microformats-discuss@micro

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

2006-10-18 Thread Andy Mabbett
In message
<[EMAIL PROTECTED]>, Benjamin
West <[EMAIL PROTECTED]> writes

>> See my reply to the same post, by Justin Thorp, to which you were
>> replying.
>
>There was no content in that post.

Try a working mail client, then.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Mike Schinkel
>> That's actually not true.  The spec is the most important thing to people
*implementing* the spec.  

Opps, you caught my lack of meticulousness!  I was focusing on making the
point that where were many classes of people each potentially interested in
something different and was otherwise being casual. Please forgive my being
careless regarding who was interested in what. :)

>> Thanks for this feedback Mike - you make very good points.

Thanks in return. It is nice to know when one's efforts are appreciated.

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tantek Ç
elik
Sent: Wednesday, October 18, 2006 7:13 PM
To: microformats-discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

On 10/18/06 4:04 PM, "Mike Schinkel" <[EMAIL PROTECTED]> wrote:

> 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 is an excellent point Mike, and one I strongly agree with.  I have
taken it to heart and will seek to simplify/reduce the text on intro type
pages as much as possible without losing meaning/utility.

> Again I agree. I think specs are *the most important thing* to one 
> class of people, i.e. those specifying the spec.

That's actually not true.  The spec is the most important thing to people
*implementing* the spec.  Implementers need to be able to read very precise
descriptions of what they are implementing in order to maximize the chances
of them implementing it correctly and interoperably.

> 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].

Strongly agreed.

Thanks for this feedback Mike - you make very good points.

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Mike Schinkel
>>  See my todo list.

Suggestion: can you be sure to include the actual URL of any referenced item
in any emails to make sure I can actually find it. :)

>> Do you think you can do a refinement of your categories on the to-do
list?  Can you also enumerate the categories of content generally available
on the wiki?

Again, same comment...  And was this for me, or everyone?

-Mike


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Wednesday, October 18, 2006 7:24 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

> The point is there isn't necessarily one for a new spec. Until someone 
> builds one.
No worries here.  I'm commited to doing this.  See my todo list.  Is there
any that are missing?

> So my point was I wouldn't see a generators/creators as the entry 
> point for a microformat, that's all.

Ah, ok.

Summary:
* Support Scanning
* Don't overwhelm with resources/text
* Provide strong scents for where relevant information lives.

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

Building consensus and making sure we understand one another isn't a waste
of time.  But now that we all agree, let's please start taking notes and
mentally sifting through everything.  Do you think you can do a refinement
of your categories on the to-do list?  Can you also enumerate the categories
of content generally available on the wiki?

I'm thinking:
* Advocacy of Best Practices
( Do we really want to do this? there are other places that do this)
* FAQ
( Both general and specific to each format.  how do we present this?)
* Spec Materials
(Landing page, getting started, guides, and spec.)

Can we somehow fit all the content on the wiki into these areas? Would it
address the concerns on the wiki-feedback page?  Are there categories
missing?

Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Tantek Çelik
On 10/18/06 4:54 PM, "Mike Schinkel" <[EMAIL PROTECTED]> wrote:

> Opps, you caught my lack of meticulousness!

No problem at all Mike.  Just want to clear that up. ;)

>>> Thanks for this feedback Mike - you make very good points.
> 
> Thanks in return. It is nice to know when one's efforts are appreciated.

You have made and continue to make well thought out contributions with solid
citations of support for your analysis and conclusions, and with a very
polite and respectful writing style, all of which is greatly appreciated in
this community.

Thanks for joining the list, contributing, and setting a good example.

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Benjamin West

Mike,
But I'm so lazy.  Point taken, I'll include more URI's when I should.

Mike, your comments are under
<http://microformats.org/wiki/to-do#Information_Architecture>.

I did the hAtom creator and am interested in further work on the
creators.  <http://microformats.org/wiki/to-do#Creators>

If there is a creator missing, I'll gladly come up with something.

Ben

On 10/18/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:

>>  See my todo list.

Suggestion: can you be sure to include the actual URL of any referenced item
in any emails to make sure I can actually find it. :)

>> Do you think you can do a refinement of your categories on the to-do
list?  Can you also enumerate the categories of content generally available
on the wiki?

Again, same comment...  And was this for me, or everyone?

-Mike


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Wednesday, October 18, 2006 7:24 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

> The point is there isn't necessarily one for a new spec. Until someone
> builds one.
No worries here.  I'm commited to doing this.  See my todo list.  Is there
any that are missing?

> So my point was I wouldn't see a generators/creators as the entry
> point for a microformat, that's all.

Ah, ok.

Summary:
* Support Scanning
* Don't overwhelm with resources/text
* Provide strong scents for where relevant information lives.

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

Building consensus and making sure we understand one another isn't a waste
of time.  But now that we all agree, let's please start taking notes and
mentally sifting through everything.  Do you think you can do a refinement
of your categories on the to-do list?  Can you also enumerate the categories
of content generally available on the wiki?

I'm thinking:
* Advocacy of Best Practices
( Do we really want to do this? there are other places that do this)
* FAQ
( Both general and specific to each format.  how do we present this?)
* Spec Materials
(Landing page, getting started, guides, and spec.)

Can we somehow fit all the content on the wiki into these areas? Would it
address the concerns on the wiki-feedback page?  Are there categories
missing?

Ben
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-18 Thread Mike Schinkel
>> Point taken, I'll include more URI's when I should.

Thanks.

>> If there is a creator missing, I'll gladly come up with something.

That said, I'll use this as an opening to pose a question that I've been
wanting to pose since I haven't gotten all my thoughts 100% sorted on the
subject, but I can do it less formally tagging onto this thread...

It seems to me that a spec in a "necessary but not sufficient" condition for
maximum adoption.  Additionally I see these things as needed:

* Reference implementation in Javascript for add-ins to web-based text
editors for blog, forum, and wiki software
* Reference implementations in Java, .NET, Ruby, PHP, Python, etc. as
Windows, Mac, and Linux components for add-ins to desktop web publishing
apps 
* Reference implementations in Java, .NET, Ruby, PHP, Python, etc. for
parsing HTML pages in Microformats
* Evangelism to Website owners 
* Evangelism to Software Platform and Tool vendors

I'm sure there are more, but I see these as critical, and I'm not sure what
level of efforts or even awareness there are towards these ends. I'd love to
be involved in some of these efforts although currently I personally don't
have enough consulting revenue to support such efforts and no one is
currently sponsoring me to be involved here (this is just a personal
interest I have.)

What's more, I'm not sure what everyone view the goals of Microformats and
the envisioned use-cases. I'm coming to believe that there are some very
different assumed goals & use-cases among the people in discussions (not
because of anything specific, just a feeling I have.)  Without clarifying
these, I think we'll be at cross purposes long term.

I guess I should probably have started a new thread on this...?

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Benjamin
West
Sent: Wednesday, October 18, 2006 8:08 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

Mike,
But I'm so lazy.  Point taken, I'll include more URI's when I should.

Mike, your comments are under
<http://microformats.org/wiki/to-do#Information_Architecture>.

I did the hAtom creator and am interested in further work on the creators.
<http://microformats.org/wiki/to-do#Creators>

If there is a creator missing, I'll gladly come up with something.

Ben

On 10/18/06, Mike Schinkel <[EMAIL PROTECTED]> wrote:
> >>  See my todo list.
>
> Suggestion: can you be sure to include the actual URL of any 
> referenced item in any emails to make sure I can actually find it. :)
>
> >> Do you think you can do a refinement of your categories on the 
> >> to-do
> list?  Can you also enumerate the categories of content generally 
> available on the wiki?
>
> Again, same comment...  And was this for me, or everyone?
>
> -Mike
>
>
> -Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Benjamin West
> Sent: Wednesday, October 18, 2006 7:24 PM
> To: Microformats Discuss
> Subject: Re: [uf-discuss] hCalendar spec- no specification included!
>
> > The point is there isn't necessarily one for a new spec. Until 
> > someone builds one.
> No worries here.  I'm commited to doing this.  See my todo list.  Is 
> there any that are missing?
>
> > So my point was I wouldn't see a generators/creators as the entry 
> > point for a microformat, that's all.
>
> Ah, ok.
>
> Summary:
> * Support Scanning
> * Don't overwhelm with resources/text
> * Provide strong scents for where relevant information lives.
>
> > And sorry if I'm overstating that which everyone may already be 
> > agreeing
> on.
>
> Building consensus and making sure we understand one another isn't a 
> waste of time.  But now that we all agree, let's please start taking 
> notes and mentally sifting through everything.  Do you think you can 
> do a refinement of your categories on the to-do list?  Can you also 
> enumerate the categories of content generally available on the wiki?
>
> I'm thinking:
> * Advocacy of Best Practices
> ( Do we really want to do this? there are other places that do this)
> * FAQ
> ( Both general and specific to each format.  how do we present this?)
> * Spec Materials
> (Landing page, getting started, guides, and spec.)
>
> Can we somehow fit all the content on the wiki into these areas? Would 
> it address the concerns on the wiki-feedback page?  Are there 
> categories missing?
>
> Ben
> ___
> microformats-discuss mailing list
> microformats-discuss@microformats.org
> http://microformats.org/mai

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

2006-10-19 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Mike Schinkel
<[EMAIL PROTECTED]> writes

>I'm coming to believe that there are some very different assumed goals
>& use-cases among the people in discussions (not because of anything
>specific, just a feeling I have.)  Without clarifying these, I think
>we'll be at cross purposes long term.

I think you're absolutely right. It's important to be able to "walk a
mile in the other person's shoes".

We have one 'wiki' page, for instance, which refers to the use of a uF
by bloggers, when the usage described could be by any web publisher, on
any web age, not just a blog.

We have pages which refer to the need to use "Z part of XHTML" when "Z"
is also a component of perfectly acceptable and valid HTML.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-20 Thread Mike Schinkel
FYI, I have in mind a proposed list of goals I plan to send out for everyone
to comment on, but I will be away from the computer for 2-3 days so I want
to wait until I get back.

-Mike

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Andy
Mabbett
Sent: Thursday, October 19, 2006 3:49 PM
To: Microformats Discuss
Subject: Re: [uf-discuss] hCalendar spec- no specification included!

In message <[EMAIL PROTECTED]>, Mike Schinkel
<[EMAIL PROTECTED]> writes

>I'm coming to believe that there are some very different assumed goals 
>& use-cases among the people in discussions (not because of anything 
>specific, just a feeling I have.)  Without clarifying these, I think 
>we'll be at cross purposes long term.

I think you're absolutely right. It's important to be able to "walk a mile
in the other person's shoes".

We have one 'wiki' page, for instance, which refers to the use of a uF by
bloggers, when the usage described could be by any web publisher, on any web
age, not just a blog.

We have pages which refer to the need to use "Z part of XHTML" when "Z"
is also a component of perfectly acceptable and valid HTML.

--
Andy Mabbett
Say "NO!" to compulsory ID Cards:  <http://www.no2id.net/>

Free Our Data:  <http://www.freeourdata.org.uk>
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-10-30 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Andy Mabbett
<[EMAIL PROTECTED]> writes

>I've just been introducing a colleague to the concept of hCalendar; and
>referred her to:
>
>http://microformats.org/wiki/hCalendar
>
>She was baffled; not lest because, though the page had a treatise on
>"Semantic XHTML Design Principles", it didn't list the hCalendar
>fields, let alone say which are mandatory and which are optional!

It's now two weeks since I wrote the above, and nothing has changed.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-01 Thread Benjamin West

It's now two weeks since I wrote the above, and nothing has changed.


Seems like a lot has changed to me.  Lots of people are working on the wiki.
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-02 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>,
Benjamin West <[EMAIL PROTECTED]> writes

>> It's now two weeks since I wrote the above, and nothing has changed.
>
>Seems like a lot has changed to me.  Lots of people are working on the wiki.

You snipped my quote of my original post:

>>>I've just been introducing a colleague to the concept of hCalendar;
>>and
>>>referred her to:
>>>
>>>http://microformats.org/wiki/hCalendar
>>>
>>>She was baffled; not lest because, though the page had a treatise on
>>>"Semantic XHTML Design Principles", it didn't list the hCalendar
>>>fields, let alone say which are mandatory and which are optional!

Here's the "diff" from the 'wiki', from when I wrote that, 'til now:



Perhaps you could point where in the small amount of new material the
hCalendar fields are listed, and where those which are optional are
identified?


-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-13 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Andy Mabbett
<[EMAIL PROTECTED]> writes

>In message <[EMAIL PROTECTED]>, Andy Mabbett
><[EMAIL PROTECTED]> writes
>
>>I've just been introducing a colleague to the concept of hCalendar; and
>>referred her to:
>>
>>http://microformats.org/wiki/hCalendar
>>
>>She was baffled; not lest because, though the page had a treatise on
>>"Semantic XHTML Design Principles", it didn't list the hCalendar
>>fields, let alone say which are mandatory and which are optional!
>
>It's now two weeks since I wrote the above, and nothing has changed.

Another two weeks have passed...

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-14 Thread Colin Barrett

On Nov 13, 2006, at 1:28 PM, Andy Mabbett wrote:


In message <[EMAIL PROTECTED]>, Andy Mabbett
<[EMAIL PROTECTED]> writes


In message <[EMAIL PROTECTED]>, Andy Mabbett
<[EMAIL PROTECTED]> writes

I've just been introducing a colleague to the concept of  
hCalendar; and

referred her to:

   http://microformats.org/wiki/hCalendar

She was baffled; not lest because, though the page had a treatise on
"Semantic XHTML Design Principles", it didn't list the hCalendar
fields, let alone say which are mandatory and which are optional!


It's now two weeks since I wrote the above, and nothing has changed.


Another two weeks have passed...


Who exactly are you expecting to do something about this? I would  
suggest editing the page yourself.

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-14 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Colin
Barrett <[EMAIL PROTECTED]> writes

 I've just been introducing a colleague to the concept of
hCalendar; and
 referred her to:

http://microformats.org/wiki/hCalendar

 She was baffled; not lest because, though the page had a treatise on
 "Semantic XHTML Design Principles", it didn't list the hCalendar
 fields, let alone say which are mandatory and which are optional!
>>>
>>> It's now two weeks since I wrote the above, and nothing has changed.
>>
>> Another two weeks have passed...
>
>Who exactly are you expecting to do something about this?

You tell me...

>I would  suggest editing the page yourself.

I admire your naive optimism (or should that be "your sense of
humour"?):



-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-14 Thread Colin Barrett


On Nov 14, 2006, at 9:32 AM, Andy Mabbett wrote:


In message <[EMAIL PROTECTED]>, Colin
Barrett <[EMAIL PROTECTED]> writes


I've just been introducing a colleague to the concept of
hCalendar; and
referred her to:

   http://microformats.org/wiki/hCalendar

She was baffled; not lest because, though the page had a  
treatise on

"Semantic XHTML Design Principles", it didn't list the hCalendar
fields, let alone say which are mandatory and which are optional!


It's now two weeks since I wrote the above, and nothing has  
changed.


Another two weeks have passed...


Who exactly are you expecting to do something about this?


You tell me...


I would  suggest editing the page yourself.


I admire your naive optimism (or should that be "your sense of
humour"?):




Well, you've been waiting for a month, and nobody has raised  
objections, so I would say go ahead. If someone suddenly starts  
caring, well, it's a bit late.


Take the initiative, like you did with species. :)

-Colin
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-14 Thread Tantek Çelik
On 11/14/06 1:33 PM, "Colin Barrett" <[EMAIL PROTECTED]> wrote:

> 
> On Nov 14, 2006, at 9:32 AM, Andy Mabbett wrote:
> 
>> In message <[EMAIL PROTECTED]>, Colin
>> Barrett <[EMAIL PROTECTED]> writes
>> 
>> I've just been introducing a colleague to the concept of
>> hCalendar; and
>> referred her to:
>> 
>>http://microformats.org/wiki/hCalendar
>> 
>> She was baffled; not lest because, though the page had a
>> treatise on
>> "Semantic XHTML Design Principles", it didn't list the hCalendar
>> fields, let alone say which are mandatory and which are optional!
> 
> It's now two weeks since I wrote the above, and nothing has
> changed.
 
 Another two weeks have passed...
>>> 
>>> Who exactly are you expecting to do something about this?
>> 
>> You tell me...
>> 
>>> I would  suggest editing the page yourself.
>> 
>> I admire your naive optimism (or should that be "your sense of
>> humour"?):
>> 
>> > 6.html 
>>> 
> 
> Well, you've been waiting for a month,

Email is a very poor mechanism for archiving/tracking issues.

hCalendar issues may be added to this page:

 http://microformats.org/wiki/hcalendar-issues

> and nobody has raised
> objections, so I would say go ahead.

As cited, there are objections to rewriting/reorganizing fairly established
spec pages without discussion and at least a reasonable resemblance of
consensus.

The key with edits on the wiki, as with any wiki or source control system,
is small contained edits that solve exactly the problem they are meant to
solve, and no more.

Thanks,

Tantek

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-14 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Colin
Barrett <[EMAIL PROTECTED]> writes

>>> I would  suggest editing the page yourself.
>>
>> I admire your naive optimism (or should that be "your sense of
>> humour"?):
>>
>> >er/006396.html
>> >
>
>Well, you've been waiting for a month, and nobody has raised
>objections, so I would say go ahead.

I don't think you're reading the situation correctly.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  
___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


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

2006-11-16 Thread Andy Mabbett
In message <[EMAIL PROTECTED]>, Tantek Çelik
<[EMAIL PROTECTED]> writes

>>>http://microformats.org/wiki/hCalendar

>>>didn't list the hCalendar
>>> fields, let alone say which are mandatory and which are optional!

>hCalendar issues may be added to this page:
>
> http://microformats.org/wiki/hcalendar-issues

And they may be raised on this mailing list; and were, on 16 October
(that's one month ago, today).

>As cited, there are objections to rewriting/reorganizing fairly
>established spec pages without discussion and at least a reasonable
>resemblance of consensus.

If there is no consensus as to what the hCalendar fields are, and which
are mandatory, what are we doing here?

>The key with edits on the wiki, as with any wiki or source control
>system, is small contained edits that solve exactly the problem they
>are meant to solve, and no more.

1. You're either presenting your opinion as fact, again; or simply
inventing facts.

2. Such edits were made:

  

and were reverted by you.

One month on, the issues raised in my original post are unaddressed.

-- 
Andy Mabbett
Say "NO!" to compulsory ID Cards:  

Free Our Data:  

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss