A while ago I wrote an alternative search and navigation interface to InfoWorld.com. The search is broken now because the underlying engine switched from Ultraseek to Google, and nobody has updated the search wrapper. But the navigation piece still works, and while it does, I want to invite some commentary because I’m thinking of doing something similar for another project.
In this model the navigation is metadata-driven, and supports views like:
InfoWorld stories tagged ‘Silverlight’
InfoWorld news stories tagged ‘Silverlight’
InfoWorld news stories by Elizabeth Montalbano tagged ‘Silverlight’
Every piece of metadata in the tabular display is active, and toggles a filter for that item. This works especially well for the tags, and enables you to cruise through the tagspace in a fluid way. For example, try this progression:
1. InfoWorld news stories tagged ‘Silverlight’
2. Click ‘flash’ to toggle it on
3. InfoWorld news stories tagged ‘Silverlight’ and ‘Flash’
4. Click ‘silverlight’ to toggle it off
The same principle holds for other bits of metadata, like storytype. So for example:
1. InfoWorld news stories tagged ‘Silverlight’
2. Click ‘News’ to toggle it off
3. InfoWorld stories tagged ‘Silverlight’
4. Click ‘Review’ to toggle it on
5. InfoWorld Reviews tagged ‘Silverlight’
6. Click ‘Martin Heller’ to toggle it on
7. InfoWorld Reviews by Martin Heller tagged ‘Silverlight’
8. Click ‘silverlight’ to toggle it off
It’s powerful to explore things this way, but if I did something like this again, I’d look for ways to make these filter progressions more intuitive and discoverable.
I just don’t think people expect every item to work as a control as well as an information display. And because they don’t, it may be a bad idea to do things that way. Or maybe it’s a good idea that’s still in search of its perfect expression. I’d be curious to know what you think.
One idea that I’m exploring, is to have a tag cloud that strongly highlights a selected tag and weakly highlights other tags that as associated with the selected tags.
So if you select the “silverlight” tag, it would be strongly selected it in the cloud, and you would only see entries for silverlight in the search return list. But you would also see a weak selection of “flash” and “stories” in the tag cloud. If you then select “flash” in the tag cloud it would strongly select “silverlight” and “flash” and weakly select stories and any additional tags associated with “flash”. The list would then show entries with both flash and silverlight at the top, followed by stories only about silverlight or only about flash.
As you continue to select more tags you get more search results and more associations. The list being sorted by the number of matching tags.
If it weren’t for the long server delay, this might work. So maybe it would be lively enough as a Flash or Silverlight or Ajax interface.
This reminds me a little of the search interface in Freebase, but that seems to be a little more self-explanatory.
> As you continue to select more tags you get more search results and more associations.
That’s a good idea! I like the notion of showing more, but in a controlled way, rather than showing less.
> If it weren’t for the long server delay, this might work. So maybe it would be lively enough as a
> Flash or Silverlight or Ajax interface.
I did a version Ajax-style, and the JS overhead was worse than the server delay. But it’s probably no different than Flash or Silverlight, in that for immediate responsiveness you’d want to cache as much metadata as possible locally.
But that’s entirely separate from the question of whether it is conceptually intuitive to do things this way, or if it isn’t, how it can become so.
You’re right that Freebase is worth taking another look at.
There’s also the Simile Exhibit examples, which pop up controls with checkboxes for something like this. Not a perfect design solution, but it helps show what the logic is as you use it.
Hello Jon,
This is very similar to the questions that are permanently coming up in Business Intelligence projects when OLAP is required. If I am looking at the way how I played with your prototype I have following suggestions:
-that there are use cases where I would prefer to see/treat the group of tags more as a bread crumb trail – means that the sequence how the tags have been selected is relevant and the UI should allow to things like “drill up” (today only reset or the more difficult to understand concept of “select a tag that is in the group of selected tags again but don’t do it in the UI in the group of the selected tags itself but in the table”
-there is a value of providing “standard hierarchies for navigation” (or easy access to those prefedined groups of tags) even when there is the full nav-flexibility as your MD UI prototype is motivating.
I hope this makes sense, please feel free to ask if anything is not clear why I am connecting this to the OLAP UI experience.
Best regards,
Ralf