Re: [drupal-devel] A Folksonomy module
This 1000 tag thing. I've found vocabularies with a tree of 100 tags a bit awkward to use. The Admin vocab overview gets very long and the few places where you have all tags for a vocab in a combo box will also get awkward to use.
This sounds like something that UI can overcome. I agree with the Admin vocab overview length issue, but if you use system vocabs, the folksonomy could have it's own admin display for this. Tag-per-line or comma-separated tags would be the preferred input, would they not? so I don't see the terms every necessarily being displayed in a combo box. I think that aiming to be able to implement folksonomies with our existing taxonomy system is a good thing to strive for, even if it means code changes to taxo.module to encompass this use. Now all we need to do is have aggregator create feed_item nodes, add a little publish/subscribe/workflow magic to delete/update them, and we can replace the strange "categories" used there with taxonomy as well... (let me dream, OK?) Hmm. And if profiles were nodes, you could "tag" users by tagging their associated profile(s). -- Boris Mann http://www.bryght.com
Hi, I have a client/site with a few Huge (yes, capital 'H'; and still growing) taxonomy tree. I need to fix the UI for this too. Maybe Chris Messina, I and others, can work out the agreements from the Useability sprint, and actually code something for this? I will first focus on getting the notes and agreements of tis sprint together & online, but in the mean time this taxo-interface issue can be launched. Because IMO the whole taxonomy admin is a UI problem. Chris, can you get back to me about this? Anyone else with some interface-ideas and some time, please volunteer? Bèr Op woensdag 9 maart 2005 11:08, schreef Boris Mann:
This 1000 tag thing. I've found vocabularies with a tree of 100 tags a bit awkward to use. The Admin vocab overview gets very long and the few places where you have all tags for a vocab in a combo box will also get awkward to use.
This sounds like something that UI can overcome. I agree with the Admin vocab overview length issue, but if you use system vocabs, the folksonomy could have it's own admin display for this.
Tag-per-line or comma-separated tags would be the preferred input, would they not? so I don't see the terms every necessarily being displayed in a combo box.
I think that aiming to be able to implement folksonomies with our existing taxonomy system is a good thing to strive for, even if it means code changes to taxo.module to encompass this use.
Now all we need to do is have aggregator create feed_item nodes, add a little publish/subscribe/workflow magic to delete/update them, and we can replace the strange "categories" used there with taxonomy as well... (let me dream, OK?)
Hmm. And if profiles were nodes, you could "tag" users by tagging their associated profile(s).
-- Boris Mann http://www.bryght.com Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
Hi,
I have a client/site with a few Huge (yes, capital 'H'; and still growing) taxonomy tree. I need to fix the UI for this too.
Maybe Chris Messina, I and others, can work out the agreements from the Useability sprint, and actually code something for this? I will first focus on getting the notes and agreements of tis sprint together & online, but in the mean time this taxo-interface issue can be launched.
May I suggest that a variant UI be considered? For example, a short list might be displayed one way (e.g. a combo box) and a longer list would be displayed using a different technique. One "size" does not fit all, so to speak. -- Chris Johnson
Op woensdag 9 maart 2005 16:30, schreef Chris Johnson:
May I suggest that a variant UI be considered? For example, a short list might be displayed one way (e.g. a combo box) and a longer list would be displayed using a different technique. One "size" does not fit all, so to speak.
We did not really get into this @ the useability meetings, but a foundation was layed. As soon as i have all notes in, I will release the first part. We can then discuss this in more detail ,because we kow where we ended, and what still needs to be discussed. Maybe even in a dedicated IRC meeting. For the time being: ideas and thoughts are welcome. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Boris Mann <borismann@gmail.com> Wed, 9 Mar 2005 02:08:20
This sounds like something that UI can overcome. I agree with the Admin vocab overview length issue, but if you use system vocabs, the folksonomy could have it's own admin display for this.
Yes. That's where I've ended up.
Tag-per-line or comma-separated tags would be the preferred input, would they not? so I don't see the terms every necessarily being displayed in a combo box.
Yes.
I think that aiming to be able to implement folksonomies with our existing taxonomy system is a good thing to strive for, even if it means code changes to taxo.module to encompass this use.
I think folksonomy tags are too different from taxonomy terms so I think there's benefit from sharing vocabulary tables and codes but not term tables and code. I've only needed three patches to taxonomy.module to make this work. Each one is just to prevent taxonomy from generating form fields for vocabularies that have module<>'taxonomy'.
Hmm. And if profiles were nodes, you could "tag" users by tagging their associated profile(s).
That's another story! On Ecademy we have a "50 words" field on profiles that is really a folksonomy field. All my messing in this area started with implementing a folksonomy interface to navigate user space. It's open to the world so you can see it here. http://www.ecademy.com/module.php?mod=member&op=popular As somebody else mentioned we'd need a user_tag field to go with node_tag to do this in Drupal. Or make profiles, nodes. -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/
Julian Bond <julian_bond@voidstar.com> Wed, 9 Mar 2005 10:52:12
I think folksonomy tags are too different from taxonomy terms so I think there's benefit from sharing vocabulary tables and codes but not term tables and code. I've only needed three patches to taxonomy.module to make this work. Each one is just to prevent taxonomy from generating form fields for vocabularies that have module<>'taxonomy'.
I lost my way a little on this last night as I tried to build and use a tags table that had a single entry for each tag used. Maintaining data integrity is proving a little hard. It revolves around whether a tag should stay in the database when it's no longer used by any nodes. Anyway. Patching Taxonomy. What are the implications of stopping any output from taxonomy_form(), taxonomy_form_all() and taxonomy_node_form() when the vocabulary->module <> 'taxonomy'. Basically saying that if the module isn't 'taxonomy' don't bother providing end user UI in the same way that it currently doesn't bother providing admin UI. Will this break existing contrib modules? Now if a module provides it's own admin and user UI, what is there to be gained from it keeping it's vocabulary data in the vocabulary table apart from a little code reuse from taxonomy.module? The one thing I can think of is that as taxonomy.module develops, there may come a time when it would make sense to use the admin and user UI again and at least the data is in the right place making upgrades easier. -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/
participants (4)
-
Boris Mann -
Bèr Kessels -
Chris Johnson -
Julian Bond