Larger buttons in the UI

Bug #763517 reported by Hans Joachim Desserud on 2011-04-17
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Widelands media development

Bug Description

A while ago I started thinking about the buttons in the UI, which are rather small heightwise. Accessibility wise this makes it harder to click them than it would if they were taller. They are already quite wide, so they are easy to select in the width, but slightly harder to select in height. Also, looking at the various menus, there is a lot of whitespace which is not used for anything. Rather than having lots of wasted screen area, I suggest rather filling it with larger buttons. This change would also increase accessibility as it gets easier to click the intended button when it has a larger click area.

I have experimented a bit with adjusting the height on the main menu, which makes the buttons a bit taller. However, from what I can see the width/height of the various buttons are set on each menu? Is there any reason this isn't defined in one place, to ensure all buttons behave the same. I was happy to see they automatically scale to the resolution set, though.

Since other changes to the user interface which might happen this iteration , I thought I'd post this early in the build17 cycle to get some feedback and discussion going. I think lots of the work posted in that forum thread looks great, so I suspect build17 might see some large changes to the look and feel of Widelands.

Hans Joachim Desserud (hjd) wrote :

Just a demonstration. I played a bit around with various values for button height.
This is *not* intended as a suggestion, more to better display my suggestion.

tags: added: a11y ui
Changed in widelands:
milestone: none → build17-rc1
SirVer (sirver) wrote :

A resonable suggestions imho. I think close colaboration with the graphics team is most important.

Chuck Wilder (chuckw20) wrote :

Personally, I like this suggestion for a number of reasons and think it should be implemented.

Hans Joachim Desserud (hjd) wrote :

Ok, I have made some attempts to establish a common default height and width for buttons, but have so far been unsuccessful. The current situation is that each menu, for instance src/ui_fsmenu/
        m_butw (get_w() * 7 / 20),
        m_buth (get_h() * 18 / 300),
These variables are then sent as arguments when the buttons are created. This means that the default height/width is duplicated in each file needing it, and all occurrences need to be updated.

My suggestion is to organize so that it is possible to call the button constructor without specifying height/width and it will be assigned a default value. This would allow us to move it to one place where it can be updated. Also for any buttons we don't want the default size, calling the constructor with height/width parameters will override it. (In essence two constructors, one with height/width and one without, where the latter would redirect to the first with the default values specified) I have tried adding default values to the constructor, but the compiler does not like it when the rest of the parameters have no default values.

However, I suspect the reason it is done the way it is currently is due to the get_w()/get_h() methods which will not be available in the button class. Which means my approach may not even work if done correctly. I would still really like to see this defined in a single place. Does anyone have any ideas?

Oh, and I'm not sure if I have mentioned this already, but while I know programming, I don't really know c++ :/

SirVer (sirver) wrote :

those calculations are done to make the button's size resolution independent in the menus, defaulting to one button size would be bad if you increase the resolution: the buttons would need scaling.

A better approach might be remodel the UI to work with normalized coordinates going from 0 to 1 or so. With this, the resolution would not matter for the layout and your approach with the default sizes will work out.

As it stands now, I cannot see how the button default size can be moved inside the button class besides adding a static member variable. That is clutchy though.

Hans Joachim Desserud (hjd) wrote :

>those calculations are done to make the button's size resolution independent in the menus
yes, that's what I thought.

I am not sure about your suggestion about normalized coordinates. I think that may make it harder to finetune positions.

I thought a bit about making a variable (call it a semiconstant) which holds the current button-height/width scaled to the current resolution. This would be a "semiconstant" since it would only be updated when the resolution changes (singleton?). It seems a bit hacky though...

SirVer (sirver) wrote :

thats along the lines what I suggested with a static member in the Buttons class. Not nice.

The normalized variables idea come from recent open gl based games that define their menus in such a way. Upping the resolution doesn't change the size of the elements on the screen, only their resolution. I find this really neat.

Hans Joachim Desserud (hjd) wrote :

>The normalized variables idea come from recent open gl based games that define their menus in such a way

Any examples I can take a look at? I'd like to see how it works before commenting on it further.

SirVer (sirver) wrote :

One example is Starcraft 2. I guess all newer 3D games will use this.

Hans Joachim Desserud (hjd) wrote :

This has been on my todo list for a while, but I guess we will just have to wait a while.

I would like to be able to see how the tweaked buttons work over time, and allow time for adjustments both for improvement and consistency. Therefore I consider this a bit late in the release cycle, so I'm retargetting this to build18. I plan set up an experimental branch with this as soon as build17 is out the door to get this done, though.

Changed in widelands:
importance: Undecided → Low
milestone: build17-rc1 → build-18rc1
Changed in widelands:
status: New → Confirmed
Joseph Nahmias (joe-nahmias) wrote :

Hmm, this seems to dovetail with Bug #1030691 that I just opened. It would be nice if that one made it into M-18 as well.

Chuck Wilder (chuckw20) on 2012-09-11
tags: added: graphic
Chuck Wilder (chuckw20) on 2012-09-11
Changed in widelands-media:
status: New → Confirmed
Shevonar (shevonar) on 2012-10-05
Changed in widelands:
status: Confirmed → In Progress
assignee: nobody → Shevonar (shevonar)
Chuck Wilder (chuckw20) wrote :

FYI - in case it might be convenient as a test bed, I have updated the GUI-Development public branch ( on launchpad with the latest revisions in the trunk.

SirVer (sirver) wrote :

not sure what the status of this is. But it seems not be happening for b18.

Changed in widelands:
status: In Progress → Incomplete
milestone: build18-rc1 → none
SirVer (sirver) wrote :

Setting to incomplete for bug sweeping.

GunChleoc (gunchleoc) wrote :

IMO The easiest way to have a common button height is to define it in the constructor of the FullscreenMenuBase and have it as a protected const variable. That's the way I'm going at the moment anyway.

We also have buttons in the wui, which are of different sized to the fs_menu buttons, so I don't think a general solution in the UI::Button class would be viable.

Changed in widelands:
status: Incomplete → Confirmed
GunChleoc (gunchleoc) on 2016-10-10
tags: added: accessibility
removed: a11y
GunChleoc (gunchleoc) on 2016-10-10
tags: added: graphics
removed: graphic
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments