tags instead of categories (was Re: [SVN] New info.plist keys for description etc.)

[Chris Thomas]

On Feb 16, 2007, at 2:04 AM, Charilaos Skiadas wrote:

> On Feb 16, 2007, at 1:54 AM, Allan Odgaard wrote:
>
>> On 16. Feb 2007, at 05:59, Chris Thomas wrote:
>>
>> It seems elegant, but maybe it should be in addition to the fixed  
>> category hierarchy.
>>
>> The overwhelming reason for wanting the category system is to  
>> present new users with a simpler view of bundles. I.e. disable all  
>> but just a handful by default, then give them a browser with the  
>> above categories (on first launch or so).
>>
>> The user should feel that he is not overlooking anything, and by  
>> showing him around six categories (which will likely each need a  
>> longer description), it should be easy for him to drill down into  
>> the Markup / Prose, if he just want TextMate for Markdown, or  
>> ignore the SCM System if he does not work with version control  
>> system, etc.
>>
>> With a tagging interface it would either be to show him everything  
>> and let him filter (which would be too much information at once for  
>> new users, i.e. >100 bundles) or we could show nothing, and let him  
>> search, but then new users will miss out on stuff (or at least feel  
>> this way).
>>
>> At the same time it seems redundant to have a category system and a  
>> tagging system, as there is a huge overlap -- maybe do the tagging  
>> system, but promote some tags to take the role of forming the  
>> initial hierarchical index?
>
> I totally agree with Allan's reasons for wanting the categories. I  
> would suggest having the categories and bundle browser as described  
> above, and for each bundle an array of "keywords", instead of  
> "tags" (though I guess there's not much of a difference between the  
> two). Somewhere in the interface, perhaps in a second "bundle  
> browser mode", the user would be able to search for a specific  
> keyword, and get a listing of all the bundles that have something to  
> do with that keyword.

"tags" used in the web sense. Keywords.

> But we definitely should have a single category to describe what the  
> main thing the bundle does is.

Put it in a tag. Require one of the six categories to be present as a  
tag.

The simple category approach is much simpler, for sure, and has fewer  
upfront maintenance costs. There are problems that tags would address  
that a simple category cannot:

1. Streamlined first-time experience. Present subsets of bundles by  
tag. "Rails development." "Mac applications."

2. Overwhelming bundle complexity -- too many bundle commands visible  
at once. Switch between visible bundle sets at runtime by tag.

It's possible this is better implemented through an external mechanism  
rather than directly in bundles.

Chris