Tarek Ziadé wrote:

Hi Tarek,

first of all thanks for addressing this. I consider this really
a great addition and I have been playing with your branch a bit
recently.

I agree with you that we should use the Trove classifiers as
much as possible but obviously this is a challenge for the UI.

Before commenting on your specific points just a general remark
or question from my side:

 - are we sure we know what use cases we want to cover?

   plone.org and the Plone community itself is obviously
   one as PSC was developed for that purpose in the first
   place but as PSC turns out to be fairly generic (could be
   better of course, like supporting a language field OOTB)
   it could be used for other target groups as well.
   I for one am setting up a site for a specific scientific
   community that also produces and publishes code.

I guess we should be careful to keep PSC and in particular
its web UI useful even for people that find the Trove
classifiers intimidating or too limiting or simply not
fitting their use case.

I'm not saying that would be hard or we would be way off
I just want to reinforce that IMHO we should have that in mind.

Now to the details:

Ok, here's my proposal. That's a lot of work, so I need to make sure that's
what everyone involved agrees before I code it:

1/ A new field is added, called Trove, that contains the flat list of classifiers

+1

2/ Each one one of this field become a single value that is
   hooked to the Trove by its first discriminant:


I understand this to mean the default value for the categories etc
vocabularies as you define them on the main SC instance, right?
If so, site managers would still be able to prune the list and/or
override the label shown in the UI etc.

   Categories = 'Topic'
   Available licenses = 'License'
   Platforms = 'Operating System'

3/ The Version field stays like it is, and keep by default
   Plone versions


This is a field that makes not much sense from a generic
perspective anyway, so fine with me.

4/ The leave of the trove branch is used to display the elements

For instance, this classification: Topic :: Internet :: WWW/HTTP :: Site Management :: Link Checking
Topic :: Multimedia
Topic :: Multimedia :: Sound/Audio :: Analysis
License :: Nokia Open Source License (NOKOS)
License :: OSI Approved :: Academic Free License (AFL)
Operating System :: Microsoft :: Windows

Will end up having on the front page of PSC three categories:

Link Checking | Multimedia | Analysis

The only problem with that is that the leaves labels are not unique, for
example:

Topic :: Desktop Environment :: K Desktop Environment (KDE) :: Themes
Topic :: Desktop Environment :: Window Managers :: CTWM :: Themes

Would end up into a front page with two 'Themes' that does not refer
to the same leave.

To prevent it, the front page could look like this:

Internet :: WWW/HTTP :: Site Management :: Link Checking | Multimedia |
Multimedia :: Sound/Audio :: Analysis

But this doesn't look right... So my proposal is to compute a unique label
for each leave, by adding the previous node for the leaves that have the
same label, in order to have the shortest unique name.


As long as it can easily be overridden manually (like indicated above)
I think it is OK to apply whatever magic we want to come up with a
sensible default.

I only think we shouldn't exclude the use case where people want to use
a completely customized way to do the thematic grouping (e.g., for my
current use case it would be rather something like
modeling platform | specific model implementation | data analysis tool | ...) while still supporting the use of Trove classifiers where it
makes sense (license, language, platform, etc but also a more generic
categorization).

Maybe it would even be worthwhile to support the configuration
of a more explicit mapping from Trove's Topic classifiers to
PSC 'categories' - I don't know.


5/ The user will have to manage the trove himself, and a trove editor could
help him a little bit.
My proposal on this is to provide a form that contains the whole trove in a
text area


Might be a use case for the UeberSelectionWidget (usw)
https://svn.plone.org/svn/plone/plone.app.form/branches/plip201-usw/


So much from me at the moment,

        Raphael



Regards
Tarek




_______________________________________________
Product-Developers mailing list
[email protected]
http://lists.plone.org/mailman/listinfo/product-developers

Reply via email to