Topic on VisualEditor/Feedback/Flow

The way categories are currently edited in VisualEditor is not WYSIWYG at all. Can something like HotCat be added as well?

(Personally, I don't find the "Page Settings" == "Edit categories" intuitive.)

VisualEditor is not intended to be "WYSIWYG" as a main criterion. :-) If you mean that you'd expect categories to be editable in the place in the skin where they can be edited, that's something we've thought about but is very complicated (how do you show and set hidden categories? what about non-Vector skins - do we just abandon them? etc.).

We're not totally wedded to the name of "Page Settings", though note that it covers categories, language links, "magic word" page settings (REDIRECT, NOTOC, DISPLAYTITLE, etc.) and possibly other things too (one suggestion was to put maintenance templates in here (like "unsourced", "orphaned", "spam-like" or whatever - either wiki-specific ones, or build them into MediaWiki in some way). If you have a better name for this collection of things we'd love your ideas. :-)

It's just that to me, Settings implies user-specific preferences, not metadata.

Yes, though we have very carefully used the term "preferences" for users rather than "settings", I worry that this distinction may not have been kept clear in other languages.

Ooh sounds cool that we will have an interface to play with magic words :)

Why not call the link "Categories and metadata"? Sure, it's verbose (and a long string - it might fail the German test), but 100% clear. Most users won't understand the term "metadata", but then, most users probably won't need to tweak langlinks, magic words, etc. "Page settings" is quite vague, and the overlap with "preferences" is problematic (MW might be making a clear distinction between the two, but many other software programs/websites/smartphones etc. regrettably do not).

I like "Categories and metadata".

I think we need to be very careful to avoid putting needlessly-complicated words in front of potential new editors that are likely to scare them away rather than encourage them; "metadata" sounds intimidating, confusing and is not just very unlikely to get users to click the button, but will also add a tone of complexity and technical speciality that will dissuade users from staying.

So, if we can't use "metadata" (and we really, really shouldn't), what else? "Page data"? "Page details"? I also think splitting out the message to name categories differently from other meta-data is the wrong approach - it tries to box people into not setting things like DISPLAYTITLE which are very useful. Just because editing through wikitext makes these very hard to discover doesn't mean we should discourage users from using them in software (that's what community policy and socialisation is for).

For as long as categories are hidden away in the "page settings" dialog, the name of that dialog really should include the word "categories". I think the main reason to invoke this dialog is to add or remove categories. New users who see the "categories" section on the page and want to make changes, as well as experienced users wishing to modify page categories, will not know where to look to make the change unless the word "categories" is prominent.

I think a name like "page data" scares people off just as much as "categories and metadata", because it sounds really "internal". And "page details" sounds to me like some static information. Although I don't really have any better suggestions :(

"Page settings" would be a fine name (or almost any other name, for that matter) IF hovering or clicking that resulted in a menu of choices (categories, default sort, interlanguage links, etc.) That way, an editor could immediately see what "page settings" involved, and whether he/she wanted to explore further.

Instead, at the moment, to see what is "under" that name, the editor has to click on the link, which opens a dialog box; then the editor can explore further.

It's possible to combine the best of both of these (submenu items, single dialog box) by specifying, in the software, that when someone (say) selects the "Default sort" menu item, the dialog box opens with that item already selected (in the left side side of the dialog box), so that the editor can immediately go to work on that particular aspect of page metadata. So a menu of choices not only informs the editor more quickly what his/her options are, but it also saves a click in cases where the editor doesn't want the top-most option (in this case, categories) handled by the dialog box.

To add categories should not be intimidating to any users. When viewing pages, these categories are simply shown at bottom of pages in the footer. In the "visual editor", this should be visully editable at the same place (no need to hide this in "page settings" drop down menu, they are directly visible in the bottom of pages

This should use an existing tool that works very well : HotCat, which should be working as well in the visul editor (except that it will not save directly in the actual page, but in the work buffer used by the visual editor, which will immeditely render the new Categories page footer).

Otherwise drop this menu, and activate HotCat instead : the page will be categorized separately from its edit work, and the VisualEditor will not alter the categories, just displayed at the bottom

If you relly want to include this menu for editing categories, place it there in the page footer, not at the top with the odd menu: - a link under the (translated) term "Categories:" at start of this footer (to add a new category) - a link under an existing (and editable, not generated internally by templates) category name (to edit it, or remove it) with the same effect as the action link "[+/-]" added by HotCat *after* this category name (HotCat cannot replace the link in page view mode, so it has to insert an dditional link after it)

In visual-edit mode, HotCat would not add "+/-" links, it can - safely replace the target link (under each displayed category name) normally going (in view mode) to visit the category page, by a javascript link opening a popup menu for: "view category in a new tab", "view category in a new window", "modify category", "remove category". - insert the link to add a category under the label "Categories:", or still with the "+" link at end of list of categories.

Ideally, we should also be able to edit the category name, along with its sort key parameter. If we edit an existing category but drop the name, the category would be removed, unless there's a non-empty sort key, in which case the empty category name just means the "defaultsort" key for the page. The VisualEditor (HotCat as well when it is used in page view mode..) should warn if there are attempts to place several occurences of the same category name (including the empty category name for the default sort key), but with a distinct sort key parameter.

Let's not mix things with other skins. The VisualEditor hs its own interface, and it should more or less mimic the look and feel seen in the default skin, or in the Monobook skin, where editable categories to include/modify remove in the wiki code of the page will be at bottom of page.

The HotCat extension behavior is perfect (and much more practical to use than the very basic (insufficient) interface currently presented in the VE. I also vote for the integration of HotCat in the VE (or something very similar). Except that this edit will be possible without having to open a menu, and nothing will be saved before saving the whole page visually edited.

This should not be hidden in that menu. Make the categories visible and editable at the bottom of pages.

For now I'll stick with HotCat, or with editing them in the wiki code editor.

---

My opinion is that both editors should be integrated, so that you can switch back and forth between the partially editable preview and the wiki code view during the edition. There would then be later a single "edit" tab on wiki pages (the current working mode would still use the user's preferences, if he only wishes to use the wiki code editor. We should always be able to see at any time every wiki code being modifed by any edit action in the VisualEditor, by just clicking a button.

Also, the editable preview panel (or the wiki code editor) will be scrollable, the interface at top may become a right-side properties pane, fixed on the page and not scrolling (the option buttons will be there in this properties pane.

Still missing as well in the VisualEditor: no support for the very useful characters selector (needed for I18n or for editing IPA and Maths symbols, or some useful punctuations like bullets, rarely present on keyboards). That's another reason why I still prefer not using the VisualEditor by default.

Another reason is that if the VE is your default, there's no way to edit a section in the wiki code editor, only visual editing is present. As long as the two editors are not integrated, we should still have two edit links: "[edit]" and "[edit code]" at end of editable sections, if the VE is enabled in user's preferences.

Lots of template transclusions also offer a specific edit link. Their action uses only the wiki code editor. If both actions "edit" and "editVE" were merged into a single one (with a simple switch to show either the editable preview or the wiki code) it would be simpler. And the "Show preview" button could disappear below the wiki editor (it would just remain a "Save page" button), but the "Save" button could also show the actual rendering without the limitations of the editable preview.

There is bugzilla:52281 about the "veaction" problem.

"(Personally, I don't find the "Page Settings" == "Edit categories" intuitive.)"

+1. I thought VE still couldn't edit categories until I read this thread.

Which is why I do suggest taking a look at its user guide from time to time to find out what it can do :) Maybe not covered there yet in all languages, but available from the icon with the 3 bars, there's the option to easily switch to wikitext (one-way only for now).

If you need to check the user guide to use VE, then it's failed in its goal to be easier than wikitext.

Agreed. I learnt wikitext by trial and error back in the days without consulting the manual. I think we can agree that, in VE, things should be as easy to locate in edit mode as in read mode.

Perhaps there should be a HotCat-like toolbar at the bottom of the VE box?

Yes, the language is crappy. The categories are not settings.