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.
No, I wouldn't be.
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%?Darinth wrote: ↑Thu Mar 07, 2019 3:03 pmThe 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.
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.Darinth wrote: ↑Thu Mar 07, 2019 3:03 pmThe 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.JohnyDL wrote: ↑Sun Oct 01, 2017 4:24 pmSnapping 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.
So you're acknowledging my point then? Taking away controls in these places would detract from the UXDarinth wrote: ↑Thu Mar 07, 2019 3:03 pmYou'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.JohnyDL wrote: ↑Sun Oct 01, 2017 4:24 pmIn 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?
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.
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?Darinth wrote: ↑Thu Mar 07, 2019 3:03 pmUI 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.
Users browsing this forum: Bing [Bot]