Open TheJJ opened 7 years ago
Wouldn't it be better to start with working out everything that we want to be configured and then create a mockup first? That way we can seperate design prototypes and actual implementation. The problem is that the UI could easily become cluttered and confusing if more stuff is added later on. Creating a mockup should be easy if we use tools like Pencil. Design Process would probably look like this:
Here is an example of a simple mockup made in pencil.
Cool :) I agree, but someday we have to create the ui in practice. Prototyping first is of course great, but we don't have that many config options yet, so we have to adjust the ui once more values end up there. Otherwise we'll prototype forever.
I usually prototype straight in QML... :smile:
we don't have that many config options yet, so we have to adjust the ui once more values end up there.
That's the point though. Creating an interface and then adding features to it as they come is very inefficient and leads to UIs that feel unintuitive and cluttered because you have to "tag on" every option. Or worse, the UI would have to be rewritten after 4-5 additional GUI elements.
Otherwise we'll prototype forever.
Uuuh no ;-) . Designing the interface with a mockup would take 1-2 days max. I created the mockup from my above post in 30 mins. The beauty of mockups is that you can design the interface with every feature you possible want in the options and it's fast and easy to do. A well designed mockup could also last one year until every feature is implemented in the "real" GUI in Qt.
I usually prototype straight in QML... :smile:
Too slow but I know what you mean ^^
I understand you probably don't think of UI design as a priority (may you don't even use a Desktop Enviroment :smile: ) and think it's easier to just add GUI elements on the fly but the Setting UI is what people trying out the project see and have to deal with. I've seen many open source projects do this with the result of horrible UX caused by messy interfaces because they never adapt their "provisional" UI to their new features. That's why I'm lobbying here to do it right the first time ;-)
I meant that it's not so different from the Qt QML Designer (you put buttons on the page).
But I'd probably go with defining positions or layouts by typing them into a qml file and looking at realtime view of the render in qmlscene
tool or in-game (C++ doesn't need to be attached). I also do LaTeX docs like that.
Regardless of whether it's prototyped / developed in Qt directly or a prototyping tool, we should have a short reference doc that enumerates the organization of the options & values (@heinezen's suggested step 1). That should help the developer of the UI enormously, they can just focus on code & functionality. Adding the options now and marking them disabled until they're functional is a better option than adding piecemeal I think ... we have 20 yrs of experience in which options are important, so it shouldn't be too difficult to come up with a beautiful / coherent settings interface
@heinezen I can help with that if you want, we would probably just try to coherently enumerate and combine:
Some things are straightforward, but the UI for managing things like hotkeys, mods, dataset conversion, player profiles, potential Twitch/OBS integration, multiplayer ladder connections etc. can potentially be quite complicated and critical to get right
Re-reading @TheJJ original issue, perhaps the ask is for something to be slapped together now to improve quality of life for development, which also makes sense and sounds useful. Maybe a long-term proper settings planning Issue could be split out from that.
@coffenbacher Ooops, if the graphical config interface is just meant to be created for the developers anyway, my rambling about user experience doesn't really make sense (sorry @TheJJ 😄 ). Nevertheless I still think that planning out the interface entries and layout now can benefit us in the long run.
- all useful settings available up through the latest UP / Voobly / HD
- any settings we see demand for that aren't even in UP but will highly likely be in OpenAge
- any settings for any highly likely OpenAge-specific features
That looks like a great plan. Help is always appreciated! We also had a nice talk at the IRC/Matrix-Chat about settings menus from other games that could be used as an inspiration, e.g. the ones from DoTA 2, EVE, WoW. I'll create a seperate issue and a gist for discussing what menu entries/options we should have.
Yes, we don't have many things to configure right now, but we need an interface.
[ ] Use QtQuick to draw a config UI
[ ] Display settings from the cvar subsystem
[ ] Write back changes done in the ui (cvar system probably doesn't support that yet)
[ ] Needed settings