Page MenuHomePhabricator

Autocomplete on Subcategories
Closed, DeclinedPublic

Description

I would like to autocomplete on Subcategories.
Currently, if I use "values from namespace=Category", I get all existing categories as suggestions; if I use "values from category=ParentCategory", I only get the pages in the main-namespace as suggestions but the subcategories are obviously in the Category-namespace.

Event Timeline

The "tree" input type is probably better suited for that kind of thing. Do you know about "tree"? And if so, do you still think autocompletion is preferable?

Missed the tree-input so far, thanks for pointing it out! Essentially, tree is great for choosing out of already existing subcategories. The problem is, that I would like to give the user the ability to type in a new category name. That's why I use combobox so far. I now thought about a combination of "show on select" (to display a textbox for input of the new name) and tree but then two new problems arise: 1. show on select is not supported by tree. 2. I would have to add an entry in the tree with something like "create new". That would have to be a subcategory itself (not very elegant) because manually adding something to the tree is not possible (probably with good reason).

Btw: When the user chooses a new category name, I can assign the page that is created by the form to this category but of course the page Category:NewCategoryName is not created by that (and not assigned as a Subcategory of the Category i let the user choose from). I thought about somehow using #autoedit to do this in background but the function refuses to create pages in the Category-namespace. Is there a good reason for that?

I would like the same thing, if possible - to present existing categories as options but allow creation of new categories.

This is an interesting issue - there are technical, UI/UX and data design concerns here.

Let me start by saying that one my philosophies during the development of Page Forms has been that users should only be doing one thing at a time. In this case, a user could both modify a page, and modify the data structure, at the same time, which seems like it could cause confusion - and it would go against that philosophy.

On the other hand, there are probably hacks to enable this anyway, such as by using #autoedit. Plus it does seem like a neat feature. MS Windows lets users create and rearrange directories at the same time as they're going to save or open a file, which I sometimes use, and which is more or less the same thing we're talking about here. One big difference is that in Windows there's usually only one user at a time, whereas here you could be modifying a category tree while someone else is using that tree. It's probably not a major concern, though - edit conflicts can happen in a variety of different ways, and they get dealt with.

A possibly bigger issue is that category trees themselves are, in my opinion, not an ideal data structure. They're used in Page Forms to define hierarchies, but they're mostly used because that was the easiest way to define them. When category trees are created for the purpose of being displayed as input trees in a form, they're not being used for the original purpose that MediaWiki categories are created for: in other words, if page A gets added to category B, it's only for purposes of tagging and querying; no one is expected to go to the page Category:B to check out what pages are there, and traverse through the tree. (Let me know if I'm wrong about that.)

In the Cargo extension, there happens to be a Google Summer of Code project currently underway to let hierarchies be defined directly for each field that uses one - they're defined directly in the template, in the same way that you can already define a hierarchy directly in a form definition, using the "tree" input type's "structure=" parameter. I'm hoping that this Cargo feature will succeed, and perhaps Semantic MediaWiki will eventually get a similar way to define hierarchies, within the property page. So perhaps this use of categories will become obsolete.

Then again, one nice feature of using categories to define hierarchies is that anyone can modify them - it doesn't need to be restricted to people who can modify forms/templates/properties, assuming there are restrictions on those. Regular users can make changes to the hierarchy without worry that they'll break something major.

So as you can see, I'm torn on this. (And that's without even getting to how exactly this could be implemented, on a technical level). Any feedback would be helpful - I'm especially curious to hear whether you're actually making use of these categories, or whether you just use them as a convenience for inputting data.

@Marccreal - as for #autoedit of "Category:" pages, that was removed fairly recently as part of an attempt to improve security, though it could be restored - the real goal was removing #autoedit access to "MediaWiki:" pages.

in other words, if page A gets added to category B, it's only for purposes of tagging and querying; no one is expected to go to the page Category:B to check out what pages are there, and traverse through the tree. (Let me know if I'm wrong about that.)

I have a DPL query (which could be replaced by a Cargo query) in each Category page and people do click the category link to get more details of each page in that category.

I also use the Category Tree extension as the initial way to browse the categories.

#autoedit of "Category:" pages, that was removed ...

This would probably be useful for me (though I haven't tried #autoedit yet).

A possibly bigger issue is that category trees themselves are, in my opinion, not an ideal data structure. [...] if page A gets added to category B, it's only for purposes of tagging and querying

I would concur that category trees that are created solely for input trees in forms are not ideal. But in my wiki, that's not the case. I have set up a wiki for a laboratory and people can use a form to create pages about lab devices (the Device-pages are added to a "Devices"-Category). To get a certain categorization of the devices, the users has the possibility to input a subcategory for the device-page he is creating (for example "Power supply", "Oscilloscope"...). That's why I use a combobox with autocompletion to let the user know about already existing subcategories. Of course, those Category-pages will also be used by the users to see what devices are available (of a certain type).

There goes my theory, then! Well, perhaps re-adding #autoedit support for category pages will be enough to get this working, at least via a hack. I'll look into that.

Okay, I just added "Category" back to the set of namespaces that #autoedit is allowed on. Is that enough to fix this issue? Or would you want some way to do inline editing within the "tree" input?

Hm I have to think about the best way to implement that with #autoedit. With inline editing within the tree you mean creating categories there "on the fly"?
What about the original request "autocomplete on Subcategories."?

Yes, I mean creating categories on the fly - and adding them to the appropriate parent category. This could potentially even mean editing multiple category pages at the same time: if a new category is added "between" two existing categories, then the subcategory needs to be modified to have a new parent category.

Right, I wasn't sure whether to comment further on "autocomplete on subcategories"... it just seems to me that a tree input is a much better input for categories than autocompletion. If you still think "autocomplete on subcategories" is worthwhile, let me know and we can discuss it.

Hi @Yaron_Koren
I see that this discussion is over three years ago, but happens to be that was about the autocomplete, which is a task in the GSoC I am proposing.
I am not sure whether or not implementing this may help your philosophy. So, do you recommend me to consider it for now?!

@AmrEl-Absy - I still don't think it makes sense to support this feature. I should probably mark it as "Declined".

I would like the same thing, if possible - to present existing categories as options but allow creation of new categories.

Currently (for the idea above) I am using the "tree" input type, and it works well. It would be good if it could allow the user to add a new category (as well as choosing from existing ones) and would be ideal if that category page somehow got created automatically... I guess I should create a new topic for that though!

Yes, that would be a separate issue. Okay, marking this as "Declined"...