Hello all, in participation of the new project pages and navigation as envisioned by Mark Boulton (see [1] and [2]), we added two new vocabularies to the project pages on drupal.org. We decided to add these in preparation of the new design so that we'd have enough data by the time we launch the new drupal.org (and so we can do proper performance testing of the Solr integration). If you edit your project(s), you'll see the two new vocabularies that I'm talking about, and how they relate to the designs in [1] and [2]. [1] http://drupal.markboultondesign.com/iteration11/download.html [2] http://drupal.markboultondesign.com/iteration11/modules.html Thanks! -- Dries Buytaert :: http://buytaert.net/
Hm, while I get trying to categorize, I just want to point out that a vast majority of modules will select very single "Type of site" so I'm not sure that list is all that helpful. :-/ Most modules good for an E- learning site are probably good for lots of other kinds of sites too. Just curious are we going to "maintain" the tags list of just let module owners do what they will. I can see people doing weird things like --menus, nice, dropdown, CSS, "add1suns modules", "best module evar", "must have" -- etc. It will say something about the maintainer, dependng what they put so I'm not that pressed, but others may get in a froth over it. ;-) - Addi (rulAr of teh nIce Menus Universe) On Feb 12, 2009, at 6:40 AM, Dries Buytaert wrote:
Hello all,
in participation of the new project pages and navigation as envisioned by Mark Boulton (see [1] and [2]), we added two new vocabularies to the project pages on drupal.org.
We decided to add these in preparation of the new design so that we'd have enough data by the time we launch the new drupal.org (and so we can do proper performance testing of the Solr integration).
If you edit your project(s), you'll see the two new vocabularies that I'm talking about, and how they relate to the designs in [1] and [2].
[1] http://drupal.markboultondesign.com/iteration11/download.html [2] http://drupal.markboultondesign.com/iteration11/modules.html
Thanks!
-- Dries Buytaert :: http://buytaert.net/
I completely agree with Addison's sentiments here. With many modules being appropriate for all types of sites, we'll end up with a lot of noise in those categories preventing people from really finding modules that are specifically appropriate for their type of website. How about separating the "always applicable" modules from the type-specific modules? I found the tags a bit confusing. I wasn't quite sure what to put. Help text that is specific to this context would be good, instead of the default general help for freetagging. -- Kathleen Murtagh On Thu, Feb 12, 2009 at 7:44 AM, Addison Berry <drupal@rocktreesky.com>wrote:
Hm, while I get trying to categorize, I just want to point out that a vast majority of modules will select very single "Type of site" so I'm not sure that list is all that helpful. :-/ Most modules good for an E-learning site are probably good for lots of other kinds of sites too.
Just curious are we going to "maintain" the tags list of just let module owners do what they will. I can see people doing weird things like --menus, nice, dropdown, CSS, "add1suns modules", "best module evar", "must have" -- etc. It will say something about the maintainer, dependng what they put so I'm not that pressed, but others may get in a froth over it. ;-)
- Addi (rulAr of teh nIce Menus Universe)
On Feb 12, 2009, at 6:40 AM, Dries Buytaert wrote:
Hello all,
in participation of the new project pages and navigation as envisioned by Mark Boulton (see [1] and [2]), we added two new vocabularies to the project pages on drupal.org.
We decided to add these in preparation of the new design so that we'd have enough data by the time we launch the new drupal.org (and so we can do proper performance testing of the Solr integration).
If you edit your project(s), you'll see the two new vocabularies that I'm talking about, and how they relate to the designs in [1] and [2].
[1] http://drupal.markboultondesign.com/iteration11/download.html [2] http://drupal.markboultondesign.com/iteration11/modules.html
Thanks!
-- Dries Buytaert :: http://buytaert.net/
+1 to addison & kathleen's sentiments. I don't think this really has benefits, compared to the downsides. I also think it takes away some of the creativity with using modules for different purposes. On Thu, Feb 12, 2009 at 11:52 PM, Kathleen Murtagh <kathleen@ceardach.com>wrote:
I completely agree with Addison's sentiments here.
With many modules being appropriate for all types of sites, we'll end up with a lot of noise in those categories preventing people from really finding modules that are specifically appropriate for their type of website. How about separating the "always applicable" modules from the type-specific modules?
I found the tags a bit confusing. I wasn't quite sure what to put. Help text that is specific to this context would be good, instead of the default general help for freetagging.
-- Kathleen Murtagh
On Thu, Feb 12, 2009 at 7:44 AM, Addison Berry <drupal@rocktreesky.com>wrote:
Hm, while I get trying to categorize, I just want to point out that a vast majority of modules will select very single "Type of site" so I'm not sure that list is all that helpful. :-/ Most modules good for an E-learning site are probably good for lots of other kinds of sites too.
Just curious are we going to "maintain" the tags list of just let module owners do what they will. I can see people doing weird things like --menus, nice, dropdown, CSS, "add1suns modules", "best module evar", "must have" -- etc. It will say something about the maintainer, dependng what they put so I'm not that pressed, but others may get in a froth over it. ;-)
- Addi (rulAr of teh nIce Menus Universe)
On Feb 12, 2009, at 6:40 AM, Dries Buytaert wrote:
Hello all,
in participation of the new project pages and navigation as envisioned by Mark Boulton (see [1] and [2]), we added two new vocabularies to the project pages on drupal.org.
We decided to add these in preparation of the new design so that we'd have enough data by the time we launch the new drupal.org (and so we can do proper performance testing of the Solr integration).
If you edit your project(s), you'll see the two new vocabularies that I'm talking about, and how they relate to the designs in [1] and [2].
[1] http://drupal.markboultondesign.com/iteration11/download.html [2] http://drupal.markboultondesign.com/iteration11/modules.html
Thanks!
-- Dries Buytaert :: http://buytaert.net/
In the redesign discussions, we'd discussed having nodereferences between case studies, site recipes and projects for this purpose rather than tags. That way, people documenting how particular types of sites are built could show which modules they used - as opposed to project owners saying 'I think this might be useful for'. You could then show showcases and site recipes next to modules, and modules next to showcases and site recipes in a structured way (and with some data munging, get aggregate data if needed). Was this discussed as an option? Nat
THAT sounds *much* cooler (and more useful) than having another vocabulary for modules to try slotting themselves into. +++1 for implementing that instead. On Fri, Feb 13, 2009 at 12:15 AM, Nathaniel Catchpole < catch56@googlemail.com> wrote:
In the redesign discussions, we'd discussed having nodereferences between case studies, site recipes and projects for this purpose rather than tags. That way, people documenting how particular types of sites are built could show which modules they used - as opposed to project owners saying 'I think this might be useful for'. You could then show showcases and site recipes next to modules, and modules next to showcases and site recipes in a structured way (and with some data munging, get aggregate data if needed). Was this discussed as an option?
Nat
2009/2/12 Nathaniel Catchpole <catch56@googlemail.com>:
In the redesign discussions, we'd discussed having nodereferences between case studies, site recipes and projects for this purpose rather than tags. That way, people documenting how particular types of sites are built could show which modules they used - as opposed to project owners saying 'I think this might be useful for'.
That sounds really useful! Dan
This is the conversation Catch was referring to: http://groups.drupal.org/node/16732 Kyle Research Assistant eBusiness Center @ BYU kyle.mathews2000.com/blog On Thu, Feb 12, 2009 at 6:45 AM, Dan Smith <galooph@gmail.com> wrote:
2009/2/12 Nathaniel Catchpole <catch56@googlemail.com>:
In the redesign discussions, we'd discussed having nodereferences between case studies, site recipes and projects for this purpose rather than tags. That way, people documenting how particular types of sites are built could show which modules they used - as opposed to project owners saying 'I think this might be useful for'.
That sounds really useful!
Dan
Then instead of referencing the nodes from the case studies attaching taxonomy terms to the references, we can tag the case studies themselves, and just have taxonomy lists of case studies on those links, can't we? I mean if you'd use this data from actual case studies, then why not show the modules in context, where the usage is actually described? Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well. Gábor On Thu, Feb 12, 2009 at 2:15 PM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
In the redesign discussions, we'd discussed having nodereferences between case studies, site recipes and projects for this purpose rather than tags. That way, people documenting how particular types of sites are built could show which modules they used - as opposed to project owners saying 'I think this might be useful for'. You could then show showcases and site recipes next to modules, and modules next to showcases and site recipes in a structured way (and with some data munging, get aggregate data if needed). Was this discussed as an option?
Nat
On Thu, Feb 12, 2009 at 8:11 AM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well.
I agree. Sure, some modules are useful on all sites and will select that, but some modules really are applicable to only a few kinds of sites. The tag issues will cause some additional maintenance problems but we have tools for dealing with it. Let's try this out long enough to see how it works with a faceted search interface. Greg -- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
Remember folks, these are usability experts focusing on people coming to drupal.org. That means, the main concern in our minds is, given a pressing need, how can I obtain a list of modules that might be just what I'm looking for! Cool! So if we stop analyzing it from the module author's point of view (another chore to do in creating/updating a project, having to pick out tags) and start analyzing it from the "how can I do what I need to do with contributed modules real quick" point of view, the tags start making sense as a basis for building that kind of functionality. Victor Kane http://awebfactory.com.ar On Thu, Feb 12, 2009 at 1:25 PM, Greg Knaddison < Greg@growingventuresolutions.com> wrote:
On Thu, Feb 12, 2009 at 8:11 AM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well.
I agree. Sure, some modules are useful on all sites and will select that, but some modules really are applicable to only a few kinds of sites. The tag issues will cause some additional maintenance problems but we have tools for dealing with it. Let's try this out long enough to see how it works with a faceted search interface.
Greg
-- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
On Feb 12, 2009, at 10:48 AM, Victor Kane wrote:
Remember folks, these are usability experts focusing on people coming to drupal.org.
That means, the main concern in our minds is, given a pressing need, how can I obtain a list of modules that might be just what I'm looking for! Cool!
So if we stop analyzing it from the module author's point of view (another chore to do in creating/updating a project, having to pick out tags) and start analyzing it from the "how can I do what I need to do with contributed modules real quick" point of view, the tags start making sense as a basis for building that kind of functionality.
My concern is simply what Kathleen articulated. That if 90% of modules pick every category, then usability is greatly reduced. It would be *much* more useful if all modules are assumed useful for all sites, except for ones that are specifically limited to a niche category. I'd rather get 5 results for E-learning for modules that only apply to that category rather than 4000 modules, 3995 of which apply to all sites plus 5 for E-learning. That said, I'm not opposed to just turning it on and seeing how it goes, but I know that all of my modules are applicable to all sites and there aren't many that I use when site building that aren't used everywhere as well. - Addi
Victor Kane http://awebfactory.com.ar
On Thu, Feb 12, 2009 at 1:25 PM, Greg Knaddison <Greg@growingventuresolutions.com
wrote: On Thu, Feb 12, 2009 at 8:11 AM, Gábor Hojtsy <gabor@hojtsy.hu> wrote: Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well.
I agree. Sure, some modules are useful on all sites and will select that, but some modules really are applicable to only a few kinds of sites. The tag issues will cause some additional maintenance problems but we have tools for dealing with it. Let's try this out long enough to see how it works with a faceted search interface.
Greg
-- Greg Knaddison http://knaddison.com | 303-800-5623 | http://growingventuresolutions.com
http://lists.drupal.org/listinfo/development Kieran On Thu, Feb 12, 2009 at 8:31 AM, Dmytro Solodovnyk <sdimass@gmail.com> wrote:
Sorry, people, how can I unsubscribe from this mailing list?
Tagging case studies - yes that makes sense - so then the hard node reference to the actual project (as opposed to a mention) means you could have a view of case studies showing all the modules used with direct links, browsable by tag. So in the right sidebar of the download and extend page, you still have a list like: Media Government Technology Upon clicking media, you'd see: - Warner Bros. | Views, CCK, Embedded Media Field | some other tags | date posted (or whatever) Some Record label | Audio, Panels Photo gallery site building howto | imagefield, imagecache, lightbox etc. etc. The advantage there is you get lists of modules which are actually used / documented, rather than lists of modules who's authors could be bothered to tag them. And yeah there's definitely no harm in having the vocabulary and trying it out for a while, I was just very fond of the showcase idea and didn't want it to get lost ;) Nat On Thu, Feb 12, 2009 at 3:11 PM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
Then instead of referencing the nodes from the case studies attaching taxonomy terms to the references, we can tag the case studies themselves, and just have taxonomy lists of case studies on those links, can't we? I mean if you'd use this data from actual case studies, then why not show the modules in context, where the usage is actually described?
Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well.
Gábor
On Thu, Feb 12, 2009 at 2:15 PM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
In the redesign discussions, we'd discussed having nodereferences between case studies, site recipes and projects for this purpose rather than tags. That way, people documenting how particular types of sites are built could show which modules they used - as opposed to project owners saying 'I think this might be useful for'. You could then show showcases and site recipes next to modules, and modules next to showcases and site recipes in a structured way (and with some data munging, get aggregate data if needed). Was this discussed as an option?
Nat
Case studies referencing projects via a nodereference provides a nice way of contextualizing how a module is used. While improved tagging (and active maintenance of the tagging structure) would also be helpful, seeing links to case studies that incorporate a particular module from the project page would be very useful. Of course, this list would be very long on project pages for views and cck, but that can be managed. An aside here: the mention of e-learning as a category points at both a shortcoming of the tagging system, and (IMO) a misunderstanding of e-learning. Many modules on d.o have applications within online learning, even if it's not immediately obvious -- and the purpose of the categorization system should be to extend what is immediately obvious. While modules like quiz and gradebook have a specific elearning component, they are the exception. Pathauto and token are pretty critical for online learning sites, for exactly the same reason they are useful outside of a learning context. Cheers, Bill Nathaniel Catchpole wrote:
Tagging case studies - yes that makes sense - so then the hard node reference to the actual project (as opposed to a mention) means you could have a view of case studies showing all the modules used with direct links, browsable by tag.
So in the right sidebar of the download and extend page, you still have a list like:
Media Government Technology
Upon clicking media, you'd see: - Warner Bros. | Views, CCK, Embedded Media Field | some other tags | date posted (or whatever) Some Record label | Audio, Panels Photo gallery site building howto | imagefield, imagecache, lightbox
etc. etc.
The advantage there is you get lists of modules which are actually used / documented, rather than lists of modules who's authors could be bothered to tag them.
And yeah there's definitely no harm in having the vocabulary and trying it out for a while, I was just very fond of the showcase idea and didn't want it to get lost ;)
Nat
On Thu, Feb 12, 2009 at 3:11 PM, Gábor Hojtsy <gabor@hojtsy.hu> wrote:
Then instead of referencing the nodes from the case studies attaching taxonomy terms to the references, we can tag the case studies themselves, and just have taxonomy lists of case studies on those links, can't we? I mean if you'd use this data from actual case studies, then why not show the modules in context, where the usage is actually described?
Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well.
Gábor
On Thu, Feb 12, 2009 at 2:15 PM, Nathaniel Catchpole <catch56@googlemail.com> wrote:
In the redesign discussions, we'd discussed having nodereferences between case studies, site recipes and projects for this purpose rather than
tags.
That way, people documenting how particular types of sites are built
could
show which modules they used - as opposed to project owners saying 'I
think
this might be useful for'. You could then show showcases and site recipes next to modules, and modules next to showcases and site recipes in a structured way (and with some data munging, get aggregate data if
needed).
Was this discussed as an option?
Nat
-- Bill Fitzgerald http://funnymonkey.com FunnyMonkey -- Click. Connect. Learn. ph. 503 897 7160
On Thu, Feb 12, 2009 at 6:11 PM, Bill Fitzgerald <bill@funnymonkey.com> wrote:
An aside here: the mention of e-learning as a category points at both a shortcoming of the tagging system, and (IMO) a misunderstanding of e-learning. Many modules on d.o have applications within online learning, even if it's not immediately obvious -- and the purpose of the categorization system should be to extend what is immediately obvious. While modules like quiz and gradebook have a specific elearning component, they are the exception. Pathauto and token are pretty critical for online learning sites, for exactly the same reason they are useful outside of a learning context.
How would ecommerce be different for example? Pathauto and token would equally apply. Or blogs. There are definitely modules applying for all site types for sure. Drupal by nature has more of these modules then specific ones IMHO. Gábor
On Feb 12, 2009, at 7:11 AM, Gábor Hojtsy wrote:
Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well.
Can we at least make it not a required field in the short term? I just tried to edit one of my project pages (signup[1]), didn't see any "Types of sites" terms that really seemed appropriate ("collaboration", "community"?), and now I have to come up with some half-baked term association to be able to edit anything about this project. Furthermore, what am we supposed to do for modules like CVS deploy[2] and/or Update status[3] that have nothing to do with the "type of site"? Should we add an "<any>" option? Or, are these other good use- cases for making it not required and not having any terms selected? If I select all a) it's noise in each category, b) I'll have to keep remembering to select all as new terms are added, c) the project page (assuming it will list all the site type terms) will get ugly and busy. Thanks, -Derek (dww) p.s. For the record, I'm vastly more in favor of the case study + node reference approach catch is advocating. ;) [1] http://drupal.org/project/signup [2] http://drupal.org/project/cvs_deploy [3] http://drupal.org/project/update_status
On Feb 13, 2009, at 3:28 AM, Derek Wright wrote:
On Feb 12, 2009, at 7:11 AM, Gábor Hojtsy wrote:
Note: IMHO we can remove the types of sites vocabulary always, if we find it is not working well.
Can we at least make it not a required field in the short term?
Please yes. I just tried to reset the format on a project back to filtered HTML for someone and got the angry read required category. It's not my module, but looks to me like one that can be used anywhere so I selected all. Not really my place to decide that though and I still hold that this won't be helpful forcing everyone to pick all of them. As Derek suggested, if it is required, please add an "any" option. - Addi
On Feb 13, 2009, at 2:50 AM, Addison Berry wrote:
Can we at least make it not a required field in the short term?
Please yes.
That's good enough for me. ;) No longer required.
As Derek suggested, if it is required, please add an "any" option.
I added "- Any -" to the mix, too. Even if it's not required, that's probably a reasonable option to have. Cheers, -Derek (dww)
On 13-Feb-09, at 10:52 AM, Derek Wright wrote:
I added "- Any -" to the mix, too. Even if it's not required, that's probably a reasonable option to have.
I would suggest removing "None" now that "Any" is available. To me "None" means "this code isn't usable anywhere, avoid it!". I'm sure this was talked about in the redesign somewhere, but I think moving that field out into a user-vote kind of field would be much more useful. As a module maintainer, *I* have no idea what users are using my code on except in cases where they report a bug and mention the site. I think it's fair to assume that most maintainers know their own (often off-the-wall) use cases, but not too much beyond that. Imagine if when a logged in user downloaded a module upgrade (since we could track their previous downloads if they were logged in), an option appeared asking them to fill in where they use the module. They could optionally put in a URL, along with an industry / segment / something. Or, it could just appear all the time near the "module rating" section in the iteration 11 mockup. This could even help long term usability of modules since maintainers might actually get some basic data about the profiles of their users. It could be a real boon to know that "most of my users are in education, so use terms which they're familiar with and don't have conflicting definitions". --Andrew
participants (15)
-
Addison Berry -
Andrew Berry -
Bill Fitzgerald -
Dan Smith -
Derek Wright -
Dmytro Solodovnyk -
Dries Buytaert -
Greg Knaddison -
Gábor Hojtsy -
Kathleen Murtagh -
Kieran Lal -
Kyle Mathews -
Nathaniel Catchpole -
Ryan Cross -
Victor Kane