Last modified: 2011-07-24 11:42:35 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T22678, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 20678 - List of essential features for AJAXCategories
List of essential features for AJAXCategories
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Categories (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-17 10:17 UTC by Lupo
Modified: 2011-07-24 11:42 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Lupo 2009-09-17 10:17:02 UTC
First off, I know this AJAXCategories feature only from this mailing list discussion:

http://lists.wikimedia.org/pipermail/wikitech-l/2009-September/045203.html

Glad to see that HotCat is on its way to make into the standard MediaWiki.

I glanced over the JavaScript code, and it seems to me that compared to the currently active HotCat versions at the English Wikipedia and at the Commons (that's two different versions!), this new implementation is missing several essential features:

- Changing an existing category. Maybe I overlooked it, but I only see support for adding and deleting categories as two separate operations.

- I didn't look at the suggestion code in depth. Just a question: does it do the replace-and autoselect stuff HotCat currently does? (It places the first suggestion, if the user's input is still a prefix match, into the input box and selects the new suffix such that it is overwritten if the user keeps typing. Kind of an auto-completion feature.)

- Does/can it automatically resolve hard and soft category redirects? (HotCat does. Might be difficult to do in a general library since different wikis may have different ways to do soft redirects. If it can't be done in your core code, please provide easy hooks where people can plug-in a resolution mechanism (which might make an API call itself, so prepare for continuations). In any case, this feature is essential enough at the Commons that a replacement for HotCat would need to provide it.)

- Does/can it automatically handle disambiguation categories? (Same comment as for redirects applies).

- Does/Can it automatically remove {{uncategorized}} templates? (Same comment as for redirects applies).

- Does/Can it omit handling of transcluded categories? (HotCat doesn't do that currently. Either would need to get the page text up front and check which categories occur directly in the text, or a server-side change that would mark transcluded categories in the served (X)HTML, maybe using a class.)

- In HotCat, users can temporarily switch off auto-saving by ctrl-clicking.

- The HotCat at the English Wikipedia tries to figure out the right place to add new categories. Basically, where there already are categories. Just appending at the end may lead to a cluttered wikitext with intermingled categories and interwiki links.

- At the Commons, HotCat ties into the upload form.

- Confirmation dialogs should be optional; at least logged-in users should have the ability to switch them off.

- Edit summaries need not be localizeable to wgUserLanguage, it's sufficient if they are always in the wgContentLanguage of the wiki. An Arabic edit summary at the English Wikipedia is utterly useless to most contributors there (as only a few can read Arabic). Edit summaries are first and foremost for the benefit of the other editors at a wiki, not for the editor making the edit.

- It also seems to me that the current implementation makes three requests for each category change (without the suggestions): one to get the page and the edit token, a second one to save, and a third one loading the page again to refresh the category list. Isn't this last request unnecessary? It is known which category was added/deleted/changed and how, so the DOM could be adapted accordingly on the client side without reloading the page.

- If HotCat is to be replaced/reimplemented, finally implement adding/changing/deleting several categories at once. Otherwise, there's no real gain. Just reimplementing working code because the new code might look nicer is, IMO, not enough reason to do it. HotCat is pretty much self-contained and works well, so there is no pressing need to refactor it unless there is functionality it cannot do without a refactoring. (Of course, one reason to refactor is also to include it in the standard distribution. But then it should at least provide all that the current solution provides.)

- It would also be nice if a re-implementation of HotCat offered the ability to browse the category tree besides its prefix-based auto-suggestions.

- What's the status of bug 19586? Should IMO be resolved before jQuery is deployed globally.

- What about IE ActiveX alerts? Currently, HotCat is a gadget to be enabled explicitly by a user, so that's tolerable. But if this jQuery-reimplementation of HotCat is enabled for everyone by default, it must not cause spurious "Do you want to allow ActiveX execution"-alerts for IE users.

I hope you find at least some of these comments useful.
Comment 1 Derk-Jan Hartman 2009-09-17 12:42:17 UTC
Euh a note, I was reworking HotCat for en.wp with some of the same features. It isn't fully jQuery yet, since I didn't really get around to that yet.


http://en.wikipedia.org/wiki/User_talk:TheDJ/HotCat#First_test_round_for_CatBurn
Comment 2 Roan Kattouw 2009-09-17 12:45:46 UTC
(In reply to comment #0)
> - What's the status of bug 19586? Should IMO be resolved before jQuery is
> deployed globally.
> 
jQuery is only loaded when necessary, i.e. on the edit form if the usability toolbar is enabled and on page views if AJAXCats is enabled. It's never necessary on the login form, so it isn't enabled there, hence bug 19586 doesn't block deployment of AJAXCats.

> - What about IE ActiveX alerts? Currently, HotCat is a gadget to be enabled
> explicitly by a user, so that's tolerable. But if this jQuery-reimplementation
> of HotCat is enabled for everyone by default, it must not cause spurious "Do
> you want to allow ActiveX execution"-alerts for IE users.
> 
Neither jQuery nor AJAXCats use ActiveX in any way. The fact that HotCat does scares me.
Comment 3 Derk-Jan Hartman 2009-09-17 13:07:04 UTC
XHR is implemented as Active X in old versions of IE.
Comment 4 Andrew Garrett 2009-09-17 13:19:34 UTC
(In reply to comment #0)

I'll note first that while there's plenty of stuff that I'd like to do with this, I don't necessarily have the time for them between my other commitments. This was intended primarily as something simple, to hack on at Wikimania, that would measurably improve MediaWiki's usability.

It would have been nice if this bug report was submitted as a few separate bugs so I could track them separately, but oh well :0

> I glanced over the JavaScript code, and it seems to me that compared to the
> currently active HotCat versions at the English Wikipedia and at the Commons
> (that's two different versions!), this new implementation is missing several
> essential features:
> 
> - Changing an existing category. Maybe I overlooked it, but I only see support
> for adding and deleting categories as two separate operations.

Could be done, I suppose.

> - I didn't look at the suggestion code in depth. Just a question: does it do
> the replace-and autoselect stuff HotCat currently does? (It places the first
> suggestion, if the user's input is still a prefix match, into the input box and
> selects the new suffix such that it is overwritten if the user keeps typing.
> Kind of an auto-completion feature.)

The suggestion code is the same code that is being developed by the usability folks for search suggestions. I don't think it does what you suggest yet.

> - Does/can it automatically resolve hard and soft category redirects? (HotCat
> does. Might be difficult to do in a general library since different wikis may
> have different ways to do soft redirects. If it can't be done in your core
> code, please provide easy hooks where people can plug-in a resolution mechanism
> (which might make an API call itself, so prepare for continuations). In any
> case, this feature is essential enough at the Commons that a replacement for
> HotCat would need to provide it.)

I don't understand why you would have soft redirects, it seems totally bizarre. Probably not something I'd like to provide core support with.

A hooking mechanism may be a decent solution.

> - Does/can it automatically handle disambiguation categories? (Same comment as
> for redirects applies).

What's a disambiguation category?

> - Does/Can it automatically remove {{uncategorized}} templates? (Same comment
> as for redirects applies).

My response is roughly the same, also.

> - Does/Can it omit handling of transcluded categories? (HotCat doesn't do that
> currently. Either would need to get the page text up front and check which
> categories occur directly in the text, or a server-side change that would mark
> transcluded categories in the served (X)HTML, maybe using a class.)

It doesn't make sense to allow people to remove transcluded categories. Currently it just gives an error message.

> - In HotCat, users can temporarily switch off auto-saving by ctrl-clicking.

Yes, I'd like to replace the current automatic save with accumulating the edits, then clicking "Save" to enter an edit summary and confirm the edit.

> - The HotCat at the English Wikipedia tries to figure out the right place to
> add new categories. Basically, where there already are categories. Just
> appending at the end may lead to a cluttered wikitext with intermingled
> categories and interwiki links.

Yes, this might be a nice idea.

> - At the Commons, HotCat ties into the upload form.

That would also be interesting, but I think the real solution is a better upload form.

> - Confirmation dialogs should be optional; at least logged-in users should have
> the ability to switch them off.

Maybe.

> - Edit summaries need not be localizeable to wgUserLanguage, it's sufficient if
> they are always in the wgContentLanguage of the wiki. An Arabic edit summary at
> the English Wikipedia is utterly useless to most contributors there (as only a
> few can read Arabic). Edit summaries are first and foremost for the benefit of
> the other editors at a wiki, not for the editor making the edit.

Yes, I think it's in the user language right now. Should be localised to the content language.

> - It also seems to me that the current implementation makes three requests for
> each category change (without the suggestions): one to get the page and the
> edit token, a second one to save, and a third one loading the page again to
> refresh the category list. Isn't this last request unnecessary? It is known
> which category was added/deleted/changed and how, so the DOM could be adapted
> accordingly on the client side without reloading the page.

It's possible to do this, but it's much easier and much more reliable to just reload the category section.

> - If HotCat is to be replaced/reimplemented, finally implement
> adding/changing/deleting several categories at once. Otherwise, there's no real
> gain. Just reimplementing working code because the new code might look nicer
> is, IMO, not enough reason to do it. HotCat is pretty much self-contained and
> works well, so there is no pressing need to refactor it unless there is
> functionality it cannot do without a refactoring. (Of course, one reason to
> refactor is also to include it in the standard distribution. But then it should
> at least provide all that the current solution provides.)

As mentioned above, accumulating changes is on the cards.

I wrote about HotCat's other shortcomings on wikitech-l, and it should be noted that this implementation is intended primarily as an inclusion of HotCat's features in the standard MediaWiki distribution, for all users, and implemented to MediaWiki's high code standards.

> - It would also be nice if a re-implementation of HotCat offered the ability to
> browse the category tree besides its prefix-based auto-suggestions.

Nice idea, but I'm not sure if this is something I'm willing to spend time on implemented.

(In reply to comment #3)
> XHR is implemented as Active X in old versions of IE.
> 

We're definitely not going to forego using XHRs because old versions of IE pop up a stupid warning.

We already use them for a few things.
Comment 5 Lupo 2009-09-17 13:59:16 UTC
> Nice idea, but I'm not sure if this is something I'm willing to spend time on
> implemented.

Understandable, but I just hope the rewrite (which I warmly welcome, mind you)
provides at least the functionality of the existing solution, or at least doesn't
block the way to patch it so that it does what has proven useful. HotCat is widely
used, so care should be taken not to disappoint users. Users don't care if it's crappy
years-old code or nifty jQuery stuff. They only care whether it reliably does what
they're used to.

> We're definitely not going to forego using XHRs because old versions of IE pop
> up a stupid warning.

It's not just old versions of IE. IE7 and IE8 also have that dreadful "security" option
to prompt for ActiveX execution, and jQuery loads on IE the ActiveX variant even if
window.XMLHTTPRequest exists. Check for yourself in the jQuery sources. The following
snippet is directly from the jQuery 1.3.2 sources:

// Create the request object; Microsoft failed to properly
// implement the XMLHttpRequest in IE7, so we use the ActiveXObject when it is available
// This function can be overriden by calling jQuery.ajaxSetup
xhr:function(){
  return window.ActiveXObject ? new ActiveXObject("Microsoft.XMLHTTP") : new XMLHttpRequest();
},

There you are.

Comment 6 Lupo 2009-09-17 14:07:04 UTC
> It doesn't make sense to allow people to remove transcluded categories.
> Currently it just gives an error message.

Of course it doesn't! That's the whole point! The tool should not offer change/delete
on transcluded categories in the first place.

> What's a disambiguation category?

It's basically a disambiguation page in category space. You don't ever want to
add the disambiguation category anywhere, but you use it to help the user figure
out the real category he or she should add.

Comment 7 Lupo 2010-06-02 09:56:00 UTC
Just FYI: http://commons.wikimedia.org/wiki/MediaWiki:Gadget-HotCat.js has been updated recently and is used already at de.wikipedia.org (copy) and cs.wikipedia.org (hotlinked), and at de.wikiversity.org (also hotlinked). If you want to take this into core, the Commons version is probably the one to look at. Apart from the things mentioned originally, it also does multiple category changes, integrates the category tree (a bit awkwardly, but well...), and skips transcluded categories. It doesn't use jQuery on purpose so that it works in all skins without having to include a copy of jQuery on-wiki, and to keep it all in one file to facilitate hotlinked uses.
Comment 8 Neil Kandalgaonkar 2010-07-12 22:38:18 UTC
Another FYI: I'm implementing a category picker for UploadWizard. 

After reviewing both HotCat & AjaxCategories I reluctantly came to the conclusion I needed to implement my own.

HotCat has a lot of great features and is much more robust to how people use categories in the real world. Unfortunately the interface is confusing, especially with the recent addition of the hierarchy browsing features. Also, I see no good reason to eschew jQuery, which would make the extension vastly simpler.

AjaxCategories is decently usable, but the interaction assumes a little too much about what we're doing -- one commit message per category change, as far as I can tell. 

Here's the general plan: 
- Create a category adding and editing widget, that has no knowledge of how to update the wiki.
- Depending on use case, surround this widget with other widgets which:
   - configure the widget with categories, if we're editing categories, or using
      auto-suggested categories.
   - submit or otherwise use the categories as it sees fit, maybe adds commit messages, maybe not

Generally I am going to try to support as much of the feature set of HotCat as I can, while trying to make it more usable.

For the moment, I only need to be able to add multiple categories while uploading, so be patient for the more esoteric features of HotCat. Also I have a number of questions probably best resolved over email, or we can keep chatting here.

The current library I'm working on is at:
trunk/extensions/UploadWizard/js/jquery/plugins/jquery.mwCoolCats.js
Comment 9 Neil Kandalgaonkar 2010-07-13 18:43:46 UTC
Lupo: could you explain what the use cases are for hierarchically browsing categories?

At least the way I'm using HotCat, it seems to be easier to enter a category, then replace it with a category found by traversing the "up" or "down" directions. But I'm assuming that the point is not to replace categories, but somehow indicate that there could be more general and less general choices. I'm wondering if an "ipod" style drilldown menu is actually the better choice, although without writing new API methods, this involves more AJAX requests to figure out which categories have sub and super-cats. 

http://www.filamentgroup.com/lab/jquery_ipod_style_drilldown_menu/

The other problem is that it almost feels like one ought to be able to create a new category as a subcategory of another. That is, if I browse to "Animals -> Felines -> Felix lolcatus" I should be able to add "Felix lolcatus canhazcheeseburger". Currently, Categories can be spontaneously created, but not with hierarchical relations.
Comment 10 Lupo 2010-07-20 14:49:12 UTC
As I wrote in my e-mail, the use case is re-categorizing a file from a parent category to a sub-category. The feature was added by de:User:Merlissimo; I later added the parent category browsing as an experiment to see what could be done cheaply. I agree that it isn't yet a full-fledged integration of the category tree.

A drill-down menu like the one you pointed out would be much better.
Comment 11 DieBuche 2011-07-14 01:06:41 UTC
Closing, issues are split into separate bugs.
Bug 29880
Bug 29881
Bug 29882
Bug 29883
Bug 29885
Bug 29886
Bug 29887

The following is fixed since r92112:
*Changing an existing category
* three requests for each category change

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links