Cursor placement in "Select a signal"

[ikarikeiji]

By clicking the selector, you'd be acknowledging that the other controls will be disabled while you select a signal or input a constant, an action that would take tiny amounts of time if this change were implemented.

No, I wouldn't be.

There is no indication immediately on the signal selector that your focus will be taken away. Remembering from before does not count.

Sure, add an option to do this if you really want, but not on by default.

[JohnyDL]

1: How do new users know this the first time they interact with the thing? opt in is only opt in so long as you know, if they don't know then they think that their controls being taken away is a bug

The first time they interact with the thing, they'd learn. Especially since most of their controls are still perfectly functional, it's a trade-off, and one that I think in excess of 99% of players come away on top. Standard keys to escape from dialogs still function perfectly fine. This dialog is in fact a special case, in that the only reason to pull up the dialog is to either enter a constant or select a signal. The dialog is up for a very short period of time, and this change reduces the amount of time the dialog is up even further.

Just because it's good for 99% doesn't make it a good argument to change it, where do you draw the line? 90%? 51%?

You are trading User eXperience and User Interface consistency for some benefit potentially even removing accessibility.

As for "learning" this the first time you use something, the sodding things were hard enough to get a handle on without making the UX less intuitive by default.

Snapping even a limited number of keys away from their default uses without warning or explanation or an obvious way to undo it in a panic is bad UI design. Since all the keys can be remapped you don't know that everyone uses the number keys the same way you do, someone using the numpad for their primary controls to me seems an obvious, and valid, alternative to WSAD and E you don't but it doesn't mean nobody does.

The obvious ways to close the dialog still work for the vast majority of people. It's unfortunate that a reasonable keybind concept (swapping the WASD + E over to the numpad) would develop a minor issue with this, but even then it's only a minor issue. They swap E over to the "+", "-", "*", "/", ".", or the numpad enter key and the UI becomes more functional for them.

You make it sound like swapping key binds is easy, I play a lot of minecraft and the picker/eye dropper tool there is middle click, factorio the default is Q so you know what happened after hours of trying to use the controls default? I changed them to match the other game I play, if this player always puts their inventory on 7 because WASD+E is mirrored to 8456+7 for their left hand in every game changing that for factorio is gonna be a pain in the ass, What if they use 4268 with 5 being shoot (which is a windows disability option default to use 5 as a trigger button and the numbers to move the mouse). Remap your E keys to Q and your Q keys to E and tell me that wouldn't make the game frustrating to play to the point you'd give up or revert the mapping. You're basically asking the same thing.

And you're saying that able people who play games are more important than disabled people just because there are more of them. This is one of the few games with substantial accessibility features allowing players of all types to play their way, there's no calling no biter mode 'baby mode', there's no calling sandbox mode 'cheating' pretty much every control can be remapped to anywhere else, the alt mode is a fantastically useful curb-drop feature, red/green/blue prints not only have their colours but different symbols too in 0.17, the UX has always tried to be consistent through out the game and in 0.17 really is etc etc, you're asking for some of this to go away.

In UI design consistency is important so as not to disorientate new users and screw up their User Experience, if you snap to a box in one place then you should snap to a box in all places that have similar apearances. In this case snapping to a slider with a number attached would be applicable in requester chests as well but the hot bar keys already have uses there, and the snapping there is ambiguous, if there are 8 items being requested which one gets the benefit of the snapping feature, and what does that mean if there are no items being requested?

In your own inventory there is a slider for trash slots and requesting while the hot bar keys can be used to assign items to the toolbar.

In trains there are sliders and numbers attached too, but not in all cases how do you provide a consistent and pleasant UI in that example?

But if you're snapping to text boxes why not the names of blueprints? or search functions?

You've answered your own questions in a lot of these circumstances. Requester chests? You're frequently moving from chest to chest looking at things. It would be a regular disruption to take away user controls every time they open them and of minimal value. If you're adjusting values in one, you almost always have to move your mouse over there anyways to select items. Though I could make an argument that upon selecting an item, it might be beneficial to highlight the item selection field under the same set of rules as above. Being able to select the item, type 10, and then press a key (E by default) to unbind my input from that field makes a lot of sense.

Your own inventory? That's regularly opened and closed and taking away user controls every time they open up their inventory would be a major hassle. To basically every player. Even just removing the ability to use numerics would be a substantial hassle to a lot of players. It's obvious why this is a bad idea.

Trains have multiple text boxes and sliders. There's no 'obvious' first choice for where to focus text input and the need to type text into trains is infrequent at best. There's no need or benefit from any kind of automatic text focusing there and it's ambiguous.

Blueprints? Search functions? No need for this optimization and these would would take away inherently all user controls as these text boxes allow full text entry.

So you're acknowledging my point then? Taking away controls in these places would detract from the UX

Right but from a UI consistency and UX consistency perspective you'd have to do the same thing every place with the same type of text box or you make the learning curve harder. If you're doing one thing in one place and everywhere else it's different then things become harder to learn. For example, I can't recycle at home, the few places I've worked haven't been recycle either, and my city doesn't seem to have recycling in public, so if I empty a bottle 99% of the places where I might empty it it's destined for the bin, so when I go to my mum who does have recycling and put an empty bottle in the bin there I get told off for not recycling it, I might might empty a bottle there once a month and every time I forget because it's a special set of rules in one place compared to everywhere else. The snapping is going to be the same either you're going to forget the snapping and be annoyed by it every time you go to that place because even though you're 'expecting it' and know about it there's an inconsistency you have to deal with, or the reverse will happen which would be my mum being so used to recycling that it's second nature and she comes to my place and asks me "where's your recycling box?" you'd become so used to the snapping being in and out of combinators all the time that you expect the snapping everywhere but don't get it

UI Consistency is important, but it's not a 100% unbreakable rule. There are exceptions. You talk about all of these other locations where the slider shows up or other places where other text boxes show up but there are good obvious reasons that a large number of players aren't going to want those text boxes auto-focused. This is in fact a special case. Even if it meant completely removing all controls to allow this simple optimization in this one spot, I'd still support it. When you start doing constants on lots of combinators, it's a major time saver and I'm hard pressed to believe it'd be any substantial annoyance to any substantial number of users.

Simply put, I think you're comparing apples and oranges. There are times that UIs with substantially different purposes follow a slightly different set of rules. Even if I was someone who rebound movement to the number keys of the num pad, I'd still rather have those keys focused to that input.

But even within only the select a signal submenu this would end up being inconsistent, not every signal can be set to a constant so do you take player controls away even when there isn't a number to enter? How do you justify your answer cause I think both are wrong, yes you take away controls for no good/obvious reason, no you allow inconsistency into the design that will confuse players. And there's a search box in that menu, why couldn't people argue that instead should be auto selected instead of this, the majority of cases shouldn't you want to select a signal not type in a number? Deciders and Arithmetic both use 2 signals and only one constant, while Constant combinators can't even use the set a constant part of the set a signal sub menu, instead it's just in the combinator menu. On that point do you then add snapping there? and how would snapping there be any different to snapping to logistic sliders? it's basically the same feature (multiple options with multiple sliders and numbers). Or do you only snap sometimes even within constant combinators? Or not at all and have combinators inconsistent? Do you snap there after selecting the signal you want but not when opening the constant combinator's UI? what if the constant combinator only has one signal? should you snap when you open it then or not?

I'm looking at the global picture of the game because it's a million times easier to acknowledge that the idea has no legs elsewhere in the game, you've admitted that yourself. I definitely wouldn't call this an optimisation or even QOL to add this when there's no consistant way to make it happen within the game. It's hardly apples and oranges it's just a question of scale.

There is one place in the game with an autosnapping feature already (Map tags) and I don't like that either, for the same reason, it makes the UI less consistent and changes the way I have to interact with the game without giving me that explicit opt in that I'm taking my controls away. Even though if I'm making a tag I should probably want to name that tag something 90% of the time, that my usual response to exiting that UI element without doing anything is taken away by default really really annoys me, especially cause it's easy to accidentally right click on the map, and there are times when using tags on MP servers that using tags to outline areas can be really useful which is click enter repeat, deleting tags isn't as intuitive because of that snapping, I'd like click delete but since it snaps to typing delete would just start erasing the tag's name, and so I have to use the mouse to click the delete button, using the delete key would be an opt in because with default controls requires moving my hand away over to it and the devs would include a way to remap this button like all the others. But the way this feature is set up also means tag spamming is much easier to do than cleaning up that same spam which isn't exactly great design either.

[Darinth]

I'm going to open this up with the simple statement that I'm conceding the point that having mandatory snap to this text box is likely to bother more people than I'd expected. That's not to say that I don't want an option for it, in fact I want an option for it really really badly still; it's one of those things that I regard as sufficiently inefficient that I actually work with combinators less as a direct result. But making a change to appease one group while frustrating another is not the right course.

I also don't regard removing accessibility as an acceptable option under pretty much any circumstance, though I have to acknowledge I don't think this would've impacted it and if it did it would've been relatively easy to work around, such as disabling the auto-snap if the E key were rebound to a numeric.

I want something available to simplify combinator setup and am generally willing to take whatever reasonable shortcuts someone is willing to hand me. My father taught me to program when I was 6, understanding computers and combinator logic is relatively easy, but ohh how I hate the tedious process of actually setting the things up. I'm guessing it's why, as much I like setting up my various machines and as cool as I find many of the redstone contraptions that I see people put together in minecraft, I'm rarely willing to work with vanilla redstone. I just find the process itself tedious.

[provet]

Is this even possible to add as a mod just to experiment with the feature and see what side-effects it would have?

[Bergham]

TL;DR

When selecting a signal for the circuit network, the amount field should be empty and ready for typing in a number.

What ?

Factorio number before.jpg (616.14 KiB) Viewed 483 times

Factorio number after.jpg (653.84 KiB) Viewed 483 times

Why ?

More comfort when creating new circuits.
Skipping a step.

I hope this says all. (edit: second picture didn't show)

[Koub]

[Koub] Merged into older thread with same suggestion

[Illiander42]

Now that "E" is pressing confirm, what actions would this make take an extra step?

Any?