New .17 GUI: Number Input System

[Cabanur]

I posted this on the subreddit, but I think it belongs here better. I'm just gonna copypaste it here:

I strongly dislike sliders for number input. Here's my suggestion for an alternative:

Code: Select all

    +---+---+---+---+---+---+ +-----+
    | 0 | 1 | 2 | 5 | 10|x10| |   0 |
    +---+---+---+---+---+---+ +-----+

Six buttons next to the actual text field, which should use almost exactly the same space. The behaviour of all buttons except 0 is different if you left-click or right-click them.

• [0] Sets the field to 0. Allows you to undo whatever if you screw up.
• Left-click [1] - [10]: Add 1 - 10 to field.
• Right-click [1] - [10]: Substract 1 - 10 from field.
• Left-click [x10]: Append a 0 to the field (multiply by 10)
• Right-click [x10]: Remove right-most number (floor divide by 10)

This system allows you to very quickly insert any kind of number without moving your hand away from your mouse, and with unit precission regardless of the magnitude of the number.

It is also optimal for newbies. When a newbie sees a slider, he may very well consider there's a limited range to the number you can input in the field.

It is also optimal for power users. There is a consistent input accross all number inputs, including train timers. Color inputs could have buttons for 0, 1, 4, 16, 64 for easy color replication. Muscle memory develops over hundeds of hours. The input works perfectly for small numbers and large numbers alike, without any restrain or need to manually type numbers.

Examples:

[1] means left-click 1, [r5] means right-click 5.

• 1: [1]
• 10: [10] - Very useful to add 10s to a train schedule.
• 25: [10]x2 (20) [5|
• 50: [5] [x10|
• 75: [5] [x10] [10]x2 (70) [5] or [10] [x10] (100) [r10]x2 (80) [r5]
• 99: [10] [x10] [r1]
• 32k: [10]x3 [2] [x10]x3 - Generally, to put any number in the thousands, you put that same number then you click [x10]three times.
• 31999: [10]x3 [2] [x10]x3 [r1|
• -1: [r1] - one-button -1 ! This saves so much time when putting down combinators.
• -10: [r10] - Very useful to substract 10s from a train schedule.
• 125: [10] [x10] [10]x2 [5]

Let me know what you think!

[adiac]

I never thought about this, but the slider is really useless. For Inventory Logistics its okay. But anything circuit related I always type in the number. The Slider is way to imprecise. And it doesn't even Support negativ values.
And this field with some buttons looks like it could be very efficient.

Like clicking to the field, marking everything (if there was a number in there before), then moving the hand over to the numpad, typing the number, pressing enter, moving the hand back to the mouse... is pretty annoying.
In Factorio you can do most things without the Keyboard, so it would make sense.

[Factoruser]

Better: [-10] [ - ] [        ] [ + ] [+10] button arrangement; maybe Ctrl-clicking on + / - for plus/minus 100 or Shift-clicking for +/-10... "Sensible" values (10-stepping for seconds, 100-stepping for items)...

The slider is not very handy indeed, anyway.

[Lav]

Alternatively, only have [-] and [+] buttons to offset the value by 1, and multiply their effect by 10 if Shift or Ctrl are pressed. If both are pressed, multiply by 100. Should be enough for most purposes.

[Cabanur]

Better: [-10] [ - ] [ ] [ + ] [+10] b

These buttons are already in my original post. If you right click [1], [2], [5] or [10] the buttons substract instead of adding to the field. However, your idea may be cleaner with less buttons and more obvious behaviours for each of them.

plus/minus 100

With my original suggestion to remove or add 100, you first divide by 10 (right-click [x10]), then add/remove 10 (right-)clicking [10], then multiply by 10 again with [x10]. It is a bit more tedious than shift+click, but it's possible.

Alternatively, only have [-] and [+] buttons

This would be a simplification of my idea, which might very well be the best choice if it makes it more intuitive for new players.

[JohnyDL]

Wouldn't 12 buttons sort it?
[1][2][3][4][5][6][7][8][9][0][+-][backspace]

Intuitive like a calculator, no special learning of how to use it.

In fact why use the mouse to click it you have 11 of those buttons on the keyboard already, and 1 suitable substitute for the 12th

The slider is meant to be coarse control of course if you want fine input you should have to do something different but that's why you have the text box entry too. It's not like it's hard to use the number row in fact you're almost on top of it for 1-5 you can get 0s with the slider and the chances of actually needing the 6-9 are relatively low not impossible but low enough to not be worried about inventing a new input system.

Why reinvent the wheel?

I'd much rather have to text entry than worry about miss clicking my mouse (especially since it randomly double clicks sometimes anyway)

[Factoruser]

Better: [-10] [ - ] [        ] [ + ] [+10]

These buttons are already in my original post.

But not in that arrangement.

[eradicator]

I use the slider when i need an "approximate" value. So i would be very very sad indeed it they were removed. For precise numeric input my keyboard already has all the number keys i need, and the very idea of having to click at least once for every digit is ...disturbing at least. Also button-clutter is not a very good UI design philosophy. Besides i don't see the merit of your initial proposal. Why would i want to click 5 times to insert a 3 digit number? A simple on-screen numpad style gui element below the slider would be far more efficient AND intuitive to use for everybody.

Code: Select all

123 (ToggleMinus)
456 (Clear)
789 0

[bobingabout]

Better: [-10] [ - ] [        ] [ + ] [+10] button arrangement; maybe Ctrl-clicking on + / - for plus/minus 100 or Shift-clicking for +/-10... "Sensible" values (10-stepping for seconds, 100-stepping for items)...

The slider is not very handy indeed, anyway.

This.

[Koub]

I would favor the "stack approach" for the items :
[Empty] [-1 stack] [-1] [input field for numeric value] [+1] [+1 stack] [Fill]

And the "time unit" approach for the time
[-1h] [-1mn] [-1s] [input field for numeric value in seconds] [+1s] [+1mn] [+1h]

[Cabanur]

Wouldn't 12 buttons sort it?
[1][2][3][4][5][6][7][8][9][0][+-][backspace]

Technically it would work, but that's way too many buttons and you are effectively putting what you already have in hardware (a keyboard) on your screen, which seems unnecessary to me.

Why reinvent the wheel?

Because we can design a better wheel that suits our needs best than the existing one!

A simple on-screen numpad style gui element below the slider would be far more efficient

It might be more click-efficient, but way less space-efficient, which i think is an important factor when designing a GUI. Also, I think copying what you already have in your keyboard on your screen is a waste.

the merit of your initial proposal

My point is to use a consistent number input accross all places in the game where you can put numbers: logistics slots, train schedules, and circuit networks. My idea only uses 6 buttons (space-efficient, no visual clutter), provides unit-precission (as opposed to the most-significant-digit precission of the current slider) and provides a single array of buttons that are fit for all kinds of numbers the game requires, namely small units in the circuit network (-1, 0, 1), time amounts (2, 5, 10, 20, 30, 60, 120) and large numbers for logistics (100, 200, 500, 1k, 5k, etc)

I would favor the "stack approach" for the items :
[Empty] [-1 stack] [-1] [input field for numeric value] [+1] [+1 stack] [Fill]

And the "time unit" approach for the time
[-1h] [-1mn] [-1s] [input field for numeric value in seconds] [+1s] [+1mn] [+1h]

I, too, like the idea of having buttons to both sides of the text-field, but it effectively doubles the amount of buttons necessary where in my idea you just right-click the same button to make it negative. If you put different numbers for logistics (stack-size), trains (time-size) and circuit network (unit-size?) you break the consistency and therefore the user has to learn three different input methods, even if they have things in common. Also, the stack size is different for many items, and making the gui figure out which item is being selected to change the buttons means more code and more complexity.

[Koub]

I would favor the "stack approach" for the items :
[Empty] [-1 stack] [-1] [input field for numeric value] [+1] [+1 stack] [Fill]

And the "time unit" approach for the time
[-1h] [-1mn] [-1s] [input field for numeric value in seconds] [+1s] [+1mn] [+1h]

I, too, like the idea of having buttons to both sides of the text-field, but it effectively doubles the amount of buttons necessary where in my idea you just right-click the same button to make it negative. If you put different numbers for logistics (stack-size), trains (time-size) and circuit network (unit-size?) you break the consistency and therefore the user has to learn three different input methods, even if they have things in common. Also, the stack size is different for many items, and making the gui figure out which item is being selected to change the buttons means more code and more complexity.

Actually the stack size is a property of the item prototype. Getting any item's stack size should be something extremely easy.
And if the devs prefer to have a static gui, why not leave the "+1 stack" text (instead of the actual stack size) ?

[Cabanur]

why not leave the "+1 stack" text (instead of the actual stack size) ?

I agree this would work pretty well for logistics. But then you have a different input for logistics, train schedules and circuit networks. At this point I'm talking more about personal preference than one way being better than the other, but I prefer consistency accross my inputs.

[JohnyDL]

5x2 grid of buttons wouldn't be much more space than 1x6 imo but my point was you're not making a better wheel, you're making one that's more clunky than a slider, is less useful than a slider (given with 2 clicks in effect the slider can give you course adjustment from 1,2,3 to 20,000 which is enough to fill a box/inventory with any type of item stack. Getting to there with x10 is 5 clicks but there's also a problem request amount sets priority (iirc), so requesting 100,000 is substantially different from requesting 1,000,000 and could break some types of systems and not having an easy maximum might means inefficient distribution of items between requesters (if you're requesting several chests to fill with items).

If you want precision there's an easy way to get it right now, the keyboard, if you want 10, 100, 300, 1000, of an item which is by far more common than 75, or 37, the slider is perfectly adequate.

Don't get me wrong I do a lot of combinator work but actually that only strengthens my desire in this case to have the easy method of getting the 10s 100s 1000s with one or 2 clicks and not have to think too hard about it in a way I can get wrong, in a way that doesn't match the way of crafting 1, 5, all available items, and that requires extra work to learn and I have to be more constantly double checking if there's autosaves (that screw up clicks) or my hardware is breaking (and I know I should get a new mouse but that's besides the point people can accidentally multiple click the wrong number of times anyway or in the wrong place).

At speed type in 37296 with clicks (arbitrary number) thats what [1][1][1][1][x10][r1][r1][r1][x10][1][1][1][x10][x10][r1][r1][r1][r1] so that's 4 clicks move mouse click move back 3 clicks with a different finger move mouse click, move back 3 clicks move mouse 2 clicks move mouse 3 clicks with a different finger, that hardly sounds simpler than typing it in. 20,000 is one click now [1][1][x10][x10][x10][x10] and anything that doesn't start with 1 and has some 0s is a much more difficult task

I'd like to maybe see a single button after the slider that switches from item mode to stack mode, you should never need more than 100 stacks in an inventory and this slider can have all the numbers from 0-100, and when you're done it does the conversion to item count *wants 48 stacks of X* easy enough but gah your [1][10][x10] right click left click shift system really jars the mind

if you insist though make it consistent with the existing mechanic, left click is 1 right click is 5, have buttons for [/10][-10][-1][+/-][1][10][x10] right click is 5x whatever you click on, so instant 100,000 fill inventory with again now 1 right click on x10, and shift click maybe to add stackwise +1 stack etc.

But I still say it's an awful system compared to the ease of use of the slider.

[Kyralessa]

I'd simply like to see the type-in field select anything in it when I click in it, so I don't have to double-click to get it to do that.

[Cabanur]

At speed type in 37296 with clicks (arbitrary number) thats what [1][1][1][1][x10][r1][r1][r1][x10][1][1][1][x10][x10][r1][r1][r1][r1] so that's 4 clicks move mouse click move back 3 clicks with a different finger move mouse click, move back 3 clicks move mouse 2 clicks move mouse 3 clicks with a different finger, that hardly sounds simpler than typing it in. 20,000 is one click now [1][1][x10][x10][x10][x10] and anything that doesn't start with 1 and has some 0s is a much more difficult task

[2][1] (3), [x10] (30), [5][2] (37), [x10] (370), [2][1] (373), [x10][x10] (37300), [r2][r2] (37296). But, at this point I would type it manually too. This is why my idea doesn't get rid of the text field input system. Of course there's always gonna be numbers that are just faster to type in manually.

The point is having the more common numbers be as quick as possible to put in without moving your hand to the keyboard. The slider puts a lot of guessing into the mix which is uncomfortable, time-consuming and tedious.

I'd simply like to see the type-in field select anything in it when I click in it, so I don't have to double-click to get it to do that.

Yes, if the slider is to stay having the field be selected when you open the window would be a huge quality of life improvement.

[eradicator]

Before you go ahead and ignore my post: I challenge you to make a mock up mod that at least visually, at best functionally demonstrates the superiority of your layout in comparison to the other ones mentioned here. The tools are there in the API already.

A simple on-screen numpad style gui element below the slider would be far more efficient

It might be more click-efficient, but way less space-efficient, which i think is an important factor when designing a GUI. Also, I think copying what you already have in your keyboard on your screen is a waste.

Wtf. So you think clicking 2 to 5(!!) times more often, including having to move your mouse between buttons (which is error prone and time consuming) AND switching mouse keys AND having to calculate the number in your head first AND having to chose which of several different methods to input (6 times 1 vs 10 minus 4 etc...) ....that all that bulky and completely unintuitive interaction is worth saving 3 or 4 buttons worth of space on a gui that has tons of space to spare?

Also, I think copying what you already have in your keyboard on your screen is a waste.

I thought your whole point was that you don't want to use your keyboard because it's inefficient to move your hand. In that case you really should prefer the system that allows you to enter the number you want the fastest way possible. Otherwise your argument is inconsistent.

the merit of your initial proposal

My point is to use a consistent number input accross all places in the game where you can put numbers: logistics slots, train schedules, and circuit networks. My idea only uses 6 buttons (space-efficient, no visual clutter), provides unit-precission (as opposed to the most-significant-digit precission of the current slider) and provides a single array of buttons that are fit for all kinds of numbers the game requires, namely small units in the circuit network (-1, 0, 1), time amounts (2, 5, 10, 20, 30, 60, 120) and large numbers for logistics (100, 200, 500, 1k, 5k, etc)

It's already consistent. You replace intuitive ease of use with "space efficient" when space is not an issue. How is 6+ extra buttons less visual clutter than one slider? Your system becomes unfit for anything as soon as you have more than one non-zero digit.

I, too, like the idea of having buttons to both sides of the text-field, but it effectively doubles the amount of buttons necessary where in my idea you just right-click the same button to make it negative.

Wait. First you say you want to save space and have no visual clutter and then you agree on that spreading buttons on BOTH sides of the text-field is a good idea? The increase in mouse-travel-distance in such a layout is HUGE if you try to enter something like "1 stack minue 3" for requester chests.

If you put different numbers for logistics (stack-size), trains (time-size) and circuit network (unit-size?) you break the consistency and therefore the user has to learn three different input methods

You didn't seem to object the user having to learn new overcomplicated systems before if it makes input faster though.

[JohnyDL]

Eradicator he's wrong and he's seen it it's why he's picking and choosing his arguments. Rather than addressing all points I made he picked out the one where I used reductio ad absurdum rather than pointing out I was making a ridiculous point and deal with the other far more reasonable objections he chose to actually continue that as if it was legitimate and ignore the rest of my post, bad form.

All the 'easy' numbers in his system are a click and drag away in the slider anything that points out his system is prone to error he's ignoring

Code: Select all

Number | Slider | Manual | Cabanur (lazy)
-------|--------|--------|-----------
1      | 1      | 1      | 1 (-)
2      | 1      | 1      | 1 (-)
3      | 1      | 1      | 2 (3) [2][1] vs [1][1][1]
4      | 1      | 1      | 2 (-)
5      | 1      | 1      | 1 (-)
6      | 1      | 1      | 2 (3) [5][1] vs [2][2][2]
7      | 1      | 1      | 2 (-)
8      | 1      | 1      | 2 (4) [10][r2] vs [2][2][2][2]
9      | 1      | 1      | 2 (-)
10     | 1      | 2      | 1 (-)
11     | NA     | 2      | 2 (-)
12     | NA     | 2      | 2 (-)
13     | NA     | 2      | 3 (-)
14     | NA     | 2      | 3 (-)
15     | NA     | 2      | 2 (3) [10][5] vs [5][5][5]
16     | NA     | 2      | 3 (-)
17     | NA     | 2      | 3 (-)
18     | NA     | 2      | 3 (-)
19     | NA     | 2      | 3 (-)
20     | 1      | 2      | 2 (-)
21     | NA     | 2      | 3 (-)
22     | NA     | 2      | 3 (-)
23     | NA     | 2      | 4 (5) [2][x10][2][1] vs [10][10][1][1][1]
24     | NA     | 2      | 4 (-)
25     | NA     | 2      | 3 (5) [2][x10][5] vs [5][5][5][5][5]
26     | NA     | 2      | 4 (5) [2][x10][5][1] vs [10][10][2][2][2]
27     | NA     | 2      | 4 (-)
28     | NA     | 2      | 4 (6) [2][1][x10][r2] vs [10][10][2][2][2][2]
29     | NA     | 2      | 4 (-)
30     | 1      | 2      | 3 (-)
31     | NA     | 2      | 4 (-)
32     | NA     | 2      | 4 (-)
33     | NA     | 2      | 5 (6) [2][1][x10][2][1] vs [10][10][10][1][1][1]
34     | NA     | 2      | 5 (-)
35     | NA     | 2      | 4 (-)
36     | NA     | 2      | 5 (6) [2][1][x10][5][1] vs [10][10][10][2][2][2]
37     | NA     | 2      | 5 (-)
38     | NA     | 2      | 4 (5) [2][2][x10][r2] vs [10][10][10][10][r2]
39     | NA     | 2      | 4 (5) [2][2][x10][r1] vs [10][10][10][10][r1]
40     | 1      | 2      | 3 (4) [2][2][x10] vs [10][10][10][10]
50     | 1      | 2      | 2 (5) [5][x10] vs [10][10][10][10][10]
60     | 1      | 2      | 3 (4) [5][1][x10] vs [2][2][2][x10
70     | 1      | 2      | 3 (-)
80     | 1      | 2      | 3 (5) [10][r2][x10] vs [2][2][2][2][x10]
90     | 1      | 2      | 3 (-)
100    | 1      | 3      | 2 (-)
111    | NA     | 3      | 6 (-) non-trivial example takes twice as long as the typing method and you have to move the mouse between every press vs not at all
200    | 1      | 3      | 3 (-)
300    | 1      | 3      | 4 (5) [2][1][x10][x10] vs [1][1][1][x10][x10]
400    | 1      | 3      | 4 (-)
500    | 1      | 3      | 3 (-)
1000   | 1      | 4      | 3 (-)
2400   | NA     | 4      | 6 (-)
4800   | NA/1*  | 4      | 5 (8) [5][x10][r2][x10][x10] vs [10][10][10][10][10][r2][x10][x10]
9600   | NA/1*  | 4      | 6 (-)
19200  | NA/1*  | 5      | 7 (9) [2][x10][r1][x10][2][x10][x10] vs [2][x10][x10][r2][r2][r2][r2][x10][x10]

* close enough for 1 chest of plates/circuits/anything 5000, 10,000 and 20,000

I'll come back and fill in more numbers but every single cabanur method will get to be longer than almost any other I'm sure. And the lazy way is not moving your hand unless you have to which is far more efficient in most cases than stumbling through clicking multiple buttons once each.