[Clipart] Browsing interface

[Bryce Harrington]

On Thu, 16 Sep 2004, Carl Worth wrote:
> So, there are 20 thumbnails there, but it requires a minimum of 2 clicks
> per sub-category (total of 8 clicks and page loads) to browse through
> them all. Additionally, these two clicks are in separate elements of the
> website. Going deeper in the hierarchy requires using the menu on the
> left, while going up requires using the "You are here" path across the
> top.
> 
> So, I can think of a few things to help with these problems:
> 
> 	1) Display item counts next to category names in the
>            menus. These counts should include sub-categories so that
>            when the user sees "Computer (81)" but only 21 things on the
>            screen, she knows to look deeper for more.
> 
> 	2) Combine the two separate navigation menus. A simple thing to
>            do would be to just place the current path immediately above
>            the menu on the left. For example, the user might see:
> 
> 		You are here:
> 		home / Computer / icons
> 			Actions
> 			Apps
> 			Devices
> 			...
> 
> 	   The important things is that these should be combined within
> 	   the same structural element of the website.
> 
> 	3) At any level in the hierarchy, display thumbnails for all
>            items in the current category and in all sub-categories.
> 
> For item #3, I know that I would love to be able to casually browse
> through hundreds of thumbnails by just clicking "next" on each page, (or
> clicking to a specific page). Even being able to examine the entire
> collection this way would be quite useful for certain kinds of casual
> browsing.
> 
> Thoughts, reactions?

Sound like good ideas.  With the DMS I'm planning on providing some
functions that allow better navigational solutions, so this is good
feedback to be hearing right now.  I agree with your points; I think the
reason they haven't been done in the current system is that the current
system simply displays what's in the current directory.

With DMS, though, items are stored conceptually using keywords, not
hierarchically in folders.  So the idea of doing a query for "all
animals" meshes very well with its architecture.  Along with that, I
would imagine it should be feasible to do things like, "All animals
EXCEPT insects", which of course couldn't be easily done in a
hierarchical scheme.

Sounds like we also need to make sure any routine returning clipart
items also provide a grouping mechanism for doing prev/next buttons and
a total count.  

Anyway, yeah all sounds doable.  

Another trick that we've been mulling over but that I don't have a good
idea for implementing is the idea of 'hierarchical overlays'.  In other
words, it's all well and good to say that clipart should be stored
conceptually rather than hierarchically, and certainly a search/query
tool can work well with that, but sometimes you really do want to
navigate things using a hierarchy.  An idea is to provide hierarchy
schemes that list out particular keywords, so that you can navigate
through the clipart using your chosen scheme.  The idea is to set things
up to work analogously to how Wikipedia does it.  The example I use is
if you're a biologist, you may expect to find 'dalmatian' somewhere
under 'Canidae/Canis lupus', whereas a dog owner might look for them
under 'pets/dogs', and a game designer might like to find them under
'Firehouse/Animals'.  

One approach is to hyperlink *everything* together, as Wikipedia does,
but this ends up getting rather large, such as when we want to create a
distribution tarball for a user to download and install.  So the
approach we'd like to have is an abstract "hierachy overlay".  This
overlay would be essentially an XML tree of keywords.  A dms routine
would take this overlay file and iterate through it, extracting the
appropriate items out of dms and building a tree from it. 

I'd like to get some further discussion of this approach - especially
ideas for implementing it, or additional features/capabilities we'd like
to get out of it.

Bryce