[uf-discuss] FYI: ModuleT Is Live

[Kevin Lawver]

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
> ryan at technorati.com
> 
> 
> 
>