Friday Facts #246 - The GUI update (Part 3)

Regular reports on Factorio development.
User avatar
Dev-iL
Filter Inserter
Filter Inserter
Posts: 298
Joined: Thu Jul 02, 2015 2:48 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Dev-iL »

eradicator wrote:Just out of curiosity because some of my mods have GUIs. Is the $proper_fix even remotely automatable? Or would i have to redesign every GUI twice? Because as a "solo modder" i don't have the manpower to do everything twice, and i doubt most of the others have :x.
Well, I have no experience creating GUIs for Factorio, but here's a decent overview of what Android requires from developers, in the hope it applies.

In short: as a modder, the amount of work depends on the tools given to you by the environment (i.e. if Factorio does everything for you it's easy), how different is a "correct RTL layout" from simple mirroring of the LTR layout, and whether the layout was built with RTL in mind.

For example, if instead of "A is to left of B" you can define "A is before B" and let the engine map "before" to either "left" or "right" depending on the locale - it's a matter of just some "find and replace". Alternatively, if the engine supports a flag (on a layout or item level) that says "just mirror this entire thing when RTL", it is also quite easy. Not many elements need to be defined differently, mostly just animations that rely on absolute positions of elements on the screen.
Leading Hebrew translator of Factorio.

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by eradicator »

Dev-iL wrote:Well, I have no experience creating GUIs for Factorio, but here's a decent overview of what Android requires from developers, in the hope it applies.
Thanks for the link. I read that page (having no prior knowledge of android internals) and looked at the picture and your picture of windows. For factorio i guess it might be possible to have a forced direction flag on some of the containers where nessecary and auto-reverse everything else, and hopefully have the engine to the rest. But quite honestly having no experience with LTR (Japanese conveniently uses RTL for anything digital even though it can be written in any direciton including up-down-LTR) i'm still struggling with the difference between what you call "proper RTL" and "just mirror the whole thing". I.e in your MS example none of the english strings are mirrored, and i thought that's the proper way, but you say it's the cheap way.

User avatar
Dev-iL
Filter Inserter
Filter Inserter
Posts: 298
Joined: Thu Jul 02, 2015 2:48 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Dev-iL »

eradicator wrote:I'm still struggling with the difference between what you call "proper RTL" and "just mirror the whole thing". I.e in your MS example none of the english strings are mirrored, and i thought that's the proper way, but you say it's the cheap way.
The difference is subtle but noticeable - when you "just mirror everything" indiscriminately, as was the case in WinXP, not only the ordering of elements and justification of texts was reversed, but all the icons too - which made absolutely no sense (e.g. an arrow that represents the action "back" is generally accepted as pointing left, which is why the keyboard shortcut involves the left arrow key. When they mirrored the UI it became a mess). Especially when it was done automatically on software that wasn't designed for it. To this day, I can't stand RTL software.... But some people just can't live without it...
Leading Hebrew translator of Factorio.

User avatar
Oktokolo
Filter Inserter
Filter Inserter
Posts: 883
Joined: Wed Jul 12, 2017 5:45 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Oktokolo »

Bilka wrote:+1 to giving them another color if you dont want to change the button look at all. Just a way to make more clear that it's NOT a button.
Buttons will come in different colors - at least in grey, green and red. So coloring the button will not make it become a text field in the perception of users. One exception: White is such a common color for text fields, that it might override the raised look - or just confuse the user.

zyklame
Inserter
Inserter
Posts: 30
Joined: Fri Jul 01, 2016 2:03 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by zyklame »

Bilka wrote:...

Need to clarify that the text boxes are not elevated, they don't look like a button, they are inset and really look like a text box. (look map size as an example)
What it's elevated is what I call editable display (fancy, I know).

...
In that case the shadow should be reversed. dark on toe top and light on the bottom so ins more clear. Right now the stay out like the buttons and not inwards like described.

PWNSTRADAMUS
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sat Jun 09, 2018 5:54 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by PWNSTRADAMUS »

Are you getting rid of the Destroy factor or is that just because it is a work in progress?

User avatar
eradicator
Smart Inserter
Smart Inserter
Posts: 5206
Joined: Tue Jul 12, 2016 9:03 am
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by eradicator »

Dev-iL wrote:
eradicator wrote:I'm still struggling with the difference between what you call "proper RTL" and "just mirror the whole thing". I.e in your MS example none of the english strings are mirrored, and i thought that's the proper way, but you say it's the cheap way.
The difference is subtle but noticeable - when you "just mirror everything" indiscriminately, as was the case in WinXP, not only the ordering of elements and justification of texts was reversed, but all the icons too - which made absolutely no sense (e.g. an arrow that represents the action "back" is generally accepted as pointing left, which is why the keyboard shortcut involves the left arrow key. When they mirrored the UI it became a mess). Especially when it was done automatically on software that wasn't designed for it. To this day, I can't stand RTL software.... But some people just can't live without it...
The android page you linked as far as i understood it (and in the example pictures) explicitly advises to mirror arrows. Makes sense to me because i'd assume if you write RTL you also read RTL, and thus the "previous page" would be on the right, not on the left as in english. Ofc that would require reversed keyboard shortcuts. I mean, i understand the uselessness of mirroring some icons, or company logos. But with the arrows you got me confused :P.

Alaura
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sun Oct 09, 2016 6:29 am
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Alaura »

When might we get a 0.17 branch for factorio on steam? Would be great to help give feedback while ingame.

NetArc
Burner Inserter
Burner Inserter
Posts: 7
Joined: Wed Mar 01, 2017 9:15 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by NetArc »

Everything is looking great so far!

My 2c regarding any screen that has both Back/Cancel and a Reset..
I feel like you can just de-clutter that screen more and remove the Reset by making it implicit in the Back/Cancel action.
Screenshot Reference

TheRaph
Fast Inserter
Fast Inserter
Posts: 221
Joined: Sun Sep 24, 2017 6:31 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by TheRaph »

NetArc wrote:Everything is looking great so far!

My 2c regarding any screen that has both Back/Cancel and a Reset..
I feel like you can just de-clutter that screen more and remove the Reset by making it implicit in the Back/Cancel action.
Screenshot Reference
I understand it as follows: If you open that window it will show you your current settings. If you change something you'll discard it by pressing "back". The reset button will not discard your new settings, but will set everything to factory default instead.
So you may have set your master volume to zero yesterday and want it now back to normal today - you just open sounds settings press "reset" and "confirm" and have it now on default settings. ...

Just a possible reason why there is a reset button.

Dune
Fast Inserter
Fast Inserter
Posts: 201
Joined: Tue Dec 12, 2017 4:27 am
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Dune »

These look great!

I can't wait for the new game load that takes into consideration mods and a directory structure!
Image

Henry Loenwind
Long Handed Inserter
Long Handed Inserter
Posts: 52
Joined: Fri Mar 09, 2018 7:33 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Henry Loenwind »

The whole "preset" area makes no sense at all unless you know what is it.

First there is that row with "bright orange text field with settings icon and some text, weird button, return/re-run button". Nothing here indicates that this is a preset selection or how to use it. Then there is some white text that is not attached to anything, so it looks like some general information. And then there's a whole bunch of random settings that you seem to be supposed to edit before pressing "play".

My suggestion:

1.) Label the "preset" field. "Preset: " would be a good start.
2.) If it is supposed to be a dropdown, make it look like one.
3.) Is that "settings icon" thing clickable? I can't tell, but if it is not, lose it. If it is, make it a separate button.
4.) Drop the preset description in the main dialog and add it into the dropped down list.
5.) Hide all settings below the preset selection behind a "Customize..." button.
6.) Move the "Reset to preset values button" (I'm guessing that's what the red button does?) to the settings.

Unrelated to this:

* I don't think the "editable button" thing will work. That's a concept that doesn't exist anywhere.
* The "randomize" button should be a dice. "Shuffle" has a different meaning, it is a mode switch, not an one time action.
* I have no idea what the "replay" check box does, and I've played for a couple hundred hours...
* The first map exchange string button should directly copy to the clipboard (with a popup that tells the user that it has been copied). The second one should be disabled normally and light up (maybe even blink) if it detects a valid exchange string (different from the last one that was copied there) in the clipboard. Also, that string needs some human readable marker like "FactorioMapSettings:(.....)"
* Um, also those map exchange buttons look reversed in their meaning to me.
* The "Advanced" tab looks weird. I'd suggest to use the same layout as the "Pollution"/"Enemy expansion"/"Evolution" areas. Bold header line, settings below. And all of them actually could be sliders, which would better distribute them horizontally.
* The "ATTENTION!!!" icon on the "Preview" button makes no sense. It seems to say "you must go in here because there's something wrong you have to correct".
* On the sound settings dialog, the "Reset" button has no real use case. The use case "user changes some values, resets to default, changes them differently, confirms" just doesn't happen in sound settings. They either change their mind completely, or they are happy with their changes. That button actually makes sense for map setting, especially if the preview is on.
* Also, the sound settings dialog feel cramped compared to the old one.
* I really hope the real engine doesn't produce blurry text like the mock-ups have. (Hint: When scaling images by integer factors, set it to "pixel resize".)
* Windows that don't have action buttons on the right side (and title icons on the left) work better with centered title lines. At the far left the title gets disconnected from the content as it if far away from the users' attention area.
* The setting dialog actually has the same issue with the "Play" button. As it nearly has full screen height in 1080, even in the scaled down version, the button is too far away from the users' attention area. The users will see all the options first and look at those for a while before letting their eyes wander to find the play button. (Starting with the detailed settings collapsed behind a button would fix this, too.)

Some general things:

* Users should NEVER have to guess if an element is clickable, editable and where it belongs to.
* When mixing checkboxes and iPhone-style toggles, use checkboxes for "on/off" and toggles for switching between 2 values which are displayed left/right of the toggle. Or just don't mix them.
* Labels should end with a ":" if the are left of the value. Even if they are in row headers. Column headers should never have a ":".
* Mind your plural. While some words can stay singular in a plural list ("Advanced"), pluralize as much as possible. It's "Enemies", even so there only is one type of enemy. This is not a street fighter game where you fight exactly one enemy at a time...
* Mind the___________________________________gap. Alsobetweenbuttons.

hockeyhack
Manual Inserter
Manual Inserter
Posts: 4
Joined: Sun Feb 21, 2016 7:08 am
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by hockeyhack »

Bilka wrote:I'm calling it now: With the new GUI tileset, nobody will know if a value can be changed because the button and editable field look exactly the same. Notice the seed field for example, it looks exactly the same as the other buttons, making me wonder if it's a button, or a text field.
If it is the same UI interface as the current one just with updated graphics that seed is NOT an input field. In the current interface if you hit generate preview it generates a preview and at the top it says in non interactive text "Map Preview Seed XXXXXXXXXX(a 10 digit number)".

So yes it may look not interactable, that is probably because that is the case, seriously go boot up the game hit new game then hit generate preview and you will see exactly what I mean, the only different between it and the mock UI is the wording and the ability to change the sliders while viewing the preview.

User avatar
sporefreak
Fast Inserter
Fast Inserter
Posts: 181
Joined: Sun Apr 17, 2016 12:55 am
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by sporefreak »

One thing that really bugged me was that I was unable to easily set a setting back to its default. If I changed pollution decay for example and didn't pay attention to its value before changing it I would never remember the default is 2 without resetting everything.

I think I am getting my point across, but I propose a fix to this:
Double clicking a slider will reset only that slider to its default setting.
This is easy to avoid doing on accident (If you know how to do it) and will easily allow changing a single slider at a time until you get the exact setting you want.

NetArc
Burner Inserter
Burner Inserter
Posts: 7
Joined: Wed Mar 01, 2017 9:15 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by NetArc »

TheRaph wrote:
NetArc wrote:Everything is looking great so far!

My 2c regarding any screen that has both Back/Cancel and a Reset..
I feel like you can just de-clutter that screen more and remove the Reset by making it implicit in the Back/Cancel action.
Screenshot Reference
I understand it as follows: If you open that window it will show you your current settings. If you change something you'll discard it by pressing "back". The reset button will not discard your new settings, but will set everything to factory default instead.
So you may have set your master volume to zero yesterday and want it now back to normal today - you just open sounds settings press "reset" and "confirm" and have it now on default settings. ...

Just a possible reason why there is a reset button.
You might have a point there, I think in that case; the confusion can be remedied by changing the wording from Reset to Defaults

dRaMaTiC
Burner Inserter
Burner Inserter
Posts: 11
Joined: Fri Jan 27, 2017 12:11 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by dRaMaTiC »

Nice design so far. But maybe we could get percentage numbers for each slider. Otherwise it could be diffcult to sync settings e.g with an friend. The numbers doesn't have to be visible all the time, on dragging only should be fine.

Lappro
Burner Inserter
Burner Inserter
Posts: 6
Joined: Fri Jul 22, 2016 8:02 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Lappro »

There is a typo in the map generator. Under Terrain/Pollution it says "Absorved per damaged tree", which should've been "Absorbed per damaged tree".

Sander_Bouwhuis
Filter Inserter
Filter Inserter
Posts: 292
Joined: Mon Dec 07, 2015 10:45 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Sander_Bouwhuis »

I haven't read all the comments (only page 1 and page 6), but I seem to be alone in not liking it. I didn't like the fat Mickey Mouse look of Windows XP, and I don't like it in the GUI mockups.
I also absolutely hate the vague 'over-large' / 'under-sharp' fonts. I tried some Linux distributions in the past, and they too didn't seem able to get font rendering right. If you look at the first 2 screenshots from Windows, the text is very sharp and clear. The third screenshot (is that Apple or Linux?) is both overlarge and wasteful space-wise.

I'm not sure why Microsoft manages to get fonts right, and none of the competitors can get it to work right. Does anyone here know about Linux or Apple and can tell me what the problem is? Is Clear-type patented by Microsoft so they can't use it?

Henry Loenwind
Long Handed Inserter
Long Handed Inserter
Posts: 52
Joined: Fri Mar 09, 2018 7:33 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Henry Loenwind »

Sander_Bouwhuis wrote: I'm not sure why Microsoft manages to get fonts right, and none of the competitors can get it to work right. Does anyone here know about Linux or Apple and can tell me what the problem is?
Funny thing is that technically Microsoft is the one rendering the fonts wrong.

Without going into too much depth: Rendering fonts is tricky because they are vector shapes with round parts, diagonals and differing line width---and the screen is made up of (not very small) square dots. Imagine making a circle out of normal Lego blocks. Microsoft's solution is to move the letters around until they fit the pixel raster best. Apple on the other hand renders them where they actually are and uses grays for half-filled pixels. (Which actually is very useful if you're designing a print product, because it looks exactly as it would after being printed. That is, as far as I know, the root for the decision to work this way.)

And with modern hi-dpi/retina displays, Apple's strategy gives the better results. It will just look bad to you when all you see is screenshots on a low-dpi display. That also is what's happening with the mock-ups. Look at the full-sized images, there the text is sharp. Only the scaled-down version have blurry text.

Tricorius
Filter Inserter
Filter Inserter
Posts: 266
Joined: Fri Jul 01, 2016 9:04 pm
Contact:

Re: Friday Facts #246 - The GUI update (Part 3)

Post by Tricorius »

KatherineOfSky wrote:I have a request -- currently the Map Exchange string is copy-able to the clipboard. Could you make it so that we can save it to a preset of our own? (So that it appears in the drop down menu). With very few exceptions, I always generate maps with the exact same settings, and it would be soooooo handy not to have to click the sliders/drop downs every time, or find the Map Exchange String and manually paste it in.

It would be great to be able to give a custom name to this new preset, (and of course have an option for deleting them).
I came here to say the exact same thing, only KoS said it better than I could have. :)

I would like this as well. I like to play with Death World “biters” settings and Rail World “environment” settings. It is kinda tricky currently to get that setup.

And I’ve always been a bit fuzzy about what the copy map string function does. I assume that it copies settings, of course, but I assumed there would be some sort of “seed” copied as well. My assumption was that you could duplicate the exact same map, but maybe resources and such are still randomized.

Regardless, a way to save custom setting sets would be amazing.

Post Reply

Return to “News”