User login

Syndicate

You are here

Lets come up with a better categorization!

I don't know whether the categorization through tags as currently used helps anybody -- there seem to be an awful lot of tags and even reading through the list takes ages.

As far as I can tell, we have tags of the following sorts:

Tags for the old menu categories or sub-categories such as "filter", "blur", "blend", "color" and so on

Various functional tags such as "grain removal", "generate", "stereoscopic", "resize", etc. This is what I personally would have expected as tags and it is quite a large category unto itself.

Version numbers, such as 2.4 or "gimp 2.x". I am not sure whether these are meant to apply to the plugin or the gimp version. In the latter case, they are a duplicate of whats already available in another category. If they are meant for the plugin, that is quite confusion.

Type tags such as "script", "script-fu", "plugin", etc. Again, these are a duplicate of something that is explicitly given before. I wonder why people add these?

Language tags such as "python" and "perl". More duplication, as this is already implied by the "scripting engine" category.

Wrongly separated tags such as "2.6 tiles generate wallpaper desktop" or "dvdauthor spumux dvd menu Python-fu titles" (all as one tag). These seem to be the result of user error, caused by the inconsistent usage of spaces vs. commas as separators on the various tag-supporting sites.

Tags that duplicate the plug-ins name or effect, e.g "Che Guevara", "Lightsaber" or

Pure numbers, e.g. "4444" or "5551". These appear to be used by just one plugin, the RAWTex plugin, which uses them to mark RGBA formats.

Well, I may have missed a few types of tags but even so, a picture emerges.

A thing I truly wonder about is this: Why do people add tags for things that have their own categories, such as the license, language and gimp version? I have no explanation for that. For the other things, what I would have liked to do for some of them is to add explicit categories which users can select from. However, if users would still add the same things as tags, that doesn't make sense.

Sometimes tags are beneficial, other times, not. I tend to look for the "effect" of a plug-in or script, and not an author name, or combo of both.

Someone mentioned changing the way the Registry tiers plug-ins and scripts (I can't remember who that was, Rob A. or Photocomix, perhaps?) I, more or less, agreed with the request to make things easier to find and more organized. (I think this was aimed at forming standards for how plug-ins and scripts are classified in the GIMP menu)

Then I read your comment here and felt now is as good a time as any to "make it happen" for forum categories. There is only one problem, everybody has to be on board in order for it to be successful. If tags are still going to be the factor in searches, they need to be used wisely. How do we determine what is a good or bad tag?

I guess the first thing that would need to be done in order to obtain maximum organization and efficiency is to lay out what you think the categories should be. If someone were to ask me, I would look at the GIMP menu and compare scripts/plug-ins to that hierarchy and then layout the scripts/plug-ins according to that structure. The GIMP menu fairly indicative of what script is where and it hasn't changed that much over the years. Just a few ideas to toss around and get some additional feedback.

I've not yet been able to find scripts on this site using the tags. The most productive way for me was simply browsing either from the home page or through the list or by using keywords. I once discussed a similar matter with the writer of a picture organizing program. His software allowed me to attach no matter what tags to my pictures without any idea which tags I had previously used. That didn't work. I asked him to create a basic tag tree structure which would allow me to add my own branches and tags. In most cases both tagging and searching could IMHO be reduced to a few clicks on tags available in the tree structure. Unfortunately he didn't agree. I hope the overseer of this registry (is that Ingo?) does.
To start with, the tree could look something like this
Gimp version
-2.4
-2.6
graphics
photography
-sharpness
-noise
--add
--reduce
layers
colour
-hue
-saturation
and so on

I was never able to find a plugin here by looking for a reasonable tag..
and for what i uploaded i was never able to use the tags i wished
(This maybe for a bug now solved...at soon i chose 1 of the offered tag as "gimp-2.6 " then become impossible add any custom tag, ..try to type in the tag field create some critical error that made impossible add anything else there )

So i must confess that till now to search here the best way i found...is Google advanced search, limiting the search inside http://registry.gimp.org

Anyway also the side Search works fine till you may figure out the right keywords

I configured the Default Search manager in Google Chrome to use Registry as the keyword search. Then all I do is type Registry, hit Tab then type in my search parameters with the appropriate syntax. Works like a charm!

People add tags because they are there.
And they stay because there isn't any functionality for an admin to do changes to the tags in bulk, e.g. "everything that is tagged with 'Gimp2.6' should have this tags remvoed and a 2.6 version added instead", or "erase this tag from all plug-ins and add that one instead".

I guess that a viable approach - maybe even the only approach that is possible - it to delete all the duplicated or otherwise unsuitable tags, even if this leaves plug-ins or scripts without (some) useful tags.

In the past, I've tried to edit entries and change the tags (e.g. removed "2.4" and added it to the version), but the text editor makes this very hard (it deletes line breaks).

Barring any language barriers with users who provide scripts and plug-ins, it would take little effort to provide the authors of what a good tag is vs what a bad tag is. A few lines of text is all that would take (something a little more definitive when they are uploading the scripts/plug-ins).

Giving them a quick and simple example of both will motivate and encourage many to make better tag selections. Doing nothing, changing nothing results in nothing being accomplished.

Having said that, and using myself as an example, when I uploaded two upgraded plug-ins, I came to a crossroad of thought when trying to decide what to tag them, simply because I wasn't sure what to tag them. So, I added they were Python and the plug-in name simply because I didn't know the best category for them.

Therein lies a big chunk of opportunity if we can figure out how to categorize and convey to all the users the best way to utilize tags per respective script/plug-in.

If anything, we're on the right track by addressing the issue and looking for a way to remedy it. But like others who have thought of this before me, the first step should be introducing some sort of organization/categories system for GIMP that is easy to understand and use. It might not be the easiest to implement, but would be a step in the right direction.

I'm also standing back waiting to see what 2.8 looks like menu-wise, because in my opinion, the categories will be most manageable by using the menu as a guide. People can see how the menu is structured, and for the most part, more authors tend to follow what they see when it comes to plug-ins and scripts. Now if there was a way to pull a tag from the script register, it would be a slam-dunk (providing that authors followed a set of established guidelines when writing them).

This might seem redundant to some, but I find it becoming more of a necessity.

Open (free) tagging wouldn't even be a necessity if it were possible to add a tag line into the script/plug-in register, where it could be indexed and searched directly from the site or internet, even.

However, I have to agree with Photocomix on this one. Taking that source of tagging away might make script/plug-in authors feel excluded from the physical process of freely adding their own suggestions. In this case, simply giving them examples of "how to use the most effective tags" would be the best way to go.

It might be a good idea to present GIMP developers with the idea of adding a tag indexing code for the register - or otherwise incorporating some sort of tag line that once added to a script/plug-in, will make it searchable.

But it would also open the door to more tag involvement, where users would suggest to the author to use better tags to make them easier to find in a search. Having a hierarchy, like you mentioned earlier (following the GIMP menus) would be the catalyst in making those changes/improvements.

Which now makes me wonder if we shouldn't be suggesting better tag labels to the new scripts/plug-ins authors are currently adding to the Registry. We already make script change suggestions, why not suggest better tags, as well.

Half of them are probably useless anyway. The current system feels to me like little more than a truckload of confusion. It is ALMOST ridiculous. Presumably, the more content is uploaded here, the more confusing/annoying/ridiculous the whole thing will become. (Sorry, I'm really not trying to be harsh, but I think a change is certainly needed)

To get to "Home" just click the GIMP Plugin Registry title or the Wilbur Icon at the top left.

My take on the organization methods suggested by you, myself, and others, not to make little of your suggestions, is that the Registry is limited by the hosting application software - and - the logistics of "pleasing" everyone would become a horrific nightmare. But as I have mentioned before, something rather than nothing needs to be done to work toward improving the organization of this site.

Most likely, it would not be a full bore change, at least not until the application permits the brunt of what everyone would like to see done.

Personally, I would like to see the scripts and plug-ins follow the GIMP menu, and I hope that ONE day, a standard can be applied to how scripts and plug-ins are categorized. Again, although my idea is "ideal", it would be nearly impossible to enforce. Although I do believe it would be somewhat possible to maintain a GIMP menu category on the Registry, at least for classification purposes (making them easier to find and understand their purpose). Doing that might eliminate the need for a tag cloud site-wise.

I was speaking specifically about the plug-in organization here on the site, although I can certainly see where some kind of categorization standard is needed for the organization within Gimp itself.

I'm not sure I understand how the hosting application software limits the ability to organize the plug-ins, in part because I don't know what the software actually is. Any modern hosting software should allow for some degree of versatility.

My intention was not to just bash the tag method. I made another thread that contained my ideas, which in retrospect I should have probably posted in this thread. But to summarize what I said there, I basically said that much of the "valuable" space that could be used to describe the function of a particular filter is more or less wasted on the tags and the filename.

I don't think it would be very difficult to come up with a standard for filter and plug-in submission, but like you said, enforcing the standard could prove to be difficult. Then again, those capable of writing filters and plug-ins should be intelligent enough to follow directions. Then again I could be completely wrong and may be misunderstanding the issue. I have only been coming here for a few days and I have only been using GIMP for a little longer than that (though I rather like using it). The fact that I have been here for such a limited amount of times yet immediately saw the organizational problems should say a lot (about the issue at hand, that is). I do love the fact that this, GIMP, and really the entire Linux world is more or less a community project, because I despise the commercial software industry. Unfortunately though, it would seem that the price for having a vast volunteer community effort is the lack of focus/direction. Everyone has different ideas about how to proceed. Like I said elsewhere, I would love to help if possible.

P.S. I now see where clicking the logo returns you to the home page. Thank you.

I was referring to plug-in and script organization (placing them in categorical hierarchies, etc., namely compared to how the GIMP menus lay out). You can't go wrong, if you ask me.

Searching for a Selection script/plugin? Look in the Selection category. Maybe I am not reading you correctly, but that is what I am referring to when it comes to organization.

As for the host application, the site uses Drupal. There are limitations to how it works or how it can be used, in "some" instances. It can range from issues of how you want your information to be laid out (in our case, organization or categorization of plug-ins and scripts). It might require writing modification scripts (MODs) to get those results. Until a plan is drawn up and discussed, those of us unfamiliar with the internal workings of Drupal have no idea what is or isn't possible. Since Ingo has his hands full, I don't press the issue in that regard.

I have a love/hate relationship with tags, so nothing you have said was taken personally. Tags are comparable to generic grass seed. When sown, they have half as much weed seeds mixed in, but they are still green in color, so your lawn looks "covered". That's the gist of tags.

Feel free to get in touch with Ingo through his Contact link, let him know how you can help. Who knows, the right group of people with all the right skill sets could make it all happen. Just try not to let discouragement sneak up and, well, "discourage" you. I get most of my GIMP knowledge right here. Lots of cool, interesting, and intelligent people from all over the world, keep me in awe everyday. To me, that's what the Registry is all about.

Ahh, I now see what you were saying about Drupal. Essentially all of the examples I have seen of Drupal web sites have a standardized look to them. I imagine that it can be a versatile tool, and there may even be an existing module that will do what is needed (whatever that might turn out to be). Unfortunately though, to make extensive changes one needs substantial knowledge about Drupal's module API and PHP.

is a bit misleading. For instance, my perl plugins all went into the "Plugin" category, because thats what they are: They live in ~/.gimp-x.y/plug-ins, have the execute bit set and start with #!/usr/bin/perl. Perhaps it should say something like

Finally, i agree with the suggestion by someone here, namely to replicate the menu-tree from Gimp. All those "<Toolbox>/Xtns/Web Page Themes/..." and "<Image>/Filters/Render/..."-lines could easily be extracted automatically from the uploaded scripts.

Cheers

OT:

"We are sorry, but the spam filter on this site decided that your
submission could be spam."

Strangely, it *always* decides so. Why not introduce a "trusted user" status that will be set after, say, 10 submissions that are not spam? And please give me back the "Report Spam" button.

It would be good for not sending yourself a notification of your own posting. Which, was a bit ironic and amusing at the same time, considering I was expecting the post to be from someone other than myself. What perplexes me is, most forum software has code built into the modules to prevent someone from receiving a notification of their own posts, but apparently Drupal doesn't do this, or at least it hasn't prevented me from getting notified - unless - I check that box.

... for people who like to have all their stuff in one place, namely in their email-program. Only that it didn't work that way: I left the "Do not send" checkbox empty and still got no copy of my posting above....

I've left it empty since my last comment in this thread and have not received any notifications of my own postings thus far (knocking on wood). Perhaps it was just a short series of fluke incidents on the other previous postings (or Ingo fixed it).

I think Ingo pretty much warned us that notifications were going to be a little "wonky" (my term for unpredictable) and so far it has proven to be a true assessment.

As I continue experimenting on which posts I subscribe to and which I accept notifications for, it has been hit and miss. Sometimes I get notified of my own post, other times I do not. But so far, I have gotten email notifications for every post I am subscribed to. (Knock on wood, lest Murphy sets out to prove me wrong). I don't care so much about getting notified of my own post as much as I do prefer being alerted when someone replies to a post of mine.

I don't think receiving one's own posts is intended, but I guess it may happen due to the way notifications are generated with a delay (for performance reasons). You should see all posts by others, though!