General GUI re-stylization

[eleazar]

EDIT:
I split this from the Production Screen thread, because the following posts are not really about the production screen.
Also see the tech screen thread for a few relevant posts.

I don't think putting a semi-transparent rectangle of colour over a panel would be difficult.

What about basic gradients?

Currently the use of values and shapes is pretty inconsistent... (no doubt due to the chances of a long history) anything you do to the queue items is going to clash with at least half of everything else.

I think it's time rather than continuing to do things piecemeal, that we put together a simple but consistent language of color and shape so that new or modified GUI elements have something to aim at. In other words, the kind of stuff that would be in a CSS style sheet if FO's GUI was a well-designed webpage.

I should have something worth seeing tomorrow.

[Geoff the Medio]

What about basic gradients?

Hmm... I'm not sure. I'd very much like to start using them in the FO GUI, as they often seem to make a big difference in how a GUI look. I'll have to investigate.

[Edit]Gradients don't seem to be built into GiGi.

However, any GUI window can define its own custom rendering routines which should be able to do arbitrarily complicated effects.

Could you give some examples of what sorts of gradients you'd like to use, and (ideally) how you think about specifying what they are in terms of the geometry of what's being painted? That is, do you specify two points with exact colours, and then request that the gradient change only in the direction parallel to the line connecting the points, or do you define a series of control points, a series of control lines (with given colour on the line and some sort of interpolation between different-coloured lines) or a mixture of control lines and points with some sort of interpolation between them?

I think, but am not sure, that the easiest way to implement shading would be to specify colours at the vertices (corners) of a window and shade smoothly between them. See attached. Doing anything can't be specified in terms of the four corners will be more complicated. So, for example, shading from the edges inward, which is a different direction on each edge of a window, will be more complicated.

We can use a texture to do shading, or more complicated texturing effects. Easiest is if the texture can be independently scaled in X and Y directions to fit the size of the window. This is essentially what's done for meter indicator bars in the resources panel on the sidepanel, which have a texture applied to give them (complicated) shading in the Y direction.

If you want to do something that treats edges differently from the interior, then things are more complicated. For exmple, you might want to have a texture applied to the edge of a window that doesn't rescale in the direction perpendicular to the edge, but which scale or repeats in the direction parallel to the edge. This still leaves (literally) corner-cases to worry about.

At this point though, we're not dealing with "simple gradients" anymore. [/Edit]

...put together a simple but consistent language of color and shape so that new or modified GUI elements have something to aim at. In other words, the kind of stuff that would be in a CSS style sheet if FO's GUI was a well-designed webpage.

That's sort of what I've been trying to do by modelling the look of various things after the tooltips. A mid-gray background with a title / name, black body with white detail text, and an image / icon to the left. This has been used for the original meter effect accounting tooltip, sidepanel planet panels, tooltips for game content like specials, buildings and ship parts, and would now be used for production and research queue items, and probably tech tree panels as well.

[eleazar]

We can use a texture to do shading, or more complicated texturing effects. Easiest is if the texture can be independently scaled in X and Y directions to fit the size of the window. This is essentially what's done for meter indicator bars in the resources panel on the sidepanel, which have a texture applied to give them (complicated) shading in the Y direction.

Oh, i hadn't spotted that graphic for the meter bars. (/art/misc/meter_bar_shading.png) Stretching a texture like that could probably accomplish any gradient effect i would every want.

In particular the menu bar and various headings are calling out to me to try out some gradient effects.

...put together a simple but consistent language of color and shape so that new or modified GUI elements have something to aim at. In other words, the kind of stuff that would be in a CSS style sheet if FO's GUI was a well-designed webpage.

That's sort of what I've been trying to do by modelling the look of various things after the tooltips. A mid-gray background with a title / name, black body with white detail text, and an image / icon to the left. This has been used for the original meter effect accounting tooltip, sidepanel planet panels, tooltips for game content like specials, buildings and ship parts, and would now be used for production and research queue items, and probably tech tree panels as well.

That's good as far as it goes, and indeed better looking and more consistent than most of the older stuff. I'm going to see what happens if the rest of the GUI is similarly revamped.

There's a plenty more that i want to consider and try with this, but here's how i leave the PSD as i go to bed. Not finished by any means, but you can see my general direction.

production queue take 2.jpg (187.36 KiB) Viewed 6951 times

[Geoff the Medio]

Why the uniform mid-gray fill behind the queue and encyclopedia window (top)? The gray works fine for a title bar, or a full border like with the buildable items list, but I find the lack of contrast between the queue items and the queue background, or between the title bar and the detail text of the encyclopedia window make things look quite bland and flat, and the unfunded tech panel seems half faded into the background of the queue.

I'd generally like to keep the existing theme of the "working space" black with white text (or coloured for emphasis), with gray title bars and (perhaps) borders, possibly with gradients for the title bars / borders.

If you want to reduce the text / background contrast a bit, I'd prefer to do that by making the text darker.

If you want to add a gradient to the top-of-screen info bar, then we'll probably need to do something about the size of the buttons at the top-right. They're flush with the edge of the screen so that moving the mouse all the way in their direction bumps into the limits of its motion while still over the button, making them easier to click, but they seem out of place with the visible gradient showing below them (in a way they don't if the transition between bar and background is less distinct.

[eleazar]

Why the uniform mid-gray fill behind the queue and encyclopedia window (top)? The gray works fine for a title bar, or a full border like with the buildable items list, but I find the lack of contrast between the queue items and the queue background, or between the title bar and the detail text of the encyclopedia window make things look quite bland and flat...

Generally switching to a dark grey background was very deliberate:

* Black on White is very powerful visually as maximum contrast. When that is used almost everywhere It is very hard to emphasize any areas. Even using saturated color, the increased emphasis can be ambiguous or at best moderate. A good design would use high contrast areas more sparingly and strategically.

* Since this is a space game, the background of the galaxy map has a lot of black in it. Panels of black against a backround of black provide insufficient differentiation.

* The contrast between the background and text is well within the parameters of standard UIs. The grey is currently RGB 32,32,32, and provides more contrast against white text than common elements of Vista and Os X for instance. My next version will probably take it a notch lighter, so i can have black and an intermediate darker grey for special emphasis. I gotta wonder if your screen gamut is off, because i'm not even close to the danger zone. And just to make sure, i just re-calibrated my monitor.

... and the unfunded tech panel seems half faded into the background of the queue.

Yes, that's kinda the intention. It is much more obviously "inactive" than what we currently have, while still being entirely legible. But that's simply one method, and has no really bearing on weather a dark grey background is a good thing or not, especially since this item is going to be redone anyway.

I'd generally like to keep the existing theme of the "working space" black with white text (or coloured for emphasis), with gray title bars and (perhaps) borders, possibly with gradients for the title bars / borders.

If you want to reduce the text / background contrast a bit, I'd prefer to do that by making the text darker.

I could have said the same thing, but apparently i define "working space" much more narrowly. For example, a text input field (as on the game-start screen last time i checked). This works well as black on a dark grey window, but looses any emphasis if it's just black on black. When the background is black, all you can do is make things brighter, which is really limiting.

I can't think of any visual reason why leaving the background generally black is a good thing. It's pretty clear to me that it's a bad choice.

If you want to add a gradient to the top-of-screen info bar, then we'll probably need to do something about the size of the buttons at the top-right. They're flush with the edge of the screen so that moving the mouse all the way in their direction bumps into the limits of its motion while still over the button, making them easier to click, but they seem out of place with the visible gradient showing below them (in a way they don't if the transition between bar and background is less distinct.

Yeah they should at least be centered in the bar. Though there's no visual necessity to of making the box go all the way to the top in order to take advantage of Fitt's law. If the box goes nearly to the top of the screen, and the few additional pixels beyond are also part of the active target, most users will be just as happy. The apple menu item and IIRC the start menu on xp and/or vista both do this.


Which of these items are drag-able by their title-bars? Or can you grab drag-able windows anywhere? These kind of items should have some sort of distinct appearance.


The other major issue i haven't yet address in my mock-ups is the practice of "highlighting" active toggle buttons with a med-dark grey background and leaving the active ones black. At best this is ambiguous, since the active items have significantly less contrast, this is too close to making the item "grayed out". It's the inactive buttons that should have the low contrast. There are several ways this could be accomplish this, i'll have more to say about that later.

[Geoff the Medio]

Generally switching to a dark grey background was very deliberate:

I did consider calling it "mid-dark" instead of "mid"...

* Black on White is very powerful visually as maximum contrast. When that is used almost everywhere It is very hard to emphasize any areas. Even using saturated color, the increased emphasis can be ambiguous or at best moderate. A good design would use high contrast areas more sparingly and strategically.

* Since this is a space game, the background of the galaxy map has a lot of black in it. Panels of black against a backround of black provide insufficient differentiation.

* The contrast between the background and text is well within the parameters of standard UIs. The grey is currently RGB 32,32,32, and provides more contrast against white text than common elements of Vista and Os X for instance.

Vista generally uses black text on white or light-gray backgrounds, so that's not really a fair comparison... Or did you mean white text on 32,32,32 background gives more contrast than the typical Vista / OSX black on white-ish background?

Any yes, RGB 32,32,32 is pretty dark in general, but here it's set against the even darker FreeOrion interface, so seems brighter than it would in a lighter context like the OSX or Vista interfaces. It's also in the dark end of the scale, meaning that, assuming the numbers translate linearly to actual brightness (which is probably not a very good assumption, but I'll make it for the sake of argument) there is a lot bigger relative and perceived difference between 0,0,0 and 32,32,32 than 128,128,128 and 160,160,160.

I can deal with UI panels being not black... I said above that borders can be lighter gray to separate their contents from the back background, and upon reflection I also don't object to a dark fill colour... but I still find 32,32,32 to be to light for this purpose.

How about meeting me about half way, and using 15,15,15 for the "working" space, with 32,32,32 or slightly lighter for the borders? (See rough approximation in attached... MS Paint fill doesn't have an easy way to paint over nearby colours). In the relatively dark context, the 15,15,15 is clearly not background of space, at least to me, but is dark enough to make the tech panels stand out better than they did on 32,32,32, I find.

The text in the top panel could perhaps be a bit grayer (ie. less bright white) to reduce its contrast with the 15,15,15 behind it. The lighter text at the top makes its background seem darker to me than the queue background with grayer objects on it, although both backgrounds should be the same 15,15,15.

My next version will probably take it a notch lighter, so i can have black and an intermediate darker grey for special emphasis.

This is sort of what I'm doing with the 15,15,15, I think... The 15,15,15 areas are where the contents of a window are displayed, be it a queue, list or block of text. I an see an argument for making the text background lighter since it's not "interactive" like the queue or list, but it might also make sense to keep the lighter border / darker insides arrangement consistent for all the windows.

I gotta wonder if your screen gamut is off, because i'm not even close to the danger zone. And just to make sure, i just re-calibrated my monitor.

Could be...

... and the unfunded tech panel seems half faded into the background of the queue.

Yes, that's kinda the intention. It is much more obviously "inactive" than what we currently have, while still being entirely legible. But that's simply one method, and has no really bearing on weather a dark grey background is a good thing or not, especially since this item is going to be redone anyway.

I can't explain why, but that particular type of fading just doesn't imply the right thing to me if the background colour of the tech panel is the same as the colour of the queue it's on top of. With 15,15,15, I like the current graying method for inactive tech panels (or prod queue in this case) more than on 32,32,32.

I'd generally like to keep the existing theme of the "working space" black with white text (or coloured for emphasis), with gray title bars and (perhaps) borders, possibly with gradients for the title bars / borders.

If you want to reduce the text / background contrast a bit, I'd prefer to do that by making the text darker.

I could have said the same thing, but apparently i define "working space" much more narrowly. For example, a text input field (as on the game-start screen last time i checked). This works well as black on a dark grey window, but looses any emphasis if it's just black on black. When the background is black, all you can do is make things brighter, which is really limiting.

I don't follow what you're describing here. (I think I get the point about having no room to emphasize if the background is at the extreme (0,0,0), though)

Though there's no visual necessity to of making the [button at top of screen's] box go all the way to the top in order to take advantage of Fitt's law. If the box goes nearly to the top of the screen, and the few additional pixels beyond are also part of the active target, most users will be just as happy. The apple menu item and IIRC the start menu on xp and/or vista both do this.

This requires some extra coding beyond just dropping a GG::Button in place to make happen, though. It wasn't really necessary with just the black background, so I didn't bother.

Which of these items are drag-able by their title-bars? Or can you grab drag-able windows anywhere? These kind of items should have some sort of distinct appearance.

The buildable items list and the encyclopedia detail panel can be dragged and resized. If necessary, the queues could be made draggable and resizable, but this would be quite a bit of effort to get working properly.

Most draggable things can be dragged by their title bars and their borders. The resizing can only be done using the hashed tab at the bottom-right, which is actually rather difficult to successfully grab for this purpose. (Quite often I end up grabbing whatever's under the corner, be it the tech tree or the galaxy map, and dragging that instead of resizing the window I intended to).

The other major issue i haven't yet address in my mock-ups is the practice of "highlighting" active toggle buttons with a med-dark grey background and leaving the active ones black. At best this is ambiguous, since the active items have significantly less contrast, this is too close to making the item "grayed out". It's the inactive buttons that should have the low contrast. There are several ways this could be accomplish this, i'll have more to say about that later.

Whatever scheme is used, there needs to be a distinction between "inactive" and "disabled". The buttons at the top right that aren't "active" can (generally) still be clicked, unless it's the main menu that's open, which is "modal" so takes control of the UI and prevents anything else from be interacted with. For the other windows (sitrep, production, research, design, or just the map) the user can click the other buttons to switch screens or turn off the current screen.

[eleazar]

Generally switching to a dark grey background was very deliberate:

I did consider calling it "mid-dark" instead of "mid"...

Then maybe there is hope.

...
* The contrast between the background and text is well within the parameters of standard UIs. The grey is currently RGB 32,32,32, and provides more contrast against white text than common elements of Vista and Os X for instance.

Vista generally uses black text on white or light-gray backgrounds, so that's not really a fair comparison... Or did you mean white text on 32,32,32 background gives more contrast than the typical Vista / OSX black on white-ish background?

Any yes, RGB 32,32,32 is pretty dark in general, but here it's set against the even darker FreeOrion interface, so seems brighter than it would in a lighter context like the OSX or Vista interfaces. It's also in the dark end of the scale, meaning that, assuming the numbers translate linearly to actual brightness (which is probably not a very good assumption, but I'll make it for the sake of argument) there is a lot bigger relative and perceived difference between 0,0,0 and 32,32,32 than 128,128,128 and 160,160,160.

I strongly suspect your screen is giving you something way off standard, a different aesthetic preference alone can't explain what you are saying. Perhaps you have the gamma set to something close to "1"? Standard PC gamma is 2.2, and the standard for Mac is 1.8. The Mac gamma is lower contrast, and thus it is easier to distinguish colors that are almost black from pure black. So while 15,15,15 is visually very close to black on my Mac screen, many people with standard PC gamma would be literally unable to distinguish it from black at all.

Until you get that normalized, statements about what seems too dark or light aren't going to be very helpful.

Which of these items are drag-able by their title-bars? Or can you grab drag-able windows anywhere? These kind of items should have some sort of distinct appearance.

The buildable items list and the encyclopedia detail panel can be dragged and resized. If necessary, the queues could be made draggable and resizable, but this would be quite a bit of effort to get working properly.

Most draggable things can be dragged by their title bars and their borders. The resizing can only be done using the hashed tab at the bottom-right, which is actually rather difficult to successfully grab for this purpose. (Quite often I end up grabbing whatever's under the corner, be it the tech tree or the galaxy map, and dragging that instead of resizing the window I intended to).

I don't see much reason to make the queues movable. There's some advantage to leaving them nailed to the side so it's easy to keep the tech tree or selected planet from getting hidden underneath them.

I think part of the reason the re-sizer tab is hard to grab is because that corner has the diagonal chip taken out of it. Cutting off the corners is OK, in general, but it shouldn't be that corner.

The other major issue i haven't yet address in my mock-ups is the practice of "highlighting" active toggle buttons with a med-dark grey background and leaving the active ones black.....

Whatever scheme is used, there needs to be a distinction between "inactive" and "disabled". The buttons at the top right that aren't "active" can (generally) still be clicked, unless it's the main menu that's open, which is "modal"...

Good point.

[Geoff the Medio]

I strongly suspect your screen is giving you something way off standard, a different aesthetic preference alone can't explain what you are saying. Perhaps you have the gamma set to something close to "1"? Standard PC gamma is 2.2, and the standard for Mac is 1.8. The Mac gamma is lower contrast, and thus it is easier to distinguish colors that are almost black from pure black. So while 15,15,15 is visually very close to black on my Mac screen, many people with standard PC gamma would be literally unable to distinguish it from black at all.

I'm confused... if standard PC gamma is higher contrast, shouldn't that make it *easier* to see the difference, or "contrast", between two colours?

I have two LCDs: one glossy and one matte. The glossy LCD that I've mostly been using during this discussion shows the dark grays noticably lighter than does the matte LCD. However, when showing my latest mockup on a black background on the matte LCD, the 15,15,15 is still clearly different from the 0,0,0 behind it. Both are set to their default gamma of 1.0, which has always seemed fine on both, giving me no reason to change it. (I always used to adjust the gamma higher when using a CRT, however.)

I tried turning up the gamma on the glossy LCD, and it made the darker grays even brighter. Full 0,0,0 black is still black, but the colour curve slope is much higher at the bottom end with increased gamma, making all the near-black grays get brighter faster with (numerical) distance from black, increasing the low-end contrast. This seems to have the opposite of the effect you're saying it should (ie. you said increasing gamma should make it harder to see the difference between black and near-black).

Increasing the gamma would reduce the high-end contrast, as it makes the slope of apparent vs. numerical brightness less steep at the high end (and steeper at the low end).

I assume since you're all graphically-inclined that you're using a CRT? I suspect most non-art-types today have moved to LCDs, since I don't think most consumer electronics stores even sell new computer CRTs anymore...

...

Anyway, I'll concede that 32,32,32 will generally look darker than I'm seeing it, and that it works as the background colour or border colour / title bars of windows. I'd still like a brighter colour for the borders and title bars of windows than the main fill colour, though. This probably means either using 32,32,32 for the borders and title bar and black for the fill, or 32,32,32 for the fill and something brighter for the borders and title bar. A concern with a brighter title bar / border colour is contrast with text on the title, though. We could add drop shadows or some approximation of black outlining of text, if that would help... Or what about gradients or textures on all window borders?

I think part of the reason the re-sizer tab is hard to grab is because that corner has the diagonal chip taken out of it. Cutting off the corners is OK, in general, but it shouldn't be that corner.

Making something smaller / harder to click on does seem like a backwards method to indicate clickability...

...

Edit: It might be better to use a list of large icons, like the parts list on the ship design screen, on the production screen items list, rather than the columns of name / cost / build time / short description we have now. Details are always available in the encyclopedia window, and could be added to tooltips for the icons. Any thoughts on this? One issue might be that we'd need a lot of distinctive ship icons to be able to tell them apart on the list. Currently all user-designed ships have the same icon, which is the only available background image on the design screen to represent hulls. Parts aren't indicated on the icons at all.

[eleazar]

I strongly suspect your screen is giving you something way off standard, a different aesthetic preference alone can't explain what you are saying. Perhaps you have the gamma set to something close to "1"? Standard PC gamma is 2.2, and the standard for Mac is 1.8. The Mac gamma is lower contrast, and thus it is easier to distinguish colors that are almost black from pure black. So while 15,15,15 is visually very close to black on my Mac screen, many people with standard PC gamma would be literally unable to distinguish it from black at all.

I'm confused... if standard PC gamma is higher contrast, shouldn't that make it *easier* to see the difference, or "contrast", between two colours?

No. There's a finite amount of color space, so you can't give clarity without taking it away somewhere else. "Increasing the contrast" in the general sense i used, makes the brights whiter, and the darks blacker. With ultimate contrast there would be nothing but pure black and white. So by increasing the overall contrast the distinction between dark and very dark is minimized. Do some Googling.

I have two LCDs: one glossy and one matte. The glossy LCD that I've mostly been using during this discussion shows the dark grays noticably lighter than does the matte LCD. However, when showing my latest mockup on a black background on the matte LCD, the 15,15,15 is still clearly different from the 0,0,0 behind it. Both are set to their default gamma of 1.0, which has always seemed fine on both, giving me no reason to change it. (I always used to adjust the gamma higher when using a CRT, however.)

I tried turning up the gamma on the glossy LCD, and it made the darker grays even brighter. Full 0,0,0 black is still black, but the colour curve slope is much higher at the bottom end with increased gamma, making all the near-black grays get brighter faster with (numerical) distance from black, increasing the low-end contrast. This seems to have the opposite of the effect you're saying it should (ie. you said increasing gamma should make it harder to see the difference between black and near-black).

Increasing the gamma would reduce the high-end contrast, as it makes the slope of apparent vs. numerical brightness less steep at the high end (and steeper at the low end).

It's possible your monitors brightness contrast settings and or video card settings are manually adjusted to somewhat make up for your low gamma. If you have Vista i think it also has some system-wide controls. In spite of all these variables, i don't understand how raising the gamma could make near-blacks look brighter. That's the opposite of what should happen. The fact that i correctly guessed your Gamma was set to ~1 by the fact that you could easily distinguish the blacks from the near blacks, also confirms that increasing the gamma should make the difference less dramatic.

Gamma correction is somewhat complicated mathematically.
This much i'm sure of: With the standard PC gamma setting 2.2, the darks look darker than on the standard Mac setting of 1.8. Thus when i set my screen to a gamma of 1, i see what i expect: the darks brighten and in general everything looks washed out.

I assume since you're all graphically-inclined that you're using a CRT? I suspect most non-art-types today have moved to LCDs, since I don't think most consumer electronics stores even sell new computer CRTs anymore...

The earlier LCDs had some issues for higher end graphic work, but that stigma has pretty much been lifted with better LCD tech. I have an LCD.

Anyway, I'll concede that 32,32,32 will generally look darker than I'm seeing it, and that it works as the background colour or border colour / title bars of windows. I'd still like a brighter colour for the borders and title bars of windows than the main fill colour, though.... A concern with a brighter title bar / border colour is contrast with text on the title, though. We could add drop shadows or some approximation of black outlining of text, if that would help... Or what about gradients or textures on all window borders?

I'm working with the brighter title-bar idea, and like it. I'm not sure about brighter borders, i want to try some things. If it is any consolation, out of all the designers i've known, i'm one of the most fanatical about preserving legibility. Drop-shadows/outlines are probably not strictly necessary for legibility, but could be a nice touch.

Perhaps i should explain a little more about what i'm trying to do.
The goal is the sweet-spot between simplicity, clarity, and flexibility, and to make it look as good as possible without diminishing any of the previous 3 qualities. FO has a very long road ahead, and there will be numerous changes to the GUI and tons of additions. This style-sheet is supposed to make it as easy as possible to prototype and implement new or altered GUI elements. Maybe there will come a time to make the GUI "fancy", but that should be towards 1.0 in the polishing stage. A lot of the nifty looking UI ideas submitted earlier in the project were over-designed, so they couldn't be easily generalized to new UI elements, and broke if any part of the interface changed.

I don't know what it looks like behind the scenes, but i'd guess that the each window or panel is defined individually. I don't know how much GG allows, but ideally all "dragable windows" (for instance) would be mostly defined by a "dragable windows" archetype, and differ only according to the inside. ... Scrollable text-boxes should all be the same etc.

So in anticipation of the submission of other cooler, fancier concepts, i argue that right now we need something with maximum simplicity and flexibility.

Edit: It might be better to use a list of large icons, like the parts list on the ship design screen, on the production screen items list, rather than the columns of name / cost / build time / short description we have now. Details are always available in the encyclopedia window, and could be added to tooltips for the icons. Any thoughts on this?

I'd like to stay focused on the style of the GUI for now rather than specifics about how different parts should work, which probably means i should split out the recent posts into a new topic.

[Geoff the Medio]

I'm working with the brighter title-bar idea, and like it. I'm not sure about brighter borders, i want to try some things. If it is any consolation, out of all the designers i've known, i'm one of the most fanatical about preserving legibility. Drop-shadows/outlines are probably not strictly necessary for legibility, but could be a nice touch.

I put some black outlines behind the system names on the galaxy map, and it helps, especially when a starlane of the same colour passes behind the name text.

System names have black shadowy bits all around them.

System_Name_Drop_Shadows.png (165.94 KiB) Viewed 6855 times

I don't know what it looks like behind the scenes, but i'd guess that the each window or panel is defined individually. I don't know how much GG allows, but ideally all "dragable windows" (for instance) would be mostly defined by a "dragable windows" archetype, and differ only according to the inside. ... Scrollable text-boxes should all be the same etc.

Do you mean all draggable windows should have the same border style or title bar colour, and this would be different from other types of windows in at least one obvious way?

Warning, rambling ahead...

The way windows or controls are rendered is entirely customizable in GiGi and FreeOrion. Each window can render itself entirely differently from others, or can use a shared rendering scheme, or can render according to the shared scheme and then do something else as well. A shared scheme can be rendered using a different set of colours depending on what the individual window needs.

Right now, we have a mixture of different methods of determining how something looks. Some windows have custom rendering code, and others use a common rendering routine.

There are some shared colour options (see attached) which are somewhat inconsistently and misleadingly applied throughout the UI.

Options screen, colours tab.

Options_Colours.png (152.13 KiB) Viewed 6854 times

To make a more consistent and customizable UI, it would be helpful to have a full list of window appearance "features" that you'd like to be able to turn on or off or control the value of as a UI designer. Which ones you'd want to change frequently and which should be consistent across the UI is important. Examples might be colours of various features, sizes of features, whether features are shown or not, and all the features these these should apply to. Wanting to turn something on or off or change it can mean change it in code but leaving it fixed after the program is compiled, or it could mean being able to change it in the options screen, although the latter is more work.

Having a small set of window template that can be the base for other windows is possible. Easiest is if a window always uses the same template, but if the templates are similar enough, we could swap which a window uses during runtime in response to user actions. (eg. "docking" a window to make it non-draggable and updating its apperance accordingly, although there's presently no window-docking functionality anywhere...)

The more individual window appearances that can be described in terms of general features or sets of features, the easier it is to make it customizable and designer-editable.

In the semi-ideal future, we'd have a set of XML files that you could edit to change how each window appears in-game, and these XML files would be able to refer to general-purpose in-GUI options such as "window background colour", "title/border background colour" "border thickness", "title font size", "general text font size", etc, but also specifiy things specific to the individual window the file is for, such as the position and size of various controls within the window, or how that changes if the window is resized, or default layout of windows contained within other windows. How much work it would be to set that up, I'm not sure, and we'd first need to work out a language to describe it (unless there's a commonly-used grammar and vocabulary for this sort of thing that would be easy to implement). Obviously the more complicated stuff (how contents rearrange if a window is resized) are more difficult to describe in XML.

But shorter term, it's relatively easy to have just the set of general-purpose GUI-controls that are in-GUI adjustable that determine aspects of how windows are rendered. The way each window would depend on these controls would be hard-coded, though. This is roughly what we have now, for font size and colours of various parts of the UI, but it's followed inconsistently.

[eleazar]

Here's a couple of drag-able windows. Most of this could be achieved simply by changing color values.

Specifically notice: titlebar, window-resizing-tab, buttons, and scrollbar.

It's not everything i want to do, but it shows where i'm going.


Note: the lightest gray on the background is ~30% gray and thus should appear significantly closer to black than white.

[Geoff the Medio]

Something else to consider... both those examples are cases where a window has a box-shaped something inside it that fills up all the space that's not the title bar or edges. The encyclopedia panel has a text box, and the items list has a list box that cover the whole interior. Such window-spanning list and text boxes can have colour you've used as their background, but what should be done if there isn't such a functional-bits-enclosing box spanning the space between edges and title bar inside of a window? Examples of this are the galaxy setup window and main menu which have a few buttons, indicators and widgits within a large empty space. You might consider adding an example for one of those.

[pd]

Just wanted to jump in to say, that I REALLY LIKE what's being done here. Tremendous improvements. I'll be back around next week with some actual useful input.

Hooray for the black outlines behind system names.

[eleazar]

I put some black outlines behind the system names on the galaxy map, and it helps, especially when a starlane of the same colour passes behind the name text.

Ah, yes. In that context a drop-shadow is a much needed improvement.

I don't know what it looks like behind the scenes, but i'd guess that the each window or panel is defined individually. I don't know how much GG allows, but ideally all "dragable windows" (for instance) would be mostly defined by a "dragable windows" archetype, and differ only according to the inside. ... Scrollable text-boxes should all be the same etc.

Do you mean all draggable windows should have the same border style or title bar colour...

Yes to both.

... and this would be different from other types of windows in at least one obvious way?

Well something obvious should be different about drag-able as opposed to non-drag-able windows. The title bar seems like the best candidate ATM.

Warning, rambling ahead...

All that's actually helpful. It sounds more promising than i thought it might be.

To make a more consistent and customizable UI, it would be helpful to have a full list of window appearance "features" that you'd like to be able to turn on or off or control the value of as a UI designer. Which ones you'd want to change frequently and which should be consistent across the UI is important.

Yes, at the conclusion of the mock-up phase i would expect to put together such a list.

Having a small set of window template that can be the base for other windows is possible. Easiest is if a window always uses the same template, but if the templates are similar enough, we could swap which a window uses during runtime in response to user actions. (eg. "docking" a window to make it non-draggable and updating its apperance accordingly, although there's presently no window-docking functionality anywhere...)

Other examples: Giving the sidebar a "view mode" so that it displays only all your inhabited planets in all systems, or allowing the player to switch between a list and box of icons when choosing buildings or ship components.

... How much work it would be to set that up, I'm not sure, and we'd first need to work out a language to describe it (unless there's a commonly-used grammar and vocabulary for this sort of thing that would be easy to implement).

I don't know about "easy to implement", but otherwise you might be talking about CSS.

Something else to consider... both those examples are cases where a window has a box-shaped something inside it that fills up all the space that's not the title bar or edges.... Examples of this are the galaxy setup window and main menu which have a few buttons, indicators and widgits within a large empty space. You might consider adding an example for one of those.

Good point. Now that i know there's a Mac-intel friendly version i grabbed screenshots of several windows in the startup area that showcase GUI elements and arraignments not currently found elsewhere.

Just wanted to jump in to say, that I REALLY LIKE what's being done here. Tremendous improvements.

EDIT: P.S. for this project i'm working with a gamma setting of "2", which splits the difference between standard PC and Mac screens so that the result should be about equally good in either situation.

[eleazar]

Here's the same theme (slightly refined) applied to the galaxy setup window. I left the "main menu" alone because i'm lazy and to provide a before/after comparison.

Galaxy setup.jpg (175.64 KiB) Viewed 6788 times

About the snipped-off corners:
I haven't done much with them yet. If we were starting from scratch i probably wouldn't include them, but now they are sorta part of FO's identity. But again we use them inconsistently. I think we should use either rounded or straight corners, or at the very least use round and straight in an internally consistent way.
And of course we need to avoid chopping off important stuff like the window-resize-tab.