2

I'm writing a wasm statistical calculator, so I need to allow an arbitrarily long number input on my website's front end. My current design looks like this:

screenshot of 'mean' form

A number is entered where the line is. Enter adds a new number input to the end and focuses it. Emptying an input removes it (and similarly focuses the last element), for instance like below:

enter image description here

The 'calculate' button can be clicked/pressed, and the page logic will take place, outputting results above the input.

How can I improve this such that it takes no instruction to use?

Edit

In case the above description of the current design was confusing, here's a GIF

enter image description here

5
  • Provide an example instead of instruction. More thoughts: Why must they be separate fields? You can provide a single input textarea and allow the user to separate values via a character (e.g. any whitespace). Then you can parse and validate the values before supplying them to your function. Best of all, this allows for a placeholder value (a type of example), which is often as or more useful than any instruction. – jsejcksn May 30 at 8:28
  • @jsejcksn I thought about using a plain text area - ultimately I rejected it because it would require a lot of parsing and validation overhead for all the intuitively correct but subtly incorrect ways to input text: separating with a newline, varying delimiters across the whole, etc. – lincoln May 30 at 15:04
  • 1
    I just worked on a one day hack project that did exactly this. It wasn't as bad as you might think, but YMMV. See parseNumbers in src/utils.ts in the sandbox link: jx4f4.csb.app – jsejcksn May 30 at 17:33
  • @jsejcksn I guess I'm not sure what the 'correct' behavior is for that. If I enter "4-3", should that be interpreted as a 4 and a 3, a 4 and a -3, or, as it currently interprets it, a 4? If I use commas to separate parts of a number, how should it be interpreted? 100,012: 100 and 12 or 100012? To me it makes sense to avoid these problems altogether by enforcing a single way to enter numbers and disallowing some confusing notations. Is that reasonable? I know next to nothing about UI, so I'm really just guessing at what I should do. Thanks so much! – lincoln May 30 at 17:44
  • Although you haven't said so, my intuition is that this is in a web browser and that you're using <input type="number"> to do number validation. I think "parsing number values" is an entirely different question, and you can make decisions about an implementation yourself. There is no wrong answer—it's your app and your API! – jsejcksn May 31 at 8:22
1
+50

There are a couple of elements I see rare or unusual in the design:

  1. The button moves when adding new numbers, this is totally unusual in interactivity. One of the premises in interactivity is the user must clearly know where to interact, if the interaction field changes places it generates uncertainty.
  2. The text insertion line is horizontal, this occurs in coding programs but it's unusual in user interfaces, where the text field is accompanied by the vertical blinking insertion line.

I can think of two basic possibilities, one complete and one with more interactivity. The base is the same for both, a text insertion field, an area with the added quantities, a scroll bar to see the hidden numbers and the operation buttons:

enter image description here

The second has the same elements but is cleaner, favoring the vision of the data:

  • Info button shows the tooltip
  • Eraser button to reset
  • Check button to calculate

enter image description here

Added after the comment

How modification or deletion of an individual element takes place?

To edit an element:

  • Click the element to select it
  • Tap the Erase Button to delete the content
  • Type the new number at the text insertion field

To delete an element:

  • Click the element to select it
  • Tap twice the Erase Button

enter image description here

3
  • Re: the first point you made, I want my interface to be very efficient with a keyboard. Organizing it so that the calculate button occurs after the text inputs allows numbers to be entered, tab to navigate to the final button, and space/enter/whatever to calculate. Re: 2, I think my screenshots were a bit unclear - the small line in the top is where the result will be shown, and the long lines below are each styled <input type="number"/>s. I like the designs you suggested, but I'm not sure how modification or deletion of an individual element takes place. Could you clarify that? Thanks! – lincoln May 30 at 17:07
  • Answer updated.- – Danielillo May 30 at 18:02
  • 2
    "The second has the same elements but is cleaner" I'd have to disagree. I don't think there's any reason to hide the labels ever, and your erase logic is not clear at all: "Tap twice the Erase Button" will never be discovered. – lights0123 May 30 at 20:57

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.