Friday Facts #243 - New GUI tileset
-
- Manual Inserter
- Posts: 1
- Joined: Tue May 22, 2018 7:11 pm
- Contact:
Re: Friday Facts #243 - New GUI tileset
1. Text readability is bad. Mostly, it's because of too compressed line height. Also, note that you're making a life for people with disorders really harder because it's harder to distinguish lines. Maybe it even worth to make body text smaller, but maintain same line height.
2. It's hard to tell does UI using any grid at all, but some random spacings and element sizes suggest that it doesn't. Because there is no vertical rhythm, defined by main line height, some sizes feel unbalanced in relation to each other or at least a bit off.
3. Can't get rid of the feeling that's something misaligned here
It would be safer to align h1 to the bottom of the decorative element.
4. A spacing between the decorative element and body text feels too small and inconsistent
5. Buttons clearly missing focus state. Though, I'm not sure about plans to support keyboard\gamepad navigation at all.
6. A subjective thing, but glows on hovers and some presses are too aggressive and make UI very cheap and plastic. I'd review them.
7. "Press" state actually should be called "active".
8. Unclear, why sliders inputs have almost identical to buttons appearance. They aren't buttons. They're inputs.
9. Slider's filled area somehow is thicker than a notch
Mind games?
10. Good disabled buttons are always hard to design. This one feels close, but the label is too bright, which feels like it's another type of the button or filled input. Or like it's a disabled input.
11. Completely unclear why Confirm button has another disabled colors, as well as Cancel button. I tried to justify it for myself, but there is no motivation to make its appearance different.
12. An idea to align labels of Confirm and Back buttons doesn't worth it, and looks especially od and harder to read when placed next to each other, due to emptiness between them. Align labels at center, don't create unjustified system exceptions. Even when they will be placed at sides, centered labels will give better, consistent readability. Don't make the user search label on Confirm button.
13. Cancel button appearance is very questionable. I'd recommend making its appearance more different than regular buttons since it is usually dangerous action. For instance, it could be a "ghost" button, which will attract much less attention
.
The complete visual difference makes it clear that it is very different action and forces the user to think before clicking it.
I'd even argue that it shouldn't be red
because red makes it stand out too much and instead of protecting the user from stupid actions encourages him to do it.
14. It is unclear why checkboxes have such different appearance than switch and radio buttons
For some reason, it's hovered above the background, like a button, on contrary to other similar element types, which are embedded.
15. Not important, but unclear why some headings have been putted outside of the frame, while other — inside
16. Loading bar "Loading sprites" label placed in illogical place. Loading bar moves from left to right, and constantly catching user attention, while the label is at the right side. When user will try to read the label, it will make user's eyes jump back and forth without any reason. Center it.
17. The idea between stickers, crafting button, and virtual slot design is very obscure. If they are important to be visually different, I must admit that even in that example they're almost too similar to tell the difference.
18. I'd question that often usage of hover on buttons and some interactive elements. Hovers should facilitate some specific interaction, but when we're talking about buttons and most form elements, interaction is clear enough without hover, while hover itself becomes just a constantly annoying noise. At best hover, if present, should be subtle, to help, but avoid noise and collisions with active elements. In most examples hover effect is just too "in the face".
2. It's hard to tell does UI using any grid at all, but some random spacings and element sizes suggest that it doesn't. Because there is no vertical rhythm, defined by main line height, some sizes feel unbalanced in relation to each other or at least a bit off.
3. Can't get rid of the feeling that's something misaligned here
It would be safer to align h1 to the bottom of the decorative element.
4. A spacing between the decorative element and body text feels too small and inconsistent
5. Buttons clearly missing focus state. Though, I'm not sure about plans to support keyboard\gamepad navigation at all.
6. A subjective thing, but glows on hovers and some presses are too aggressive and make UI very cheap and plastic. I'd review them.
7. "Press" state actually should be called "active".
8. Unclear, why sliders inputs have almost identical to buttons appearance. They aren't buttons. They're inputs.
9. Slider's filled area somehow is thicker than a notch
Mind games?
10. Good disabled buttons are always hard to design. This one feels close, but the label is too bright, which feels like it's another type of the button or filled input. Or like it's a disabled input.
11. Completely unclear why Confirm button has another disabled colors, as well as Cancel button. I tried to justify it for myself, but there is no motivation to make its appearance different.
12. An idea to align labels of Confirm and Back buttons doesn't worth it, and looks especially od and harder to read when placed next to each other, due to emptiness between them. Align labels at center, don't create unjustified system exceptions. Even when they will be placed at sides, centered labels will give better, consistent readability. Don't make the user search label on Confirm button.
13. Cancel button appearance is very questionable. I'd recommend making its appearance more different than regular buttons since it is usually dangerous action. For instance, it could be a "ghost" button, which will attract much less attention
.
The complete visual difference makes it clear that it is very different action and forces the user to think before clicking it.
I'd even argue that it shouldn't be red
because red makes it stand out too much and instead of protecting the user from stupid actions encourages him to do it.
14. It is unclear why checkboxes have such different appearance than switch and radio buttons
For some reason, it's hovered above the background, like a button, on contrary to other similar element types, which are embedded.
15. Not important, but unclear why some headings have been putted outside of the frame, while other — inside
16. Loading bar "Loading sprites" label placed in illogical place. Loading bar moves from left to right, and constantly catching user attention, while the label is at the right side. When user will try to read the label, it will make user's eyes jump back and forth without any reason. Center it.
17. The idea between stickers, crafting button, and virtual slot design is very obscure. If they are important to be visually different, I must admit that even in that example they're almost too similar to tell the difference.
18. I'd question that often usage of hover on buttons and some interactive elements. Hovers should facilitate some specific interaction, but when we're talking about buttons and most form elements, interaction is clear enough without hover, while hover itself becomes just a constantly annoying noise. At best hover, if present, should be subtle, to help, but avoid noise and collisions with active elements. In most examples hover effect is just too "in the face".
- thereaverofdarkness
- Filter Inserter
- Posts: 558
- Joined: Wed Jun 01, 2016 5:07 am
- Contact:
Re: Friday Facts #243 - New GUI tileset
Nothing outside of the public domain should be universal, especially anything owned by Microsoft.
Re: Friday Facts #243 - New GUI tileset
I think this is possible. As an example, take a look at:Sigma1 wrote:How about an option for the player to use their own font through mods or something if they want?
With some default one of course, like TItillium or Roboto. Or Verdana.
Code: Select all
FACTORIO_ROOT\data\core\locale\he\info.json
Leading Hebrew translator of Factorio.
Re: Friday Facts #243 - New GUI tileset
Surely you meant the greatest font in the world loved by many - Comic Sans.
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: Friday Facts #243 - New GUI tileset
Yes.thereaverofdarkness wrote:I've been curious about that for a long time. They are essentially useless attributes in-game because vanilla ores within a category generally have the same hardness. I wish the base game would make more use of the hardness attribute.bobingabout wrote:don't forget there's a difference between mining speed and mining power.
After reading your explanation, I was able to verify it seems that your equation is correct. I am guessing that without a tool your mining power is 1, which would explain why stone (hardness 0.4) mines many times faster than standard ore (hardness 0.9).
Personally I feel that any font where the lower case L and capital i look the same should be avoided too, like, shouldn't even exist kind of avoid them, yet people say that you should always give a Dyslexic a sans serif font... about about 90% of sans serif fonts have an I that looks like and l, if anything those are your target audience to avoid this!thereaverofdarkness wrote:No font should ever do this. Titillium has a difference between I and l: the l is slightly taller. But the difference is small enough to suggest it isn't a very good font. Titillium seems generally very readable overall, but it has a few quirks with some letters. Mostly these are either minor annoyances or subjective views, but it has a few instances in which small details are almost invisible. Case in point: the little nips on u and n.seePyou wrote:One thought: The use of any font that has the same character for small L and capital I should be avoided. The Tittilium font fits this description. I would encourage you to change this, if you can, or choose another.
They also recommend that comic sans is the best font to give a dyslexic, due to the simple, yet unique style of each letter making them more recognisable and easier to read.
Personally, I feel that comic sans feels unprofessional, and cringe whenever I see it on a CV document, I remember I was told in school that you need to use a very specific plain and easy to read font, yet don't remember what that font was. Possibly Arial. Though the more modern me, armed with all this knowledge basically sees anyone using the comic sans font as them shouting "I'm dyslexic!" on their paper/screen.
- thereaverofdarkness
- Filter Inserter
- Posts: 558
- Joined: Wed Jun 01, 2016 5:07 am
- Contact:
Re: Friday Facts #243 - New GUI tileset
There is no need to give dyslexic or other people a sans serif typeface. If you avoid Times New Roman, which is a very bad typeface and should never be in general use, you will generally avoid problems. There are lots of serif-ed typefaces that are legible because their serifs are minimal and unobtrusive. Furthermore, there are plenty of typefaces without serifs which have marks on the capital I.bobingabout wrote:yet people say that you should always give a Dyslexic a sans serif font
Examples of typefaces with serifs which are legible: Georgia, Palatino Linotype
Examples of typefaces without serifs which feature capital I wings: Comic Sans MS, Segoe UI
Examples of typefaces without serifs and without capital I wings, but which distinguish the l and I characters in another way: Candara, Gabriola, whatever font this forum is using
Re: Friday Facts #243 - New GUI tileset
My history professor always insisted that we had to use Times New Roman 12pt.thereaverofdarkness wrote:There is no need to give dyslexic or other people a sans serif typeface. If you avoid Times New Roman, which is a very bad typeface and should never be in general use, you will generally avoid problems. There are lots of serif-ed typefaces that are legible because their serifs are minimal and unobtrusive. Furthermore, there are plenty of typefaces without serifs which have marks on the capital I.bobingabout wrote:yet people say that you should always give a Dyslexic a sans serif font
Examples of typefaces with serifs which are legible: Georgia, Palatino Linotype
Examples of typefaces without serifs which feature capital I wings: Comic Sans MS, Segoe UI
Examples of typefaces without serifs and without capital I wings, but which distinguish the l and I characters in another way: Candara, Gabriola, whatever font this forum is using
Yeah.
There are 10 types of people: those who get this joke and those who don't.
- thereaverofdarkness
- Filter Inserter
- Posts: 558
- Joined: Wed Jun 01, 2016 5:07 am
- Contact:
Re: Friday Facts #243 - New GUI tileset
I had several teachers insist on this. I don't know why they would choose such an awful typeface, don't they want to ensure the paper is readable? Some specifically insisted that we use TNR because it's readable, as if you can't just pick a random typeface and get something easier to read. Aside from symbol typefaces (like Webdings), the only typefaces that are harder to read than TNR is really extravagant text like Playbill or Jacques & Gilles.Jap2.0 wrote:My history professor always insisted that we had to use Times New Roman 12pt.
Yeah.
Re: Friday Facts #243 - New GUI tileset
Thanks, this works when I do it inDev-iL wrote:I think this is possible. As an example, take a look at:Code: Select all
FACTORIO_ROOT\data\core\locale\he\info.json
Code: Select all
FACTORIO_INSTALL/data/core/locale/en/info.json
she/they
Re: Friday Facts #243 - New GUI tileset
I guess it would present a more aged "technical" look to the game 80s nostalgia me thinks Shall we ask for feature request on Themes for Factorio?Sigma1 wrote:Thanks, this works when I do it inDev-iL wrote:I think this is possible. As an example, take a look at:Code: Select all
FACTORIO_ROOT\data\core\locale\he\info.json
BTW Factorio looks incredibly good with monospace as the font everywhere!Code: Select all
FACTORIO_INSTALL/data/core/locale/en/info.json
Re: Friday Facts #243 - New GUI tileset
You have my support for sure!seePyou wrote:Shall we ask for feature request on Themes for Factorio?
she/they
-
- Inserter
- Posts: 20
- Joined: Tue Jul 12, 2016 10:56 pm
- Contact:
Re: Friday Facts #243 - New GUI tileset
In the FFF, you mentioned that you would be using the GNOME button order. Sadly, I know from experience that this makes the interface hard to use for Windows users.
Let's see now.... If I may?, try to think from a usability perspective ... not so much based on your own preferences but how it will affect many types of people.
First, the technical issue:
1. In Windows, the "Confirm" button must always be the leftmost button and the "Cancel" button must always be the rightmost button.
3. in GNOME, these rules are completely reversed.
The problem for users:
Believe it or not, this small issue confuses users immensely. If you design for GNOME, it will confuse Windows users and vice versa.
As an example, the GIMP program used to reverse the buttons ... and it was a pain to use; I constantly clicked the wrong button. It took me a while to actually figure out why it was such a big problem, since it is not very obvious. I've also experienced this issue in Factorio, when key dialogs have the buttons reversed.
Argument #1: Users can read, so why does it matter?
Think back to your UI/UX studies. The difference between a good design and a bad one is very subtle to notice sometimes. In this case, the issue is that most users have learned the button ordering for their OS so well that they no longer have to "read" the actual buttons .. it is just "muscle memory". This allows a person do things much faster since they don't have to waste time reading. ... However, if you switch the layout a person has learned, they will automatically click the wrong button.
Argument #2: Why not just make Factorio use GNOME style everywhere; people can eventually learn that, right?
Not really. If the user comes from Windows, they are constantly using the Windows layout in every other program. So, every time they switch to Factorio, they will mess up. Or... even worse is that a user learns the Factorio layout so well that they now mess up in every other Windows program! (Keep in mind that you are confusing a person's muscle memory; this is hard to overcome.)
Argument #3: Well I'm not personally affected by this, and it just sounds silly that other people would be.
As a UI/UX designer you can't think like this. If you use Linux all the time and if Factorio uses the GNOME layout, then you will think everything is great. Or, if you don't use a single OS heavily every single day, then you won't see the issue because you haven't personally developed that particular muscle memory. This issue is definitely very subtle and context sensitive, but when it happens in a program it can make things a pain to use.
The solution:
The solution is rather simple:
1. Define the 2 key buttons: the "Confirm" or "action" button and the Cancel button
2. In Linux builds, put the active button like "Confirm" to the far right, and "Cancel" to the far left. (by default)
[Cancel] [button 1] [button 2] [Confirm]
[(exit this menu and cancel any changes)] [random button 1] [random button 2] [(initiate the main action)]
3. On Windows, put the active button like "Confirm" to the far left, and "Cancel" to the far right. (by default)
[Confirm] [button 1] [button 2] [Cancel]
[(initiate the main action)] [random button 1] [random button 2] [(exit this menu and cancel any changes)]
4. All other "random" buttons go between the Cancel and Confirm.
5. Note: For all OSes, it is ok if the row of buttons (as a group) is left aligned.
5. Problem: I am unsure of "Back" button placement because I do not know the context in which you intend to use it. So, I don't want to steer you wrong.... However, I do know the following is the correct order for Windows if there's these specific buttons:
[Back][Next][Cancel]
As you can see "Cancel" MUST ALWAYS remains as the leftmost button.
On the other hand, if you are using "back" as a replacement for "Cancel" (like in the multiplayer list) then it would go in the same spot as "Cancel"
[Join game] [Refresh] [Back]
Here's some dialogs from Factorio and their order:
Multiplayer list:
Windows: [Join game(action)] [Refresh] [Back (cancel)]
GNOME: [Back] [Refresh] [Join game]
Hosting a game, creating a game, etc...
Many of these dialogs currently follow the Windows ordering, but have many extra buttons on the left side of the screen like this:
Windows: [Reset] [Generate preview] ................... [Generate][Close]
GNOME: [Reset] [Generate preview] ................ [Close] [Generate]
Having them separate is fine, but if you do decide to group them all together, then the layout would look like this:
Windows: [Generate] [Reset] [Generate preview] [Close]
GNOME: [Close] [Reset] [Generate preview] [Generate]
Tips and Tricks:
Windows: [Previous] [Next] [Cancel]
GNOME: [Cancel] [Previous] [Next]
Tag properties
Windows: [Confirm] [Delete] [Cancel]
GNOME: [Cancel] [Delete] [Confirm]
Options > Controls
currently the two buttons are separate, ideally they should all be aligned together as a group on the right side for all OSes:
Windows: [Reset] [Cancel]
GNOME: [Cancel] [Reset]
Options > Mod Settings
Windows: [Apply] [Reset] [Reload] [Cancel]
GNOME: [Cancel] [Reset] [Reload] [Apply]
I can't believe I made such a big deal out of this. But I do know from experience that it is a super annoying issue to have when programs get it wrong... and I'm hoping you can make a solution for Factorio.
I know from experience that this is gonna make the interface hard to use for a portion of the Factorio userbase. Let me backup and try to explain in a friendly tone.kovarex wrote: *Confirm button will be located always at the right side.
Back button * Located always at he left side.
Let's see now.... If I may?, try to think from a usability perspective ... not so much based on your own preferences but how it will affect many types of people.
First, the technical issue:
1. In Windows, the "Confirm" button must always be the leftmost button and the "Cancel" button must always be the rightmost button.
3. in GNOME, these rules are completely reversed.
The problem for users:
Believe it or not, this small issue confuses users immensely. If you design for GNOME, it will confuse Windows users and vice versa.
As an example, the GIMP program used to reverse the buttons ... and it was a pain to use; I constantly clicked the wrong button. It took me a while to actually figure out why it was such a big problem, since it is not very obvious. I've also experienced this issue in Factorio, when key dialogs have the buttons reversed.
Argument #1: Users can read, so why does it matter?
Think back to your UI/UX studies. The difference between a good design and a bad one is very subtle to notice sometimes. In this case, the issue is that most users have learned the button ordering for their OS so well that they no longer have to "read" the actual buttons .. it is just "muscle memory". This allows a person do things much faster since they don't have to waste time reading. ... However, if you switch the layout a person has learned, they will automatically click the wrong button.
Argument #2: Why not just make Factorio use GNOME style everywhere; people can eventually learn that, right?
Not really. If the user comes from Windows, they are constantly using the Windows layout in every other program. So, every time they switch to Factorio, they will mess up. Or... even worse is that a user learns the Factorio layout so well that they now mess up in every other Windows program! (Keep in mind that you are confusing a person's muscle memory; this is hard to overcome.)
Argument #3: Well I'm not personally affected by this, and it just sounds silly that other people would be.
As a UI/UX designer you can't think like this. If you use Linux all the time and if Factorio uses the GNOME layout, then you will think everything is great. Or, if you don't use a single OS heavily every single day, then you won't see the issue because you haven't personally developed that particular muscle memory. This issue is definitely very subtle and context sensitive, but when it happens in a program it can make things a pain to use.
The solution:
The solution is rather simple:
1. Define the 2 key buttons: the "Confirm" or "action" button and the Cancel button
2. In Linux builds, put the active button like "Confirm" to the far right, and "Cancel" to the far left. (by default)
[Cancel] [button 1] [button 2] [Confirm]
[(exit this menu and cancel any changes)] [random button 1] [random button 2] [(initiate the main action)]
3. On Windows, put the active button like "Confirm" to the far left, and "Cancel" to the far right. (by default)
[Confirm] [button 1] [button 2] [Cancel]
[(initiate the main action)] [random button 1] [random button 2] [(exit this menu and cancel any changes)]
4. All other "random" buttons go between the Cancel and Confirm.
5. Note: For all OSes, it is ok if the row of buttons (as a group) is left aligned.
5. Problem: I am unsure of "Back" button placement because I do not know the context in which you intend to use it. So, I don't want to steer you wrong.... However, I do know the following is the correct order for Windows if there's these specific buttons:
[Back][Next][Cancel]
As you can see "Cancel" MUST ALWAYS remains as the leftmost button.
On the other hand, if you are using "back" as a replacement for "Cancel" (like in the multiplayer list) then it would go in the same spot as "Cancel"
[Join game] [Refresh] [Back]
Here's some dialogs from Factorio and their order:
Multiplayer list:
Windows: [Join game(action)] [Refresh] [Back (cancel)]
GNOME: [Back] [Refresh] [Join game]
Hosting a game, creating a game, etc...
Many of these dialogs currently follow the Windows ordering, but have many extra buttons on the left side of the screen like this:
Windows: [Reset] [Generate preview] ................... [Generate][Close]
GNOME: [Reset] [Generate preview] ................ [Close] [Generate]
Having them separate is fine, but if you do decide to group them all together, then the layout would look like this:
Windows: [Generate] [Reset] [Generate preview] [Close]
GNOME: [Close] [Reset] [Generate preview] [Generate]
Tips and Tricks:
Windows: [Previous] [Next] [Cancel]
GNOME: [Cancel] [Previous] [Next]
Tag properties
Windows: [Confirm] [Delete] [Cancel]
GNOME: [Cancel] [Delete] [Confirm]
Options > Controls
currently the two buttons are separate, ideally they should all be aligned together as a group on the right side for all OSes:
Windows: [Reset] [Cancel]
GNOME: [Cancel] [Reset]
Options > Mod Settings
Windows: [Apply] [Reset] [Reload] [Cancel]
GNOME: [Cancel] [Reset] [Reload] [Apply]
I can't believe I made such a big deal out of this. But I do know from experience that it is a super annoying issue to have when programs get it wrong... and I'm hoping you can make a solution for Factorio.
- thereaverofdarkness
- Filter Inserter
- Posts: 558
- Joined: Wed Jun 01, 2016 5:07 am
- Contact:
Re: Friday Facts #243 - New GUI tileset
I'm a lifelong Windows user and I think you're wrong. Windows has always had it backward, and it's certainly not familiarity with which I say this. Nearly every application that isn't forced to put the confirm button on the left puts it on the right. It seems correct because it is congruent with everything else we're used to in life. As a Windows user, I have learned to read the buttons before I click them, because I can never expect them to be in the order in which I think they should be.Kevin Ar18 wrote:1. In Windows, the "Confirm" button must always be the leftmost button and the "Cancel" button must always be the rightmost button.kovarex wrote: *Confirm button will be located always at the right side.
Back button * Located always at he left side.
3. in GNOME, these rules are completely reversed.
- bobingabout
- Smart Inserter
- Posts: 7352
- Joined: Fri May 09, 2014 1:01 pm
- Contact:
Re: Friday Facts #243 - New GUI tileset
at least when I was in school... the later years anyway, because it took that long to get decent computers, it was either Times new Roman, or Arial, depending on your preference.thereaverofdarkness wrote:I had several teachers insist on this. I don't know why they would choose such an awful typeface, don't they want to ensure the paper is readable? Some specifically insisted that we use TNR because it's readable, as if you can't just pick a random typeface and get something easier to read. Aside from symbol typefaces (like Webdings), the only typefaces that are harder to read than TNR is really extravagant text like Playbill or Jacques & Gilles.Jap2.0 wrote:My history professor always insisted that we had to use Times New Roman 12pt.
Yeah.
I guess that's why they recommend comic sans for Dyslexics. it's a sans serif font (which they recommend) but distinguishes the I.thereaverofdarkness wrote:Examples of typefaces without serifs which feature capital I wings: Comic Sans MS, Segoe UI
I'd have to agree, since 80%(ish) of users will be windows users, I'd recommend going with the order that windows uses.Kevin Ar18 wrote:In the FFF, you mentioned that you would be using the GNOME button order. Sadly, I know from experience that this makes the interface hard to use for Windows users.
also WTF is GNOME?
but, OSs doing things different isn't new, due to windows, I expect a close button to be at the top right of a window, but for decades they've been the only one doing this, when it was introduced this way, you had Amiga Workbench, Mac OS and even Windows 3.1 having the close button in the top left of a window, and probably others I don't remember/know about.
Re: Friday Facts #243 - New GUI tileset
Mac Mac and Ubuntu have their windows controls on the top left.bobingabout wrote:even Windows 3.1 having the close button in the top left of a window, and probably others I don't remember/know about.
Re: Friday Facts #243 - New GUI tileset
The point is that I have multiple monitors on which I play and every time I switch I have to change the setting. Nobody is talking about the internal measurement. The point is the external measurement, the scale you set in the options.seePyou wrote:Which is exactly the point. I don't get the discussion here, since we can set the scale. Whether internally it is pixels, or dpi, or light point per kilometer, who cares? We have a scale setting tool, set it to what you like and move on?
Re: Friday Facts #243 - New GUI tileset
Pardon? When you go to one computer and set the scale, then you go to the other computer and the scale from the first computer follows? You change it in one and it changes in all others?mrvn wrote:The point is that I have multiple monitors on which I play and every time I switch I have to change the setting.
-
- Long Handed Inserter
- Posts: 79
- Joined: Mon Nov 03, 2014 12:28 pm
- Contact:
Re: Friday Facts #243 - New GUI tileset
Please don't do that. It's easy enough to get used to any button layout in one given application, and as lifelong Windows user I always read and remember in which order buttons are and never had much problem with that. But it will the most frustrating thing of them all to switch your OS only to find your buttons backwards in the environment you already used to.Kevin Ar18 wrote:The solution is rather simple:
1. Define the 2 key buttons: the "Confirm" or "action" button and the Cancel button
2. In Linux builds, put the active button like "Confirm" to the far right, and "Cancel" to the far left. (by default)
3. On Windows, put the active button like "Confirm" to the far left, and "Cancel" to the far right. (by default)
Re: Friday Facts #243 - New GUI tileset
Pics or it didn't happen!Sigma1 wrote:BTW Factorio looks incredibly good with monospace as the font everywhere!
Leading Hebrew translator of Factorio.
Re: Friday Facts #243 - New GUI tileset
Agreed. As long as the looks of the "Accept" and the "Cancel" buttons are different enough, people will tell them apart easily (Difference in shape, font size/thickness, colors, ...)maniak1349 wrote:Please don't do that. It's easy enough to get used to any button layout in one given application, and as lifelong Windows user I always read and remember in which order buttons are and never had much problem with that. But it will the most frustrating thing of them all to switch your OS only to find your buttons backwards in the environment you already used to.Kevin Ar18 wrote:The solution is rather simple:
1. Define the 2 key buttons: the "Confirm" or "action" button and the Cancel button
2. In Linux builds, put the active button like "Confirm" to the far right, and "Cancel" to the far left. (by default)
3. On Windows, put the active button like "Confirm" to the far left, and "Cancel" to the far right. (by default)
Koub - Please consider English is not my native language.