Page MenuHomePhabricator

[Task] create new design and UX concept for input of complex datatypes
Closed, ResolvedPublic


We need to improve the input of complex datatypes. This includes dates, coordinates, quantities, monolingual text and multilingual text.

Event Timeline

Lydia_Pintscher raised the priority of this task from to Medium.
Lydia_Pintscher updated the task description. (Show Details)

After some first evaluation, I still quite like the basic input concept offering as few input elements as possible and having the software make a best guess. This interface simplicity, however, has some implications. Those are, at least:

  • The software needs proper logic for making best guesses.
  • It is not obvious how some options may be set instantly, for example: uncertainty options like "before" and "lower bound". The question is, per option, whether it can be regarded primary or secondary. The term "advanced options" currently in use, probably, is not the right expression.
  • The preview needs to be specific enough to make the user aware of additional adjustments (e.g. planetographic coordinates may probably need to display the globe unless there is some other concept that defines the globe, for example, per Property resulting in some Property like "position on Venus").
  • Experienced users should be offered ways to enter information specific enough in order to circumvent false guesses (i.e. by entering something like "1 7 2015 Julian") in order to get around clicking through the secondary options.

The concept is simple: Enter something, have the software present the guess (preview) and ask the user whether that is what the user expected. If it is not, the user may open detailed input components. This keeps the UI unobtrusive and accessible for new users.

basicinputconcept.png (180×440 px, 7 KB)
(Could also be something like "Not what you expected?" or "Not what I expected?" for a more personal address. Appending some phrase like "Refine [date/amount/coordinates/...]." would emphasize the hint about additional input options even more.)

Everyone of the existing data types can have one input box as its only primary input method, except, maybe, monolingual text. However, I wonder why the language of a monolingual text value should not be specified directly on the Property. Very likely, at least multilingual text and geographic shapes need some more sophisticated primary input, but the basic concept should remain the same. Keep it simple by not filling the page with input elements a user most likely does not need anyway.

In my opinion, the actual issues are more on a per data type basis. Time data type is most prominent here as the UI for it is not as flexible as it should be and, even more, is missing options. As mentioned, "advanced adjustments" may change to something more "communicative". Apart from that, I would propose creating tickets for the input concept of each individual data type and evaluate one by one about primary input, secondary input and how to integrate these aspects.

Snaterlicious changed the task status from Open to Stalled.Jul 30 2015, 11:17 AM
Snaterlicious set Security to None.
Jonas renamed this task from create new design and UX concept for input of complex datatypes to [Task] create new design and UX concept for input of complex datatypes.Aug 13 2015, 4:18 PM
Lydia_Pintscher changed the task status from Stalled to Open.Aug 18 2015, 9:25 AM

Ok I agree with this. And I like changing the wording for "advanced options".

I think what is needed next is a look at the advanced options. The list rotator for example is problematic based on the feedback I received. It gives you several ways to do the same thing in a confusing way. I also think the way we let people enter the language for monolingual text (and soon units) is not as good as it can be.

Lydia_Pintscher claimed this task.

Henning and I sat down and talked the remaining things through. The outcome are the following tickets: T109455, T109457, T109459, T109460.