Opening documents

[mike29]

Hi I would like to know a little bit more about what should be done by this command.

Open command should allow user to select esps, optional master files and select "active file". Then masters files and plugins should be loaded witch active file as last. All changes from this state should be written to edited plugin.

1. Should user care about loading order except last plugin?
2. There should be list of last loaded files that will remember selected files. If all files can be still found dialog shouldn't be showed.

From http://forum.openmw.org/viewtopic.php?f=14&t=138 :
"The problem is the load part. Obviously what the TES-CS does it totally wrong. Its one of the most confusing dialogues the whole CS has to offer. We must do better. I think we should reuse the profile system from the launcher. But that needs more thought and maybe a separate discussion thread too."

Saing "TES-CS does it totally wrong" says everything and nothing. Can anyone elaborate?

[pvdk]

Yes, we plan on re-using the Data Files section of the launcher in a dialogue, it will feature sorting based on dependency and will be a lot more user-friendly than the original TES:CS dialogue. Haven't had the time for it yet though, as I'm a bit occupied with other affairs currently.

[Zini]

Saing "TES-CS does it totally wrong" says everything and nothing. Can anyone elaborate?

We are talking about the most unintuitive GUI design ever. The core problem here is the way the active file is selected. You may know that I have been doing MW modding in a large team for a long time. We often got people, that had no experience with the TES-CS. The first stopping block they encounter is usually this dialogue, because they can not figure out how to select a file for editing.
I must admit that I ran into the same problem, when I used the CS first. I think it took me bloody 15 minutes to figure it out and that mostly consisted of digging through the documentation.
There is simply no way anything of this horrible UI design can be salvaged. In fact it should be burned and then its originator with it.

[hircine]

Saing "TES-CS does it totally wrong" says everything and nothing. Can anyone elaborate?

We are talking about the most unintuitive GUI design ever. The core problem here is the way the active file is selected. You may know that I have been doing MW modding in a large team for a long time. We often got people, that had no experience with the TES-CS. The first stopping block they encounter is usually this dialogue, because they can not figure out how to select a file for editing.
I must admit that I ran into the same problem, when I used the CS first. I think it took me bloody 15 minutes to figure it out and that mostly consisted of digging through the documentation.
There is simply no way anything of this horrible UI design can be salvaged. In fact it should be burned and then its originator with it.

[Greendogo]

I actually like that menu a lot, because I'm used to it, but I can understand a newbie's confusion.

Perhaps if you created a second empty list box below the main list box and then moved the selected plugins/masters to it, and have the Active plugin become highlighted in a color or bolded.

[mike29]

Perhaps if you created a second empty list box below the main list box and then moved the selected plugins/masters to it, and have the Active plugin become highlighted in a color or bolded.

3rd list box just for selecting one element could be wasteful. I was thinking about editable combo box (or not editable text box) and right click menu on plugins list box and button like in original window. I'll have time today after work to look into this... if I won't start playing morrowind.

[Zini]

Actually, the situation is rather simple. You can not edit a file unless it is the last in the list. I am not entirely sure, how that was handled in the original CS, but doing anything else would increase the complexity of the editor by a huge amount.

Therefore it should be enough to somehow highlight the edited file (either within the ESX selection UI elements or as a separate text field).


The real problem here is how to handle loading ESX files when you do not want to edit anything at this point. What the CS did was basically creating a new document and let you allow to decide on a name when you save. This is consistent with what other editors do. But it might not be the right solution here, because the CS isn't like other editors.


I am somewhat inclined to offer to different open file functions and separate new file functions:

1. Open a stack of ESX files with the last one set up for editing.

2. Open a stack of ESX files for viewing only (maybe).

3. Open a stack of ESX files and add a new ESP file for editing on top of that.

4. Create a new ESM file and open that for editing.

These would all be different dialogues (still re-using UI elements where possible), that are invoked via separate menu items. And for startup instead of throwing the user straight into a load file dialogue, we could offer a small dialogue with a button for each of these options.


Just an idea. Probably needs further refinement.

[pvdk]

I was hoping we could have all of that functionality in one dialog. Please consider the following mockups:

Spoiler: Show

The dialog as it first appears to the user:


Creating a new document which is dependant on Morrowind.esm and CleanAreaEffectArrows.esp:


Opening CleanAreaEffectArrows for editing:

My proposal: when the user clicks on an item in the list, the Name: combobox will hold the name of the selected file and the Open button will be enabled. As soon as the user clears the combobox and enters a new plugin name the New button will be enabled. Creating an ESM instead is as easy as appending .esm to the filename, .esp is the default when no extension is supplied by the user. The sorting is based on dependency (so disregard the obvious alphabetical sorting in the mockups) and plugins that don't have their dependencies met are disabled, see KRS_VM_Sickle.esp. Hovering over the the items in the list view will give extended information and there will be a custom context menu for right-clicks. Also, there will be a "Details" viewmode that lets the user add/remove various columns holding extra information on the files.

EDIT:

2. Open a stack of ESX files for viewing only (maybe).

We could add a drop-down menu to the Open button that adds an "Open read-only" option, it looks like this.

[mike29]

I was thinking about same thing. Only difference between open and new is name of edited file. Some other thoughts:

1. Open and New buttons could be merged and change caption based on name field.
2. Plugins don't have to be grayed, they can force master file selection.
3. There can be one dialog but it doesn't have to allow creation and edit at the same time.

Should user care about loading order of master files and plugins except of last plugin?

[Zini]

Not too keen on this approach. Open File and New File are completely different operations. Mixing them up in the same window is pointless IMHO. The user doesn't go into this dialogue and then considers, do I want to edit a file or do I start a new project today?

We could add a drop-down menu to the Open button that adds an "Open read-only" option

A clear no to that. Having a 2-click input path for this feature means nobody will use it. You can as easily open the file regularly and then not edit it. This feature provides only a limited improvement to usability to start with. Making it anything but immediately accessible will make it useless. Actually, I am not 100% if we need it at all.

Should user care about loading order of master files and plugins except of last plugin?

Absolutely. Load order can be important in some situations.

btw. we also need to find a way to integrate the profile system.