VisualEditor: Allow the user to edit categories at the bottom of the page, similar to HotCat
OpenPublic

Description

At the moment adding categories (through "page settings") involves turning away from the actual content. This is a problem because a lot of categories are dependent on the actual content, which needs to be referred back to - birth or death years, college, etc, etc.

Suggestion is:

  • Show the existing categories in the standard skin location (at the bottom of the page, in Vector)
  • Make the categories editable there, in some way.

Original onwiki comments were archive 6

I can see categories when I read an article. I can see them below the editing paraphernalia when I'm in Edit Source. But in VE I can only see them by clicking "Page Settings", which (a) takes a click and (b) means I can't see any of the article content (eg the hard-to-remember-the-spelling district name, the birth date, etc which I might want to use in creating categories, having seen that they aren't already there). Please display the categories in or around the article, not just as "Page settings".

and archive 7:

I want to be able to see the categories when I've got an article open in VE: just as I can see them when reading the article, or when editing it in Edit Source. I don't want to have to click on "Page Data" to find out whether or not it's already got categories.


See also: T67518: VisualEditor: Categories cannot be edited, only added or deleted

merged duplicates: T53153: VisualEditor: Category interface is hard to find and T71506: VisualEditor: Categories should be displayed at the end of the page

bzimport set Reference to bz50239.
Ironholds created this task.Via LegacyJun 26 2013, 4:06 PM
Jdforrester-WMF added a comment.Via ConduitJun 26 2013, 6:18 PM

We've discussed (but there's no bug for it - until now) duplicating the editing of categories in a box at the bottom of the article that would look similar to/the same as the category box in Vector (but with hidden categories shown, and inherited categories not shown). We'd have to properly design this, of course, so it may take a little time.

There's also a proposal to make the dialogs themselves smaller - bug 49549 - and draggable - bug 49969.

PamD added a comment.Via ConduitJul 7 2013, 11:06 PM

I've been told that [Wikipedia:VisualEditor/Feedback#Categories:_please_display_them_in_VE_-_not_the_right_bug my request] is covered by this bug, so I'll restate it here: please make the categories visible when I'm editing in VE. I can see them when I read an article, or while I'm editing in Edit Source, and I shouldn't have to click on "Page Data" to find out whether the article has been categorised or not.

PamD added a comment.Via ConduitJul 15 2013, 10:16 AM

To expand on my point of 07-07: if I'm stub-sorting an article which already has categories, a common technique is to look at a key existing category, see if it has a stub category, if not then go to its parent category, and onwards up the tree (particularly useful in biological taxa etc which are so hierarchic); another technique is to assign a broad stub category and then look at the sub-categories of the stub-category, as being much quicker than going to the full stub listings. Neither of these approaches is possible with VE - I have to either open the article a second time in another tab, or quit VE and do it in Edit Source.

Please just display clickable links for the categories while I'm editing the article in VE. Is it such a big ask?

Aklapper added a comment.Via ConduitJul 15 2013, 11:02 AM

pamdavies7: It is not "such a big ask" and the problem is well understood. This is an enhancement request with low priority because there are currently more important things to do, but this will be handled at some point.
In case you have a tech background, patches are welcome: http://www.mediawiki.org/wiki/Developer_access

Krenair added a comment.Via ConduitNov 1 2014, 1:45 AM
  • Bug 69506 has been marked as a duplicate of this bug. ***
Jdforrester-WMF moved this task to Backlog on the VisualEditor workboard.Via WebNov 24 2014, 4:24 PM
Ironholds removed a subscriber: Ironholds.Via WebDec 5 2014, 7:51 PM
Quiddity changed the title from "VisualEditor: Alternative way of editing categories" to "VisualEditor: Alternative way of editing categories, at the bottom of the page, similar to HotCat".Via WebJun 20 2015, 8:14 PM
Quiddity edited the task description. (Show Details)
Quiddity added a project: Design.
Quiddity set Security to None.
Quiddity edited the task description. (Show Details)Via WebJun 20 2015, 8:17 PM
Neil_P._Quinn_WMF changed the title from "VisualEditor: Alternative way of editing categories, at the bottom of the page, similar to HotCat" to "VisualEditor: Allow the user to edit categories at the bottom of the page, similar to HotCat".Via WebJul 24 2015, 12:32 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptVia HeraldJul 24 2015, 12:32 AM

I'm not sure this would actually be easier for the user. Currently, you can edit categories whenever you want without losing your place in the article; if we just stuck a category widget at the end of the document, you'd have to scroll all the way to the bottom every time you wanted to use it.

We could prevent that by putting the widget in a static flyout at the bottom of the window (as opposed to at the bottom of the document). But that means taking more screen space with the interface and splitting the editing tools between two different locations.

Jdforrester-WMF added a comment.Via WebJul 24 2015, 12:54 AM

Certainly I think this should only happen at the bottom of the page, not the window, yes.

Neil_P._Quinn_WMF added a comment.Via WebJul 24 2015, 12:59 AM

Certainly I think this should only happen at the bottom of the page, not the window, yes.

In that case, we'd either be duplicating controls (if we leave the current category interface in) or removing the ability to edit categories without a bunch of scrolling (if we take the current interface out).

Whatamidoing-WMF added a comment.Via WebJul 28 2015, 9:56 PM

This has been discussed several times on wiki, and none of the experienced editors have mentioned concerns about having to scroll all the way to the end of the page. However, if you're worried about that, then you could leave an item in the toolbar that either jumps to the end of the page, or that does exactly what it does now.

Qgil added a comment.EditedVia WebJul 28 2015, 10:36 PM

Just reinforcing @Whatamidoing-WMF's point. This is one of those features where some user feedback would be welcome indeed, to see whether we are planning to put the right effort in the right feature. My totally subjective impression is that editors seem to be happy with HotCat, where you don't need to deal with wikitext at all. IMHO HotCat's UI could welcome some enhancements, but editing categories at the bottom of the page (where categories are found) seems to be unproblematic.

Ricordisamoa added a comment.Via WebJul 29 2015, 8:50 AM

How about extracting the categories editor and making it a beta feature as "HotCatoid"?

Mbch331 added a subscriber: Mbch331.Via WebTue, Aug 4, 2:18 PM
Akoopal added a subscriber: Akoopal.Via WebTue, Aug 4, 7:30 PM

I was pointed to this bug because of a feedback comment. I mostly see discussion about category editing on the page itself. Another feature hotcat offers is to navigate the category-tree, so it is quite simple to put an article in a subcat, or to bring it to a category above it. Can that feature be considered as well?

John_Broughton added a subscriber: John_Broughton.Via WebSat, Aug 22, 1:12 AM

It would be a definite improvement if the user could reach categories either via a top menu, or by scrolling to the bottom of the page. As several people have pointed out, there are disadvantages of the user being able to do only one of these, and - of course - there is no reason, from a programming viewpoint, why there can't be two paths to the same dialog.

So yes, I support (a) making existing categories visible at the bottom of a page, when in editing mode, (b) having something at the bottom of the page that, when clicked, will open the dialog where categories can be added or deleted, and (c) leaving that dialog accessible via the Pages options menu.

Neil_P._Quinn_WMF added a comment.Via WebMon, Aug 24, 6:12 PM

It would be a definite improvement if the user could reach categories either via a top menu, or by scrolling to the bottom of the page. As several people have pointed out, there are disadvantages of the user being able to do only one of these, and - of course - there is no reason, from a programming viewpoint, why there can't be two paths to the same dialog.

So yes, I support (a) making existing categories visible at the bottom of a page, when in editing mode, (b) having something at the bottom of the page that, when clicked, will open the dialog where categories can be added or deleted, and (c) leaving that dialog accessible via the Pages options menu.

This sounds like a good path forward. It gives two paths to one dialog rather than two different dialogs. Hopefully, we can also extend the bottom-of-the-page experience to the read mode at some point.

Add Comment