FreeOrion

Forums for the FreeOrion project
It is currently Tue Oct 24, 2017 12:30 am

All times are UTC




Post new topic Reply to topic  [ 53 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Wed Jan 21, 2009 10:07 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12007
Location: Munich
Do you not want any visible transition between the title bar and the background of windows like the galaxy setup? No gradients in the title bar, even?

A gradient across the body of the window or near the edges might look interesting.

Please illustrate mouseover feedback for everything that should have it, and how things change when being clicked on.

When do widgets - pictures or buttons or droplists - get border outlines that are dark then light or light then dark or just dark when moving outside towards their insides?


Top
 Profile  
 
PostPosted: Thu Jan 22, 2009 12:26 am 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
Geoff the Medio wrote:
Do you not want any visible transition between the title bar and the background of windows like the galaxy setup? No gradients in the title bar, even?
I was thinking that the gradient title bar would be a distinctive of the moveable windows, but now i'm not so sure that works. At least for the moveable windows there needs to be some boundary between the grabable title bar and the rest of the window, which i haven't done yet because the content disguised the need.


Geoff the Medio wrote:
A gradient across the body of the window or near the edges might look interesting.
I'd rather use gradients somewhat sparingly for emphasis. Also because a GUI with lots of gradients will probably have some odd issues when different elements are combined in different ways. Anyway its something that can be added later without otherwise changing the design.


Geoff the Medio wrote:
Please illustrate mouseover feedback for everything that should have it, and how things change when being clicked on.
Of course, but that will probably be the last thing.


Geoff the Medio wrote:
When do widgets - pictures or buttons or droplists - get border outlines that are dark then light or light then dark or just dark when moving outside towards their insides?

* Droplists are somewhat special because they need to be visible when intersecting any other UI element. I need to redo them because i hadn't thought about the occasional need for scrollbars.

* Pictures are probably fine with a single black stroke... I just unthinkingly re-colored the strokes that were on my "galaxy setup" screenshot.

* Buttons of course depend on their status, mouse-state, etc. Text buttons and little wiget-y buttons like the ones to change the number of stars are probably different.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Thu Jan 22, 2009 3:39 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12007
Location: Munich
eleazar wrote:
Geoff the Medio wrote:
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.

That's not really what I meant...

A window rendering template (perhaps it needs a different name...) could be a bit of code that draws a window background with curved corners and a solid fill. It would be fairly easy to set up an option to switch between that bit of code and another bit that draws pointed corners and a blurred version of the stuff behind it as the window fill.

A slightly more complicated, but probably doable option might alter the position and size of widgets or controls in a window, or define how they resize and (using simple rules) how they reposition if the window enclosing them is resized.

But the key distinction here is that these examples just change how the existing window is rendered, or the position of wigits and controls. It is much more complicated to add or remove subwindows or widgets or change the content or behaviour of the contents of a window or control. Doing anything like that is would need to be done by changing the C++ code significantly right now. Doing it with a scripting language or XML file or similar would probably require a script or XML file almost as complicated as the equivalent C++ code, and the associated parser to be written.


Top
 Profile  
 
PostPosted: Thu Jan 22, 2009 4:33 am 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
Geoff the Medio wrote:
....Doing anything like that is would need to be done by changing the C++ code significantly right now. Doing it with a scripting language or XML file or similar would probably require a script or XML file almost as complicated as the equivalent C++ code, and the associated parser to be written.

I guess i missed your point there, i wasn't suggesting that it should be doable in something like XML. Those were just scenarios in which we would want to transform a window.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Thu Jan 22, 2009 10:16 pm 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
Attachment:
shape vocab.jpg
shape vocab.jpg [ 78.06 KiB | Viewed 1718 times ]


OK, here's my idea for a standardization of shapes. Stuff that functions similarly (moveable windows and queue items) also looks similar, and stuff that might otherwise be confused (modal windows vs. normal windows) has a distinct look. Of course players won't generally be conscious of this kind of stuff, but if consistently applied it will help them understand how things work.

I think i've covered all the major "box" elements, but perhaps i've missed some?

EDIT: added ship slots. The 3 different types of techs might also need better shapes, but i'm still kinda hoping for another solution that i haven't yet though of.

All the angles are 45º angles, but don't take the proportion of angle cut off to normal edge too seriously, these are just approximations.

EDIT2: scrollbar angles changed.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Fri Jan 23, 2009 2:08 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12007
Location: Munich
eleazar wrote:
I think i've covered all the major "box" elements, but perhaps i've missed some?

There are slot controls on the design screen detail panel into which the user can drag part controls to define a shipdesign. I'm not sure if these should be treated with standard UI elements, though... In particular, a different appearance for external and internal slot controls would be good, since some parts can only go in one or the other. Other than what parts can be put in them, all slot controls act the same though, so using UI elements that normally indicate movability or resizability probably isn't best.
Attachment:
File comment: Design Detail Panel with SlotControls
Design_Details_Slot_Controls.png
Design_Details_Slot_Controls.png [ 35.55 KiB | Viewed 1845 times ]

Also, I'm not clear on whether "text-bearing Drag-able item does not include dragable icons (tech or production queue item)" includes queue panels or not. If not, what do queue panels look like?

What about panels within another window? In particular, each planet has a separate planet panel on the sidepanel, but the planet panels can't be dragged around independently of the sidepanel, but can be scrolled through within the fixed-position sidepanel. Currently there's no distinction between the background of the planet panel and the sidepanel that contains it, and the top of the planet panel is just indicated by the title bar, and the bottom by where the bottom of the bottom-most container within the planet panel is.

Would there be a way to distinguish the planet panels' extent from the sidepanel that ocntains them? If the planet panel's widgets are black background, then the planet panel would need to be dark gray to be distinct from the widgets, but then the sidepanel would need a third colour to be distinguished from the planet panels.

I don't want to extend the background of the planet panel around the rendered planets, but connecting them to the rendered icon somehow (besides being adjaent) and highlighting both when the planet is selected (eg. on the production screen) would be better than the current method of just encircling the rendered planet with an outline.

(We also have some planet selection indicator art, similar to the system icon selection indicator, that's not used.)

Edit: A possibility would be to not render anything for the sidepanel background where the planet panels are shown, and just have the planet panels be fixed to the right edge of the screen, and scroll through them with the scrollbar. There would be a small transparent gap in the space between adjacent plane panels. Planet panels would then use standard window shape and colours, and there would be no need for another set of colours to indicate the sidepanel's own extent. The top portion of the sidepanel that shows system-specific (not planet-specific) info would be a separate, with a border at the bottom, below which the planet panels would appear.

I'm not sure whether all instances of window-within-window could be avoided in this manner, though./Edit


Top
 Profile  
 
PostPosted: Sat Jan 24, 2009 4:03 am 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
Geoff the Medio wrote:
eleazar wrote:
I think i've covered all the major "box" elements, but perhaps i've missed some?
There are slot controls on the design screen detail panel into which the user can drag part controls to define a shipdesign.

Added to the previous post.


Geoff the Medio wrote:
Also, I'm not clear on whether "text-bearing Drag-able item does not include dragable icons (tech or production queue item)" includes queue panels or not. If not, what do queue panels look like?
Heh, not the most lucid description. I was just trying to say that pure icons, like ship components, don't need to have that shape. It's supposed to include queue panels at least for the production queue.


Geoff the Medio wrote:
What about panels within another window? In particular, each planet has a separate planet panel on the sidepanel, but the planet panels can't be dragged around independently of the sidepanel, but can be scrolled through within the fixed-position sidepanel. Currently there's no distinction between the background of the planet panel and the sidepanel that contains it, and the top of the planet panel is just indicated by the title bar, and the bottom by where the bottom of the bottom-most container within the planet panel is.

There are a lot of things that should change about how the sidepanel looks to make it easier to use, and consistent with the this new scheme. However, there's aren't many horizontal pixels to spare, so it is quite likely that it's design may need to be somewhat special. Generally i would make the scrollable area background the dark grey that's in the text box, and use the lighter (but still dark) background grey for the non-scrolling part.


Geoff the Medio wrote:
Would there be a way to distinguish the planet panels' extent from the sidepanel that contains them? If the planet panel's widgets are black background...

Yes, but it wouldn't be by leaving the black background which is problematic for all the same reasons previously discussed that other things should no longer be black. A bunch of lines, words, and icons floating on black just doesn't give you much room to express the interrelationships.

I've work on mock-ups for the sidepanel too. I just haven't shown them yet because they are pretty messy, and would at this point probably cause more confusion than understanding.


Geoff the Medio wrote:
I don't want to extend the background of the planet panel around the rendered planets, but connecting them to the rendered icon somehow (besides being adjaent) and highlighting both when the planet is selected (eg. on the production screen) would be better than the current method of just encircling the rendered planet with an outline.

I agree about the highlighting. The problem is that extending the background is the most obvious means of accomplishing what you've just described.
Also, I've long been dissatisfied with the way that the sidebar planets can easily get jumbled and obscured by the stuff on the galaxy map. And having bits of intractable map between the planets and the sidepanel proper is just weird. Like this, outdated, but still relevant screenshot:
Attachment:
sidepanelmess.jpg
sidepanelmess.jpg [ 16.26 KiB | Viewed 1801 times ]



Geoff the Medio wrote:
I'm not sure whether all instances of window-within-window could be avoided in this manner, though.

This design works fine for "window-within-window", but would break if we had to do "window-within-window-within-window".

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Sat Jan 24, 2009 7:39 pm 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
Here's a standard window built from scratch, and thus more what i had in mind than the previous windows which were modified screenshots.

Attachment:
standarwindow.jpg
standarwindow.jpg [ 84.08 KiB | Viewed 1764 times ]

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Sat Jan 24, 2009 7:51 pm 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12007
Location: Munich
eleazar wrote:
Here's a standard window built from scratch, and thus more what i had in mind than the previous windows which were modified screenshots.

Did you intentionally swap the corners of the scrollbar that are cut off?

Otherwise, looks pretty good, IMHO.


Top
 Profile  
 
PostPosted: Sun Jan 25, 2009 1:19 pm 
Offline
Graphics
User avatar

Joined: Tue Jul 01, 2003 8:27 pm
Posts: 701
Geoff the Medio wrote:
Otherwise, looks pretty good, IMHO.

I agree. Nice work, Eleazar!

_________________
If I provided any images, code, scripts or other content here, it's released under GPL 2.0 and CC-BY-SA 3.0.


Top
 Profile  
 
PostPosted: Mon Jan 26, 2009 9:41 pm 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
Geoff the Medio wrote:
eleazar wrote:
Here's a standard window built from scratch, and thus more what i had in mind than the previous windows which were modified screenshots.

Did you intentionally swap the corners of the scrollbar that are cut off?
Yeah, somehow it didn't look right the way i had it in the "shape vocabulary". Updated.


In order to be able to mix-n-match all these elements in the most efficient and consistent way possible, i mentally employed something i'm calling "default minimum inset". This controls how far away different elements are from each other, for instance the distance of buttons from each other or the distance of a text-box from the edge of its containing window. It's called "default" because 90% of the time you'll want to use the same minimum inset for an instance of a "button", but occasionally you'll want to give it a special value.

How it works: When two elements are next to each other, you use the largest inset value, unless one of the elements is set to ignore inset. For instance, the scrollbar and resize-tab are theoretically set to ignore other insets, and thus can get jammed up against the right and lower-right (respectively) corners of the box that contains them. However, while buttons have a default minimum (DMI) inset of 2 pix and the entire window has a DMI of 6, the buttons end up 2 pixels away from each other and 6 pixels away from the edge of the window.

Does that make sense? Basically it is supposed to make consistent placement easy, as well as global changes to the interface.


Type styles used:

Standard Title Bar Title = FFFFFF, Bold, 13pt, Shadow
Enabled Button Text = FFFFFF, Book, 12pt
Disabled Button Text = "Enabled Button Text" + 747474

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Tue Jan 27, 2009 1:15 am 
Offline
Programming, Design, Admin
User avatar

Joined: Wed Oct 08, 2003 1:33 am
Posts: 12007
Location: Munich
eleazar wrote:
How it works: When two elements are next to each other, you use the largest inset value, unless one of the elements is set to ignore inset. For instance, the scrollbar and resize-tab are theoretically set to ignore other insets, and thus can get jammed up against the right and lower-right (respectively) corners of the box that contains them. However, while buttons have a default minimum (DMI) inset of 2 pix and the entire window has a DMI of 6, the buttons end up 2 pixels away from each other and 6 pixels away from the edge of the window.

Does that make sense? Basically it is supposed to make consistent placement easy, as well as global changes to the interface.

It makes sense as described, but it's not clear how you want the values to be used.

If you're expecting some automatic layout based on rules in a text file, that might not be realistic. There is a window contents Layout mechanism built into GiGi, but it's rather limited in what it can be used to do and how configurable it is... at least as far as I know. Figuring out a more general-purpose system is probably a lot more work that specifying exactly where everything should go in code...

In particular, a widget put onto a window won't automatically know about the other widgets in the window, and won't know which ones to check if it's too close to, or how they should all rearrange themselves if they are too close or how to deal with conflicting restrictions. There also needs to be a way to tell them collectively that "these ones go at the top in a single row and are about this wide unless there's not enough space and then they can go into two rows, and this one spans the width below them and this one is at the very bottom right and doesn't care if it overlaps other things..." etc.

What I mostly do now in window layout code is specify a top left position based on an EDGE_PAD constant, and then loop through the things I need to place, moving the placement position by placed_thing.Width() + SPACING_PAD or placed_thing.Height() + SPACING_PAD depending on the situation, and jumping down to a new row if I run out of space in the direction I was stepping.

We could standardize the use of EDGE_PAD (between window border and nearest control) and SPACING_PAD (between adjacent controls) values throughout the UI and make it an option in the options screen, but making layout scriptable in the sense of "these ones go at the top and this goes below" is much harder.

That said, a currently glaring omission from the GUI toolbox is a general-purpose media window. There is a multi-line edit (text) control that can display formatted text, like is used for tech descriptions, but there's no way to embed an image in this text. What we need is something that can process HTML-like picture + text layout directives to make much more readable help text, among other uses. (This would also let us use full-sized tech icons on help screens, embedded in the text, rather than smaller ones up on the title bar...)

If we had something like that, hopefully it would be set up in such a way that it could be used to do the same for layout of controls in a window. The use would be more limited, since you could add controls to a window that aren't defined in code already, but you could specify their layout with HTML-like directives...

Quote:
Standard Title Bar Title = FFFFFF, Bold, 13pt, Shadow
Enabled Button Text = FFFFFF, Book, 12pt
Disabled Button Text = "Enabled Button Text" + 747474

What do you mean by Book and + 747474 ?


Top
 Profile  
 
PostPosted: Tue Jan 27, 2009 8:51 pm 
Offline
Graphics Lead Emeritus
User avatar

Joined: Mon Mar 08, 2004 6:17 pm
Posts: 1924
Location: 52°16'N 10°31'E
Geoff the Medio wrote:
What do you mean by Book and + 747474 ?

Not sure about "book" either, but 747474 is most probably a color.


Top
 Profile  
 
PostPosted: Wed Jan 28, 2009 3:23 am 
Offline
Design & Graphics Lead Emeritus
User avatar

Joined: Sat Sep 23, 2006 7:09 pm
Posts: 3858
Location: USA — midwest
pd wrote:
Geoff the Medio wrote:
What do you mean by Book and + 747474 ?

Not sure about "book" either, but 747474 is most probably a color.
Yeah, 747474 is the hexadecimal color... a lightish grey.

"Book" is what some fonts (including dejavu sans) call the "normal" or "standard" form of their font, i.e. not bold or oblique.

_________________
—• Read this First before posting Game Design Ideas!
—• Design Philosophy

—•— My Ideas, Organized —•— Get an Avatar —•— Acronyms —•—


Top
 Profile  
 
PostPosted: Sun Feb 01, 2009 6:33 pm 
Offline
Programming Lead Emeritus
User avatar

Joined: Thu Jun 26, 2003 1:33 pm
Posts: 1092
I'm going to be a stick in the mud, so get ready. How is this thread different from a new member dropping by the Design subforum and suggesting off-starlane travel? Admittedly, the UI could use prettifying, but just as we say that we must accept existing designs in order to maintain forward progress, we should also say that we must accept the existing graphic design (or even lack thereof) in order to progress.

I am specifically saying this because the proposed changes are good, but would require substantial graphics and coding time to accomplish, and we are in desperately short supply of both. I have a huge laundry list of graphics assets I need to keep working on 0.4's combat engine, and I don't have all but few of them. (I also don't have much time to work on FO, but whenever I do get time, the stuff I can work on is a bit limited due to this list being unfinished.) I also have a long-ass list of stuff that needs to happen coding-wise. I feel that redoing the entire look of the game at this point is a little crazy to be honest.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 53 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group