I've been mulling over how to approach planning out my tags for using Ma.gnolia (M) to store and organize the work related resources I find via Stumble Upon (SU). At first I thought about a matrix of some sort allowing me to drill down within a topic. But how would I share that here? An HTML table won't work without getting really nasty with the colspan attribute. Mind mapping software could work, but the image it would produce would to far too huge to post here. I even tried to think of it in terms of XML and custom Doctypes where I could use “web design” like a root element and have a bunch of descendant tags from there. That lead me to two realizations:
- Only someone at least as geeky as me would have any chance of understanding such a system
- I was ultimately still thinking in hierarchies
The philosophy behind tagging is to address areas where hierarchies break down. For example, as I explored such a matrix, I found myself coming up with compound tags like “javascript-framework” and “php-framework”. Part of the reason for this line of thinking is due to the structure of SU, where such compound tags would be useful. But M allows to search and sort based on a combination of tags. Resources on Cake PHP, Zend, Ruby on Rails, and jQuery could all take the tag “framework”. I could also tag such resources with their associated language: “php”, “php”, “ruby”, and “javascript” respectively.
Simply typing this out here has lead to another discovery. Typing out “javascript” sucks. I don't plan on tagging stuff with “cascading style sheets” either, so I'll steal an idea I've been using in my directory structures for years and shorten “javascript” to “js”. That will be clear to me and should be clear to any other web professional who happens to browse through my links in Ma.gnolia. In theory, that should also apply to anyone taking over this position in the future.
I also realized that trying to use a root tag such as “web design” is short sighted. Not everything I do is related to design. Some of the server administration or SEO stuff I do would stretch the common definition of design.
Leaving behind the idea of a hierarchy should also allow me more freedom for future growth. If I'm simply tagging resources with an associated language (“css”, “js”, “php”) it becomes much easier to just add a new tag for any new languages I start to use or learn (“perl”, “ruby”, “lolcode”). This industry evolves so quickly, that sort of scalability will likely pay off in ways I currently can't even predict. Five years from now my job may require as much understanding of psychology as it currently does programming and design. I'm pretty sure we're one high profile lawsuit away from moving a solid understanding of the legal implications of accessibility from the “recommended skills” to the “required skills” section of job descriptions such as mine.
I'm going to give some thought to classification of tags I will need. Languages are an obvious example of what I'm talking about. Maybe I should add a class of tags for software, Dreamweaver, Photoshop, etc. I try to keep what I do tool-neutral, but I'd be lying if I said I never use Photoshop tutorials from the internet. If the Adobe Creative Suite was not already bought and paid for, I could get buy using free text editors and open source programs like the GIMP. But the reality of my job is that I spend a lot of time working with Adobe software so it's probably a good idea to reflect that in my tag structure. I'll also put some thought towards the need for consistency. Luckily, Ma.gnolia offers an auto-complete function based on previously used tags. SU offers no such feature. I just realized Blogger has the same sort of auto-complete function in the tag field for my blog entries. That should at least keep me from forking my tags due to a common misspelling or something silly like that. I'll continue to think things over and share my thoughts over the weekend.
No comments:
Post a Comment