Too bad.

I wouldn’t be too worried about initial resistance, so long as the animation isn’t too bad on ‘real world’ hardware, the utility of the interface should win over… you’d hope anyway! : )

Actually, performance was one of my goals. Even with a very large tag set, it runs very smoothly on my 800 Mhz iBook.

I know you’ve followed the GarageBand precedent, but perhaps ‘Reset’ could be ‘Show All (Tags?)’, and be highlighted as the default selection when no other tag is selected, to articulate that all tags, and therefore all links, are shown until a specific tag is selected?

That makes sense.

Is there any means of showing the tags that are applied to a given article via this tag grid element (i.e. basically a reverse filter)? Like the Address Book, you could option-click an article to highlight the associated tags (via a colour highlight), or more emphatically an option-click on an article could filter the tag grid to that article’s tag set, and consequently filter the article list to other matching articles.

Since we don’t have a working example yet, are there some features that stand to be lost in this element?

In theory, this makes sense and could be quite powerful, but I’m also it afraid it may be confusing. A complete reverse filter would show all posts that are identically tagged, which will most often be none, but could be some. Highlighting sounds like a great way around this (and letting the user choose what they want), but then the interface is being cluttered with lots of different colors, and many tags will be “lost” since they will need to be scrolled to. What’s great about this interface is how little scrolling you have to do.

Have we lost the ability to drag one or more articles to a tag (i.e. dropping the articles ‘into’ the tag, as a container) to apply that tag to those articles? It seems like that could still be supported by dragging a tag from the tag grid, onto a single article, and perhaps multiple selected articles (if not too awkward)?

Actually, the tags are completely draggable, but I’ve commented out the code since there’s no targets yet. I’ve seen the kind of tagging-by-dragging in some Microsoft Vista demos, and I think it is pretty awkward though. Buzz and my idea was to be able to create smart folders by dragging tags to a source list.

This change to the tag browser seems to bring with it a fairly fundamental change; the browsing pane is nowhere to be seen in these mockups, so what will the article selection/activation behaviour be? Will the page load in place of the article list? If so you’ve added branching to the navigation. Or are links intended to be off-loaded to the default browser?

The browser pane is still there, just not being shown. It works just as it always did, albeit prefers a screen in portrait mode now .

Finally, have you considered how to handle Bundles? Cocoalicious doesn’t support Bundles, of course, so that’s excusable, but I just wonder if they’ve been considered in the scope of this design?

I have made my best effort not to consider bundles. Tags are meant to be a flat space, afterall! . I’ll think about your ideas for a bit. I think the best thing might to have bundles be like a side-filter.

Thanks for the feedback!

I wouldn’t be too worried about initial resistance, so long as the animation isn’t too bad on ‘real world’ hardware, the utility of the interface should win over… you’d hope anyway! : )

The video helped a lot, but I do have a couple of questions/comments:

I know you’ve followed the GarageBand precedent, but perhaps ‘Reset’ could be ‘Show All (Tags?)’, and be highlighted as the default selection when no other tag is selected, to articulate that all tags, and therefore all links, are shown until a specific tag is selected?

Is there any means of showing the tags that are applied to a given article via this tag grid element (i.e. basically a reverse filter)? Like the Address Book, you could option-click an article to highlight the associated tags (via a colour highlight), or more emphatically an option-click on an article could filter the tag grid to that article’s tag set, and consequently filter the article list to other matching articles.

Since we don’t have a working example yet, are there some features that stand to be lost in this element?

Have we lost the ability to drag one or more articles to a tag (i.e. dropping the articles ‘into’ the tag, as a container) to apply that tag to those articles? It seems like that could still be supported by dragging a tag from the tag grid, onto a single article, and perhaps multiple selected articles (if not too awkward)?

This change to the tag browser seems to bring with it a fairly fundamental change; the browsing pane is nowhere to be seen in these mockups, so what will the article selection/activation behaviour be?

Will the page load in place of the article list? If so you’ve added branching to the navigation. Or are links intended to be off-loaded to the default browser?

Finally, have you considered how to handle Bundles? Cocoalicious doesn’t support Bundles, of course, so that’s excusable, but I just wonder if they’ve been considered in the scope of this design?

Without going into it too much, Bundles could be shown above the tag grid as another level of filtering (too much vertical space), or as collapsable groups in the tag grid (a la iPhoto Film Rolls) which would allow collapsing the tags to their parent Bundles, as a more course filter criterion.

Perhaps more efficiently Bundles could be shown as an optional parent selector sidebar to the left of the tag grid, that could be shown to view by Bundles, or hidden to revert to your original mockup.

As a vertical scrolling list, the Bundle list could operate like a ’standard’ Sidebar; clicking on a Bundle would filter the tag grid to just the relevant tags, and perhaps support Cmd-clicking to select multiple Bundles.

Alternatively, of course if the desire were to emphasise the fact that multiple Bundles could be selected, the list could be a vertical stack of your tag grid elements, to make clearer that several could be selected.

OK, that’s way too much now! : )

cheers

–jens h.

I must disagree. Adding a way to negate tags is another important element in managing large numbers of items and tags.

While one of the great advantages of tagging is that items can carry multiple tags, in modeling the world, there are sets of tags that are mutually exclusive over all items. For example, we might divide the world into X, Y, and Z (e.g., animal, vegetable, and mineral). If we create tags “X,” “Y,” and “Z,” then any item that does not carry one of these tags is incorrectly tagged. The ability to negate tags makes it relatively easy to hunt for this serious type of tagging error. Ultimately, improving the tagging of items will improve the utility of tagging. At least, that’s what I think.