UI Design Help?

13567

Comments

  • Dr_JT said:

    One of the things I like about EE is the clean look of the widgets. I've changed colors of them quite easily for a different look but that's about it. Please don't get too flashy with the displays. If you look at some of the other games the interface is all flashy and glowing making it look very game like. I guess I like the cleaner uncluttered look like Trek LCARS more than the fancy eye candy of Artemis.

    LCARS is the worst example of a minimalist, intuitive interface, but I take your meaning, there's certainly no desire from myself to overdo anything, I like to think we can strive for straddling that fine line between elegant and minimalist.

    Since the glows can't really be applied to the text, I'll probably drop the glows entirely in the next round of revisions.
  • @Interesting John Did you draw this in photoshop? Just a file with the layers in it would allow me to cut out the proper parts quite quickly. I can also just finish up the code with place-holder art and let you fill in the final images where needed.
    I think I will do the background gradient as 2 layers of images. One for the gradient, one for the crosses. Gives me some flexibility.

    @Dr_JT Oh yes, clean look is important. I think in Artemis 2.0 the graphics look "out of place". I also want to ensure that it is still easy to mod the artwork to your liking.
  • Tried to use the star template provided by Interesting John, without modifications :
    http://i.imgur.com/FnEsTOE.jpg

    One problem is that you can see very clearly the skybox partitioning while moving.
  • Fouindor said:

    Tried to use the star template provided by Interesting John, without modifications :
    http://i.imgur.com/FnEsTOE.jpg

    One problem is that you can see very clearly the skybox partitioning while moving.

    Would it help if it was converted into a seamless image?
  • And seams-aside, that actually looks pretty awesome!
  • daid said:

    @Interesting John Did you draw this in photoshop? Just a file with the layers in it would allow me to cut out the proper parts quite quickly. I can also just finish up the code with place-holder art and let you fill in the final images where needed.
    I think I will do the background gradient as 2 layers of images. One for the gradient, one for the crosses. Gives me some flexibility.

    @Dr_JT Oh yes, clean look is important. I think in Artemis 2.0 the graphics look "out of place". I also want to ensure that it is still easy to mod the artwork to your liking.

    I've got a photoshop file for each station that I've done so far.

    Let me clean up the design a bit and remove the glows from items and then I'll send you a copy.
  • edited March 2016
    I agree, it looks good, I'd be thus interested in a seamless picture. It makes the space more populated, while staying quite sober (I really hated the very bright Artemis space).


    Thanks for all of your work so far :)
  • Fouindor said:

    I agree, it looks good, I'd be thus interested in a seamless picture. It makes the space more populated, while staying quite sober (I really hated the very bright Artemis space).


    Thanks for all of your work so far :)

    I'm glad that I'm able to help :)
  • Let me clean up the design a bit and remove the glows from items and then I'll send you a copy.
    No rush, got enough to do with the mockups I already have :-)
    I really hated the very bright Artemis space
    You're not the only one :)
    The current starfield I created is very easy to have seamless. So a better picture might require more work, or even more pictures.
  • If you can keep the colors away from the edges, that should help hide the partitioning.
  • Updates!
    image
    image
    image
    image
    image

    Yes, still needs tons of work. But helms is starting to look like something.
  • Looking good! I like the "notches" for Warp & Engineering.
  • It's definitely coming together, will be much better with alpha transparency.
  • Now that's some serious GUI :)
  • One goal is to create identifiable shapes that a crewman can recognize at a glance as being information (square) or interactive (rounded).
    This does not match up with the "selector" buttons? (like the frequency selector)
  • I always wanted the selector buttons to be sliders. Sometimes you don't want to tap/click 8 times to get to the frequency you want. I'm guessing hover mouse - scroll wheel isn't a feasible option either.
  • edited March 2016
    LCARS is the worst example of a minimalist, intuitive interface, but I take your meaning, there's certainly no desire from myself to overdo anything, I like to think we can strive for straddling that fine line between elegant and minimalist.

    Since the glows can't really be applied to the text, I'll probably drop the glows entirely in the next round of revisions.

    I don't really like the LCARS as controls. I only like the sharper graphics. A little glow isn't bad. I did one edit where I put a glow on the button border image. I was actually trying for the same look as this site. The problem is that right now the text is dark so it really requires a lighter button background and a darker border. Maybe a text color could be set in the options.ini file? Another addition that would be nice would be a "selected" background color. Right now it's sometimes hard, at least on some of my screens to decern a selected button.

  • daid said:

    One goal is to create identifiable shapes that a crewman can recognize at a glance as being information (square) or interactive (rounded).
    This does not match up with the "selector" buttons? (like the frequency selector)

    To me, the selector (tap to cycle in a direction) is a different kind of widget than a slider (press and hold to move) or a button (tap to toggle).

    Should it be rendered more like a button?
  • You're the designer :-) I'm just the idiot programmer. I just apply logic.

    So when you say "interactionable stuff should be round" and I see angled arrow buttons. That does not 100% match ;-)

    @John Bono the selector design is done to minimize screen space. And also because of implementation limits of the first UI implementation (We're already on the 2nd UI implementation :) )
    I'm not a fan of sliders selecting discreet values (warp is an exception here). But maybe a dropdown menu could replace most of these. Would require 2 clicks for any selection, would show all options, and would still work on touch-screens.

    @Dr_JT I'll most likely make a whole lot more colors configurable with a config file during this new UI design implementation. As right now the UI uses a whole lot of black white and grey. But the new design uses more subtle colors.
  • Dr_JT said:

    Another addition that would be nice would be a "selected" background color. Right now it's sometimes hard, at least on some of my screens to decern a selected button.

    This is really good point. For some people just changing the color or opacity is not enough to see the difference between two button states. Distinguish between active and non-active states should be very clear.

    image
    http://codepen.io/anon/pen/RaoVQO?editors=1100

  • edited March 2016
    image
    Just playing around with things now.
  • edited March 2016
    One thing that could be improved is enabling scroll wheel in places where scroll bar is visible. Could this be possible? I assume this would be welcomed change since many don't have touch screen to play this game.

    AFAIK SFML is used in this project?
    http://www.sfml-dev.org/documentation/2.0/structsf_1_1Event_1_1MouseWheelEvent.php

    An so far this is looking very good. Nice work guys.
  • I'm really interested to see how the new GUI will look on tablets. Maybe the all-caps letters will help legibility in smaller tablets.
  • edited March 2016
    @jozan mouse wheel support is currently a bit lacking behind. And is handled on some stations, but globally. For example on science, relay and GM you can zoom with the mouse wheel. But those are the only mouse wheel implementations right now. Would make sense to have mouse wheels work on listboxes as well.

    @Fouindor as soon as I have something that starts to work, I'll do a test build for everyone to try. Currently the list of issues will be too long for me to track properly :-)


    To be clear, I'm splitting out the GUI into a lot more images now. Even if the image is the same. Example, the key-value displays look the same as the progress bar. However, they are separate images now.

    I also started to specify colors in a config file. Which currently looks like this:
    background = #1F252D
    radar_outline = #EDF5FF
    
    button = #FFFFFF
    button.disabled = #808080
    
    button_text = #EDF5FF
    button_text.hover = #808080
    button_text.active = #120A00
    button_text.disabled = #404040
    
  • It's a damn shame we can't use HTML/CSS to generate the UI, because then I could probably take some overhead off of your plate and it would be a lot more customizable.

    I like the idea of a dropdown widget for certain items, that's something I'll have to figure out a design for.

    And I'm in agreement with the "Obvious states for buttons", so that's something I'll also try and work on.
  • daid said:


    @John Bono the selector design is done to minimize screen space. And also because of implementation limits of the first UI implementation (We're already on the 2nd UI implementation :) )
    I'm not a fan of sliders selecting discreet values (warp is an exception here). But maybe a dropdown menu could replace most of these. Would require 2 clicks for any selection, would show all options, and would still work on touch-screens.

    A Drop-down, or even a pop-up to maximize functionality on smaller screens. It's not like it would annoy weapons or engineering to have something take up a quarter of the screen if they clicked on it; and it would make it very obvious to first-time players what that button they just clicked does.
  • Here's an updated version of that starfield, it should be seamless on all edges. Would it help to rotate it? Should it be square instead of rectangular?

    image
  • Thanks. But the outline is still visible : http://i.imgur.com/FyzVkhh.jpg

    Looking in the code (https://github.com/daid/EmptyEpsilon/blob/002a4de8c2f2ede3d1a9e146a92b01b5cf24d73f/src/screenComponents/viewport3d.cpp) it seems that EE takes only the first 1024*1024 pixels of the image. So we would need an image to this format. Really sorry I didn't spotted that earlier :(
  • Ah, that helps, I'll resize, crop and then fix the edges again.
  • I can fix that code. I also have no idea how the box is organized, could be that the image is incorrectly mapped on some sides causing "reflections"

    I've just pushed all my changes for the new UI. I cannot run a build for a few days, so maybe the unofficial daily build from Kwadroke will work.

    It's far from finished. But it is a start. All the art is placeholder. Icons are missing. And some pieces are still using old graphics. Most noticeably are the overheating/low power overlays. And a few white boxes here and there.
Sign In or Register to comment.