UI Rework

[erri120]

Checklist

• [ ] Manager View
• [ ] Installation View:
  • [ ] Basic
  • [ ] Advanced
• [ ] Compilation View
• [ ] Color Schema

Current Interface

Main Screen

Installing a Modlist

Creating a Modlist

The Problems

The Main Screen is fine, it serves it purpose and only has some scaling problems which our entire UI has. The biggest problem come from the Installation and Compilation Views, namely: extendability.

We currently have multiple open issues that are about adding more stuff to our UI, like #1188, #1033, #919, #681 or #484. The interface we have at the moment was made with a specific layout in mind and does not make it easy to add new elements, reason being that we designated a specific area of our interface to be the holding place of our UI elements and exhausted its entire capacity. Just take a look at the installation view:

This is pact and while it does work at the moment, we can't easily add new elements to it without having to rearrange the entire thing. The compilation view is even worse because that is the place where we often add new elements.

Solutions

Time for some solutions. Due to the size of this endeavor we can deal with multiple UI related issues at once, starting with #1188.

Modlist Launcher/Manager (#1188)

I think users who only install 1 modlist and never update it are in the minority and most users update the modlist they installed at least once. Of course we also have the active users who have like every SE modlist installed or chads with every NSFW modlist on their hard-drives. Anyway, point is that Wabbajack was made for downloading, installing and updating 1 modlist. It is very portable and does work fine if you only have one modlist.

Design

The design of a Manager type application works best at high screen sizes, preferably maximized. The raw layout goes as following:

We ofc have our Titlebar and underneath that a Toolbar which could hold buttons like "Add", "Remove", "Settings", "GitHub" and others. The rest of the view is divided into left and right pane. The left pane will contain the list of modlists and the right pane will show information and actions for the selected modlist.

Left Pane

Left Pane should be a ListView containing all Modlists we are managing. Each Modlist element should contain at least the title but having the status and maybe the game right next to it would definitely not hurt either.

Right Pane

Right Pane could look something like this. We have the Modlist image (if available) at the top consuming the entire width of the pane (-padding). Below that is the title, author, installed version and installation date as well as action buttons for Updating (if available), Opening the Website, Opening the Installation Folder and Running MO2 (or shortcut, #919).

This is just the complete basics as we can probably add more information like Game, Install Size, indicator for having an update available and more.

Prototype

Everything then comes together in this poorly made Prototype:

Implementation

The ModlistManagerVM should have an IEnumerable for all Modlists the user added and a reactive object for the currently selected Modlist. We should create a new class because Wabbajack.Lib.ModList is not really what we want here.

The new class should have the following properties:

• State: this should be an enum containing the state of the Modlist. Possible values: Ready (Modlist downloaded+installed+ready to play), NeedsConfiguration (when the Modlist is installed but ENB/SKSE related files need to be installed), NotFound (User deleted the MO2 instance), HasUpdate (or not, might also just be a bool or something)
• ModlistInfo: cacheable info of the Modlist, we don't want to load every Modlist we manage to get the Author, Title, Version, ... This should be an intermediate class which holds basic info about the Modlist and should be deserialized on startup meaning we don't load the Modlist itself but a json file containing the info.

Some stuff the ModlistInfo should hold:

• Author
• Title
• Version
• Installation Date
• Game
• Locations (Installation location, download location and maybe .wabbajack file location)

Manager should look for update on startup (if supported, meaning we have to get the current version from somewhere. For official lists we can use the modlists.json file and for unofficial ones we could use GitHub release tags or something tho this is a discussion for another time.). So maybe a HasUpdate bool and a CurrentVersion property with HasUpdate being HasUpdate => CurrentVersion > ModlistInfo.Version?

Installation/Compilation

Installation and Compilation Views have some tricky problems, the latter especially, which we have to deal with.

Installation View

The Installation View should be kept simple. I think having a Basic and Advanced configuration mode would be ideal. This way we can have a clean configuration view in the Basic mode similar to the one we currently have, and an Advanced mode which features way more install options like #919 or #681.

Lets go over what a Basic mode should have:

• Modlist Title, Author, Image, Description and maybe Version
• Installation Location
• Download Location
• Website Button
• Start Button

This is the bare minimum. You just select where you wanna install and download all the files and hit go.

With Advanced mode you obviously have all of the above as well as anything extra.

Compilation View

The current compilation view is a bit... weird? The image is definitely way too large and restricts the amount of elements we could have. I personally think we should go with a very extensive and customizable configuration menu. The first thing that comes to mind is Visual Studio Properties Menu for Projects:

This is of course way too complex for our purposes. I believe we should use a step-based approach to this. Similar to the image above, the categories on the left tree view would be steps. In our case we could have a Path Configuration step where you input all path related stuff, then a Metadata Configuration step for title, image, author and others. Using something like the list view in the image above we can quickly add a ton of configuration options to the view without having to implement as much as we'd normally do.

Color Schema Update

Our color schema is kinda shit. While I personally love Dark UI themes it is very hard to work with it and even harder to get it right. I'm not saying we should switch to a Light theme but we should definitely get some new color codes in there. Background colors (multiple of #121212) are fine but the main and secondary color is meh.

Conclusion

This is gonna take a while.

[tr4wzified]

I agree that the color scheme is quite limited, I also think a better font selection could go a long way. I can spend some time making more mockups if you guys are interested. This was an old one, I kinda like the text positioning for modlists on here:

[tr4wzified]

Mockup for main menu

[tr4wzified]

Another idea I had: it would be much easier to let the gallery look nice if all the images were the same size/format. Maybe restrict modlist authors to uploading 16:9 images, preferably 1280x720 or higher?

[erri120]

From discord:

[...] the "main screen" should be only when a user has no lists installed IMO, if a user has lists, WJ should default to the left pane/right pane list screen @Unnoen

[erri120]

This might also be a good opportunity to add some routing: https://www.reactiveui.net/docs/handbook/routing/ The only major problem with this is view registration tho I'd have to look into that again.

[halgari]

Might also be a time to look into dependency injection of some sort. We seem to be right on the edge of needing it, if we’re taking in routing.

On Thu, Nov 19, 2020 at 7:20 AM erri120 notifications@github.com wrote:

This might also be a good opportunity to add some routing: https://www.reactiveui.net/docs/handbook/routing/ The only major problem with this is view registration tho I'd have to look into that again.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/wabbajack-tools/wabbajack/issues/1190#issuecomment-730406683, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAE72HP6C273TCI7S4OCY63SQUSUTANCNFSM4T2FMQCA .

-- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth)

[EzioTheDeadPoet]

Issue #1328 would be a good fit for the UI rework as well. (I will at most in 2 weeks, when my internship is finished, start on a "workaround" by making a java GUI (maybe I will use C# instead at that point who knows for sure), that uses current WJ CLI commands to achive something similar.)

[ghost]

Since you are delving into the world of launching lists, I thought I'd drop some planned features that I never got around to implementing, seeing as this would essentially replace AS, and I'd like for what I learned to be useful somehow.

The idea behind AS was simple; game installs would remain clean even after installing as many modlists as you wanted. I did this just by copying the GFF in when users launched the list, then removing the files when the game closed. I was planning on moving over to symlinking the files soon to cut down on launch time, disk usage, etc. I also needed to save changes made to the GFF while the list was running (like if an ENB configuration was changed)

I planned on implementing a file list authors could include in their installs to give AS additional information on the modlist (obviously this part is already handled by the .wabbajack file). This would've been used to define the default executable, and any manual patchers that may need to be run prior to the list being playable (such as the Morrowind Code Patch), as well as social links for the list author. I planned to add more as time went on, but that was the basic idea.

An ENB and script extender handler was a high priority, allowing the user to download and manage multiple ENB's for each game, and keep one updated copy of script extenders on their drive to avoid having the same files in 10 different modlists.

The next major update was going to see a Developer tab be added, specifically for modlist authors. It would have facilitated the download of utility lists such as SMEFT, modding tools specific to the game you were modding, and integration with tools like Load Order Library, LOOT, xEdit, GitHub, and more. Specifically, I wanted a way modlist authors could easily collaborate on lists by utilizing GitHub repos with meta files, custom patches, and dev .wabbajack files.

This was all I had planned for the next update, which was slated to release next month. At that point I was going to start making more of an effort to advertise the platform, then add features and changes based on feedback. After seeing the Patreon post about adding launcher functionality, I knew I would just be further wasting my time. This is the second time Wabbajack has superseded Azura's Star's functionality (the app started as an installer for Ultimate Skyrim, integrated with Automaton) and at this point I just need to cut my losses and consider what's best for the community as a whole instead of trying to rethink the app's direction yet again.

The source code is available on the AS GitHub repo, as well as all current releases, and they will remain there should you want to take inspiration. AS was written in JavaScript, so I don't know how useful it would be, but I hope you find some use out of it

[EzioTheDeadPoet]

1339 and #1320 should be part of this as well.

[CritLoren]

Mockup for main menu

It might be better to just start at the modlist view page all the time, and feature a "load install file" and "create modlist" buttons in some sort of nav bar, together with links to the wabbajack website, patreon and discord.

I took liberty to create some concepts, partly based on those wireframes and adding some things of my own that I thing could work well from a UX standpoint.