Page MenuHomePhabricator

VisualEditor: Transclusion dialog should make it easier to add parameters and see other values
Closed, InvalidPublic

Description

The current workflow for adding a new template; you add the template, you add parameter 1, you go to add parameter 2...only you can't, because adding parameter 1 jumped you to an entirely new tab that doesn't contain a mechanism for adding parameter 2.

It'd be good to have some mechanism to add additional parameters that is more intuitive - something as simple as not jumping a user to the parameter page, even. I appreciate bug 49778 partially solves for this but it's going to be a looong time before all our templates have templatedata.


Version: unspecified
Severity: enhancement
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=51774
https://bugzilla.wikimedia.org/show_bug.cgi?id=49772

Details

Reference
bz50354

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:45 AM
bzimport set Reference to bz50354.

Another thought; the different tabs for different params is something that takes a while to figure out, and introduces a lot more hoops into the system.

Additional thoughts - copied from En Wikipedia. Pam has done a ton of work with templates in VE and is at this point pretty dead familiar with how it impacts her workflow.


Many of the templates I add most often either have no parameters (eg stub templates), or take "date" as a parameter (maintenance templates like {{unref}}), or take one or more positional parameters (eg {{in title}} or {{about}} or {{coord}}).

The handling of templates seems to assume that each template has one or more named parameters.

Inputting a 3-parameter template like {{about|this|that|the other}} is very tedious, even after you've discovered how to do it (very non-intuitive). You can't see the content of previous parameters as you go along, so have to remember where you've got to. Messy and stressful and takes a whole lot of clicking.

It's probably too late to suggest this, but imagine the following scenario:

  1. I click on the jigsaw icon
  2. A box appears where I input the name of the template and click "Add template"
  3. The next box includes a prominent "See template documentation" button which links to the appropriate documentation, perhaps popping it up in another window or tab.
  4. This box is divided into two columns and a note says "use either the left-hand or right-hand column to add any parameters to this template". One col has named parameters, the other has a set of boxes labelled "1st parameter", "2nd parameter", etc. Along with buttons for "Next template" and "Apply changes".

A further refinement would be for VE to be aware of (a) templates which take no parameters (eg stub templates), and (b) templates which only take the date (many maintenance templates), and in these two cases not to prompt for parameters (but to quietly add the date for (b), saving this having to be done by a passing bot later).

A yet further refinement would be for VE to recognise stub templates (they all end in "-stub}}", apart from {{stub}} itself, so it shouldn't be hard), offer them as a separate drop-down menu (much easier when stub-sorting), and put them in the "right" (per WP:MOS) place at the end of the article.

Probably too much to hope for: but going back to the basics, please work out a way for parameters to be input without all the clicks involved in making "names" like "1", "2", etc. I haven't yet tried to add a coords parameter - something on the lines of {{coord|54|36|51|N|2|49|34|W|display=title}}. That's going to be really tedious.

... Getting a bit stream-of-consciousness here: can't we just have two columns of boxes: "parameter name if any" and "parameter contents" - perhaps 10 rows and a "More parameters" button. Then to input that coord template I'd just leave the first column blank and put the values I've got, in order, and hit "Apply changes". Simple, allows you to see previous params as you go to keep track of where you've got to, etc. Ah well, perhaps it's all in hand. Good luck. PamD 14:12, 4 July 2013 (UTC)

Another editor doing a lot of work with templates suggests that in commonly used templates with regular parameters, it might be a good idea to have the parameters preloaded. Speaking of the common "cite web" template, she says:

"I think it would be easier for the parameteres to already being added, at least the basic ones, to the template. For example, to the "cite web" template, the parameters that most people use (title, url, author, publisher and date). So, when the editor adds the "cite web" template, would only have to add the content of each parameter and not the parameters themselves. If the editor wants to add an extra parameter, they could choose it from the list and add it. I am sure that this is difficult to be done knowing that there are lots of templates to go through but maybe keep it as a thought if it can be done?"

I'd also request the elimination and replacement of the word "transclusion"; it's very opaque to non-wikimedians (and also potentially incorrect).

euro wrote:

(In reply to comment #4)

I'd also request the elimination and replacement of the word "transclusion";
it's very opaque to non-wikimedians (and also potentially incorrect).

Agreed...Perhaps it would be helpful in "dumbing down" the term to review the Free Dictionary treatise on "transclusion":

http://encyclopedia.thefreedictionary.com/Transclusion

--It pretty much comes down to the age-old issue of taking whatever is somewhere originally and replicating it somewhere else. The catch: no matter what happens to the original material, it's reflected immediately in the replicated copy. So within the context of "Wikistuff", how about "replicate"?

Webbie

Retitling this ticket to keep it more focussed as a generic "improve X" is hard to actually resolve definitely. I suppose the main goal here is:

  • It should be easier to add the Nth parameter after having added one already (e.g. not having to go back to the template page from the navigation sidebar and adding a new one).
  • One should be able to see other parameters (including their values) at a glance.

I've been thinking about the following UI changes (in no particular order, some options are mutually exclusive):

  • Though having sidebar entries for each parameter (as opposed to just the template) is a nice way to jump to a specific parameter at once, but for other purposes it is imho too big and unhelpful. I can't justify its prominence other than that this is the only method we have in the UI right now to allow navigation to other pages in the dialog.
  • I'd like to try for a Template to be a single page in the dialog where one can scroll from one parameter to another (e.g. more like a regular form).
  • The sidebar should probably be reduced (parameters either not in there, or significantly less prominent (e.g. a third of the height and indented from the parent item). The navigation sub-items for parameters wouldn't be for separate pages in the dialog, but would trigger a scroll to the param section and (if not already) to go to that template page the parameter section is inside of. We could go fancy and update the sidebar in two-directions (e.g. clicking an item will scroll there, and if you scroll there manually, we update the sidebar active item. This principle is quite common on one-page sites, example implementation of such principle:

http://webdesign.tutsplus.com/tutorials/javascript-tutorials/create-a-sticky-navigation-header-using-jquery-waypoints/
https://webdesigntutsplus.s3.amazonaws.com/tuts/313_waypoints/demo/index.html

  • As for bigger templates the "Template" page would now be very long, it becomes important that our "Add parameter" button is not only on top or bottom of the Template page, but accessible at all times (e.g. sticky on the bottom, and when clicked we attach a new section, add it to the list and scroll to it).
  • Separate: I'd like to get rid of the [+] -> [+ {template}] button we have right now. It is quite counter intuitive in my opinion. Aside from the "+" being unclickable (one has to hover it, then find out there are different options and pick one, even though there was only 1 option, now there are 2: template and content), it is also too small. I'd recommend we either have both + buttons visible at all times (+template, +content) or put them in the sidebar are sticky bottom-positioned slugs/placeholders (e.g. each + item would be its own row in the sidebar, clicking it will add an entry to the sidebar).

</brain dump>

More user suggestions:

After selecting a template and clicking "Add template", the left side of the box should read (in descending order): (1) Dialog box name (which should be "New template", not "Transclusion"); (2) the name of the new template [done now, but this should not be clickable - see (6)]; (3) A title, "Required parameters" [new], (4) a list of the required parameters [done now; done now], (5) a title, "Added parameters" [new], (6) A button, "Add a parameter", which when clicked, changes the right side of the box to the "Add parameter" dialog; and (7) a list of added parameters [done now; may be blank]. The button should be greyed out if the editor cannot add any new parameters (the only allowed parameters are required; all possible added parameters have been added)

After clicking "Add template", the left side of the dialog box highlights the template name, and always shows, on the right side, the "Add parameter" dialog. This is wrong if there are any required parameters. What should be highlighted on the left is the first required parameter. Editors should be completing the required parameters first, then turning to adding optional parameters.

When a editor clicks, on the left side, on a parameter, the right side shows an input box. It isn't clear, after the editor has added the desired information, what to do. Pressing [Enter] (or [Return]) just puts a newline character into the box (starts a new line). Clicking on "Apply changes", which seems like a possible solution, actually saves the template and exits the dialog box - that's frustrating. There should be a "Done" button that closes the edit window, and moves the left-side focus to (a) the top-most required parameter without information, or (b) the "Add a parameter" button/option.

When a parameter listed in the left side of the box gets its information added by the editor, the visible format of the parameter does not change. This is a particular problem if there are a lot of mandatory parameters, and the editor is not adding information linearly. It would be helpful if the text of the name of the parameter were to turn green once the parameter has been filled out; that's also positive feedback to an editor looking at anything with more than a few required parameters.

How to add a parameter is not obvious, as indicated by the frustration voiced by an editor previously. It looks like an editor can click on a parameter in the list, and then click the boxed parameter name towards the right side of the areas that has turned blue (that is, to click on what appears to be a button with the parameter name within it). But clicking on that "button" does nothing. Nor does clicking on a parameter result in the name of that parameter being put into the search box. The secret of adding a parameter [I guess; I've not been able to figure out anything else] is to ignore the fact that parameter names can be selected by clicking on them, instead (a) typing the parameter name into the search box, and (b) pressing [Enter]. I admit to being baffled by the rationale here: why make (the parameter name) clickable, yet have the click do absolutely nothing useful? Clicking on a small button within the parameter description, or double-clicking (or best, either way) is much more what editors would expect. [I also note that the user guide is not helpful, saying in its entirety, on this issue: "You can add parameters or edit those already listed."]

What makes the "type in the parameter name and press enter" approach particularly problematical is that if you misspell the name of an optional parameter, you get no feedback that you have done so. That's because VE assumes you're adding a parameter that's not covered by templatedata, but still is valid. That's a necessary assumption now, but clicking to add a parameter, rather than typing to add one, would remove the potential for this problem.

When adding a parameter, the list of parameters includes a description (e.g., "Full date when the source was published; if unknown, use accessdate ..."). It would be extremely useful if this description was also visible when the enter enters information for that parameter. (Bug exists for this, I believe.)

VE should prevent an editor from adding a template to the page text unless information has been entered for all required parameters. This could be done by greying out the final button (currently "Apply changes"), or by an appropriate error message if that button were clicked while a required parameter was still blank. If the first approach is taken, then it's particularly important to show the editor his/her progress in filling out parameters (the fourth suggestion, above), perhaps even turning red the required parameters that still require information.

The final step, for a different process, adding images, is to click a button labeled "Insert media". Similarly, the final step for the template process should be a button labeled "Insert template", rather than "Apply changes".

The treatment of "required parameters" is positively unhelpful. I suggest that they should be listed below the input box, like the other parameters, with a note saying "Required". At present it's easy not to notice that they're there, at the top of the left-hand column, while a few of the other parameters and their descriptions are listed conspicuosly below the input box.

Steps to add a non-required parameter:
#See it listed below the box, with its descriptionm and click (or, remember its name and type it)
#type the value into the displayed box

(non-intuitively) click on the template name top left to add another parameter (please give us an "Add another parameter" box!)

Steps to add a required parameter:

  1. Notice that it's listed, top left - just the name, no description
  2. Recognise that it's an important and required parameter, even if the name is a bit cryptic
  3. Move mouse up there and click on it

#Now see it displayed with its description

type the value into the displayed box

#...

I don't think the editor benefits from the current situation: I've tried adding a few templates and been flummoxed by it: sometimes the parameter name doesn't convey what it is, while if it was listed below the input box with its description it would be much clearer. Stick a red "Required" note beside it: editors are used to this on all sorts of other web forms.

I've added bug 51774 as a see-also. That bug is about making it easier to see long descriptions by use of a tooltip. I don't think it is dependent on or duplicative of this though.

Bug 49772 is also relevant here, that asks for links to extended documentation.

<< When the templatedata does not take any parameters, as specified by the corresponding templatedata (e.g. <nowiki>{{fixed}}</nowiki>, don't show the add parameter heading/text field and 'no unused parameters'. --[[User:Wouterstomp|WS]] ([[User talk:Wouterstomp|talk]]) 11:08, 6 August 2013 (UTC) >>

<< For templates, it would be helpful to provide some links to the actual template page from the transclusion dialog. At least a direct link, but perhaps something like v*t*e (view/talk/edit) like included in many navigation templates. --[[User:Wouterstomp|WS]] ([[User talk:Wouterstomp|talk]]) 11:12, 6 August 2013 (UTC) >>

(In reply to comment #11)

<< For templates, it would be helpful to provide some links to the actual
template page from the transclusion dialog. At least a direct link, but
perhaps
something like v*t*e (view/talk/edit) like included in many navigation
templates. --[[User:Wouterstomp|WS]] ([[User talk:Wouterstomp|talk]]) 11:12,
6
August 2013 (UTC) >>

Links to template documentation pages from the transclusion editor is bug 49772

I think these are all now tracked in bug 53604's dependencies, which is a more scalable way to find, triage and fix bugs; consequently, closing this as INVALID (though each of its suggestions are of course real bugs or enhancements).