ESX selector and stuff

[pvdk]

Whelp, if that works on all platforms (and I reckon it does) I agree we can get rid of it. I didn't like it in the CS file dialog either, too cluttered indeed.

[graffy]

Ok, I can sort of visualize the new ESX selector dialog as we've described...

Based on the description in item #4 of Zini's early post, I see some natural categories for the file structure that might help a bit:

1. The single combo box drop down means to make the base game file an exclusive choice. I previously indicated I liked the term "Content Library". I feel it would be a well-suited term to be used here. That is, the combo box allows the user to select one "Content Library" or "Game Library" from which they wish to work (which is really just an omwgame file).

2. Once the user choses their library to work from, they can choose a "Content Profile". I realize that "profile" seems like an ambiguous term, but if we specifically refer to it as a "Content Profile" it should be fine. Call it for what it is, I say, just be a bit more explicit.

The only reason I'm revisiting this is because it seems to directly play into the UI layout. Zini's usability concern w.r.t. the dual selection scheme is mitigated using a single-selcet combo box, but makes it even clearer (in my mind) that one is choosing a "library" providing a particular type or flavor of core content before they are really working with individual profiles / lists / whatever.

Also, I presume the profiles / lists are really just the omwaddon files? That is, are we storing the addon dependency tree in a separate file or is that recursed in real time as needed?

[Zini]

That is, the combo box allows the user to select one "Content Library" or "Game Library" from which they wish to work (which is really just an omwgame file).

I don't like the term library in this context. Sounds misleading. What we are actually selecting here is the game. This results in filtering a group of addons that you might call library, but the primary action here is still picking a game, not setting a library filter.

2. Once the user choses their library to work from, they can choose a "Content Profile". I realize that "profile" seems like an ambiguous term, but if we specifically refer to it as a "Content Profile" it should be fine. Call it for what it is, I say, just be a bit more explicit

I think we ended up with content list. More explicit. Profile might still be misinterpreted, but the term list is instantly clear to everyone. It even communicates that we have a linear sequence of content with a specific order, which is exactly what we got.

Zini's usability concern w.r.t. the dual selection scheme is mitigated using a single-selcet combo box

That is true for the game combobox, but not for the addon list. Here we still have to come up with something.

Also, I presume the profiles / lists are really just the omwaddon files? That is, are we storing the addon dependency tree in a separate file or is that recursed in real time as needed?

No separate files. Build a dependency tree on opening the window.

[pvdk]

I think we ended up with content list. More explicit. Profile might still be misinterpreted, but the term list is instantly clear to everyone. It even communicates that we have a linear sequence of content with a specific order, which is exactly what we got.

That reminds me, would it be a good idea to call it contentlist or content-list so it forms a single word? I like it because it's similar to playlist.

[Zini]

Looks weird to me, but I leave judgment to native English speakers here.

[graffy]

Regarding the content list title, I'd leave it as-is. I get the playlist reference, but that's a commonly understood term, whereas in this case, "Contentlist" looks as though it were an afterthought a programmer threw in there. Hyphenating is more for phrases that are grammatically incorrect, but have a commonly understood meaning (jack-in-th-box, as-is, know-it-all, etc.) Of course, I'm citing U.S. grammar here, so take it for what it is...

Regarding multi-selecting the addons, I can't quite lose the idea that having the reference tree displayed when an addon is selected would be a good idea. The value of it, at very least, is to identify any issues like circular references, redundancies, missing references, or reference conflicts. But maybe those aren't real issues? Even if they were, I suppose alll of that could be managed internally with errors being thrown as-needed. Nevertheless, a tree view showing how all of the selected references fit together (as one selects or deselects addons) as well as identifying potential conflicts or problems seems like it could be a good usability value-add for the user... Anyway, I'm not proposing building that now (definitely a 1.0 type of improvement), but just revisitng the question of whether or not to leave space for that in the UI and/or code.

Otherwise, I don't think I understand what, specifically, is the problem with the addon multi-select as it is. It seems fairly straight-forward to me...

[Zini]

About the tree: There is no tree (from the user perspective and OpenMW's perspective). We have a single ordered linear list. The tree is only used to match addons to games and (later) to build suggestions for ordering. We can look into that again, if we get to implement additional tools for sorting content lists, but I am skeptical about the usefulness of presenting the tree to the user.


About multi-select (assuming we are talking about the same thing here): There are two selection mechanisms.

1. You select a row, which then gets highlighted.
2. You select the checkbox at the start of the row.

For a user not aware of this difference it may look like as if #1 actives the item (adds it to the list of content files to be loaded). And even for a user aware of this difference, it might be confusing, if that user does not pay enough attention. I have fallen for this myself. Its definitely not an intuitive interface.

[pvdk]

For a user not aware of this difference it may look like as if #1 actives the item (adds it to the list of content files to be loaded). And even for a user aware of this difference, it might be confusing, if that user does not pay enough attention. I have fallen for this myself. Its definitely not an intuitive interface.

I would like to hear some more end-users having problems with this before changing it. I'm with graffy, I too believe our current method of checking/unchecking items is straightforward and certainly the best solution. I'm glad we got rid of the selection method we had before, because that took some serious hackery to get right and I didn't like the way it worked. So method 1 is counter-intuitive to me. But maybe you're right and ordinary users (from different platforms) do find it more convenient, but that would require some real-world proof and maybe some usability testing before I'm convinced.

Regarding the content list title, I'd leave it as-is. I get the playlist reference, but that's a commonly understood term, whereas in this case, "Contentlist" looks as though it were an afterthought a programmer threw in there. Hyphenating is more for phrases that are grammatically incorrect, but have a commonly understood meaning (jack-in-th-box, as-is, know-it-all, etc.) Of course, I'm citing U.S. grammar here, so take it for what it is...

Good, let's stay with Content List then, my suggestion was too forced and it doesn't look right when not hyphenated.

[graffy]

I guess I had never thought about a selected row vs a checked box. I had only considered the checked box to be definitive, so it was not confusing to me in that regard. But I've done a llittle bit of UI coding, so maybe I just kinda knew better... ?

So far as highlighting is concerned, I propose the following solutions:

1. Indicate selection only by highlighting the row
2. Indicate selection only by checking the box
3. Indocate selection by both checking the box and highlighting the row simultaneously.

In all cases, dual selection is eliminated and either mechanism effectively communicates the same message to the user.

[Tarius]

I like check boxes.