The plan

I probably won't have time to put this plan into action until I'm off for the holidays. Or maybe even until I'm back from the holiday break. I'm sure it will undergo some quick evolution once it's made contact with the enemy, so to speak.

Tags

Languages

• php
• css
• html
• xml
• js
• jquery

Technically jQuery is not a language. But I find myself writing more jQuery than straight JavaScript anymore. So in effect the “js” tag will simply mean “JavaScript that isn't jQuery”.

Tools/Software

• dreamweaver
• photoshop
• browsers
• firefox
• safari
• opera
• chrome
• ie
• ie6
• ie7
• ie8

The first two are the biggies. Usually when I see something pertaining to browsers, it's a comparison among several. Sometimes it's more specific, a Firefox plug in for example, or a bug in IE. That's the main reason for breaking IE into different versions. Each version has it's own set of bugs. :(

Content type

• tutorial
• plug in
• code
• framework
• tips
• gallery
• interview
• list

I've put those in order of descending anticipated usefulness. A “tutorial” is an article or blog post that deals with a specific goal in depth. Photoshop tutorials are the most obvious example, but there are tutorials for PHP, jQuery, CSS, DreamWeaver, even specific plug ins like Firebug (which may end up getting its own tag under Tools/Software depending on how much content I find).

Software can have a “plug in” but so can languages and frameworks. “Code” would apply to any specific technique within a language that is meant to be copied and pasted rather than published as a plug in. It's also distinguished from the more general philosophical stuff that would normally be tagged as “tips”.

The “framework” tag is something that will probably fall out of favor as I research more frameworks. If I end up adopting Cake PHP as my PHP framework of choice, then I'll probably start using a “cake” or “cake php” tag the same way I plan to use “jquery”. The framework itself will be promoted to a tag describing the language.

“Tips” aren't plug ins and they aren't code, they are less concrete than either of those. Both the articles I linked to yesterday about writing style guides and creating maintainable CSS are good examples of tips.

A “gallery” is usually but not always visual. There are many galleries of CSS designs out there meant to inspire other designers. But there are also galleries of plug ins and code snippits. The “interview” tag is self explanatory.

Usually, the stuff worth tagging will be a few of the individual resources being linked to on a “list”. I'm thinking of all those “50 CSS Tricks You Can't Live Without!” and “Avogadro's Number Photoshop Tutorials for People Who Spend More Time Reading About Photoshop than Working in Photoshop” that have gotten so popular lately.

Content source

• blog
• article
• video
• screen cast
• pod cast
• wiki

I think most of what I find would technically be classified as “blog” posts. If I notice myself tagging several posts from the same blog, I should probably add it to my RSS reader.

Speaking of RSS feeds, that can cause some problems with the “article” tag. The articles I read online are often from sources that provide RSS feeds (A List Apart, Smashing Magazine, SitePoint, ThinkVitamin, etc.). But I'd also use that tag for anything from a peer reviewed journal, for example, the 80+ articles I've dug up on web usability studies as part of my lit review for my final project. RSS feeds are much less common in that world.

Is the different enough to justify coming up with a new way to categorize content such as Taming Lists vs. Testing web sites: five users is nowhere near enough? My heart tells me no. Jared Spool blogs. As important as peer review is, I think that sort of review process happens more quickly and more transparently online. So blogs, the good blogs at least (those that actually get read, possibly unlike this one), are not free from such a review process. At this stage, I think the academic model servers more as a means of exclusion than as any real control on quality of content. Portals like ACM may be on their way out in favor of Technocrati.

Anyway, I was talking about these tags, but I think the remaining ones are self descriptive enough to not explore in detail. :)

That should provide enough of an organizational skeleton for me to get started. I'm sure it will expand and evolve with use. The most important thing, I think, is to keep it detailed enough to describe resources in a useful way while staying small enough to be maintainable.

And someday, I'll need to work in the need to organize and tag stuff that isn't exactly work related. Luckily, the nature of tags will keep most of that content separate naturally. There may be the occasional overlap with a tag like “funny” and resources like You Suck at Photoshop.