Friday Facts #212 - The GUI update (Part 1)

Regular reports on Factorio development.
User avatar
TRUEpicness
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Wed Aug 09, 2017 8:21 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by TRUEpicness »

OMG i absolutely ADORE that gui
and I completly agree with moving schedules around for the sake of getting rid of the tediousness.
As I said in the last fff. 0.17 hype train is accelerating hard
1 more YouTube vid before bed *starts 24hr long vid*
User avatar
TRUEpicness
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Wed Aug 09, 2017 8:21 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by TRUEpicness »

Also I notice some different terrain in the background too
More desert types?
Could we start the red desert hype again?
1 more YouTube vid before bed *starts 24hr long vid*
User avatar
Dev-iL
Filter Inserter
Filter Inserter
Posts: 304
Joined: Thu Jul 02, 2015 2:48 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by Dev-iL »

The changes look very nice! My 1M$ question, though, is will this GUI update (or any other before Factorio 2.0) bring RTL support any closer...?

BTW, I'd love the game to "send anonymous statistics to the devs" (if a setting - one that's clearly on by default ;) ) so you can show us some nice graphs every once in a while of player behavior/settings, including data on how many people play in which language...
Leading Hebrew translator of Factorio.
User avatar
Proxy
Fast Inserter
Fast Inserter
Posts: 165
Joined: Mon Mar 30, 2015 11:10 am
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by Proxy »

it looks beautiful, and i love how you keep the gray monotone color from the very first Factorio versions... never change that.
a GUI has to work, not be overly detailed
snds
Burner Inserter
Burner Inserter
Posts: 6
Joined: Sun Aug 03, 2014 9:51 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by snds »

Hey guys, a fellow UXer here.

I really love the functionality shown here. The UX here implies a much better way to interact with stations and wait conditions that have made it difficult for me as a player to get into in the current iteration of the UI. It's one of the reasons I haven't been able to really get a complex train base going.

Now for the issues. I know this is the first stab at things so please just take this as a friendly critique.

The font colors and weight really hurt the UI usability and legibility, it's actually one of the problems I see here with the site UI. There are similar contrast issues at work here. I know that Factorio is NOT a web app, but it would behoove your team to use a contrast legibility tool for the web. The same kind of physical issues occurs even in video games.

I would also go so far as to say that the heavy shadows on the active/hover states add to that legibility issue. They end up making the screen overall dirty and hard to interact with. I do get the point of the visual style. We're building a factory, factories are dirty, but you can make a clean and legible UI with visual treatments that don't make it hard to use.

The legibility issue also goes for the icons. The icons are too detailed for the size you're using and with that dark gray color. If you're going with that size, the icon needs to be far brighter and larger to make sure users understand what the icon is meant to imply. The tabs to the top right could probably use an increase in size as well. You have really big tabs on the left but these tiny ones at the top right. A size for the right ones that are a little bit larger might make more visual sense and would help with the user with parsing the systems you have employed here.

As much of the issues I've mentioned are legibility and color related I've included a link here for a legibility tool to try. https://webaim.org/resources/contrastchecker/

All of that said, I really do like where things are going. Factorio is a massive beast of a game when it comes to UI and I applaud the work done thus far. If you'd like another UX person's perspective and help you guys brainstorm things remotely, I'd love to help.

-Sean
vsvasya
Burner Inserter
Burner Inserter
Posts: 7
Joined: Fri Jul 21, 2017 9:17 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by vsvasya »

Looks scary and much harder to read (
User avatar
taikodragon
Inserter
Inserter
Posts: 26
Joined: Fri Sep 09, 2016 4:18 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by taikodragon »

Teraka wrote:
deef0000dragon1 wrote:Finally, I personally have always found it difficult to parse the train logic, so I am not always sure in what order the AND and OR conditionals apply. It may be useful to add parenthesis type conditionals or something to make it easier to read.
It doesn't solve the issue of it not being intuitive but here's an easy way to remember it: AND is like logical multiplication (1x0 = 0, 1x1 = 1) and OR is like logical addition (0+0 = 0, 0+1 = 1, 1+1 = ... well 1 but you get the idea), and just like for regular arithmetic, you resolve the multiplications before resolving the additions, so X AND Y OR Z = (X AND Y) OR Z.
Unfortunately it isn't that AND will resolve before OR, the operators are handled in order of appearance so X AND Y OR Z AND Q = (((X AND Y) OR Z) AND Q) which like regular arithmetic would be resolved from the inner most set of parentheses to the outer most set.
ske
Filter Inserter
Filter Inserter
Posts: 412
Joined: Sat Oct 17, 2015 8:00 am
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by ske »

Matthias_Wlkp wrote:Does this mean 1.0 will be delayed?
It won't be delayed. It will come when it's ready. They already stopped adding a lot of new (breaking) features and concentrate on polishing instead. Polishing takes time. You can play pre-1.0 versions which are really great. A lot of people play the experimental versions instead of waiting for the final stable release. Story spoiler: The guy builds a rocket and wins the game but he doesn't leave the planet instead he goes on and on building bigger and bigger factories. Then he restarts with mods.

To the devs: Keep up the good work. Go the full distance.
ricky3350
Burner Inserter
Burner Inserter
Posts: 9
Joined: Fri Jan 16, 2015 9:54 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by ricky3350 »

This looks amazing! The train GUI has always been a bit confusing/hard to use, so I'm sure I'll like this.

Some small things that bother me a little bit:
  • The lines behind the title ("Locomotive") are completely pointless and make the text harder to read.
  • The wait conditions don't line up—I think it would be much better (if only for readability) to have the leading edge of the "15s passed" line up with the leading edge of the "Cargo: " condition.
  • The buttons on top of the window (color, close, etc.) look out of place. Just my personal opinion, but I think it would look a lot nicer if the buttons were inside the frame.
All in all though, it really looks great. I'm also excited for the temporary stop thing—it'll save so much trouble.
doktorstick
Fast Inserter
Fast Inserter
Posts: 219
Joined: Fri Aug 12, 2016 10:22 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by doktorstick »

Kyralessa wrote:I feel like it would make more sense to design a route, and then assign that route to one or more trains.

You could keep a set of routes like a set of blueprints.
Keeping with the pattern of Factorio,it might fit better if you make a schedule on a train and then save it as a route blueprint. You can apply route blueprints to trains and then make any changes.

This doesn't have the flexibility of automatically changing all trains on the same route at once (by modifying the master route). But if you wanted that, then I would think you would create groups of trains and create a route (apply a route blueprint) to the group.
Last edited by doktorstick on Fri Oct 13, 2017 10:18 pm, edited 1 time in total.
Rocksen
Burner Inserter
Burner Inserter
Posts: 10
Joined: Tue Jun 23, 2015 5:22 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by Rocksen »

wow that's a huge step in the right direction for me. i really want to know if that path also accounts for invalid paths, where it will try to path from A-B but instead of showing NO path,if it's invalid, it will show where the possible paths of the trains ended. this will make it easier for new players or really players that never used trains a tool they can use to debug their rail systems.
doktorstick
Fast Inserter
Fast Inserter
Posts: 219
Joined: Fri Aug 12, 2016 10:22 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by doktorstick »

People have touched on this... parentheticals for the logical operations. Or something like this:

Image
Teraka
Inserter
Inserter
Posts: 34
Joined: Mon Jun 27, 2016 7:50 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by Teraka »

taikodragon wrote:
Teraka wrote:
deef0000dragon1 wrote:Finally, I personally have always found it difficult to parse the train logic, so I am not always sure in what order the AND and OR conditionals apply. It may be useful to add parenthesis type conditionals or something to make it easier to read.
It doesn't solve the issue of it not being intuitive but here's an easy way to remember it: AND is like logical multiplication (1x0 = 0, 1x1 = 1) and OR is like logical addition (0+0 = 0, 0+1 = 1, 1+1 = ... well 1 but you get the idea), and just like for regular arithmetic, you resolve the multiplications before resolving the additions, so X AND Y OR Z = (X AND Y) OR Z.
Unfortunately it isn't that AND will resolve before OR, the operators are handled in order of appearance so X AND Y OR Z AND Q = (((X AND Y) OR Z) AND Q) which like regular arithmetic would be resolved from the inner most set of parentheses to the outer most set.
That's wrong, you can test it in-game. X AND Y OR Z AND Q will leave the station when either X AND Y or Z AND Q is true, even though in your explanation it should never leave if Q is false.
User avatar
TRUEpicness
Long Handed Inserter
Long Handed Inserter
Posts: 74
Joined: Wed Aug 09, 2017 8:21 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by TRUEpicness »

About the temporary stop... When you mean as close as it can to that point does it mean as close as it can go without no pathing when it resumes its schedule?
1 more YouTube vid before bed *starts 24hr long vid*
User avatar
Dr. Walrus
Long Handed Inserter
Long Handed Inserter
Posts: 96
Joined: Fri Nov 20, 2015 6:30 am
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by Dr. Walrus »

TehDwArF wrote:A few of quality of life improvements I would like for the GUI.
  • Destinations should drag-able (or use up/down arrows) in order to rearrange the station list.
  • The ability to switch a destination but keep the current wait conditions (useful for decommissioning a mining outpost and using the trains for other outposts).
  • An option to have a train automatically switch to manual mode upon arrival at a designated station (personal and outpost building trains would massively benefit).
  • A slim mode where only the stations are listed and the conditions are hidden, view-able by expanding the menu by clicking the station.
Not GUI related but as others have mentioned, having train groups would be really cool. Similar to some Rail style games, you could then even add a schedule where the leave condition is based off of even spacing (timing of departure/arrival) of trains, or an always occupied mode where it departs if a new train has arrived and is waiting to come into the station.
BUMP

Plus I'd love to see the ability to copy and paste wait conditions from one station to another. My trains going to mining outposts have a fairly large amount of wait conditions and every time I add an outpost to my system I have to put in the same 8 conditions as every other outpost.
Last edited by Dr. Walrus on Fri Oct 13, 2017 10:41 pm, edited 1 time in total.
User avatar
MrGrim
Fast Inserter
Fast Inserter
Posts: 241
Joined: Sat Apr 09, 2016 7:58 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by MrGrim »

For the people asking for various additions and changes to how to do schedules like GOTO's and conditional exit conditions and conditional grouping to control order of operations...

... Just make train schedules modifiable with combinators, and we can create any complex system we can imagine on our own. :D

Maybe something like allow us to assign signals and values to stations and trains then read the trains assigned values from the station when a train is parked there. Then allow to add a "meta" station to the schedule causing the train to go to whatever station is assigned the value it is being sent when the leave condition is true. Fairly simple, but could be used to create complex systems.

I like that rust themed idea. :D
User avatar
taikodragon
Inserter
Inserter
Posts: 26
Joined: Fri Sep 09, 2016 4:18 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by taikodragon »

Teraka wrote:
taikodragon wrote:
Teraka wrote:
deef0000dragon1 wrote:Finally, I personally have always found it difficult to parse the train logic, so I am not always sure in what order the AND and OR conditionals apply. It may be useful to add parenthesis type conditionals or something to make it easier to read.
It doesn't solve the issue of it not being intuitive but here's an easy way to remember it: AND is like logical multiplication (1x0 = 0, 1x1 = 1) and OR is like logical addition (0+0 = 0, 0+1 = 1, 1+1 = ... well 1 but you get the idea), and just like for regular arithmetic, you resolve the multiplications before resolving the additions, so X AND Y OR Z = (X AND Y) OR Z.
Unfortunately it isn't that AND will resolve before OR, the operators are handled in order of appearance so X AND Y OR Z AND Q = (((X AND Y) OR Z) AND Q) which like regular arithmetic would be resolved from the inner most set of parentheses to the outer most set.
That's wrong, you can test it in-game. X AND Y OR Z AND Q will leave the station when either X AND Y or Z AND Q is true, even though in your explanation it should never leave if Q is false.
I'm sorry, I must concede you're right. I feel like that makes ORs very hard to effectively use because they operate on an unequal level to ANDs. I can't think of a programming language where ANDs and ORs are not of the same precedent.
Faark
Burner Inserter
Burner Inserter
Posts: 19
Joined: Tue Apr 25, 2017 8:33 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by Faark »

I like the new UI showing conditions of multiple stations. But the mock-ups show quite simple train schedules but already have so much stuff displayed. All the buttons and highlights are distracting. I hope that can be made less intrusive. Maybe by not showing all the edit controls until the player somehow indicates he actually wants to modify that schedule? Also i agree with other comments, reordering stations, copying schedules between trains and more would be awesome.
User avatar
taikodragon
Inserter
Inserter
Posts: 26
Joined: Fri Sep 09, 2016 4:18 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by taikodragon »

Faark wrote:I like the new UI showing conditions of multiple stations. But the mock-ups show quite simple train schedules but already have so much stuff displayed. All the buttons and highlights are distracting. I hope that can be made less intrusive. Maybe by not showing all the edit controls until the player somehow indicates he actually wants to modify that schedule? Also i agree with other comments, reordering stations, copying schedules between trains and more would be awesome.
The copy paste functionality already present in the game works for trains and their schedules.
TehDwArF
Burner Inserter
Burner Inserter
Posts: 11
Joined: Sun Mar 23, 2014 9:30 pm
Contact:

Re: Friday Facts #212 - The GUI update (Part 1)

Post by TehDwArF »

Dr. Walrus wrote:
TehDwArF wrote:A few of quality of life improvements I would like for the GUI.
  • Destinations should drag-able (or use up/down arrows) in order to rearrange the station list.
  • The ability to switch a destination but keep the current wait conditions (useful for decommissioning a mining outpost and using the trains for other outposts).
  • An option to have a train automatically switch to manual mode upon arrival at a designated station (personal and outpost building trains would massively benefit).
  • A slim mode where only the stations are listed and the conditions are hidden, view-able by expanding the menu by clicking the station.
Not GUI related but as others have mentioned, having train groups would be really cool. Similar to some Rail style games, you could then even add a schedule where the leave condition is based off of even spacing (timing of departure/arrival) of trains, or an always occupied mode where it departs if a new train has arrived and is waiting to come into the station.
BUMP

Plus I'd love to see the ability to copy and paste wait conditions from one station to another. My trains going to mining outposts have a fairly large amount of wait conditions and every time I add an outpost to my system I have to put in the same 8 conditions as every other outpost.
If I'm not mistaken, I believe you can Shift+Right Click and Shift+Left click to copy a train's color and schedule to another train (like how you can copy assembler recipes or inserter configurations). Unfortunately, because you can't modify a destination station you would still need to add all the conditions for stations you remove and replace. If all you want is a second train doing the exact same thing, copying it is quite easy.
Post Reply

Return to “News”