Page MenuHomePhabricator

Localizable tooltips, for html form fields - guidelines?
Closed, ResolvedPublic

Description

I want there to be tooltips in the edit-forms here, at phabricator. For example in the "Title" field, it could tooltip:

Title: A short one-sentence summary that explains the problem (not your suggested solution)
If you're changing an existing title completely, perhaps leave a note in the Description below.

(text from mw:How to report a bug, plus my addition)
I'd like to make an upstream request at Phabricator.org, for a customer-customizable tooltip in the software config, but I'm not sure how to phrase it, or what details are needed...


  1. What accessibility issues need to be considered, for using tooltips in form fields? (e.g. old browsers, screen-readers, accesskeys)
  2. Do we have any mediawiki guidelines on what developers/extensions should use? (and should they be linked in the Codex e.g. here or is that outside of it's remit?)
  3. What is the best external documentation, and "best in class" examples?
  4. Where do we currently store some examples? e.g. the title="Enter a short summary [Alt+Shift+b]" in enwiki's edit-summary field.
  5. What pragmatic limits are there, on the formatting & length of tooltip content? (can we do split lines in basic HTML? How much harder is it to get clickable links in them? F108798: this is very pretty, but the rendered HTML is gigantic, and it's still not clickable/copyable text.)
  6. What other things should I/we be asking?

Thanks. :) [Expand/tweak/amend this task, as needed]

Event Timeline

Quiddity raised the priority of this task from to Needs Triage.
Quiddity updated the task description. (Show Details)
Quiddity subscribed.
Aklapper edited projects, added Phabricator (Upstream); removed Phabricator.
Aklapper set Security to None.

Q1 - Q4 are more technical, I'll leave it for people who know better. cc: @TheDJ

Q5 :

There are a few kinds of tooltips.

[Small – Non-interactive]

  • Triggered by mouseover event;
  • These are non-interactive. Disappears when cursor leaves an element;
  • Suggested to not be a full sentence because concise word(s) and language is important. One-liners are ideal;
  • Used to give short description for an item (e.g.: icon) or give short helpful info depending on context (e.g.: keyboard shortcut, where this links to).

[Small-to-medium-sized – Interactable]

  • Can be triggered by mouseover or click event, depending on context;
  • Could include thumbnail sized photo or icon and/or links.
  • Used to give confirmation (e.g.: User just added an article to a watchlist, point to where user can access watchlist items), guide user (, warn (e.g.: log in to protect your IP address)
  • Because this could be used to give warnings or caution messages, unlike other tooltips, this particular tooltip can appear in blue or any warning colors depending on severity (orange, red).

[Large sized – Interactable]

  • Can be triggered by mouseover or click event, depending on context;
  • Could include medium-sized photo and/or icon(s) and/or links. (The most recent example is hovercards).
  • Used to give extended information.

Q6 :

Some questions currently being considered by @MNguyen and @goenning (they're currently working on tooltips) are:

  • Character limitations for small - medium tooltips
  • How can we format, section, and organize info within medium-larger sized tooltips from real life examples, how would a tooltip template look like (images, text, links)?
  • When to use click vs. mouseover
  • When to use colors vs white/grey
  • … I'll let them expand more in here :)

The upstream hope/expectation is that this need is generally resolved by custom forms, which allow you to put a block of instructions in the header instead of tooltips on each field (and hide or lock fields which aren't relevant to a workflow). This is now live on this install: the "Create Task" form has a header callout linking to the "How to write a good bug report" documentation.

This feature is primarily trying to address the problem of "users do not always submit high-quality bug reports" (and similar problems in this class, where workflows would benefit from more overall structure). Although I think this problem is largely not truly a technical one, we've had some success in the upstream using custom forms to add more cues and guardrails, like this install now does. I'm not sure whether you'll see a similar improvement or not, but I'd guess things will be at least a little better.

We haven't seen reports that I can recall of particular difficulty understanding the behavior or use of specific fields in a narrow sense. If you are seeing this (for example, users are confused about what the "Assigned To" or "Priority" fields mean) I'd like to try to understand the underlying confusion first -- we may be able to address it in the product in a more general way.

Very narrowly, in the F108798 example, if we had that form and ran into a problem with irregular data entry, we might prefer to change the form to read like this:

 Author First Name: [__________________________]
    Author Surname: [__________________________]
Author Name Suffix: (None  V)
                    (Sr.    )
                    (Jr.    )
                    (II     )
                     ...

Human names are complex, this presentation of the form implies tradeoffs which make it both worse and better at solving certain problems, and this might or might not be a good solution if we were actually encountering that problem, but I'd guess it's probably a better solution to the specific problems identified by the tooltip (wrong first name / surname ordering, inclusion of improper suffixes, improper use of punctuation) than adding a tooltip describing those rules in human language.

This tooltip feature wouldn't be particularly difficult to add technically, but if the request is upstreamed we'd like to see a strong justification in terms of problems you've encountered that you believe this is the best solution to. I don't currently believe this is the best solution to any problems I'm aware of at the moment, and wouldn't want to pursue this without a clearer picture of what specific problem it is aimed at resolving.

This tooltip feature wouldn't be particularly difficult to add technically, but if the request is upstreamed we'd like to see a strong justification in terms of problems you've encountered that you believe this is the best solution to. I don't currently believe this is the best solution to any problems I'm aware of at the moment, and wouldn't want to pursue this without a clearer picture of what specific problem it is aimed at resolving.

WMF folks: Would anyone willing to elaborate on the problem?

Another (last) call for more specific problem descriptions before declining this request...
(@Quiddity?)

I guess it would be low priority, and I think the custom forms will suffice for now. Quick questions:

  • Is it already possible for us to add a placeholder in the "Title" field? (i.e. Create task currently has "Type a username..." in the "Assigned To" field. We could add a concise tip, in the "Title" field.)
  • If not, then let's add a brief tip in the current header-banner callout, underneath the link to "How to write a good bug report."

(Bonus: I'd love to see a quick accessibility investigation, for how this works for blind-users - i.e. confirm whether or not the placeholders are useful to them.)

In a task description, @Quiddity wrote:

I want there to be tooltips in the edit-forms here, at phabricator. For example in the "Title" field, it could tooltip:

I can naïvely imagine that someone would just need to add three lines of code (public function getPlaceholderText() { return pht('Enter a title. A good title. Now think. No! Harder!'); }) at the right spot in the Phabricator code, so...

  • Is it already possible for us to add a placeholder in the "Title" field? (i.e. Create task currently has "Type a username..." in the "Assigned To" field.)

...we could easily override existing strings via [[ https://phabricator.wikimedia.org/diffusion/OPUP/browse/production/modules/phabricator/data/fixed_settings.yaml;3d29a7ec1f42b5dcea2dd107042ba965598b06b9$187 | translation.override ]]. However there is no existing string for the Title field. Currently.

I suspect this is largely obsolete nowadays with the option to add instructions to custom forms? The New Bug Report form now has a block of instructional text, particularly.

mmodell claimed this task.