Object editing widgets

Involved development of the OpenMW construction set.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Object editing widgets

Post by akortunov »

I started to work with OpenMW-CS and found out that autogenerated widgets are extremely annoying.
Take and NPC editong widget as example.
Here is a screenshot how it looks in Morrowind:
Screenshot_20181007_192421.png
Since there is a lot of info here, this widget uses custom layout with tabs and buttons.
This widget is a separate window, so you can open several of them and layout manually (to compare NPCs, for example).

Here is an example about how it looks in OpenMW-CS:
Screenshot_20181007_192329.png
This widget is just an autogenerated list of buttons and input fields. To view the whole widget, I'd need to layout my FullHD display vertically.
Two opened widgets will occupy almost the whole screen, what is annoying since we place them as tiles in the main window.

Is there a reason why we use such autogenerated widgets instead if common widgets with layout, created in Qt Designer, for example?


The second thing - is an Objects table. Are you sure that that placing objects of different types in a single table is a good idea? Since objects of different types have only one common field - Id - this table is extremely monstruous (near 90 columns, and most of cells are just empty), and user needs to mess with filters.
Why to do not use per-type tables (as for spells and bodyparts, for example)?
There are at least two possibilities here:
1. Use a single widget and use tabs to switch between tables.
2. Use completely different widgets and add a submenu to World->Objects to open such tables.


Also we have some tables which contain only one column. Is there any purpose for them?
An example if such thing is a Textures table. In theory, to make this table useful we can add some additional info about such textures - location, resolution, file format, etc.
The same thing for another tables under Assets section.


Any suggestions?
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Object editing widgets

Post by Zini »

Two opened widgets will occupy almost the whole screen, what is annoying since we place them as tiles in the main window.
There is an issue about placement of newly opened subviews on the tracker (we call them subviews not widgets). So far we failed to do anything about it because of Qt limitations.
Is there a reason why we use such autogenerated widgets instead if common widgets with layout, created in Qt Designer, for example?
Yes. There are is just too many record types with too many fields. Also, generating the subviews procedurally will ensure a level of consistency that can't be guaranteed when doing it by hand. However the code used in OpenMW-CS could use some improvements (more intelligent placement and sizing).

I consider this method superior to manual layout for the reasons listed above. Personally I find the OpenMW-CS version more usable than the TES-CS version (less cluttered), but that will vary from user to user. And that is another advantage of the automatic approach. If there is interested we can implement configurable and even multiple layout algorithms that the user can choose from (that is a post-1.0 feature though).

Object table: There is a lot of overlap between object types. Plenty of columns are not specific to a single type. The column filters will take care of the table size problem (we need them anyway, not just for objects). The decision for having a single object table is mostly the result of very bad user experience with separate tables on my end while I was working on the Redemption project. I would have killed for a unified table back then, so that is what I implemented in OpenMW-CS.
But representing all object types in a single table will also have advantages for editor scripts working with the tables later on (post-1.0) and future batch editing functions.

Table with one column: Tables represent records, columns represent record fields. We do not get to choose these. They are defined by the data format. Single column tables are useful for things like checking, if a record has been modified, deleting it or reverting it.
terabyte25
Posts: 55
Joined: 26 Jul 2018, 12:58

Re: Object editing widgets

Post by terabyte25 »

There's no point of having the "buys x" toggles all on the same page, you could just compress them all into one submenu, instead of them cluttering the parent menu.
terabyte25
Posts: 55
Joined: 26 Jul 2018, 12:58

Re: Object editing widgets

Post by terabyte25 »

You could also compress the services menu too.
User avatar
AnyOldName3
Posts: 2668
Joined: 26 Nov 2015, 03:25

Re: Object editing widgets

Post by AnyOldName3 »

I was going to say that the linked subview was crying out for the checkboxes to be in columns, but then I saw that the spinners and textboxes at the top are also almost entirely wasted space, too, so could be made narrower, which would take away the space for columns. It's undeniably a bad layout - there's more wasted space than useful, and that causes all kinds of issues.

The original version is also bad because it's very dense and was obviously from before the days of 1080p-as-standard, but it's also a lot more concise, which up to a point is a good thing. I'd definitely say it's better than what we have now, but only because that's such a low bar.

It's probably prudent to investigate how later Bethsoft games have things set out - if they've bothered changing a layout, it's probably because the original was a pain, and even more importantly, if they changed it back, it means that they've actually tried using both designs, and determined that one was definitely the better one.
User avatar
Ravenwing
Posts: 335
Joined: 02 Jan 2016, 02:51

Re: Object editing widgets

Post by Ravenwing »

Zini wrote: 07 Oct 2018, 18:23 There are is just too many record types with too many fields. Also, generating the subviews procedurally will ensure a level of consistency that can't be guaranteed when doing it by hand. However the code used in OpenMW-CS could use some improvements (more intelligent placement and sizing).

I consider this method superior to manual layout for the reasons listed above. Personally I find the OpenMW-CS version more usable than the TES-CS version (less cluttered), but that will vary from user to user. And that is another advantage of the automatic approach. If there is interested we can implement configurable and even multiple layout algorithms that the user can choose from (that is a post-1.0 feature though).
I don't necessarily agree with this philosophy. There is a reason why graphics designers and artists are so important in every field. That being said if an algorithmic method exists that produces good, not just acceptable results, that would obviously be ideal. Allowing configurable algorithms is even better. I'm having a hard time imagining an algorithm placing all aspects of all subviews appropriately. If this is the case I think we should consider handcrafted layouts for some of the most heavily used subviews with all others using an "acceptable" algorithmic fallback. Until that time however, I think this is a great idea that I'm very interested to see the results of, because that second screenshot is tragic.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Object editing widgets

Post by akortunov »

For now even trivial operations require a good understanding about how these auto-generated tables work, because this feature is extremely unfriendly for new developers, even if they have knowledge about how Qt works.
Also if there is a need to do something which this autogeneration framework does not support, developer needs a VERY good understanding about how it works.

As a result - generated UI is unhandy and no one knows how to improve it.

Example of such trivial action - an input field validation. For example, AI settings have value from 0 to 100, spell duration can not be negative, skills and attributes limited by 255 value, IDs length is capped by 31 characters, etc.
Last edited by akortunov on 08 Oct 2018, 07:31, edited 1 time in total.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Object editing widgets

Post by Zini »

There is a reason why graphics designers and artists are so important in every field
Well, we have to agree to disagree here when it comes to user interfaces. In other fields I agree with this statement.
For now even trivial operations require a good understanding about how these auto-generated tables work, because this feature is extremely unfriendly for new developers, even if they have knowledge about how Qt works.
What operations would there be to do? Other then adding a new field? Which is in fact trivial (it happens automatically).
Also if there is a need to do something which this autogeneration framework does not support, developer needs a VERY good understanding about how it works.
This is true, but I don't see how that would be an argument against this approach.
User avatar
akortunov
Posts: 899
Joined: 13 Mar 2017, 13:49
Location: Samara, Russian Federation

Re: Object editing widgets

Post by akortunov »

Zini wrote: 08 Oct 2018, 07:24 What operations would there be to do? Other then adding a new field? Which is in fact trivial (it happens automatically).
Limit input field range, use tabs to do not waste space, or add a custom logic (for example, autocalculate spell cost when user checks Auto Calc checkbox, or add an encumberance caclulation to NPC's inventory view).
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Object editing widgets

Post by Zini »

Limit input field range
That needs to be done through the system, because the same limits would apply to the table.
use tabs to do not waste space
Really? Our UI is complex enough. IMO adding a tab interface inside of it is a really bad idea. And its not as if space would be a limited resources.
add a custom logic (for example, autocalculate spell cost when user checks Auto Calc checkbox, or add an encumberance caclulation in NPC's inventory view).
Okay, that makes sense. However again, the same would apply to the table. If we don't use the automatic approach we would have to implement everything twice.
Post Reply