Gui for the loader - Githubissues

It's time to create proper GUI! Now we have a fair amount of plugins and it would be cool to have something to activate/deactivate them!

I'm a really bad GFX artist, so I hope some of you have some cool ideas. Please consider NO limitations when creating a mockup. It doesn't mean something is impossible when you haven't seen it on the Wii U yet. Animations are cool, new GUI elements are cool!

So these are my current ideas.

General:

I always try to make the applications as accessible as possible. So it should be usable with gamepad only AND with TV only (with wiimote, pro controller).
=> Touch, pointer and "normal" controls.
This mean both screen should contain the same content. They may differ in their presentation (like in HID to VPAD), but everything that's possible on the TV should be possible on the gamepad (and vice versa).
It should be look 2018-ish, not 2000-ish.
The target resolution will be 1280x720p, the gamepad has an native resolution of 854x480, but will rendered in 720p (and scaled down afterwards.). Keep this in mind!
No copyright violations please!
There are color-blind people out there!
Content:

At first I maybe should write down the (planned) features of the WUPS. This might change, but should be a solid base.

Plugin overview:

It should be possible to see the plugins that are currently on the SDCard. Each plugin has information about the author, version, license, compile date and a short description (maybe also an icon?).
For each plugin you should be able to if it's currently activated (with an option to (de)activate it.
Most of the plugin will be configurable in some way. Maybe an icon to open the configuration would be a solution?
Scrollable text is totally possible.
This could be a (scrollable) list, or just individual items with multiple pages (something like homebrew launcher or homebrew app store).
Categories could be necessary.

Plugin order:

The patches of the pugins will be applied in deterministic order. Depending on the order, the plugin may change their behavior.
Example: It would be always be recommended that HID to VPAD will be applied first. This way all other plugns already can use any HID controller (via the normal VPADRead/KPADRead, e.g for button activators). Also SDCafiine manipulates the filesystem, which may affects other plugins.
The user should be able to set the order of applying the plugins. Or at least give some kind of priority.
Maybe even creating something like "configuration-sets" which contain a set of plugins in a specific order would be cool. This could also be shareable between consoles (with automatic plugin downloading)
If this is a thing, people could just download the "Smash 4 configuration pack" and got all plugins in the right order for the best experience.

Plugin updating:

To make this as accessible as possible, it should be possible to manage the plugins directly on the console. This includes deleting, downloading and updating.
It should be easy to see an update if it's available. Maybe together with a short changelog?
This could be a second tab, so you can switch between "installed" and "online available" plugins.
Categories could be necessary.

Updating plugin loader:

The plugin loader should be updatable itself. Via an button on the GUI (in the options !?!?!)? And/or by an pop-up?
Maybe it would make sense to choose between nightly / stable updates?

Options:

Somewhere we need a place for options. For example: disable/enable auto updating, choosing the language etc.

Credits:

Credits.

I would be cool to have as many ideas as possible. This way we can have the best user experience.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/55675878-gui-for-the-loader?utm_campaign=plugin&utm_content=tracker%2F86487112&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F86487112&utm_medium=issues&utm_source=github).

Hmm, maybe I'll try my hand at mocking up some ideas for this.

wupl_menu_new_v1 It's a mockup I build, all the objects are separated I just put them in place for showing porpouses.

Tabs The tab "Installed plugins" is selected in this example, you can cycle between it and "Available plugins" with ZL-ZR it's more intuitive than pressing left-right in the D-Pad IMO. The selected tab is brighter too.

I have a version where the plugin gray frames are fixed to the background, I think it's up to @Maschell decide if he will go with scrollable setup, I have those same gray frames separated too :)

Highlighted Frame
X button turn ON/OFF the plugin, you can touch the area too to change it. Y button open a window (not done yet) to select plugin specific settings. minus button delete the plugin

Background plus button "Apply patches" is fixed to the background HOME button "Home" is fixed too

Notes Would like to know what's the most efficient route to take regarding highligth frame in this case, create the whole .png in both versions ON and OFF? or just replace the ON/OFF banner? The same apply for the gray frames, they should only display the ON/OFF status IMO, and the other options would only apear when it's selected (highlighted frame)

If someone is interested in messing around with this template please DON'T use this mockup, contact me and I will give you the .psd template

mockup mockup-controller mockup-sidebar

I did some work as well on an interface here, mine is a lot more rough, but I was more interested in trying to make a UI design as opposed to finalized graphics. I spent a few hours thinking about how a UI would work and flow well and I like what I came up with.

Some pros to my layout:

Large UI elements work well for the Gamepad screen, making it not just stylus friendly, but also fingers friendly.
These large UI elements are very suitable for Wiimote Pointer Controls as well
Wii U Pro Controllers or Gamepad Buttons should have no trouble navigating either if it's done right.

Touch/Wiimote Pointer Controls:

Everything is touch sensitive, dragging plugins to reorder, tapping checkboxes, tapping the play button to apply patches or save button to save the current plugin layout. The same applies if you use a Wiimote Pointer.

Button Controls:

Left Stick / D-pad: Move Selection Cursor (Seen in Image 2)
Right Stick: Scrolling (where applicable)
A Button: Toggle Plugin On/Off
B Button: Hold it to lift up the current plugin and use the D-pad to drag it where you want it to go, like the Wii U menu icons.
X Button: Open the Configuration Menu for the Plugin. This is likely going to be a scrollable pop-up menu with the A button or Left/Right changing each setting.
Y Button: Open the Plugin Info Menu for the Plugin. This is where the icon, name, description, author, version, update button, and delete button goes. If the description doesn't fit in the text box, it will auto scroll or can be scrolled with the Right Stick or Stylus/Pointer drag.
ZL Button: Opens the Side-bar, the selection cursor will automatically jump into this menu when it is opened for easy controller navigation. A button selects one of the options.
Plus Button: Loads all plugins and exits the software to the Wii U menu after doing so. Optionally, this may instead open a confirmation dialog which then does the same thing.
Minus Button: Saves the current plugin order and which plugins are enabled/disabled to a configuration file. Optionally, this may open a dialog where saving/loading of these profiles is done, I've just assumed the simplest usage here.

I haven't mocked up the "Info" or "Configure" menus yet, but it shouldn't be hard. I haven't mocked up the Plugin Store yet either, but I'd imagine it'd be a scrollable menu with larger boxes including the icon and short description, similar to what @cucholix above did for the main UI instead.

As for credits, I figure that can just be tucked away into the settings menu for the plugins loader, think back to how USB Loader GX did credits for that. You could also display the current loader version on the credits page and play custom music like ULGX did there too if you wanted.

mockup-information Decided to mock up the information page now. I also updated the above post to be much more easy to understand.

As you can see on the right there, there's a close button, update button, and a trash button.

On a Wii U Pro controller or with Gamepad buttons:

B Button: Go back to the plugin menu.
X Button: Bring up delete confirmation yes/no dialog.
Y Button: Bring up an update dialog (_or open the plugin shop page for the plugin and update it there?)

You'll notice the "for details" line is cut off. This is because this text will automatically scroll after about 5 seconds, when it reaches the bottom, it will stop for 5 seconds before jumping back to the top, and waiting another 5 seconds before scrolling again.

At first thanks to both of you! That was really quick. Here a some thoughts from my side:

@cheatfreak47 I like the idea of this pop-up menu on the left side, but the text/icons maybe a bit too big? I see the idea of having it optimized for touch, but this is still a 6,2" screen (low res and big screen is a bit weird). The information page mockup looks better, this is really good, I like that.

@cucholix The way how the "list items" look is really stylish in my opinion, but I don't like the scrollbar on the side. I think an actual bar fits better than the buttons. Settings would also be the point where you can see more information (maybe more text of the description, the version, build date)?

Maybe combining both would be cool. The list items from @cucholix and the idea of the popup menu on the left side!

@Maschell The size of the buttons on the pop-up side bar would be variable based on how many buttons need to fit, they could go as small as the buttons for "info" and "settings" on the list before it becomes troublesome for wii pointers, I just could only think of 3 menus or buttons to put there so I made them larger to fill in the sidebar.

One idea i thought of looking at @cucholix's thing is adding a button to the sidebar for the github page, which you could maybe have open in the Wii U Browser if that's a supported interface with the Wii U browser, not too sure.

About my list view, maybe the text and plugin indications themselves could be made a bit smaller, but I fear that making the buttons smaller will make them more difficult to click with the Wii Remote pointer, which was something else I took into account by testing it visually in the browser.

photo_2018-03-04_14-27-59

One of the problems I noticed immediately with @cucholix's mockup is that the text for the descriptions is just a bit too small for the Wii U gamepad screen. It's still possible to read it of course, but in the same way it's possible to read the labels on the back labels of shampoo bottles. It's really really tiny, so maybe if that could be bumped up size wise, it could work well.

I'm also not too keen on the giant orange bar stretched across the top, and the background, while stylish for sure- is too detailed as is for clear visibility on the gamepad with it's lossy video compression used, it ends up looking quite blurry.

@cucholix i'd kind of like to see your take on my list and side-bar mockup, given your great sense of style when it comes to design. If you could find a way to work the icons into the list entries for the list view that'd be pretty cool.

@Maschell I agree with the idea of a bar instead buttons it give us more free space in the right side too, I also like the side-bar, but IMO it would fit in the whole composition at the right side, in my mockup at least. Regarding the info we can add a touchable "i" icon near the app icon that is triggered with the left stick click too, that way we access to a new pop up window that show more detailed info about compilation date, version, etc... I'm not fan of clutter the the frame any further. The Settings button is just too important for each plugin to mixing with other info IMHO, at the same time not all the plugins have options =p, so I'm not quite sure either.

@cheatfreak47 I just saw the description text of my mockup in the gamepad and it's tiny, maschell mentioned that a possible solution is that the text autoscroll when you highlight a plugin, so it shows completely independent of the length. The text in the mockup is just a placement (in fact all the text, except github/twitter lines) so maschell always can adjust text size via software.

Now the side-bar what would contain? It should be global settings, it would be ideal to set plugin order for example, credits stuff, external links and whatnot.

I really like what you guys are coming up with from a user perspective, and want to offer a few thoughts of my own. Both mockups here have some really good ideas going on in terms of looks and touch-friendliness, but I feel like there is still a bit left to be desired. I think there are a few things to be learned from Nintendo's menus, or general good UX practices:

List views These are the list views for replays and music in Smash 4. Ignoring the stylized design, there are some really cool things going on here. The list on the right, with info for the selected item on the left, is a really nice balance between overview and detail. It's visually pleasing, easy to read and very functional. This removes the need for a popup/separate screen for details about a plugin, just slap all that in the area on the left. Buttons or checkboxes for plugin settings? They can go there too! Also, notice the implementation of a relatively slim scroll bar to allow for quick scrolling, and tabs/sorting methods that can be cycled through with L/R. Everything can also be touched or pointed at, meaning any controller will work, even the wiimote which has like half the buttons of other controllers.
Context menus Again, the lists in Smash 4 are great examples of a good implementation. Consider for a second the list views from above, with key information and buttons on the left and the list itself on the right. How about less frequently used functions, like "Delete plugin", "Verify files", "Check for updates" or similar? Bam! Right-click style dropdown menus are nice and dynamic, and should feel familiar to anyone who has used a GUI in the past 20 years. A scrollable one will never run out of space, so there's practically infinite room for activities. Another alternative is the Apple iOS style context menu that scrolls in from the bottom, like so: While this is closer to a pop-up it still feels less intrusive and is highly functional, allowing quick access to lesser-used functions. This style allows for bigger buttons, without necessarily feeling like a Doro phone. The wider aspect ratio of the Wii U menu would allow for items to be side-by-side here, more grid-like and less list-like.
Global settings If there are tabs, have a separate "Settings" tab. If not, bind it to a button on the controller, like minus. Having a drag-in drawer-style menu to get to the button that takes you to the settings menu sounds really clunky.
Consistent button mappings This should be obvious. The mock-up proposed by @cheatfreak47 involves a lot of nice functions, but seems to be made with a "touch first" kind of approach, with controllers being an afterthought. My biggest gripe here is the idea of using the B button to click-and-drag plugins in the list. Literally every menu I've ever used on the Wii U, no matter if it's on the Home Menu, in a game or in a homebrew app, has the B button as "go back". Every console menu I have ever used has always had a consistent back-button. Changing this is a bad idea, it goes against everything every menu has been teaching users since the dawn of menus. If moving items in the list is press-and-hold A with touch or a pointer, then it should also be press-and-hold A with a controller, or a clearly communicated separate button. If X means "show dropdown" on one screen, it shouldn't mean "go back" or "check box" on another screen.
Ease of use This is a big one. Having a menu for such a complex task as managing plugins on the Wii U gamepad means there are a lot of functions to implement and not a lot of space for them, but the solution isn't necessarily to map every function to a different physical button. When was the last time you needed to use ZL on a menu screen? An optimal setup would involve nothing but the Dpad/left stick/a pointer, A, B, L, R and Plus. If you really need to be able to any% speedrun the menu then let people enable the extra button bindings in the settings somewhere, with maybe a quick screen to explain what the buttons do. If your menu needs a tutorial screen to learn what all the buttons are, it's probably not a very well designed menu.

I'm not great at actual graphical design, but here's a written mockup of what I would think is a mostly good user experience for the plugin loader.

The basic layout

The layout should be very simple, consisting of three main parts. There's a header, a body and a footer. Very straight-forward stuff.

Header The header is relatively slim, and spans the entire width of the screen. It contains the three tabs of the main menu, which are labeled "Plugins", "Enabled" and "Settings". On the far left and right there are small icons of the L and R buttons, indicating that the tabs can be cycled through with these buttons. The tabs are touch-enabled, meaning they can be accessed even with input methods than don't have the L/R buttons. The currently active tab is indicated in some way, like it being brighter and its label being bigger and bolder than the other two.
Footer This contains basic information for the user, such as what button does what right now and eventual other things that fit such as a clock. The footer is never interactive, it's just an info display.
Body This is the meat of the view. The contents of the body are determined by the currently active tab, and are always interactive.
- Plugins tab This is the default view, and the first thing the user sees after launching the plugin loader. The Plugins view is a split list view, where the right hand side is a list and the left hand side displays information and basic settings for the currently selected list item.
- List items Borrowing from the Smash 4 replay list view, a list item should contain a plugin Title, Author and Version, as well as a small, square icon on the left. The currently selected list item is indicated by a distinctive border. When the user is interacting with the information display, the border is still present but greyed out.
- List controls While in the list view, the up and down buttons as well as the left control stick change the selected list item. The left and right buttons as well as the left control stick allow the user to move the selection between the information display on the right, the list on the left and the leftmost scroll bar for the plugin list. When the scroll bar is selected, the up and down buttons and the left control stick scroll quickly through the list. The right control stick scrolls quickly through the list, regardless of whether a list item or the scroll bar is currently selected. If the scroll bar is selected, the A button moves the selection to the middle list item on the screen. If a list item is selected, the A button toggles the item between disabled and enabled, and the Y button moves the selection over to the information display. Enabled list items are indicated by a little green checkmark in the top left corner. If a list item is selected, the X button brings up a context menu which contains some non-essential functions that users might want such as "Check file integrity", "Check for updates", "Delete plugin" and others. If the user is in a context menu, the L and R buttons are disabled, and the B button closes the context menu.
- The information display The information display consists of an optional banner image, the plugin title and version number and a short description of the plugin.
- Information display controls The up and down buttons and the left control stick move the selection up and down the available checkboxes or dropdown menus. If no checkboxes or dropdown menus are on the screen, the up and down buttons and the left control stick scroll through the description if possible. If not, the buttons do nothing. While the user is navigating the information display, the B button moves the selection back to the plugin list. If the information display's contents are long enough, it has its own scroll bar, which functions in the same way as the one in the plugin list.
- Enabled tab This menu looks like the "Plugins" view, but has a different base color to immediately indicate the difference. The information display now contains optional plugin settings, in place of the description. If there are any enabled plugins, they are listed here. If no plugins are enabled, the body of this tab simply displays the text "No plugins are enabled, enable them in the 'Plugins' tab to view them here." When there are enabled plugins, a text near the top of the body of this tab explains that plugins are loaded in the order of this list. The left part of the body, which was the information display in the "Plugins" view, is now the settings display.
- List view This list only contains enabled plugins from the "Plugins" tab. It looks the exact same, but the checkmarks for enabled plugins are not shown, since they are redundant in a list of enabled plugins. Whenever a plugin is set as enabled in the "Plugins" tab, it is added to the bottom of this list.
- List controls This list controls the exact same way as the "Plugins" list, but the context menus are different. The context menus now have options such as "Move", "Move up a spot", "Move down a spot", "Move to top" and "Move to bottom". Holding A on a list item allows the user to move it with the up and down buttons or the left control stick. "Moving mode" is indicated by the rest of the list items fading and shrinking a little. If "Moving mode" was entered via a context menu, pressing A places the list item in the indicated spot. If "Moving mode" was entered by holding A, releasing A places the list item in the indicated spot. Simply pressing A or Y on a plugin moves the selection over to the settings display if possible.
- Settings display The settings display consists of an optional banner image the plugin title, version number and author, an optional advanced description and all available settings for the plugin, if any. The advanced description should not be about the plugin itself, but rather things like information about priority requirements and recommended settings, e.g. "Must be loaded before TCPGecko". The settings are displayed using checkboxes and/or dropdown menus. The currently selected checkbox or dropdown menu is indicated by a border similar to the indication for selected list items. Checkboxes and dropdown lists are positioned to the right in the information display, with the name/function of the checkbox or dropdown menu to the left.
- Settings display controls If a checkbox is selected, the A button toggles it between checked and unchecked. If a dropdown menu is selected, the A button opens it to display the available options. When a dropdown menu is open, the up and down buttons as well as the left control stick navigate the list of options, the A button chooses an option and the B button closes the dropdown menu without choosing the selection, reverting to the option enabled before the dropdown menu was opened. If the user is in a dropdown menu, the L and R buttons are disabled. While the user is navigating the settings display, the B button moves the selection back to the plugin list. If the information display's contents are long enough, it has its own scroll bar, which functions in the same way as the one in the plugin list.
- Settings tab In this tab, we find the global settings. These are displayed and controlled in the same way as the settings display from the "Enabled" tab, but the settings now take the full body instead of just the right half. Here, we find options and functions such as "Auto check for plugin updates on launch", "Import preset", "Export preset", "Reset all plugins to default" and such. At the bottom of the body of this, we find information such as the current version of the loader, a link to this repo, a license notice and similar, non-essential things that might be useful for power users.
Global controls These are kept to a minimum. A button, maybe the plus button, closes the loader and enables the plugins in the desired order. Pressing this button opens a prompt asking the user if they want to load the plugins. This prompt can be disabled in the "Settings" tab. The HOME button closes the loader without enabling the plugins.

Here's my idea. The orange circle in active plugin screen means that there's an update for that plugin.

gui-maschell-active

gui-maschell-installed

-Animation preview- gui-maschell-gamepad

Hi there.

Maybe I am to late to the party, but wanna share some ideas, a little bit inspired on the Switch UI. This are only wireframes, of course.

This one is the homepage. The idea here is to be able to re-arrange the execution order of the active plugins, and to enter to a plugin to enable, disable or change its options. The plugin store can be entered the same way as any other plugin, but instead of loading the plugin setup view, it will load the plugin store itself. The plugin list is an offset carousel, and the re-arrange option on the bottom will only appears if the user is over an active plugin.

00 - homepage