> Could you explain this a bit more? All the Manakin explanations that
> I've looked for have briefly mentioned internationalization and
> corporate branding and then got very technical. Why is Manakin needed
> for this example? What does it provide that Web2 stylesheets / script
> combos can't?

Manakin doesn't magically make possible anything that wasn't before,
so it isn't "needed" as such (and Edward Boyle's tool doesn't use it),
it just makes it easy.

The ability to "brand" different areas of a repository was (as I
understand it) the initial reason for developing Manakin.  It does
this by using Cocoon's pipeline approach, and the Web UI is
essentially created by a series of transforms over the underlying
object.  This makes it very easy to, say, restyle the pages for
collections and items that originate from a particular department or
school, but also to introduce new UI tools based on what the
underlying object(s) is/are and the data present therein.  So, if you
have objects with geo data in, all you have to do is drop in a
transform that pops that geo information into an AJAXy Maps widget and
you have a compelling new way to visualise and explore the data.
Manakin is kind of the "glue" for this.

> - Is there a practical limit on the scalability of web 2.0 or the
> graphical display that puts a limit on the applicability of the
> technique - the URL that you gave shows a map with 11 items, but
> displaying a map with the whole collection (200+ items) takes about
> 30 seconds to display. Also the map becomes very overcrowded. Do you
> have any suggestions about the best way of deploying these techniques?

When network transfers are involved there are always scalability
limits but these can be worked round.  E.g. instead of displaying 200
items on a map, you could page through (a la  search results on
maps.google.com), or perhaps you could glob together clusters of
points that are close together on a broader map which only appear
individually when you zoom in.

If these kinds of interfaces become more common, the upshot for the
developers of repository software may be that they may have to support
smarter network APIs that can selectively serve up portions of data,
you might not be able to send you whole repo's data to the client --
i.e. start thinking about the server side of AJAX.  I'm sure we can do
a lot without going that far though and it won't only be the
diglib/repo community that's implementing that.

Rob