From: Paul E. <pa...@zo...> - 2006-01-31 17:54:09
|
Martin Aspeli wrote: > Hi, > >> 1) Over 2/3 of the tags are used for zero or one resource. I plan to >> delete all of these tags. Later we can decide to raise the threshold >> (e.g. delete things only used twice.) > > See previous post. I don't understand how you got these figures, the "tag space" > basically means "union of all keywords used anywere" so having zero resouces > using a keyword is not really possible. > >> 2) Some number overlap, either in spelling >> (authorization/authorisation), concept (Plone, Plone CMS), or >> capitalization. I plan to conflate these obvious cases. > > Indeed. > >> 3) I plan to lowercase everything. > > +1 > >> Some random thoughts from the tagspace exercise I just did. >> >> 1) I don't think there are any really good tags that are widely used. >> Kind of surprising! > > Not really. Keywords as a mechanism (DC Subject field) is not really that useful > in Plone. The "related" portlet can list things with the same keyword, but in > general, it's hard to convince people to add proper keywords to their content, > and harder still to make them re-use existing keywords, and the more noise there > is, the less useful keywords are. > > And along that vein, I don't really understand why you are pushing this so hard. First, my intention was to send this only to the website team as a report based on work that I did. I accidentally sent this to the documentation team. My apologies. I haven't decided whether I'll use keywords during the sprint. I'll take your strong opinions into account, particularly if you are sprinting with us. :^) > It's much more important that we organise the how-tos and tutorials and FAQs in > sensible sections so that e.g. http://plone.org/documentation/how-to is easy to > navigate for people looking for documentation. Better metadata will make > searches easier, perhaps, and if we were very anal about them, we could use > keywords to keep track of related content, but I fear it's an uphill struggle > that we're going to lose as more documentation comse in. I used Plone's metadata story. This is a metadata problem. I don't think my thinking is out-of-line with Plone's advertised story. I have certainly *never* heard that the properties tab was EOL'd. Until there is a PLIP deprecating this metadata story, we shouldn't act surprised when people use the product as intended. >> 2) If I could design a tool that gave better statistics, I would be >> interested in seeing things like: >> >> a. Frequency. >> >> b. Who. For that tag, who has what amount of the total? In reverse, >> show me the top 10 taggers and their percentage of the total tagspace. >> >> c. Date. In judging the health of a tag, it would be interesting to >> know: when the tag was first used, when it was last applied. Perhaps >> the tag had an initial flurry (perhaps by one person!) then died off. >> >> d. Content types. Does a tag have diversity across multiple kinds of >> usages? > > You seem to be under the impression that people are good and sensible with their > use of keywords. I think the reverse is true, but I also think this doesn't make > that much difference. Ultimately, keywords have shown themselves to have limited > value in creating navigation. Yes, because nobody has ever done the gardening work. All systems break with no gardening. Plone.org had tens of thousands of dead member accounts. It needed gardening too. Your sections thing will require gardening as well. Trac milestone reports need gardening. There is no free lunch. I was volunteering to do some gardening. Didn't expect the heavy artillery. :^( Also, since we provide a facility (metadata) that gave no ROI (e.g. smart folders or related items), it kind of follows that...well, there was no value. Again, my intention was to report back to the website team. Having ~400 keywords, increasing weekly, has a negative impact on this system. I think it is worthwhile feedback for that reason alone. > Especially when it comes to documentation, I would've thought we'd add much more > value by using a specific "related item" field to say "for more information, go > here" and keep this up to date manually. At least then we could impose some > quality control and sanity checking on what's being related. Yes, you've said you thought that. I see merit in that. I see merit in other aspects too, particularly when trying to run a sprint and putting little flags on things to come back to later. Of course, I had never heard that, when you need metadata, you should avoid Plone's metadata facility. That's news to me. :^) >> 5) What are good vectors for kinds of plone.org tags: >> >> a. Things related to CMS machinery: workflow, security > > Sure > >> b. Things related to how we organize the world of Plone: sprints > > Sure > >> c. Ad-hoc (and temporary): typo, bbb, xxx, needsreview > > Maybe ... > >> d. Architectural: zope3, cmf1, cmf2, zope2, archetypes > > Sure > >> e. Separating wheat from chaff (e.g. rating) > > We already have an importance field for this; longer term, ATRatings, if we ever > find some time to polish it, will provide proper rating and feedback mechanisms. > >> f. Creating subpools that span containment hierarchies. > > Don't understand this. Keywords are by their very nature global in Plone. Right, I put this in a section called random thoughts. Apart from a section about action items. >> 6) A diverse group of people, dates, and content types in a tag means a >> healthy tag. > > By that definition, you'd have very few healthy tags :) Correct. Currently, plone.org isn't using any of its out-of-the-box CMS functionality to give value to metadata. For example, we're not using a *single* custom smart folder. Not one. Thus, I officially declare that you are reaching a premature conclusion about plone.org's keyword potential. :^) I think Smart Folders can provide a payback for using metadata. Otherwise, why have Smart Folders? >> 7) Might need more information about a tag than just a string: >> >> a. Description. >> >> b. Who created it and when. >> >> c. Taggroup (vectors mentioned above) > > Nothing in Plone core supports this at the moment. There are some products out > there for tagging ala flickr (talk to Geoff Davis about his ideas, too). I don't > think these will be available to give us any wins for the near-term > documentation improvements, though. Correct. This was meant to be a report to the website team. My apologies for sending it to the docteam. >> 8) Relationship of centrally-created (controlled vocab) vs. organic. In >> what cases can controlled help prime-the-pump on improving the tagspace, >> vs. paving the footpaths? > > Can you stop sounding like a management consultant, please? ;) > > (aka, what do you mean?) Sorry, I didn't explain the blurb. Nor will I, at this point. Let's drop it. >> 9) First priority is to get more value from tagging. Second is to make >> gardening easier. > > Mmmm.... I think the two are very tightly linked. > >> 10) Consequences of not gardening: >> >> a. Performance. >> >> b. Broken windows. People see stale tags and think, "Why bother?" > > Which is exactly what we have now. That, and the fact that no-one (and I mean > no-one) clicks the 'properties' tab. Martin, I provided facts today that disprove this statement. Even with almost no payback, we have 10% usage. Jens Klein, for example, has done an admirable job putting keywords on his AGX docs, via the properties tab. He's hardly a neophyte. Perhaps he didn't get the memo. :^) >> 11) Analyzing the tagspace can help show how people use the site. >> >> 12) Tag consolidation means the group prevails over the individual >> author. However, the individual might have had some personal use for the >> tag. Thus, consolidation should (one day) involve pinging the authors >> and letting them know that their resource was modified. > > I think this is all a little gazing. Maybe making better use of keywords on > current documentation will make our efforts a little easier come this weekend > and subsequent documentation improvement pushes, but trying to re-architect the > navigation of documentation around such an abstract concept doesn't seem like a > very viable solution to me. I'm much more interested in seeing Kamon's work > expanded to give a better thought-out organisation to the existing documentation > using the mechanisms that show up in the UI (i.e. sections). My apologies. I thought putting things under one section, labeled actions, and another, labeled random thoughts, was clear enough. To be crystal clear: nothing in the second section has any bearing on the documentation efforts. To the degree that the website team wants any volunteers for gardening the keywords, I was volunteering. --Paul |