[uf-discuss] Size considerations

[Mike Schinkel]

>> The point I am trying to make is this: file size *is* an issue, but it is
not an insurmountable problem and can be solved through technology and good
design; file size shouldn't compromise the semantics and design of a
microformat.

Since I was the one that originally called the question I want to also point
out that, related to size of the microformat, if a microformat is too
conceptually large (and complex) it is less likely to be applied than if it
is simple and easy. Remember, there are lots of people publishing web pages
that are far from technical... (Sorry if I'm belaboring the point...)

-Mike 

-----Original Message-----
From: microformats-discuss-bounces at microformats.org
[mailto:microformats-discuss-bounces at microformats.org] On Behalf Of Charles
Roper
Sent: Thursday, October 19, 2006 3:41 AM
To: Microformats Discuss
Subject: Re: [uf-discuss] Size considerations

Scott Reynen wrote:
> Who is publishing 10 columns and 100 rows of prices or something 
> similar?  It would be helpful to look at some real-world markup so we 
> can come up with practical ways to address this concern.  If it's in 
> rows and columns, I would assume each price to be in a <td>, so <span 
> class="money"> becomes just <td class="money">, removing 14 characters 
> by my count.  But it's hard to know if this is a realistic assumption 
> when we're dealing with hypothetical markup.

Here's an example of a page that would be made larger if a species
microformat were applied to it that used the longer class names (they're
pretty long already):

http://www.sxbrc.org.uk/biodiversity/speciesinventories/psrlist.php

It's not a great example as it's a short list without much detail. The
scientific community often share long lists such as this, although web users
outside of this field probably don't come across them often. 
HOWEVER, there are design and implementation decisions on my part as the
developer and designer of a site I would take *before* I ruled out using uFs
due to their size. (I would consider 100K to long, btw) These are:

1. I would apply output compression (which I have done in the example above,
taking it from 17835 bytes down to 3972 bytes) 2. If the list were to grow
much longer than it already is, I would consider it a bad fit for a one page
design and redesign with a paging and search mechanism.
3. If #2 came into effect, and visitors required one long list (which I know
they do), then I would offer a variety of download options
*including* the big HTML version.

The point I am trying to make is this: file size *is* an issue, but it is
not an insurmountable problem and can be solved through technology and good
design; file size shouldn't compromise the semantics and design of a
microformat.

--
Charles Roper
www.charlesroper.co.uk
_______________________________________________
microformats-discuss mailing list
microformats-discuss at microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss