3

Assume you’re helping to design the GUI of a WYSIWYG word processor. Users shall be able to change font size. There could be relative controls for larger and smaller and there could be keyword-based vague absolute controls for either visual ‘large’/‘small’ or semantic ‘same as chapter heading’/‘… footnote’. Both of these can be taken into account additionally, but usually you’ll have (because users expect) an absolute form field that shows a number and maybe a unit. If there’s no unit shown, the font size is probably measured in DTP points (= 1/72 inch = 127/360 mm). The actual size of those points measured in any more common unit is unknown to most users. They’ll have to be aligned with other measures done in inches, millimetres or centimetres etc. Users therefore shall be able to use a variety of units to specify the font size.

  • How do you best indicate to users that different units are supported?
  • How do you show which units are supported?
  • Should the value automatically change when the user selects a different unit?
  • What should happen if the user removes the unit altogether (if that’s possible) – previous or default unit?
  • How would you deal with different kinds of units, i.e. absolute and relative ones, inside the same field? (Imagine CSS font sizes, which can be absolute, relative with percentage, absolute keyword, relative keyword or other keyword.)
  • Do you think typed cells would work well in spreadsheet applications?

This is not limited to font size, of course, but applies to any numeric input field where the data has a unit. Even in “metric” applications, users may change the prefix, e.g. ‘cm’ to ‘mm’.

This is also not about the best UI for unit conversion, since that is a feature but not the purpose of applications employing this.

Bad example

Microsoft Word has text fields with digits followed by optional space and unit abbreviation, e.g. for paragraph margins and line height. If a user manually changes the abbreviation to something else that the software understands, it will someplaces convert this to the default unit (e.g. points) on save and will now probably show a crudely rounded number. In other fields, user-entered value and unit will be kept, at least for some of the supported units.

MS Word 2010? Paragraph dialog box, showing inch symbol and point abbreviation

Web solutions

<input type=number id=value><input type=text id=unit>

<input type=number id=value><select id=unit><option> … </select>

<input type=text pattern="[+-]?\d+([.,]\d+)? *[A-z&quot;'%/\*]+">

Widgets

4
+100

Trying to apply blanket "best practices" to this question may have you going down a rabbit hole of half baked answers. Before your questions can be answered, requirements around the specific use case must be gathered. For example:

How do you best indicate to users that different units are supported? How do you show which units are supported?

Showing all unit types may be overwhelming, especially when most users will use the same unit type. Introducing unnecessary/bloated choice is bad UX.

Again, you have a lot of options here. You can constrain the user to a specific type, you can give them the option to select from a known list, and you can auto-convert/snap them to a unit. The last item has the advantage of you being able to apply error states/message for unsupported formats, and the default unit type should be setup in to cover 90%+ of use cases.

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Should the value automatically change when the user selects a different unit?

It depends. In most (all?) scientific fields, the standards call for metric units only. If I'm calculating force Force = Mass * Acceleration, then it may make the most sense to think of mass as kg and acceleration as m/s2. Furthermore, if in my specific use case we're dealing with larger numbers, then it may be silly to include support for auto-conversion from nm to km, much less cm to km.

A much less complex example: How long does this caterpillar look?

mockup

download bmml source

I see no reason to allow conversions here.

What should happen if the user removes the unit altogether (if that’s possible) – previous or default unit?

Plan for your use case:

  • User is building a web layout. They are selecting a width for a container.
  • User is buying pants, and wants a certain waist size.

In the first example, it's important to preserve the unit. In the second, your store may only sell pants that use "inches" for the metric. Use components that enforce these constraints and reduce choice/complexity appropriately.

How would you deal with different kinds of units, i.e. absolute and relative ones, inside the same field? (Imagine CSS font sizes, which can be absolute, relative with percentage, absolute keyword, relative keyword or other keyword.) Do you think typed cells would work well in spreadsheet applications?

Web is one of the few use cases I can imagine users providing relative values. I would argue that WYSIWYG users would be using relative values. In fact, most don't even use pixel values. Generally, a pt or value is captured, the user can preview the size, and an associated/converted style is applied when the content is actually rendered. Why introduce complexity when our user only cares about bigger/smaller and relative to the size within the current document?

  • ?? I believe I made my answer before yours. I wasn't referring to any answers already provided, just that the question was a "general best practice" question for a very ambiguous set of situations. If anything, I was calling on OP to better refine requirements/context if he/she wanted a more concrete answer. Apologies if I offended you -- really did not mean to. – Daniel Brown Oct 13 '15 at 11:16
  • No need to apologize, but apologies from my side though. I feel stupid as I didn’t take notice of the date, and I must have read it before because you didn’t edit the answer. Guess it was a bit too early in the morning for me. Sorry for this. I removed the comment. – jazZRo Oct 13 '15 at 11:43
3

Take a look at Adobe Photoshop's or Pixelmator's canvas/image resize tools.

Screenshot of Adobe Photoshop’s “Image Size” dialog

They have an answer to most of your concerns:

  • How do you best indicate to users that different units are supported?
  • How do you show which units are supported?

They show a dropdown with options

  • Should the value automatically change when the user selects a different unit?

They immediately convert to the new value, except when the value has already been changed by the user (to prevent losing input).

  • What should happen if the user removes the unit altogether (if that’s possible) – previous or default unit?

Not possible, the dropdown forces that a unit is selected

  • How would you deal with different kinds of units, i.e. absolute and relative ones, inside the same field? (Imagine CSS font sizes, which can be absolute, relative with percentage, absolute keyword, relative keyword or other keyword.)

They convert nicely between absolute and relative values.

  • Do you think typed cells would work well in spreadsheet applications?

If you have the possibility to provide a dropdown for the unit, it will be a better choice for the reasons mentioned above.

2

Just to clarify, it appears to me that your core question about a combined data and unit form field is beyond usage in a word processor because you state, "This is not limited to font size, of course, but applies to any numeric input field where the data has a unit. Even in “metric” applications, users may change the prefix, e.g. ‘cm’ to ‘mm’." And you emphasize this in a comment to an answer by stating that you believe that a "widget" can be created for the "combined data and unit form field." If I misunderstood, then you are welcome to disregard the rest of my answer.

I don't think creating a useful widget is possible. You have two base assumptions in the question: 1. in a large number of cases, numbers need units for meaning, and 2. units can use different measuring systems. Those commonalities are not enough.

The core issue lies with UI/UX in general: different users will have different backgrounds and expectations about any interaction you create. For example you should create a different interaction for experienced users compared to the inexperienced. An application with casual usage should have different requirements from one with heavy usage. Trained users will not need the same interaction as general public users. Platform standards should also be considered, since users will likely have expectations based on those experiences.

If your goal in asking this question is to find help with creating such a widget, then you will likely be dissatisfied with many answers. Even a satisfactory answer is likely to have faults and failures that are not necessarily obvious. To support all of the various options would require a complex widget, and then you need to consider the target for that widget - is it for you or internal to a company? In that case, you may spend excessive amounts of time trying to make the widget flexible for use-cases you don't use, or make your problem more complex than necessary by trying to create a "generic solution." For a developer tool in general, adoption will be your challenge.

If you are determined to try to create such a widget, here are some considerations that may help you do it (or persuade you not to do it) based on your questions:

  • How do you best indicate to users that different units are supported?

For a font, you have several examples of implementations with a short list of units. I will not discuss the pros/cons because it depends on requirements, target users, available tools, etc.

Perhaps more important, in the general case a few unit options is very different than cases of 20 or more. Fonts have a handful of common units vs. distance where there are easily more than 20, depending on the use case. Specialized cases (for example form factors like mobile apps vs. desktop vs. tablet, etc.) require more consideration.

  • How do you show which units are supported?

Again, for a short list of units it may be possible to display the data and all options simultaneously using a selector (i.e. radio button). Even so, space considerations may make that impractical. Other nearby elements may also make that confusing or helpful. Also, depending on professional vs. casual users there is the issue of being able to easily select from a very long list of units that are very familiar to the user vs. the need to make the unit options obvious.

  • Should the value automatically change when the user selects a different unit?

This seems straightforward, but as you mention, it is not. A user may enter the value and then decide the unit is wrong and want to change it. While a designer may think automatic conversion improves usability, casual users are less likely to think about the units in advance of entering a numeric amount in many cases. A power user will simply memorize whatever it does. A professional may appreciate the automatic conversion and use it for other purposes. Similarly, a casual user may not notice the automatic change while a professional may notice. With this, you can see that an application targeted to the general public could in some cases benefit from automatic changes, and in other cases it would not.

It may be that usage statistics and/or testing result in a mixed bag of options even on the same screen, which could be the reason for what happened in the example you gave. A casual user might never notice what you noticed - and if they are not always accessing that area, creating a "common interaction model" is only a design goal, and may not actually help your users. A "power user" will adapt based on the need to do so, which may make the various interactions annoying, or maybe they don't care. It is really only annoying to people that notice and appreciate the higher level pattern, which is not the goal of UI/UX in general.

  • What should happen if the user removes the unit altogether (if that’s possible) – previous or default unit?

This depends on whether the field has dependencies that might create problems. It also depends on if the interaction has meaning (a "clear" button vs. "select all" and "backspace" vs. repeated backspacing). You should determine how users and other fields are expected to interact with editable fields before deciding the appropriate handling of this case. In some situations, users may feel better seeing the number gone - and in others, it may make them uneasy. Re-populating has similar considerations. If users expect to be able to remove all data from a field and when they do it auto-populates, then it is not helpful.

  • How would you deal with different kinds of units, i.e. absolute and relative ones, inside the same field? (Imagine CSS font sizes, which can be absolute, relative with percentage, absolute keyword, relative keyword or other keyword.)

From a UI/UX perspective, casual users will need more visual cues to understand that a "unit-less" number has an implied unit, or a "percentage" entry may need to display additional context or an example to be understood. For power users or trained users, this information may be unnecessary or even a distraction or hindrance (for cases where screen space is limited). Sometimes casual users do not know or understand the unit (or its symbol), so you may want to avoid using it for them at times also.

  • Do you think typed cells would work well in spreadsheet applications?

Typed cells are fantastic for users like me that like to keep my hands on the keyboard as much as possible. Lists are more helpful for users that are less concerned with that, for cases options should be limited, for users that may need "prompting" or "example" data to help them determine the proper value and other similar situations.

I hope this is helpful. I can elaborate more if you like, but I think it's pretty lengthy already.

1

Think about the cost/benefit of this feature.

  • How many of your users will actually want multiple units for entering the font?
  • How will this feature affect those who don't care about multiple units?

If it really is a word processing application, I'm not convinced this is a good idea in the first place. Most word processors don't support this, and I would expect very few users to want this level of specificity. Furthermore, it will make font selection slower, and potentially could even confuse the users. Of course, it is a lot of work to implement as well.

If you do implement the feature, I would treat it as a rare use-case:

  • Make it hidden in an advanced font settings dialog, rather than present in the main way of setting the font.
  • Use two separate fields to implement it--one for the number and one for the units. This removes the complicated scenarios you are worried about. It will also be easier to understand. It will be slower to use, but it still seems like a worthwhile trade-off.

In every two-field design I recall seeing, the number was automatically converted when one changed the unit. I would go with this, simply because it is common. I'm not sure one is really preferable over the other--there are uses cases in favor of either way.

  • As I said, font size was just an example, because I actually believe there should be a standard widget for this. Could as well be currency, body height, cooking temperature, blood sugar measurement, even bra size … Two separate fields still raise the important issue whether the number should be auto converted if the unit changes. – Crissov Oct 23 '14 at 10:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.