Laura Scott's Blog Posts

HTML5 + RDFa = time to get rid of that 20th century furniture

Laura Scott — Tue, 24 Aug 2010 03:20:33 +0000

We're entering a new era of the web. To the ignorant masses, this transition will go largely unnoticed; they'll enjoy increased usability and convenience, with more robust functionality and more relevant data at hand. And they'll mostly just take it for granted.

However, for web designers, front-end developers and data system programmers, we have a lot of work to do.

Why HTML5?

Why indeed? As someone who's worked almost exclusively with Drupal since 2004, my nose has been pretty much in xhtml 1.1. Back then, moving to xhtml took some learning and patience on my part, having played with basic HTML since 1995. Now xhtml feels like the familiar friend and HTML the ugly cousin.

But then I started really looking at HTML5. And the more I am learning about it, the more I am appreciating how HTML5 looks to be a real game-changer.

DOMinate the web

Most of the buzz you see online about HTML5 focuses on the particulars — with the plurality of coverage over how HTML5's media tags stand to push most uses of Flash out to pasture. And that's certainly big.

However, there's something more fundamental in the change HTML5 is bringing to the web. I quote from Introducing HTML5 (Voices That Matter), by Bruce Lawson and Remy Sharp:

Many of our current methods of developing sites and applications rely on undocumented (or at least unspecified) features incorporated into browsers over time. For example, XMLHttp-Request (XHR) powers untold numbers of Ajax-driven sites. It was invented by Microsoft, and subsequently reverse engineered and incorporated into all other browsers, but had never been specified as a standard…. So one of the first tasks of HTML5 was to document the undocumented, in order to increase interoperability by leaving less to guesswork for web authors and implementors of browser.

This is big in itself. But it's not even the biggest thing, imho.

It was also necessary to unambiguously define how browsers and other user agents should deal with invalid markup…. The barrier to entry to publishing on the Web was democratically low, but each browser was free to decide how to render bad code. Something as simple as <b><i>Hello mum!</b></i> (note the mismatched closing tags) produces different DOMs in different browsers. Different DOMs can cause the same CSS to have a completely different rendering, and they can make writing JavaScript that runs across browsers much harder than it need be….

…HTML5 specifies new DOM APIs for drag and drop, server-sent events, drawing, video, and the like. These new interfaces that HTML pages expose to JavaScript via objects in the DOM make it easier to write such applications using tightly specified standards rather than barely documented hacks.

In other words, by clarifying specifics — especially in error handling — HTML5 stands to open the doors for much more efficient and effective JavaScript, heralding a new era for robust interactivity with dynamic interfaces and rich user experiences that would be too heavy and difficult, or impossible, to implement in xhtml or HTML4.

Suddenly that existing markup you have is starting to look kind of musty.

With new language comes new ways of thinking

The other thing to consider is how the web, and the nature of websites themselves, will change as the collective creativity of web designers worldwide starts to not just understand the syntax of HTML5 but also grok on an intuitive, subconscious level how websites can really let go of being collections of pages and embrace their web application natures.

There's a lot of old conventional thinking that is suddenly up for question. For example, while a website as a "navigation menu," an application may instead have a "toolbar": Does that change how you think about those links at the top of your page? People may be less interested in browsing, more interested in searching: Does that affect the role the search form plays in your interface layout?

Of course, for those of us who've been working building software-driven sites (you know, the "Web 2.0" things), this kind of thinking may have been percolating for a while.

Hopefully we'll also have learned the lessons taught by the untold numbers of Flash website designers, who gave us splash pages, annoying, gratuitous motion effects (with obnoxious sound effects), and user interfaces more focused on dazzling the user with the creator's cleverness rather than on serving the user with an interface that serves the user's needs. Here's hoping that HTML5 does not bring us into a new age of craptastic blinky poppy wooshy buzzy design.

HTML5 and Drupal

The Manifesto: http://groups.drupal.org/node/82664
HTML5 Tools module: Module: http://drupal.org/project/html5_tools
A base theme: http://drupal.org/project/html5_base
Another effort: http://drupal.org/project/boron
And http://drupal.org/project/html5
The community discussion: http://groups.drupal.org/html5 & in IRC at #drupal-html5

This is a lively and ongoing process that, so far, has ~~few allies — mostly I think because of the relative obscurity of HTML5 and the design affordances it brings in relation to the world of PHP/Drupal developers. Hopefully that's changing~~ a small but rapidly growing core of themers and developers interested in making this happen, especially in the past few days. Very exciting.

Wither RDFa?

The other side of this revolutionary coin (how many metaphors can I mix into this post?) is the growth and real-world application of RDFa.

In case you didn't know it, RDFa is already here. Google is consuming it where it finds it, using it to generate more accurate and relevant search results. Best Buy is now famous for having enjoyed a 30% increase in sales since incorporating RDFa into their online shopping site.

Robots speaking in complete sentences

That's the net effect of RDFa. You see, currently hyperlinks, to robots, are analagous mystery meat navigation. To the human reader, the nature and location of a hyperlink may make total sense in context — even the mouse-over reveal of the hyperlink URL can yield meaning to us cerebral bipeds. But all a plain hyperlink says to a robot is "follow me." The robot doesn't know who made the link (or the destination site), what the destination is, why the link is there — just where the link is going, and that only by its URL.

RDFa changes that by providing syntax, often abbreviated and/or abetted by libraries such as Dublin Core, to add meaning to the link.

Excuse me, did I say something?

One event happening (almost certainly) this year that could make for some very interesting RDFa developments will be the launch of Drupal 7. Historically, the Drupal user base, community and number of downloads have doubled with each major release of Drupal. And there are a number of factors that suggest that Drupal 7 will be no exception.

What's interesting about this is that Drupal 7 core implements RDFa. This means there are going to be umpteen oodles of websites and web apps out there talking RDFa — and, for most of them, without understanding the language. The amateurs are going to be joining the RDFa party. And that could become cacophonous.

This can mean an RDFa-enabled Tower of Babel. And that prospect has prompted some skeptics to argue against the semantic web. As they see it, we should make robots understand how we make the web, rather than try to remake the web so robots understand. It's an interesting topic, and I recommend Kate Ray's short video on the subject:

[Source: Web 3.0, on Vimeo

From where I sit, perhaps the ideal falls somewhere in a combination? There's no question that Open Data, for example, benefits from semantics. But on the other hand, it would be great to develop parsers that can interpret in existing contexts the underlying semantics of existing content, much like HTML5 provides for the kinds of sloppy markup errors that happen in the web (especially with user-generated content).

Nevertheless, it's hard to dismiss the potential of RDFa when there are be thousands of web developers bringing their creativity and initiative to the rave. For example, in Drupal, one project with interesting potential is AutoRDF, a Google Summer of Code project by Tushar Mahajan, that promises to "automatically tag node content. It will find important words and patterns in a node to tag important keyword and Rdf'ing it. It will build a taxonomy tree."

The SPARQLy Views

The fact that Drupal 7 will play a role in this democratized explosion of RDFa-related endeavors is itself very exciting. And that's not just in the RDFa structure on publishing content, but also in reaching out and pulling in structured RDFa data from elsewhere.

In other words, the web can be like one big website. Jane's site could query Joe's site's data without having any direct access to Joe's database.

One example is the a module (still in development) that leverages the power and flexibility of the Views module to consume and present SPARQL query data.

The SPARQL Views module by Lin Clark will likely be a first introduction for many to the kinds of wondrous things RDFa on the web can enable. Its drag-and-drop query builder will empower people with ability to plug SPARQL queries into Views for customized presentation. Awesome! (Disclosure: I am a Google Summer of Code mentor on this project, so feel free to take my enthusiasm with a grain of salt.)

I want my SEO

Ultimately a — if not the — big convincer for adoption of RDFa will be its effectiveness in getting content noticed. Years ago, Drupal seemed natively and naturally to beat other CMSs when it came to SEO. Drupal sites rose quickly to the top. Will it happen again with Drupal 7 and RDFa? We assume so, but the proof is in the results, and those are still many weeks, perhaps months, away yet.

But imagine what the web will be like when so many sites can be queried and polled from the outside. Information is power, shared information is empowering. When the World Wide Web becomes the World Wide Database, watch out. We'll look back at 2010 as the quaint time of horse and buggy.

Out with the old, in with the new

What this all means is that change is upon us. And all of us web designers, programmers, database administrators, information architects, strategists, and front-end developers need to get busy. We have some learning to do. Some new skills to perfect. Some new thinking to explore. Some new best practices to embrace.

The end user may not really notice as these improvements in user experience roll out. But the end user will notice if you're not rolling with these improvements. Just as a "Web 1.0" site from 1999 stands out to us today as an archaic relic, today's "Web 2.0" sites are going to feel very outdated a few years from now. And just as sites with table-based layouts or built in Flash can make for frustrating user experiences (or out and out inaccessibility) on today's delivery platforms like handhelds and tablets, websites built without the front-end affordances made possible with HTML5 may seem limited to end users, and websites without semantic metadata layers on their content may come off as rather opaque.

As a Drupal aficionado, I'm delighted to have Drupal 7 leading the way on RDFa. However, Drupal is still deeply entrenched in xhtml. The HTML5 phenomenon, while a long time coming, really sparked to life only in the last year — too late to be embraced and incorporated into Drupal 7's core.

But perhaps that's a good thing, because things can happen rapidly in Drupal contrib, and HTML5 is still evolving. So there's a new HTML5 working group on g.d.o to drive towards an HTML5 module (to transform all the markup of Drupal into HTML5-valid code) and an HTML5 base theme.

It's all very exciting. We are in interesting times. Don't stand still. The Drop is always moving.

For further reading:

If you're an Amazon shopper, here's a handy link to Lawson and Sharp's excellent book:

Floater Theme to get away from columns

Laura Scott — Sun, 25 Jul 2010 22:15:04 +0000

As a part of wanting to throw out some of the outdated design furniture of the 20th century, I created a new theme to simply float content elements against each other.

Contributed in a stripped-down version to the Drupal community as the Floater Theme, this theme is about embracing the various kinds of devices and resolutions which people use to access the web. After all, your site could be viewed on a little crap handheld or a big screen 2550 pixels wide. And in theory you want everyone to be able to see what you're offering.

This screenshot is from the soon-to-be-launched LauraScott.net

The first Alpha 1 release of this theme for Drupal 7 has just a few basics:

The main content area is a fixed width.
Blocks in the "right sidebar" (as Drupal 7 currently calls the region) are of fixed width and height, so they float cleanly and line up well with the content.
Narrower-resolution screens get an alternative stacked layout of all the content.
Generic styling (assuming the primary use case will be using this theme only as a base theme).

Once Drupal 7 stabilizes into a Release Candidate, I plan to step into the regions definitions and simplify the regions in this theme. I've generally stayed away from all that for now simply because there's still too much change happening in Drupal 7.

I've been working with Drupal nearly six years now, designed and created dozens of Drupal themes, helped people with theming questions in IRC, and presented on Drupal theming at DrupalCons, but only now have I risen to the CVS challenge and contributed a theme (or any project). CVS is that notorious bugaboo (and barrier to entry) for many designers, but even so I don't know why CVS daunted me so much. I used Subversion (which is quite similar) for years. At PINGV we use Git for versioning. Even so, I was tempted to just wait until the Drupal community gets onto the Git footing later this year.

But today I decided I'd waited long enough. Too long. So there it is. I hope people like the theme. At this point, I have no firm plans on where to take it in terms of features and characteristics. I'm open to ideas.

What's your brand? Do you have a brand? (Do you want one?)

Laura Scott — Tue, 06 Jul 2010 13:01:27 +0000

In The Rhetoric of Fiction, the late Wayne C. Booth discusses a concept of the "implied author."

The implied author, according to Booth, is a "second self" from the actual historical person who wrote the work in question, not the flesh-and-blood being but a hypothetical entity that includes "not only the extractable meanings [of the text] but also the moral and emotional content of each bit of action and suffering of all the characters" (73). To rely solely on extratextual sources that will verify an author’s "intention" is at least problematic, if not a "fallacy." The implied author, though, is a construct prompted by the text itself. The implied author, Booth asserts, is responsible for the "norms" and "values" that seem to be expressed in the work but cannot necessarily be attributed to a narrator and should not be attributed to the historical author.

From "Every Picture Tells A Story: Agency And Narration In Film," Panel: Movies as Paradigmatic Narratives. Modern Language Association Annual Conference, Washington, D.C., December, 2000

In other words, you can't know the "real" author of a book by reading the text. The implied author is the author as perceived by the reader, the audience, based upon perceptions of the text. The implied author is not the same as the actual author. Quite often that's deliberate. But it's also a matter of perceptions, and how imperfect the text can be in communicating intended meaning. All you can do is extrapolate an "implied" author: the person who seems to be who wrote the text. The text is the lens, and who you see as its author is not the same person as the actual author, it's a reflection. A projection.

This concept translates to branding quite easily.

Brand Intentions vs. Brand Perceptions

When we see a disaster like the broken underwater oil well in the Gulf of Mexico, consider that to be "the text." Whether you believe BP or Halliburton or the government is responsible, your perspective of those entities is guided — defined, in fact — by their outward appearances to you. Such views may be closely aligned with the true characters of those entities, or you may be way off. You can't know. We can't know. All we can go by is what we see. The actions. The text. –And third-party descriptions (by the media, friends, persons with axes to grind) of the text. The brand ends up being defined by perceptions, not simply the brand-maker's intentions.

Flip that around now.

How misunderstood does an author feel when her book is interpreted in ways she never intended? Writers will often blame the reader for misunderstanding a text. Samuel Beckett wryly commented, "No pun where none intended." This consummate self-reflexive author who always seemed so aware of the implied author his texts projected would steadfastly refuse to explain his texts, yet seemed not to want to accept it when people took the wrong meaning.

But how can there be no pun where none intended? Whether intended or not, a pun is in the ear of the beholder. If there's a pun, and nobody's around to hear it, is there a pun after all?

And yet, and yet, Beckett's work was about how author and implied author were rarely, if ever, the same. Take the opening lines of Worstward Ho:

On. Say on. Be said on. Somehow on. Till nohow on. Said nohow on.

Say for be said. Missaid. From now say for missaid.

To be said. To be missaid. Your intentions are for naught.

Let's take this back to brands. No matter what a company may intend, what people react to is the company they see through an imperfect lens, colored by their biases, attitudes, expectations, prejudices, politics.... What they react to ends up defining the brand. It ends up being the brand.

The brand is the implied company.

Personal Brands, Personal Intentions

On BlogHer recently, Maureen Johnson declared in her Manifesto:

I am not a brand….

I am not saying that it is a bad or dishonest thing to try to sell your work. It is not. What I am saying is that I am tired of the rush to commodify everything, to turn everything into products, including people. I don’t want a brand, because a brand limits me. A brand says I will churn out the same thing over and over. Which I won’t, because I am weird.

But what Maureen is describing — this churning over and over — is not branding, this is factory work. Branding is not about being a factory. Branding is about being aware that you have an image, and that image may have little or nothing to do with who you really are. And if you have a reality out there where people don't know the real you, just this impression of you from your logo and/or ads and/or website and/or blog and/or tweets and/or news profile, guess what!

You have a brand. Or at least an implied you that is not your own real you.

Maureen's manifesto starts off:

The Internet is made of people. People matter. This includes you. Stop trying to sell everything about yourself to everyone. Don’t just hammer away and repeat and talk at people -— talk TO people. It’s organic.

I agree. But that is not a negation of branding.

But I will say that even the most seemingly transparent, honest, heart-opening writer ends up projecting an image that is only a facsimile of the actual person doing the writing.

Call it a brand.

Call it an implied author.

Call it an image.

A rose by any other name smells just as sweet. So let's cut the baloney.

(To be fair, Maureen's post seems to be, at least in part, a rebuttal to a woman who, as she describes her, could play straw-woman in any branding discussion — huckster, pushy, microphone hog.)

Brands have a way of happening whether you want them to or not. It's not about selling. It's about perception.
Fake Brands Image by Chuck Coker

Tara Hunt, in a blog post last year, takes a slightly different tack:

We talk about authenticity, but people rarely want to see the negative side of a person. When I’ve been truly honest – angry, sad, scared, belligerent, grumpy, negative, depressed or anxious (and I keep it under control, but I have terrible anxiety) – people get nervous. I lose followers. I get long emails from people asking me to stop being self-indulgent. I get messages from concerned friends saying, “Don’t you worry about damaging your brand?”

And that’s it. Do we want authenticity? Or do we want branding? One of the most memorable lines in a movie for me is from Magnolia, where Claudia says to Jim:

“I’ll tell you everything, and you tell me everything, and maybe we can get through all the piss and shit and lies that kill other people. ”

I love that line because I think it’s what we all want to do, but are afraid to do it. We love people who represent the ideal, the perfect, the imperfectly perfect, the happy, the successful, the amazing, positive, go-for-it, wa-hoo in life. And I’m not saying those people don’t exist. They just don’t exist as much as we think they exist because there are so many bloomin personal brands out there that are inspiring the crap out of us that we lose the fact that behind the scenes, they are probably falling apart now and then….

I don’t have a personal brand, I have a personality – complete with crazy moments and drunken nights, super highs and heartbreaking lows. And every single one of those moments define who I am. Now. Who are you? A personal brand or a personality?

Tara's awareness that the image we project, or even the image simply perceived by others, can be at odds with the real us, gets at part of what I'm saying. She rejects the word "brand," but is a "personality" as perceived by others really that much different? Especially when you consider that brands can have personality?

Of course we are more than our public persona. That's true for everyone — even companies … even BP.

But maybe the issue, then, is not about whether we have a "brand" but rather how authentic is our brand. How much does your "brand" — your public image, your persona, your personality as perceived by others — truly reflect who you really are?

And is that even the goal? Do we really want everyone to know about our phobias, our weaknesses, our cravings, our petty jealousies, our financial worries, our medical concerns, our family aggravations? If I know all about the fungus between your toes, do I now know the "real" you? Or does that fungus just distort my image of you? To you, that fungus may be a minor pain in the arse annoyance, but to me, if every time I see you I think about the fungus between your toes, am I now seeing the real you?

My point is that what you choose to project ends up influencing how people perceive you. And being more "honest" or "transparent" is not necessarily going to lead to people seeing the real you. Or liking you more. Or even understanding you better.

The Unnamable

When Samuel Beckett said, "No pun where none intended," he was in effect declaring that critical interpretations, or for that matter any reader's views, of his text were secondary to his own intentions. He was, in a way, trying to take charge of his image, his brand — even while he generally shunned publicity. For him, greater transparency in his life did not mean he would enjoy a truer public image. The uncontrollable nature of identity as perceived worked at the center of his writings. And if you'll forgive me one more quotation, Beckett touches on this theme in the opening paragraphs of The Unnamable:

I am not I.

Or: I am not the "I" you read here.

Doc Searls writes, in Brands are Bull, that brands are by definition non-human:

The man is not only the closest any golfer has ever come to walking robotics, but his whole golf persona has always been remarkably mechanical as well.

Turn a person into a brand [emphasis mine], and what do you get? Something incomplete at best, and fake at worst. Borrow that human brand to represent your company, and you take some risks. Your branded celebrity might actually be a fine human being. Or they might be a philandering scumbag. Either way, the brand is a paint job. It’s not real except in the commercial dimension, and only in a narrow way even there.

The only advertiser that has stuck with Tiger since the bimbo bombs started going off is another landmark brand: Nike. The latest Nike/Tiger ad features the golfer’s sad face, staring at the camera, while the voice of his dead father speaks. “I want to find out what your thinking was,” Earl Woods says.”I want to find out what your feelings are. And did you learn anything.” Well, one thing the rest of us learned was that Tiger was with one of his mistresses on the night he got word that his father had died.

To me, this only emphasizes that you can't always control your brand. Accenture and Nike did not turn Tiger Woods into a brand. Tiger Woods already was a brand. These two corporations simply tried to hitch their brands onto the shining image of Tiger's own brand. That they suffered when Tiger's brand crashed and burned is merely guilt by association.

Every professional athlete is a brand — not because they are selling something (even if they are), but because they have public images driven by media, surrounding hype, lockerroom talk, as well as their own actions, interviews, tweets, whatever.

And when you pull the scope back from the spotlight and turn it on "regular" folks, the same is true — not on the same level, but still true. We have reputations, grades in school, credit ratings, driving records, things people say about us, perceptions drawn from things we do (almost always taken devoid of a larger context). Don't call it a brand, call it an image, call it a reputation, call it buzz, call it karma — it's expressing the same thing.

We are not our image. Our image to others is not necessarily similar to who we really are. And if not, the problem may not be not enough transparency but perhaps the wrong transparency, or too much surrounding noise.

Or poor management of getting out your message, whatever it is, in business or in your personal life.

The Bigger Picture

All this is not to say that we should focus on brand at the exclusion of all else. There's no question that, in our culture, there seems to be a real obsession with brands. For example, in politics one could say the mainstream media have been focusing on political brands far too much, when you consider things like the press coverage of the recent national healthcare reform debate in Washington, which a recent Pew study found:

Fully 41% of health care coverage focused on the tactics and strategy of the debate while various reform proposals filled another 23%. But only 9% of the coverage focused on a core issue -- how our health care system currently functions, what works and what doesn't.

For which we can all collectively thank the press for focusing on brand battles rather than what the legislation was actually about. (How many of us understand that even now?)

No, focusing on brand is not the only thing.

But it's something to be aware of. Even if you don't want one.

KIT: Best Practices for Making Drupal Features

Laura Scott — Mon, 07 Jun 2010 15:12:25 +0000

So you're building a Drupal Feature! Woohoo! Okay, so…. What to include? What to leave out? How to structure the thing so it doesn't conflict with other Features? How to avoid known issues? Where to start?

When, in theory at least, you can make an entire site into one big Feature, these questions become extremely important.

If you're using Features simply to help facilitate your own site-building workflows, this may be something you can pretty much ignore. When dealing with Features you've made for yourself, you may remember your thinking, you may follow your own logic, you may be using Features as a blobby deployment system for all kinds of stuff glommed together. Whatever works. It's all good.

But that approach won't fly with publicly shared Features. In fact, it won't work too well for teams either, probably. Without best practices, clearly laid out and understood by all, Features can trend towards amorphous nightmares. Features might conflict with each other, undoing each other. Improperly utilized, Features can easily become a nightmare that slows you down, undoes your hard work, and leaves you ready to scream and throw your computer out the window.

Enter KIT

The KIT Specification clearly lays out requirements for building clean, discrete Features.

This document provides recommendations and requirements for Drupal features to ensure the interoperability of features between different distributions and prevent conflicts between features themselves and between a compliant feature and a distribution….

–KIT Feature Specification 1.0-draft

The specification goes through terminology, namespaces, inclusion of user roles and permissions (and what not to include), working with variables, paths and menu items, blocks and dependencies.

Not all Features have to be KIT compliant, of course. But having a good, clear specification for self-contained Features that mostly likely will not break other things in your site is a great thing.

If this topic interests you, be sure to visit the KIT issue queue, where there are several discussions on clarifying, adjusting and improving the KIT spec. Good stuff is happening.

Announcing our Feature server: downloads.pingv.com

Laura Scott — Sun, 06 Jun 2010 22:49:39 +0000

Over the weekend we launched a Feature server at http://downloads.pingv.com.

Currently it has but one simple Feature: an initial release of "Photo Essay," for posting images inline in the text of an essay. We hope some people may find it useful. Or informative. Or inspiring to go make their own Features.

We see a bright future for Features. As strategists and designers, we embrace systems and practices that increase the speed and efficiency of development. Features are a great way for people to be able to mix and match components to build sites to suit their needs, without having to install and configure everything by hand, and without needing to embrace a whole website strategy inherent in a full-blown Distribution.

This is a new area of growth and rapid change in the Drupal community. It's very exciting.

So far it seems like most of the Features that people have released are designed to serve use cases more on the advanced, complicated side — with a goodly proportion of those targeted specifically for installation in Open Atrium, which in many ways has been the proof of concept for Features in the first place.

We feel there's room for Features solving more basic and common use cases, to encourage more site builders to try them out and (hopefully) get hooked on the concept. Features may seem to some like stuff for experts to dabble with, but Features are for everyone. Features can make things easier.

Features are fully formed, preconfigured functionality that can be "plugged in" to Drupal.

We had wanted to do this server months ago — soon after starting up the new company — but the best laid plans of mice and cats and all that…. Anyway, when we finally got around to it, the handy Feature Server profile shared by Development Seed made the setup easy. We also ended up building the site on Pantheon using a sweet Linode StackScript written by Justin Ellison, which worked really well. Yes, Pantheon is total overkill for a small Features server, but it was there, so what the heck! When we have more than one Feature, maybe it will make sense to let loose the SOLR search.

Other Feature Servers

There are a few Feature servers out there, but so far there doesn't appear to be any comprehensive list anywhere, and as far as I know no p2p way for them to discover each other.

Here are some directories I've found:

Directory of Public Features Servers: A wiki page with links to servers and projects, posted on Groups.Drupal.org in the Packaging & Distributions group.
Community features: A wiki in the Open Atrium Community site, with links to many features for Open Atrium.
community.featureservers.org: A community Features server and directory hosted by Miguel "mig5" Jacq.

Are there other resources? Please share them in comments and I'll update this post.