Ryan King wrote:
On Jan 18, 2006, at 9:32 AM, Kevin Lawver wrote:
Hey all,
We finally got our developer site launched with our microformat
for describing "modules" (widgets, gadgets, doo-dads, gee-gaws, etc).
We incorporated all the feedback we got from the list into the current
version, and think it's working really well so far for creating and
deploying modules. We're looking for feedback so if you've got a
couple minutes, please go check it out: http://iamalpha.com.
Its great that you guys are able to get this out from behind the
firewall (so to speak). And its really great to see you guys willing and
open to take feedback.
I know I've looked at the profile before, but reading it now I have some
new bits of feedback (shoulda thought of them earlier):
1. You have:
description
A short, user-readable (ie: not overly technical) description of the
module and what it does.
detail
A more detailed description of a module capabilities and requirements.
Why not reuse summary/description, as we have in other microformats? By
reusing you can reduce the vocabulary (total across all µf's), prevent
misunderstandings and use other microformats as normative references
(ie, you don't have to define what a 'description' is, because we
already have that defined elsewhere).
Good point. Will see how much that impacts our module parser and see
if we can get it fixed shortly.
2. You have:
liquid
The module should expand to fill all usable space (ie: it has no set
width)
default-width
The default width, in pixels.
minimum-width
The minimum width, in pixels, the module will fit in.
Aren't these style/presentation issues? In other words, shouldn't these
be taken care of by CSS?
If only they were. We need to know a module's space "requirements"
before we put it on the page. We tried to take our lead from Dashboard
widgets whose plist files have width settings, yet still let the CSS
change that (but not exceeding the initial value). It's so we know how
large to make the thumbnail when dragging the module (not yet
implemented) and how far to expand columns when someone drags a module
over a column.
3. You have:
head
The heading of a module. If your module doesn't have a title or any
heading information, it's not required. This should also be a <div>,
and if it contains heading text, it should be contained in an <h3>.
This class must be within one of the containers: edit or module.
body
This is the "meat" of the module. Can contain any markup, but it
shouldn't reuse the "module", "head" or "body" classes. This class
must be within one of the containers: edit or module.
Eh, I don't understand what's going on here. If I understand things
correctly, these widget/module things are full xhtml documents. So, why
reinvent stuff?
Because there are two distinct pieces of the module: the edit and the
view. Both of them need headings and bodies. The microformat also
doesn't forbid multiple modules in a single document, so we can't just
use title or body. Also, we don't want to dicate that the first heading
element we see in either edit or view will be used as the heading. We
felt that was too limiting.
The other reason was respecting some internal "prior art" with respect
to modules. Our content channels all have modules on them, using mostly
the same convention (right or wrong) and we wanted to keep that in mind.
4. More:
foot
A footer for a module. Must always be within one of the containers:
edit or module.
You might want to look at HTML5 as a place where this is already
defined. Though HTML5 is still a draft, it could still be useful to
borrow its semantics.
I'll take a peek and see what we can use.
5. License:
license
A link to the license for this module.
You should reference rel-license here
[http://microformats.org/wiki/rel-license].
I'm pretty sure we're using rel="license" as laid out in the spec,
we're just not saying that we are. 8)
6. author stuff:
mail
Author's e-mail address, or support address.
author
URL of Author's website.
<address> + hcard ?
Oops, I meant to switch our author stuff for hCard, but forgot about
it. Will fix that shortly.
Once again, sorry for not giving feedback earlier (ie, before you guys
went fully public with this).
You guys really have some cool stuff here and I really hope you can
collaborate with the other widget and module vendors. It'd be shame to
have a proliferation of formats for this stuff (wait, we kinda already do).
There are, but most of them are either non-formats (Dashboard) or, what
feels like, hastily thrown together XML schemas (::cough:: Gadgets and
Google Homepage) that don't express all the things we're looking for.
We tried to keep those in mind when designing ours, but really, they
weren't much help (though they should still be on the brainstorming page).
We wanted a format that would do a couple things:
1. Contain all the info about the module, including either documentation
or links to it, the license and author info.
2. Allow developers to build, test and document their module in the
manifest. It reduces effort on the part of the developer, and makes it
more likely that we'll get good modules.
3. Make it easy for us to rip them apart and get the data out (which
we're doing, and yeah, it's pretty easy).
Thanks for the feedback, and I'll try to get the changes incorporated
quickly.
Cheers,
Kevin Lawver
Keep up the good work!
-ryan
--
Ryan King
[EMAIL PROTECTED]
_______________________________________________
microformats-discuss mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-discuss
