How Plone Keywords Should Work

We’re finishing up a big intranet project here at ONE/Northwest, and that led to an interesting conversation between me, Dave Averill and Gideon Rosenblatt about tagging and keywording content in a website. Here are a few notes from it.


1) “Tags” – keywords that are stored per-item and per-user, ala Plone doesn’t provide out of the box support for tagging. That’s probably OK, because tagging doesn’t really work well unless you have a LOT of users.

2) “Keywords” – keywords that are stored per-item, but not per-user. Plone provides this out of the box.

How Things Work Now, And What’s Wrong

Plone’s current Keywords user interface is really clunky. So clunky as to be nearly useless, in fact. (Sorry.)

keyword widget

The main problem is that as the list of keywords in the site grows (which it does, very quickly, because keywords are not per-user, they’re global across the site), it quickly becomes very difficult to find and choose the keywords in the scrolling window.

Worse, you can’t easily see at a glance which keywords have already been selected.

How to fix it

Fortunately, I think this should be fairly easy to fix.

I would do the following things

  1. Move the Keywords widget from the “Properties” tab to the “Edit” tab. (Plone 3.0 fixes this quite a bit, by making the schemata refresh without page reloads, so this may ultimately be a moot point.)
  2. Show the list of keywords assigned to a content object above the keyword widget. (Bonus points for making them clickable to a search!)
  3. Change the widget to an Autocomplete widget. (Note: I need to check whether the Autocomplete widget will let you add new items to the vocabulary.) uses an autocomplete widget like this for tag entry, and it’s really efficient.

    autocomplete widget
  4. Make keywords part of the default content view templates (again, with clickable links to other items with the keyword). It’s easier to remove them (especially in Plone 3.0 with the viewlet manager) than to add them, and having them there by default will signal that we value keywording.  UPDATE: Shane Graber below points out some instructions he wrote for doing just this, in Plone 2.0-2.5.   Zope 3 fans might prefer this as a viewlet, but that’s a pretty trivial implementaton detail.
  5. We should build a screen that allows one to very quickly assign keywords to many objects in a single operation. I think I’d want to execute a search (or build a smart folder), then see a list of all found objects, their descriptions, the keywords they currently have, and an autocomplete widget for each object. Rip through the screen, assign keywords to a bunch of objects, then hit save once. That would be really fast and efficient.
  6. Finally, we should make sure that permission to assign keywords to content is separated from permission to edit the object itself. (I’m not sure if this is already the case, please leave a comment if you know!) This would make it possible to create a “tagger” role which could be used to let site members keyword content items.

OK, that’s it. All of this stuff seems like it would be pretty easy to do without any major changes to the underlying plumbing.

What do you think? Would this be more sensible, more “humane” behavior for Plone? Is there more low-hanging fruit that I’m missing?

Update: It also might be interesting to look at auto-generating keywords by using Yahoo’s Term Extraction API.

17 thoughts on “How Plone Keywords Should Work”

  1. How’s this?
    I wrote that as we wanted to have keywords exposed per Document as it allowed users to search for other content that might interest them. I almost added Technorati tag support on keywords when I implemented that on My thought was to go with a look somewhat similar to how does their Technorati tags on their Categories at the top of each of their articles/blog entries.


  2. 100% in agreement, Jon — we’ve just been waiting for infrastructure to land so we can do this.

    As for display, I am adding it to the templates in 3.0. The autocomplete will have to wait, unfortunately.

    I hoped we could have made the 3.0 cutoff, but it didn’t happen. I’ll personally make sure that it doesn’t suck in 3.5, though. 🙂

  3. Oh, and if I remember correctly, the adding of keywords is already a separate permission (something like “these roles can add new keywords”, but it might be implemented the wrong way around — it’s old code).

  4. I am not sure I agree with this behaviour. What you are describing is not how most of my customers are using keywords. For them keywords are a way to help ordering search results and categorize content so it can be used in topics and newsletters. They see keywords as an internal administrative tool, not something that users should be able to edit or see.

    What you are describing works great for blog and community sites. In my experience those are a minority of Plone users though.

  5. Autocomplete is a good idea. I would think site-configurable options for keyword choice would be even better. The current picker won’t scale to large vocabularies (auto-completion will work much better). I also like the idea of a widget that supports input of single or multiple comma separated keywords, but also has a drop-down picker for multi-level controlled vocabularies (for example, NAICS industry codes or IPTC Subject codes, tree hierarchies in ATVocabularyManager). At work, we have used something like the latter, but it has no autocomplete yet and only has limited browser compatibility at the moment (svn: Having the ability to pick as well as type is a common request of journalists, for example, when they are looking at editorial content management systems.

  6. @ Christian
    I was just playing about with Haystack “old version” yesterday — after resolving dependency hell, I was able to get it running. (Yay!) It seemed to do a decent job of generating summaries, but it didn’t seem to do a very good job of generating keywords. (I’ve heard the same from Hector Velarde, who has been using it in production at a big newspaper site in Mexico City.)
    I think this is one of the big reasons Ben moved towards a different approach for Haystack 2.0, but I’m not sure if Haystack 2.0 was every really finished. I do know that Ben Saller, its author, is off working on the OLPC project, and hasn’t made a checkin to Haystack since February.

    @ Alex
    Cool — glad to hear that at least the template issues are being solve. That’s great. RE: widget changes — that’s OK. I don’t even know if the Autocomplete Widget is all that modern — it may need/deserve to be redone with KSS. We may improvise in the meantime, which will be a fun experiment. 🙂

  7. @Wichert
    Yeah, not everyone will want to expose keywords to the public, but with viewlet manager, it will be very easy to turn public viewing of keywords off.
    @ Sean
    You make an important point, which is that hierarchical vocabularies are important too. I think these are separate from simple keywords, but Plone should definitely have a reasonable out of the box story for these tool. Drupal’s flexible “taxonomy” module provides simple hierarchical vocabularies and is one of its stronger features. I’ve long thought it would be a great idea to steal. Those with even more formal ontology needs would still be free to use a more complex package like PloneOntology.

  8. John: I’m happy to see you almost agree. However I think the current behaviour which Alex just changed is wrong. In my experience the majority of people do not want to see keywords shown on all pages, so the right default imho is to not show them but make it easy to add them. And the way Alex added them does not use a new viewlet, so we’ll be reverting that.

  9. 5 seems like an extremely useful tool. We make concerted use of Plone as a document management system. Plone is very good for organizing and re-organizing semi-structured content, but there is no way to apply keywords to a large number of documents in a single operation. I think a lot of people would find such functionality useful for breaking down folders of semi-organized documents to present targeted subsets.

    The “tagging interface” on the “ImageRepository” product is noteworthy in this regard.

    In the absence of the ideal–a dedicated librarian capable of maintaining a formal taxonomy–these semi-formal, rapidly updated folksonomies (using tags) are extremely important. They can be managed with the “PloneKeywordManager”product.

    Nice to hear #4 is underway!


  10. As the original author of the AT autocomplete widget, I’d recommend against using it. 🙂 It’s ancient stuff, and based on some old js that wasn’t so nice to begin with. However, something like this could be built using KSS fairly easy.

    Ideally, the widget used would have a mode that disallowed free-form keyword entry based on permission/role/condition, though an autocomplete that doesn’t allow arbitrary text entry is probably a tricky thing to get right.

  11. @Alec – thanks for the wise perspective! 🙂 I think free-text entry is actually a good thing in this use case, but a toggable switch is definitely a good idea.

  12. I use keywords extensively to control which items show up in different SmartFolders for a small group working on a project. This is working very well with a few exceptions.
    1. Unable to mass tag as mentioned above.
    2. Unable to add keywords when editing (should be fixed soon).
    3. I added the keyword display at the top per Shane’s how-to. It will be helpful in our use case and is consistent with how tags work with my personal stuff.

Comments are closed.