Page MenuHomePhabricator

Decide on implementation of Unit Selector widget
Closed, ResolvedPublic1 Story Points

Description

Baseline

  • The Unit Selector is basically an Entity Selector.
  • The Unit Selector shall be placed in the widget for entering quantities.
  • The selected item is converted to a full URI, and passed as an option to the value parser.
  • There must be (at least) one special choice for "no unit" (could also be multiple special choices, e.g. "unknown unit") with the internal value "1".
  • Shall allow a unit to be chose from the set of Wikidata (not necessarily local!) items.

Optional / later

  • Should allow restriction to a fixed set of URIs
  • Shall allow suggestions based on correlation ("which units are typically used with this property?")
  • Should indicate whether unit conversion is available for the selected unit

Event Timeline

daniel created this task.Dec 9 2014, 1:01 PM
daniel raised the priority of this task from to Normal.
daniel updated the task description. (Show Details)
daniel changed Security from none to None.
daniel updated the task description. (Show Details)
daniel added subscribers: Aklapper, daniel.
Snipre added a subscriber: Snipre.Jan 18 2015, 10:50 PM
daniel updated the task description. (Show Details)Mar 24 2015, 2:38 PM
thiemowmde added a comment.EditedApr 8 2015, 12:15 PM
  • The widget must support "custom" values, similar to what currently happens with the globe coordinate precision. If there is an URI the widget does not know, it displays and returns the URI as it is.
  • The widget must (otherwise it's pointless to have it in the first place) allow searching for units by name, e.g. typing "km" should work. This means it's either a "dumb" item selector or a pre-defined list.
    • Where should this list live? Should the community be able to maintain it (e.g. via a message)?
    • How are these pre-defined units localized?
  • Should we restrict the list of allowed units in the API? This may be a good starting point. It's much, much easier to drop such a restriction later than to install one (and clean up data).
  • Is it possible to support localization for all (local) Wikidata URIs?
  • Do localization with labels (probably easier and "the right thing to do") or with the unit symbol property (P558)?
  • Where is the stuff required for unit conversion stored and how does the widget know about it?
  • The widget must support "custom" values, similar to what currently happens with the globe coordinate precision. If there is an URI the widget does not know, it displays and returns the URI as it is.

Yes

  • The widget must (otherwise it's pointless to have it in the first place) allow searching for units by name, e.g. typing "km" should work. This means it's either a "dumb" item selector or a pre-defined list.

It would be an item selector. That also searches over aliases, and "km" would most likely be an alias.

  • Where should this list live? Should the community be able to maintain it (e.g. via a message)?
  • How are these pre-defined units localized?

I would like to avoid a pre-defined list for the baseline implementation. This is actually harder to implement, as far as I can tell.

  • Should we restrict the list of allowed units in the API? This may be a good starting point. It's much, much easier to drop such a restriction later than to install one (and clean up data).

We do not have such a restrictions for calendars or globes. I don't think we should introduce it here. We could, of course, but that would make the selector more complex.-

  • Is it possible to support localization for all (local) Wikidata URIs?

Sure, why not? Just use their label (with fallback).

  • Do localization with labels (probably easier and "the right thing to do") or with the unit symbol property (P558)?

Just the labels for the baseline. "Symbols" support should be added later (P558 would need to be migrated to multilingual text).

  • Where is the stuff required for unit conversion stored and how does the widget know about it?

In the baseline, the widget doesn't know about it. In fact, for now, there is no conversion.

Later, we'd have an internal service for unit conversion, and an API module for accessing it. The widget could then tell the user whether the unit they entered is a well known base unit, a convertible unit, or somethign unknown (which means the value can not be indexed/normalized/compared/queried).

Snipre added a comment.Apr 8 2015, 1:05 PM

@thiemowmde. The list will be very long: we have to think a way to avoid scrolling dozen of units to find the correct one. One possibility will be to have for each contributor a personal list which can be uploaded from a personal page like user:User/common.js. The widget compares then the selected value with the official and complete list of units maintained by the dev team (or somebody else) and if there is a match, proceeds to the next step.

We have to find a better way than having each user maintain a list of their preferred units. This is already causing a lot of headaches for the babel box config.

I agree that having such a widget is necessary as fall-back for entering units--using an entityselector derivative for that purpose probably is a sensible solution.
However, using two inputs results in some awkward interaction--especially when entering multiple values. The software should be capable of making a proper best guess on a string that contains value and unit. Such a best guess can be displayed as preview with an option for the user to adjust the unit (using something like the enhanced entityselector described).

Shall allow suggestions based on correlation ("which units are typically used with this property?")

These could really be constraints defined by Statements on Properties specifying sets of allowed units. Consequently, the number of units that may be assigned to a value of a Property would be a small set anyhow and there is no need for something like user preferred units or intelligent unit suggestions.

The widget must support "custom" values, similar to what currently happens with the globe coordinate precision. If there is an URI the widget does not know, it displays and returns the URI as it is.

Agree, but, in the user interface, displaying the Label instead of the URI probably would probably be more sensible.

Where is the stuff required for unit conversion stored and how does the widget know about it?

Could that not be stored using Statements on Properties?

I agree that having such a widget is necessary as fall-back for entering units--using an entityselector derivative for that purpose probably is a sensible solution.
However, using two inputs results in some awkward interaction--especially when entering multiple values.

The same as picking a globe or calendar model.

The software should be capable of making a proper best guess on a string that contains value and unit. Such a best guess can be displayed as preview with an option for the user to adjust the unit (using something like the enhanced entityselector described).

That would be nice, but would block us on a mechanism for (localizable?) "unit symbols". It would be good if we could move forward without being blocked on that.

Shall allow suggestions based on correlation ("which units are typically used with this property?")

These could really be constraints defined by Statements on Properties specifying sets of allowed units. Consequently, the number of units that may be assigned to a value of a Property would be a small set anyhow and there is no need for something like user preferred units or intelligent unit suggestions.

That would prevent us from using obscure or historical units. We said that we want to support these, so we can stay true to the source. The number of units you'd have to list for something like "length" or "height" would go into the hundreds.

The widget must support "custom" values, similar to what currently happens with the globe coordinate precision. If there is an URI the widget does not know, it displays and returns the URI as it is.

Agree, but, in the user interface, displaying the Label instead of the URI probably would probably be more sensible.

If it's a wikidat (or local wikibase) URI, the label should be shown. But internally we support any URI, and the UI must be able to copy with any URI. If it doesn't know how to get the label, it should just show the URI in full.

Where is the stuff required for unit conversion stored and how does the widget know about it?

Could that not be stored using Statements on Properties?

That would be hell to keep consistent, and every change to a conversion factor would require us to rebuild the query index. Not a good idea, I think.

Bene added a subscriber: Bene.May 4 2015, 6:51 PM
Tobi_WMDE_SW renamed this task from Implement Unit Selector widget to Decide on implement of Unit Selector widget.May 5 2015, 1:31 PM
Tobi_WMDE_SW renamed this task from Decide on implement of Unit Selector widget to Decide on implementation of Unit Selector widget.May 5 2015, 5:33 PM

I am not perfectly sure what is expected on that from my side.

  1. I am pretty sure there is a need for some kind of dedicated unit selector (although I am pretty sure it should not be a default interaction element).
  2. The decision on whether to implement basic functionality fast without solving interaction concerns or whether to iterate an interaction vision first and then implement accordingly is up to PM.

Personal comment:
I totally understand the temptation to implement the functionality right away and such has been common practice ever since the Wikidata project started. However, in my opinion, most of the time, this led to unforeseen consequences, strange interaction behaviour, user complaints when changing the interaction later or simply deferring proper interaction implementation to "when there is time" (never) and/or so on. Consequently, I will decline the decision to do both in parallel since an interaction concept will not be installed later on (at least not in the near future) as it has been in the past. Decision is up to PM.

Tobi_WMDE_SW edited a custom field.May 25 2015, 11:04 AM

@Snaterlicious: Can you please clarify where you see interaction issues with a unit selector?

  • No proper copy-pasting which is a big disadvantage for things like such.
  • It is quite natural to type a string that contains value and unit. Two input elements instead of where one would be natural is irritating. Placeholders would ease the situation a bit, but the need to tab between inputs for something that is normally typed in one go is kind of awkward.
  • Being aware about form/page navigation using the TAB button involves a certain degree of expertise.
  • Contradicting to natural position of some units, e.g. $10 vs. 10$.

In my opinion, it is such disadvantages and awkward interaction that repels potential contributors right from the start. Deciding on implementing an interface exclusively based on an unit selector would support giving such an impression once again by adding to the pile.

Jc3s5h added a subscriber: Jc3s5h.Jul 20 2015, 5:42 PM

Two questions about P558, unit symbol property:

  1. When this is made multilingual, is it possible and desirable to mark it as "all languages", which is the case for symbols (but not names) that are included in the International System of Units?
  1. What about symbols that include a superscript, such as the symbol for square meter, which I cannot write here.
Snipre added a comment.Aug 7 2015, 2:17 PM

@Snaterlicious. If you take account of the uncertainty, the copy-paste is not more so important: value + uncertainty + unit, I don't know
if any copy-paste will respect the same interval between the different elements, if the symbol for uncertainty will be recognized, do we need to handle the scientific notation,....

Tobi_WMDE_SW closed this task as Resolved.Aug 10 2015, 1:13 PM

We're working on T98172 so I'm closing this now.

@Jc3s5h

  1. Unit symbols are not "all languages". While many countries/languages use the standard km/h, America uses KPH, and Russia uses км/ч. But I agree that an "other languages" fallback would be nice, using English for that (as MediaWiki does) isn't really great.
  2. For the common subscripts and superscripts, there are unicode characters that can be used, see https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts. For units we'll mostly need U+00B2 (superscript 2) and U+00B3 (superscript 3). Square meter would be written as m².
In T77982#1524501, @daniel wrote in part:
  1. For the common subscripts and superscripts, there are unicode characters that can be used, see https://en.wikipedia.org/wiki/Unicode_subscripts_and_superscripts. For units we'll mostly need U+00B2 (superscript 2) and U+00B3 (superscript 3). Square meter would be written as m².

I see no mention in the Wikipedia article of an ability to provide a negative superscript. This is highly desirable for writing units.

I see no mention in the Wikipedia article of an ability to provide a negative superscript. This is highly desirable for writing units.

SUPERSCRIPT MINUS (U+207B)?

I see no mention in the Wikipedia article of an ability to provide a negative superscript. This is highly desirable for writing units.

SUPERSCRIPT MINUS (U+207B)?

I have no success entering any of these superscript numbers on my Windows 8.1 computer with Firefox. Also, using the Microsoft Charmap program, I am unable to find any font that includes the superscript minus.

Snipre removed a subscriber: Snipre.Aug 11 2015, 7:40 AM