The International Simutrans Forum

 

Author Topic: Icon standardization - RFC  (Read 15645 times)

0 Members and 1 Guest are viewing this topic.

Offline VS

  • Senior Plumber (Devotee)
  • Moderator
  • *
  • Posts: 4855
  • Vladimír Slávik
    • VS's Simutrans site
  • Languages: CS,EN
Re: Icon standardization - RFC
« Reply #35 on: January 17, 2013, 08:11:14 PM »
Personally I think that indicating waytype with colour is somewhat less important, since presence in certain menu and hover hint (?) both help identify the item. Indicating underground seems more important...

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2380
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Icon standardization - RFC
« Reply #36 on: January 17, 2013, 08:22:19 PM »
Hello all,

there are lots of interesting ideas here. I would like to say that not everything has to be displayed on the icon. We still have the tooltips, and also order of icons is given - normal road/track, elevated road/track, bridge, tunnel, wayobj/electrification, signals, bulldozer, depot, station. And roads are ordered by speed, stations by capacity. So a lot of info can be found intuitively or from tool tips.

My proposal is to keep additional icons for roads/track as fabio did - show the speed, and icons only for elevated, bridge and tunnel. Plain road can be without extra icon. Electrification should have the red lightning,

Stations symbols for pas/mail/cargo and some extra icon only for extensions. Platforms can be without icon. For undeground only stations a tooltip might be enough, as they will be visible only in underground mode.

Depots are just fine as they are. Or they could have a wrench icon in place of cargo icons.

For signals, we could use letters, as I did for pak128.cz - letters in right bottom corner: S-signal, P-presignal, L-Long, C-Choose, E-EndOfChoose, O-OneWay.

Someone mentioned that toolbars occupy a lot of space even on fullHD screen. I'd like to ask for vertical toolbars. In past few years displays grow only horizontally, from 1280x1024 to 1900x1080 - thats 620 px extra widht but only 53 px height. There is a lot of space on sides of screen for vertical toolbars.

Offline dennosius

  • *
  • Posts: 63
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #37 on: January 18, 2013, 07:00:54 AM »
As we discussed before, background colours are not for finding an icon (so they don't have an identification function for the icon itself), but for identifying the icon bar, mainly in case a couple of icon bars are open already. Of course, if one just opened the railway icon bar, there's no need to indicate that the icon bar contains railway elements. But if there are several icon bars open, identifying them by the icons is hard, as icons look pretty similar on the first glance (esp. if we put more common subicons on them).

I also think that tooltips are quite the opposite of intuition. If one needs to read the tooltip, the icon hasn't worked (so in best case tooltips are not used/only used for additional information such as pricing).

Offline greenling

  • Lounger
  • *
  • Posts: 1728
  • Simutransarchology it my hobby!
  • Languages: DE,EN
Re: Icon standardization - RFC
« Reply #38 on: January 18, 2013, 09:15:03 AM »
Hello on All
I think that all pakset need Submenüs for Rail,Road,Tram,Ships,Plans,Monorails,Station Ex tations.
Here it a photo that show how many space be need the window, then install a addon out japan and that without
Timeline. Those photo give the Size again they i use to play with simutrans on my laptop there two tool on the
Screen with use. And that not all addons they i have install here in those photo.

(Klich here, then the Photo not be show.)
https://sites.google.com/site/000002expend/simscr06.png?attredirects=0
« Last Edit: January 18, 2013, 09:21:39 AM by greenling »

Offline Raiser

  • *
  • Posts: 78
  • Languages: DE, EN
Re: Icon standardization - RFC
« Reply #39 on: January 18, 2013, 10:44:44 AM »
Hello on All
I think that all pakset need Submenüs for Rail,Road,Tram,Ships,Plans,Monorails,Station Ex tations.
Here it a photo that show how many space be need the window, then install a addon out japan and that without
Timeline. Those photo give the Size again they i use to play with simutrans on my laptop there two tool on the
Screen with use. And that not all addons they i have install here in those photo.

(Klich here, then the Photo not be show.)
https://sites.google.com/site/000002expend/simscr06.png?attredirects=0


Yes thats right - i would agree to introduce sub task bars.

Offline dennosius

  • *
  • Posts: 63
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #40 on: January 18, 2013, 05:36:13 PM »
Colour blind users may find coloured icons to be confusing if they are not chosen correctly.

Is that true? I mean, worse than the current all-grey icons?

Non-colourblind people are, on the other hand, not trained to tell shades of a colour apart, and limiting the number of colours to two (blue and yellow) is probably not a real step forward in ergonomics. What I mean is: I really like the idea of barrier-free design, but not on the cost of loosing ergonomics for ordinary users if there's no win in ergonomics for colour-blinds on the other hand. In other words: An improvement should still be done if only ordinary people profit from it, unless it makes things even worse for colour-blinds than the current state.

But coming back to my question whether it's good or not to use similar colours (i.e. shades of one colour) for all railway-like ways (narrow gauge, maglev, monorail) it may be a good compromise to answer this question with 'yes' and use (shades of) yellow (as blue is clearly intuitive for waterways) for those, so colourblind users take at least advantage of the majority of colours used.

Offline sdog

  • Devotee
  • *
  • Posts: 2039
Re: Icon standardization - RFC
« Reply #41 on: January 18, 2013, 07:52:59 PM »
As we discussed before, background colours are not for finding an icon (so they don't have an identification function for the icon itself), but for identifying the icon bar, mainly in case a couple of icon bars are open already. Of course, if one just opened the railway icon bar, there's no need to indicate that the icon bar contains railway elements. But if there are several icon bars open, identifying them by the icons is hard, as icons look pretty similar on the first glance (esp. if we put more common subicons on them).


Then the consequence of this would be to mark the bar instead of the icons!

perhaps put a train, lorry, ship symbol at the beginning of each bar, perhaps also do a colour coded rim.

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
Re: Icon standardization - RFC
« Reply #42 on: January 18, 2013, 08:25:27 PM »
Is that true? I mean, worse than the current all-grey icons?

Non-colourblind people are, on the other hand, not trained to tell shades of a colour apart, and limiting the number of colours to two (blue and yellow) is probably not a real step forward in ergonomics. What I mean is: I really like the idea of barrier-free design, but not on the cost of loosing ergonomics for ordinary users if there's no win in ergonomics for colour-blinds on the other hand. In other words: An improvement should still be done if only ordinary people profit from it, unless it makes things even worse for colour-blinds than the current state.

But coming back to my question whether it's good or not to use similar colours (i.e. shades of one colour) for all railway-like ways (narrow gauge, maglev, monorail) it may be a good compromise to answer this question with 'yes' and use (shades of) yellow (as blue is clearly intuitive for waterways) for those, so colourblind users take at least advantage of the majority of colours used.

From an ergonomics stand point, colours aren't necessary for the icon background. The picture in it should be obvious enough already. i.e. a ship looks like a ship.

The various toolbars you can open are already sorted as well. i.e. Tunnels are lumped together with tunnels, etc.

The only problem in identifying differences are stations, station extensions and electrifications. In some paks, the icon image overlaps the type icon and it may also be of a similar colour, which will cause some confusion to the user. Particularly bad ones are some of the railway stations and extensions in pak128.

Offline dennosius

  • *
  • Posts: 63
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #43 on: January 19, 2013, 01:26:39 AM »
From an ergonomics stand point, colours aren't necessary for the icon background.

This discussion is becoming a bad example of open development :) Once everyone agreed we should use colours and then we discuss what colours, people start arguing we don't need colours.

Once again: Ergonomics in GUI design (esp. icon design) means that functionalities of icons are visible at the first glance intuitively. In Simutrans, we have (at least) two different levels of choosing the right functionality: If users want to perform a certain action, they need to 1) find the right toolbar and 2) find the right icon within the toolbar.

Colours are exclusively for the first level. And colours are - at the current stage of discussion and proposals - the only possible identifiers for this level. Having to look at the icons contents for identifying the toolbars' purposes is bad ergonomics. It's like not naming the main menu items in applications with the argument if the menu contains 'Save as', it must be the 'File' menu, and if it contains 'Copy' and 'Merge', it must be the 'Edit' menu. It's practically not that bad in Simutrans, but the approach is just the same.

It's currently impossible to identify (esp. already open) toolbars in Simutrans at the first glance intuitively. This especially applies to the road and railway toolbars, which are similar in size and contain similar icons (recognizing them left-to-right both starting with a bunch of icons with speed limit info as the most eye-catching elements). And it'll get worse as soon as we have maglev and narrow gauge toolbars in place who will (necessarily) contain items very much similar to each other and the railway, monorail and tram toolbars.

Ergonomics and intuition are not about finding the icon at all. This is of course perfectly possible at the moment. They are about finding the right toolbar/icon without having to look twice, think or concentrate on it. Players' concentration should remain completely focused on the in-game task they are performing and not on how to control the software. And this, if possible, from the very first minute (so we all have to go back from our own personal scale, knowing all icons and elements already by heart).

Quote
The picture in it should be obvious enough already. i.e. a ship looks like a ship.

There's not a single ship within the waterways toolbar, just as a remark. There's a greyish canal, a bridge icon that could at the first glance as well represent a paved road, a bulldoze icon that is almost the same in every toolbar, and a couple of stations that could at the first glance as well be stations or extensions for any other waytype.

Colours are not mainly for the case players click on the ship icon. If players click on a waytype icon, it's obvious and intuitive that the toolbar then opened is the one belonging to the waytype icon. But already this is not easy: railway and narrow gauge icons both show locomotives, the road menu shows a lorry although in practice often used more for buses, the monorail icon shows something looking more like a maglev, and the tram and airplane icons are not easily recongnizable. Anyway, once several toolbars are already open, identifying the toolbar by the icons contained is the wrong way from an ergonomics perspective, and it's also practically difficult as contained icons look too similar.

Quote
The various toolbars you can open are already sorted as well. i.e. Tunnels are lumped together with tunnels, etc.

Yes, this is already good and intuitive. Slower ways to the left, faster ways to the right, and same levels (underground/surface/elevated/bridge) together. We still need to identify the exact speed limit and 'where' to build it.

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
Re: Icon standardization - RFC
« Reply #44 on: January 19, 2013, 01:35:54 AM »
I'm not sure I follow, because it's pretty obvious which toolbars are which, at least in pak britain...

The toolbars are clearly labelled

Offline sdog

  • Devotee
  • *
  • Posts: 2039
Re: Icon standardization - RFC
« Reply #45 on: January 19, 2013, 03:16:00 AM »
This discussion is becoming a bad example of open development :) Once everyone agreed we should use colours and then we discuss what colours, people start arguing we don't need colours.
I did not have the impression there was full agreement. To the contrary, it appears VS, who started the project did not consider it important. Only AEO, whose position you so staunchly oppose took a major interest in it.

I also would not consider this a bad example of an open development process either. The people who actually do the work, will pick the good ideas and develop them further or implement them.

Offline VS

  • Senior Plumber (Devotee)
  • Moderator
  • *
  • Posts: 4855
  • Vladimír Slávik
    • VS's Simutrans site
  • Languages: CS,EN
Re: Icon standardization - RFC
« Reply #46 on: January 19, 2013, 11:22:49 AM »
To clarify my position towards colour with far more verbosity:

The most important part of icon is the graphic itself, which identifies it with how it looks in game world - is unique + recognizable (dubious-contest). With all the stuff we could push into icon, it would be more and more hidden. The other parts must not overlap the central space, allow the diagonal free of clutter so that more can be seen. And - it must not drown in other colour. Perhaps you noticed that all the "type" overlay suggestions converged to b&w? I think we all intuitively understand this...

Anyway! IMO the colour coding of what waytype the item belongs to is rather secondary - as of now, we do not mix waytypes, we sort them into toolbars. Thus it can be just a tint of the background.
(BTW, there are extensions with waytype, but it is not important where you build them.)

As I see it, I am not against colour, just... not very much for it, either :D

This is not in any way authoritative.



This discussion is becoming a bad example of open development :)
Maybe!

Unfortunately, this is a topic where everyone has an opinion (including me). We can all agree that a standard is a good idea. We can all agree that something goes below the item's graphic, and something goes above it. That's about it. Perhaps it is not important to arrive at a consensus. I certainly did not expect that! I had to discuss this kind of initiative, or it never even came to mind of anyone (or so it seemed). In the end:

I also would not consider this a bad example of an open development process either. The people who actually do the work, will pick the good ideas and develop them further or implement them.

The point is (probably) that this is not the development, this is a discussion... The painfully suboptimal part is where we can't tell experts from "everyone".



From an ergonomics stand point, colours aren't necessary for the icon background. The picture in it should be obvious enough already. i.e. a ship looks like a ship.
Yes :) With building-like structures, in the available resolution, it gets worse, though :-/ If we could make icons 64*64, quite a number of these problems would go away...
« Last Edit: January 19, 2013, 11:49:47 AM by VS »

Offline dennosius

  • *
  • Posts: 63
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #47 on: January 19, 2013, 11:34:54 AM »
@sdog
Please consider the smiley. I anyway didn't want to start a meta discussion now (by having done so despite the smiley, I gave a bad example as well, sorry for that).

@ӔO
This is the Pak128 forum. Pak128 of course shows the same labels. But labels are never 'obvious' in an icon/toolbar ergonomic sense, because reading is nothing that comes from intuition. Especially not the toolbar labels, they don't have much contrast (brown/white on orange), and they contain similar descriptions ('Tools' everywhere, 'Rail' and/or 'Road' in many).

Your screenshot is actually a good example. It shows 9 toolbars with approx. 200 icons that all look pretty similar at the first glance. Imagine you just now needed to build a road depot.  You will of course find it, but it'll take like 3 seconds, an unexperienced player may even need 5 or 10 seconds. And you'll need to concentrate on finding it. If ergonomics were perfect, we'd be able to find the road depot instantly without having to invest any attention.

@VS
I share most of your points. What I don't second is that graphics are the most important part for ways, because the look of ways doesn't differ and has little (if any at all) identification potential for the capabilities (esp. max speed). A 160 km/h railroad track is not unique and recognizable if compared to 100 km/h and 280 km/h railroad tracks. And although I do share your point that the graphics are most important identifiers for most of the other items (esp. stops and extensions), some identification potential of the graphics unfortunately gets lost by the small graphics size on the icon. We'll need to find a solution for this, but that's not what the colour is good for.

As I said before, colour is not about the identification of an icon. As we don't mix waytypes *), once a user knows he's in the right toolbar, colour has little or no use, I fully agree to this. But we have to find the right toolbar first, especially if toolbars are open already (it's easier through the waytype icons at the top, so if the toolbars are not open already). So the main use case for colours is identifying the needed toolbar among several toolbars already opened.

*) This leads me to another question: Is the waytype sorting useful for extensions at all? Most (if not all) pa/mail/goods extensions are good for any waytype. Why is the petrol tank in the railroad toolbar? Shouldn't it also be used for petrol storage near harbours? Couldn't the airport passenger terminals as well be ferry or maglev passenger terminals? Why are car parks in the road menu (bus stops are probably the type of stations where in real life dedicated parking space is least common, compared to railway stations, airports and harbours)?. And what do post offices have in common with making a stop public so they go in the same toolbar? Would it therefore be a good idea to sort universal extensions into an extra toolbar?
« Last Edit: January 19, 2013, 12:02:11 PM by dennosius »

Offline VS

  • Senior Plumber (Devotee)
  • Moderator
  • *
  • Posts: 4855
  • Vladimír Slávik
    • VS's Simutrans site
  • Languages: CS,EN
Re: Icon standardization - RFC
« Reply #48 on: January 19, 2013, 11:51:46 AM »
Funny... Transport Tycoon can have only one way toolbar open at a time. Thus, it actually already wins in that aspect!

Offline dennosius

  • *
  • Posts: 63
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #49 on: January 19, 2013, 12:11:45 PM »
Funny... Transport Tycoon can have only one way toolbar open at a time. Thus, it actually already wins in that aspect!

I don't think that's a win. Simutrans clearly wins this, as it's possible to build combined stations and combined networks without having to open and close toolbars all the time (or even maintain different type separate networks). We can make it a bigger win by making this more ergonomic.

Offline Vladki cz

  • Devotee
  • *
  • Posts: 2380
    • My addons, mostly roadsigns
  • Languages: EN, CS
Re: Icon standardization - RFC
« Reply #50 on: January 19, 2013, 06:42:52 PM »
Sure you can. But so far you can only add all of the railsignals there... or none of them*. And that's not really what I'd want in the end, since it would be the identical list as displayed in the track menu already. I'd prefer signals specially painted for tram that show up only in the tram menu (just like tram tracks, catenaries, depots and stations already do) - even if they could be placed and used on normal tracks (and vice versa) as well - or not. Whatever is easier to code.

*) as long as you're planning to keep the menuconf.tab automatically showing all new signals as soon as they are added without having to add each one specifically to the menu (and I haven't yet tried if that is even possible)
Wow, is that really really possible? Any hints how modify the menuconf.tab to have just some signals into a tram menu? I have a set of tram signals, but they are coded as normal rail signals, so they appear in rail menu.

Offline DirrrtyDirk

  • Devotees (Inactive)
  • *
  • Posts: 1253
  • JR 700 Series Shinkansen
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #51 on: January 19, 2013, 07:05:22 PM »
No, apparently you can only have all or none (at least I could not get anything else to work). To include all train signals into the tram menu, all you need to do is add (or change) a line in the tramtools section of menuconf.tab:

Code: [Select]
toolbar[5][3]=signs(2)It says signs(7) in the original line, but that would only display signals coded for tram - and these (while showing up correctly) don't work as such in game.

Offline greenling

  • Lounger
  • *
  • Posts: 1728
  • Simutransarchology it my hobby!
  • Languages: DE,EN
Re: Icon standardization - RFC
« Reply #52 on: January 19, 2013, 08:17:27 PM »
Hello on all
I have look in the menuconf.tab but i have not understand how she work.

Offline sdog

  • Devotee
  • *
  • Posts: 2039
Re: Icon standardization - RFC
« Reply #53 on: January 20, 2013, 02:49:36 AM »
@denosisus today my post reads much harsher than it seemed yesterday. Please accept my apology for this.


I also think, it would be helpful to make the toolbar itself more distinctly identifyable. Your point is good there. Of course, as VS said, the waytypes are grouped in their own categories -- but with the new icons the toolbar for 'Road' and 'Rail' indeed look very similar. Of course a different button opens them, however once, open they can be confused. How about a colour code for the toolbar title-bar?

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
Re: Icon standardization - RFC
« Reply #54 on: January 20, 2013, 03:33:48 AM »
I think there is a small issue with the visibility of the title bars in the various menus.

White on orange is not exactly the most contrasting.

White on blue would be, and it's quite popular for high visibility/legibility road signs.

Offline dennosius

  • *
  • Posts: 63
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #55 on: January 20, 2013, 09:52:18 AM »
No, apparently you can only have all or none (at least I could not get anything else to work). To include all train signals into the tram menu, all you need to do is add (or change) a line in the tramtools section of menuconf.tab:

Code: [Select]
toolbar[5][3]=signs(2)It says signs(7) in the original line, but that would only display signals coded for tram - and these (while showing up correctly) don't work as such in game.

I think it could be possible. Fences in the special tools menu are defined as some kind of railroad ways:

Code: [Select]
toolbar[10][1]=ways(2,255)

So it's the second parameter (255) that makes it possible to put fences, although railroad ways, go to the special toolbar. That parameter is not documented in the menuconf file (could at least not find it), but with this kind of parameter it seems to be possible to put certain (but not all) railroad items into a different toolbar, so it seems this could work the same with signals into the tram menu. Maybe the parameter has to be set in the dat file?

How about a colour code for the toolbar title-bar?

I think we can't set colours for the toolbars, or can we? My original idea was not to use a full icon background, but to use some kind of a colour bar. I illustrated it in the middle of the icon, it could as well be on top. The disadvantage is that it takes space within the icons. We could adjust icon height to 36 to avoid this (so have a 4px colour bar at the top). The disadvantage of full coloured icons could of course be that it becomes too colourful, which could somehow be avoided by using gradients and not using full colours (so not a #FF0000 red, but a lighter one). And I don't know whether a colour bar at the top is as intuitive as a background colour, it may be less visible.
« Last Edit: January 20, 2013, 10:10:14 AM by dennosius »

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9326
  • Languages: De,EN,JP
Re: Icon standardization - RFC
« Reply #56 on: January 21, 2013, 09:21:42 PM »
You can chnage the color of the unowned player (15) which would change all unowned windows title bars.

Offline dennosius

  • *
  • Posts: 63
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #57 on: January 23, 2013, 01:02:44 PM »
Can only icons in the main toolbar open new toolbars, or are nested sub-toolbars theoretically possible?

Offline DirrrtyDirk

  • Devotees (Inactive)
  • *
  • Posts: 1253
  • JR 700 Series Shinkansen
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #58 on: January 23, 2013, 03:56:40 PM »
Can only icons in the main toolbar open new toolbars, or are nested sub-toolbars theoretically possible?

Submenus are possible (and not just theoretically  ;)).

Offline dennosius

  • *
  • Posts: 63
  • Languages: EN,DE
Re: Icon standardization - RFC
« Reply #59 on: January 23, 2013, 08:05:34 PM »
Sounds good. I wonder whether we should make use of this. Of course, it's good to have all items in one bar without sub-menus. But only if the number of icons in one toolbar is not too large. The railway and road menus are already now at the maximum, in my view. It might be useful to put less frequently used items into submenus (like bridges and elevated are probably less frequently used in comparison to surface and tunnel ways - or is that just me?).




Offline greenling

  • Lounger
  • *
  • Posts: 1728
  • Simutransarchology it my hobby!
  • Languages: DE,EN
Re: Icon standardization - RFC
« Reply #60 on: January 23, 2013, 10:35:18 PM »
Hello
I have find in the Simuconf.tab a Parameter with the names toolbar_max_width = 0 and toolbar_max_height = 0 .
I have those parameter be test and i must said that those parameter make the Menü smaller.

Offline Fabio

  • Devotee
  • Administrator
  • *
  • Posts: 2898
  • The Pak128 Guy
    • Visit me on Facebook
  • Languages: EN, IT, RO, FR
Re: Icon standardization - RFC
« Reply #61 on: January 23, 2013, 10:49:39 PM »
Ways can already have a menu entry (currently a shortcut for roads and rails) for latest used. If this could be extended to bridges and tunnels as well, we could have 2 buttons for ways (latest used and sub menu), 2 buttons for tunnels, 2 buttons for bridges: 6 buttons instead of the zillion we have now. Stations and extensions could have a sub menu as well.

Offline ӔO

  • Devotees (Inactive)
  • *
  • Posts: 2345
  • Hopefully helpful
  • Languages: en, jp
Re: Icon standardization - RFC
« Reply #62 on: January 24, 2013, 02:06:29 AM »
if menus get a key, I would suggest using the top row of keys. Function keys would be preferable.

F1: help
F2: options
F3: map
etc.

I think that would be pretty easy to find and also be universal across all types of keyboards.

Offline prissi

  • Developer
  • Administrator
  • *
  • Posts: 9326
  • Languages: De,EN,JP
Re: Icon standardization - RFC
« Reply #63 on: January 24, 2013, 09:20:30 AM »
You can define F1 to F12 in the menuconf for toolbars already ...