Usability of OpenTTD/Ingame Help

[prissi]

I think any program (including OpenTTD) would have a better experience with better usability. This has been discussed before (and was improved a little). However, it could be better. Thus I would like to make some suggestions:

- Make tooltip help default (instead of right mouse click)

- Have some ingame help system

- Same function uses always the same icon or text (e.g. the location/goto location/eye icon is a bad example.)

- Artifically division of same stuff should be avoided (like settings, difficulty settings, patch settings ... or car dialoge different from train dialoge)

- For usability, buttons with changing text and function (modal buttons, e.g. station goods dialoge) are not great; better just grey out invalid options or a drop down?

- Need of a consistent style guide (and conversions of non-conforming dialoges to this). Some issues: Where to place toolbars? Allow for button changing text and function versus top tabs or drop down?

I know the professional gamers do not care. But I am sure most gamers actually could profit from this some way or the other.

[Daz]

I think this is a good idea. Im always trying to get my friends to play the game but they lose interest because the game is too complex to learn if you are new to it. There is the wiki but there is no where in the game that links to it.

I to also made a suggestion to make the game more user friendly but nothing was done about it. Its almost as if the developers dont care about new players when accutally they are important because it will make the game more popular and more help can be provided by these new players.

Besides that the game is great! just not user friendly.

[richk67]

I think any program (including OpenTTD) would have a better experience with better usability. This has been discussed before (and was improved a little). However, it could be better. Thus I would like to make some suggestions:

- Make tooltip help default (instead of right mouse click)

This was discussed a while back. OTTD is not a Windows game, and thus it does not have an underlying event trigger to cope with "mouse has been hovered over this location for x millisecs - show tooltip". We therefore use a mouse-based trigger, which is much more easily captured.

- Have some ingame help system

1) Have you ever tried writing one? I have written in-product help (not for OTTD). It is a NIGHTMARE. For a game with a gazillion options like OTTD, it would be an entire project in its own right.
2) OTTD supports 26+ languages, and has the aim of providing text in the selected language throughout. This would also apply to the Help. So now it is 26x the workload.

- Same function uses always the same icon or text (e.g. the location/goto location/eye icon is a bad example.)

- Artifically division of same stuff should be avoided (like settings, difficulty settings, patch settings ... or car dialoge different from train dialoge)

Well, trucks and trains are two different things with different capabilities. Using one GUI for both would end up with questions on the forums "truck option XYZ is always greyed out. How do I get it to do XYZ?".

I totally agree about the settings/difficulty/patch options, etc. Mostly it is bad naming. Some of it is choosing to retain the old original item (eg. Game Settings), some is looking to not edit a working screen. Also, please bear in mind that only recently was it possible to use more than 30 elements in a GUI window. Thus, many of the old were unchanged as they worked - and "if it works, dont mess."

- For usability, buttons with changing text and function (modal buttons, e.g. station goods dialoge) are not great; better just grey out invalid options or a drop down?

Can you show an example - its not exactly clear what you mean.

- Need of a consistent style guide (and conversions of non-conforming dialoges to this). Some issues: Where to place toolbars? Allow for button changing text and function versus top tabs or drop down?

Toolbars go left to right. Icon buttons on screens with "live action" windows are on the right. Function buttons are always at the bottom of the dialogue. (The only exception I can think of is the face customisation screen, and I wouldnt make a generic complaint based on a screen most players will only use once per game.)

I know the professional gamers do not care. But I am sure most gamers actually could profit from this some way or the other.

As usual - do some of the work, and you will be listened to. e.g. you want help text. Take, say, the depot dialog or any one of the 65+ gui screens, and describe it yourself. (If you really want to appreciate just how much time it will take, try the Config Options dialog - all 6 panels of it.) Then take the time and multiply by 65, then multiply by the number of languages you are prepared to support. Then return to your original position and modify the importance of the task.

[prissi]

- Make tooltip help default (instead of right mouse click)

This was discussed a while back. OTTD is not a Windows game, and thus it does not have an underlying event trigger to cope with "mouse has been hovered over this location for x millisecs - show tooltip". We therefore use a mouse-based trigger, which is much more easily captured.

This is easy. Just add a counter to the mouse, which is increased every frame and cleared when the x or y position is changed. If counter > xyz just send the right mouse button event every frame (would change only the event loop).

- Have some ingame help system

1) Have you ever tried writing one?

Yes, as I am headcoder of simutrans. There we use hmtl-like help files (only very simple html, list, bould, strong, italicts for shadowed and h1/h2/h3. Every dialog has a reference file "railtools.txt". In the translation file directory, the are folders "de", "en", "fr", ... and inside the folders are the help files. First a help file is checked for "OWN LANGUAGE"/railtools.txt and then for EN/railtools.txt. That way there is at least an english help, if the native language is missing. And the helpfiles come from contributors, same as the translations ...

Well, trucks and trains are two different things with different capabilities.

The only difference is imho the ignore signal stuff, which is an option I never ever had to use and other also use rarely (and thus could be on the details dialoge or the schedule dialoge).

BTW: The toolbar in vehicle dialog are at the right border and go from top to bottom.

As for surprising elements, look at the attached screenshot. In the station dialoge, the middle button changes text and function (and dialoge size) when pressed. I think a drop down (maybe at the position of accepts) would be the more logical choice. Then whith schedules, there is a button in the title bar (some for vehile details for renaming). The Goto option in the schedule dialoge seems to be the same as the Nach meaning, but both have different texts.

Also the Icon and Button texts are different size. Using the same size would be more nicer too, and would increase usability on larger screens.

But the interactive "ballon" help system and maybe a dialoge sensitive help system would be useful. Or at least something that starts the wiki from OpenTTD directly on windows, Linux and Mac from the help menu.

[richk67]

This is easy. Just add a counter to the mouse, which is increased every frame and cleared when the x or y position is changed. If counter > xyz just send the right mouse button event every frame (would change only the event loop).

Usual response then; code it, submit as patch, and justify its inclusion. I suspect that the constant polling/calculating of mouse position relative to every window/button would crucify performance. At least with the current system, it only needs to do that check if the right-mouse button has been pressed.

BTW: The toolbar in vehicle dialog are at the right border and go from top to bottom.

And all windows that have an active viewing window, consistently have their buttons on the right. Personally, I think that having a button bar/toolbar above the window would look tacky. This is the long established GUI design; following the pattern of the original game. It sounds like wanting change for change's sake.

As for surprising elements, look at the attached screenshot. In the station dialoge, the middle button changes text and function (and dialoge size) when pressed. I think a drop down (maybe at the position of accepts) would be the more logical choice.

Code it, demo it, persuade people your way is better.

Then whith schedules, there is a button in the title bar (some for vehile details for renaming). The Goto option in the schedule dialoge seems to be the same as the Nach meaning, but both have different texts.

Several of your issues here look to be on consistency of translation. So switch to English, check out what the translations are, and if different, raise a bug report.

Also the Icon and Button texts are different size. Using the same size would be more nicer too, and would increase usability on larger screens.

And how does it appear on some of the tiny screens? OTTD isnt just coded to support those players with the biggest and best; it is played on some PDAs, where your solution may be completely unhelpful.

But the interactive "ballon" help system and maybe a dialoge sensitive help system would be useful. Or at least something that starts the wiki from OpenTTD directly on windows, Linux and Mac from the help menu.

As for your screenshot:
Red: you are comparing vehicle windows (with icons), with local authority and station windows. LA has a fixed view, and would look silly if it were buttonised. Station window has no view window (maybe it should??) and again a GoTo button would be silly. To un-buttonise the vehicle windows, would create text buttons splattered everywhere. Ugly as hell, IMO.

Orange: translation? Maybe change "Name" to "Rename", but then some players would whine that in their language the words outspill the boxes. Tough.

Yellow: icon buttons on right for vehicle windows is consistent throughout the game. The additional text buttons in the title bar - where else would you have them, without using up more screen-space. Remember for many users, screenspace is at a premium.

Green: A toggle button. Hmm... tricky concept (not). A drop down button (Hmm... Windows combo box?). Again a familiar concept. Again, what is your solution that is a) legible, and b) does not use any further screen space. Are you suggesting a THIRD row of text buttons... God help us.

Blue: never noticed that one before.

[prissi]

I coded a lot of these stuff already one time, as part of the passenger destination patch take two ...

(BTW: LA has a goto location button, the leftmost one, same as the stations. I sense a misunderstanding here.)

BLUE in the above image is just a suggestion. This button could be added by dialogs that hve a help file connected with them.

The vehicle window is very large and most of it is showing only some view of the map. For smaller screens this could easily be smaller. However, the automated tooltips take some of the problems with the images away.

And to the schedule dialog (which I agree is already badly cluttered): There you have the button "jump to next stop" But the stop convoi is in the main doaloge, as the goto depot and ignore signals. This is not consistent. And the Full Load/Non stop etc. options would be best directly after each entry, because they influence the entry in that line. That would also help saving space and would make the available options immediately clear.

This requires some thinking "out of the box" and may be surprising for a short while. However, this would be more ergonomically and more easy, a win-win situation imho.

As to most of your response:
I could easily code something. However, the next person would code something completely different. Without a style guide any effort would be in vain. Why is there a quite rigoriously enforce style guide for the code, but nothing for the UI? The UI was just changed by the "I'll add a button here" method.

Anyway, appended is an automatic tooltip patch.

(And given the resonance of this thread, people do not care about UI and usability much anyway.)

[belugas]

(BTW: LA has a goto location button, the leftmost one, same as the stations. I sense a misunderstanding here.)

What do you mean? I fail to see where, honestly.

BLUE in the above image is just a suggestion. This button could be added by dialogs that hve a help file connected with them.

Not bad of an idea. But it would open what? A panel with some scrolling text? A URL? If it is an Url, what if the user has no internet connection at the moment? I think it must be though of before going coding, and I see you already agreed on that

This requires some thinking "out of the box" and may be surprising for a short while. However, this would be more ergonomically and more easy, a win-win situation imho.

I fear a lot of reactions from users. I think the "surprising" is an euphemism.
To what extend do we want to change their habits? I'm not saying it is a bad idea. I'm merely establishing the fact that we, as devs, are going to answer a lot more so-called bug reports than we are today. PLus, it's not really possible (unless ugly coding) to offer the old and the new interfaces.

However, the next person would code something completely different. Without a style guide any effort would be in vain. Why is there a quite rigoriously enforce style guide for the code, but nothing for the UI? The UI was just changed by the "I'll add a button here" method.

I agree with that. Problem (once more) is that everyone has tis little idea, and it will soon become a very big mess. My idea wold be better to dress a list of what we have right now, what would need top be changed, establish that as a standard and move on according to this.
Although, we have to keep the "heritage" of the old game. Something that Simutrans does not have to take care of. So stuff like the vehicle window should remain as it is. So the tricky part is to innovate while keeping the old feeling.

Anyway, appended is an automatic tooltip patch. (And given the resonance of this thread, people do not care about UI and usability much anyway.)

I'm trying your patch right now. I have to say i'd preffer a menu check box under the quesiton mark button, but that is only icing on the cake. And as for UI, i'd say people are more craving for features than UI. Not my opinion, just a act.

[DaleStan]

PLus, it's not really possible (unless ugly coding) to offer the old and the new interfaces.

Indeed. I've done it quite a few times. It rarely works the first time, and often not the second either. There are just way too many things to consider.

Doesn't stop me from doing it, unfortunately.

[prissi]

Sorry, if I was trying to make my point a little overenthusiastic.

And there was an error in my patch: The counter should of course reseted too, if the mouse state was changed. Will look in that in the evening.

As for the question mark: One could have a virtual function, which returns a filename of the help file. The default class does return an empty string => show question mark in title bar only when the filename is not NULL. The file could be then just some text show in a scrollable windoe (most easiest solution) or some text even from the game translation (would allow for colors etc, but will be shorter and harder to modify/extend from the "normal" user point of view).

The order window is a good example how messy things have become. Not only the wiki does not know about the current state of the order window, the entries too do not tell very much about their function.

(By the way, way is the reason for a via order without non-stopping? Or the difference between Transfer and Unload all?) Below my attempt at the order window. Also two row of colums with an icon on to would do the same trick.

All buttons changing the schedule list are now in one line.
All buttons changing train behaviour immediately are now in the second line.
When entring an order, the options would be immediately clear. Alternatively a third line (yuck). Or skip the vehicle control line completely: Skip can be implemented by clicking on the triangle, service can be enforce in the detail menue.

Instead of the delete buttons in from of the icons, maybe a basket to delete like in the depots would be more consistent. I mean, you can already drag and drop orders (although the mouse do not give a feedback), but with a basket thing would ge clear immedeately.

Another suggestion: Make schedule and order window appear one windows? Use a drop down in the uppermost corner => Less screen cluttering on small monitors.