Help with the UI Design

[leeor_net]

Hey all!

As everybody knows work on OutpostHD has been somewhat slow. I'm realizing lately while working on several other projects that probably the biggest road block for me is in dealing with UI design. Frankly, I'm really bad at it and my UI's tend to reflect the minimalistic nature that I take when I slap them together.

Beyond that, actually programming them is tedious and boring. It can be painful to develop them and it takes a lot of time so getting it right the first time is important. It's so tedious and so boring that I end up just kinda wasting time and procrastinating and then things slow down and ... yeah.

That stated, I could really use some feedback, comments, whatever with the design. I've been using an online wireframing tool called draw.io to develop flow charts for logic, etc. but it's just as useful for UI wireframing.

So to begin with, let's start with the Factory Production UI!

Can comment here or in that thread.

Also, any other suggestions about the UI can be talked about here.

[Hooman]

Beyond that, actually programming them is tedious and boring. It can be painful to develop them and it takes a lot of time so getting it right the first time is important. It's so tedious and so boring that I end up just kinda wasting time and procrastinating and then things slow down and ... yeah.

This right here. Attack the meta problem rather than get bogged down in the UI. Why is it tedious and boring? Why does it take a lot of time? Is there a way to automate UI creation? Is there a way to write code once, and then just instantiate different UIs by changing a few parameters? Are you manually assigning coordinates? Maybe you can use a layout manager that places things according to rules and auto calculates positions.

[leeor_net]

This right here. Attack the meta problem rather than get bogged down in the UI. Why is it tedious and boring? Why does it take a lot of time?

As with any UI programming I've ever done without a visual layout editor, it's because you have to do a lot to hook up events, develop the layout, etc. Basically, it's all manually done. I started putting together a layout editor for NAS2D+GUI/OutpostHD and stopped when I realized it wasn't the trivial task I'd imagined it to be. If I'd exported it to C++, I'd still have to do some manual grunt work because the C++ would basically just be a layout and stub functions to handle events like clicks, mouse downs, etc. If I exported to something like XML (easier in a lot of ways), I'd have to develop a layout engine that could then read in those XML or whatever files and set up the layout. But then I'd _still_ need to manually add the event handling code and I'm not sure what would be the most effective way to handle that with a layout engine.

As for scaling UI's, that makes a lot of sense -- and it's something we talked a bit about before. I'm in favor of that and tend to use relative coordinates with those types of UI's (I have several projects that use these types of layouts) but some elements such as input windows and the basic UI design for OutpostHD don't need too much in that regard. The two scaling elements are the reseource HUD along the top and the construction UI along the bottom. The rest of the interface is much more similar to a typical desktop application... which is where I need help getting the layout right so I don't have to go dealing with it again.

Another reason I'm hesitating when it comes to building a layout engine is ... well... it takes time. And I don't know if it's beyond the scope of this project or if I should do it for this project anyway and incorporate it into NAS2D+GUI along with the basic visual layout editor... it's one of those cases of "This is kind of a bigger project than I realized it would be"... sort of a project within a project.

Finally, I've been hesitating with the layout engine because I wanted to build OutpostHD kinda fast without it necessarily being a testbed for additional code. Basically, I wanted to get things working and worry about the finer points later.

Since I haven't gotten a whole lot done in awhile maybe I should just look at building the layout engine and get over myself. Besides, if I go for an XML type deal I can edit the layout later without having to recompile the game and can even include other non-developers to help me build the layouts without ever having to touch a line of code.


Welp, this turned into another novel so I'll leave it at this:

I appreciate wireframing and could use help with that. And, I think I should probably continue work on an actual layout engine. Would likely make UI development a lot easier for this game and any others that I might develop.

[Hooman]

Hooking up events is generally a pain. Each event is generally going to be unique to the app, so there won't be a whole lot of automatic support there. Maybe a little bit for cancelling or closing windows, or some basic text-box or number-box support.

As for the layout manager, you can go beyond just relative pixel values. The layout manager itself can manage all pixel values, possibly with optional settings for margins and such. You should only need to add controls to a layout manager, and assume they will be placed well. For instance, you might have a VerticalLayoutManager, which you .Add a bunch of Button objects to (no coordinates). The layout manager will know to stack them vertically, and space them with some margin between them, and some padding away from the borders of the layout manager area. The UI can then be a hierarchy of layout managers that stack and size everything automatically, and might even provide scroll support where needed.

To use OP2 as an example, you could use a horizontal layout with the map view on the left, and controls on the right. The control pane might be a nested vertical layout which includes a mini map, a tab control for various reports, and a detail pane for context specific information. When multiple units are selected, the detail pane might contain a nested grid layout with 3 columns for unit icons. If a game menu is selected, the detail pane might contain a nested vertical layout for game options, such as "save game", "load game", "quit", etc.

At no point should you need to specify coordinates for the UI controls. Maybe specify size at the bottom level, and propagate that up. Avoid specifying location. This should (hopefully) get rid of the need for a graphical UI creation tool.

[leeor_net]

That sounds a bit overkill for something like a basic dialog box. In a case like that where it only has say, two buttons, I would just position one button at the bottom corner of the box and position the other button relative to the first.

I'm going off the way GUI's are built using Visual Studio (regardless of language). They all work basically the same way and it seems fairly standard. But I suppose innovation doesn't go by the standard way of doing things.

[Hooman]

I once used a GUI builder for Java. You didn't drag and place buttons exactly. Instead, you grouped objects into hierarchies, and set properties for how things would align.

Something like: create window, it has a default layout manager, add two buttons, change default layout between vertical or horizontal if needed. Done. Now go add events to the listeners.


The code backing it all was quite simple too. You could create your own layout managers if you wanted.


Edit: I don't remember quite what it was I used all those years ago, but I did just find an example of Layouts in Java. The BoxLayout from that page, nested in a hierarchy, is basically what I was thinking of. They have a few other interesting examples there, though I don't think you need the extra complexity.