Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add motion input support to nunchuk #8451

Open
wants to merge 1 commit into
base: master
from

Conversation

@rlnilsen
Copy link
Contributor

rlnilsen commented Nov 4, 2019

After discussions we ended up with the following UI layout. When (and only when) Nunchuk is selected as extension, two extra tabs appear: 'Extension Motion Simulation' and 'Extension Motion Input'.

2019-11-06 18_43_04-vs2017 (1) - Remote Viewer
2019-11-06 18_43_27-vs2017 (1) - Remote Viewer
2019-11-06 18_55_52-vs2017 (1) - Remote Viewer

To preserve the context of the discussion that took place, the original version of this post is preserved below

The UI layout was slightly adjusted to allow fitting five control groups on a 1024 pixel wide screen.
Added the same warning text and Alternate Input Sources button as on the Motion Input tab.

2019-11-04 18_48_38-vs2017 (1) - Remote Viewer

@JMC47

This comment has been minimized.

Copy link
Contributor

JMC47 commented Nov 4, 2019

Seems fine to me on an initial pass.

@rlnilsen rlnilsen force-pushed the rlnilsen:motion-input-nunchuk branch from 3784e0e to be01202 Nov 4, 2019
@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 4, 2019

Oops, forgot the warning text and Alternate Input Sources button. Fixed.

@rlnilsen rlnilsen force-pushed the rlnilsen:motion-input-nunchuk branch from be01202 to 8217c99 Nov 4, 2019
@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 4, 2019

Noticed some weirdness with the look of the spin boxes, seems like a possible QSS bug. Fixed by doing things differently (and simpler).

@jordan-woyak

This comment has been minimized.

Copy link
Member

jordan-woyak commented Nov 4, 2019

I think selecting "Nunchuk" should make another tab with the "Accelerometer" mappings or there should be a button that opens another dialog with the mappings.

The amount of configuration available is already hard for users to handle and these additional mappings should rarely be used.

Or maybe I like this better:
When Nunchuk is selected, add its "Accelerometer" mappings to the "Motion Input" tab. There isn't much going on there and it keeps all the raw input stuff together.

@mbc07

This comment has been minimized.

Copy link
Contributor

mbc07 commented Nov 4, 2019

Controls magically appearing/disappearing might confuse users. I think it would be better having the Nunchuk's raw accelerometer bindings always visible on the "Motion Input" tab but in disabled state if the Extension setting of the main tab is set to anything other than Nunchuk...

@jordan-woyak

This comment has been minimized.

Copy link
Member

jordan-woyak commented Nov 4, 2019

Controls magically appearing/disappearing might confuse users. I think it would be better having the Nunchuk's raw accelerometer bindings always visible on the "Motion Input" tab but in disabled state if the Extension setting of the main tab is set to anything other than Nunchuk...

That sounds good.

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 4, 2019

I think it would be better having the Nunchuk's raw accelerometer bindings always visible on the "Motion Input" tab but in disabled state if the Extension setting of the main tab is set to anything other than Nunchuk...

I think @MayImilae may disagree:

I really really do not want you to put the Nunchuk accelerometer mappings into the Motion Input tab! Ok so, Dolphin has a design metaphor it is using for extensions that center around plugging a device into the Wii Remote. So like, for example, say a Wii Remote has nothing connected to it (extension is set to none), the extension tab is blank, just like a port would be in the physical setup. But plug in a Classic Controller (set the extension to "Classic Controller") and now the extension tab is filled with Classic Controller mappings. It mirrors the process of plugging a device into the Wii Remote, so the UX mirrors the experience of using the real thing: a classic design metaphor! Metaphors like this are the bread and butter of UX design are crucial for helping users understand their way around a UI. If you place the nunchuk motion input settings in with the wii remote input settings it will break that metaphor.

@mbc07

This comment has been minimized.

Copy link
Contributor

mbc07 commented Nov 4, 2019

To be clear, the current design looks good to me, but if it ends being moved to the motion input tab like @jordan-woyak asked then I prefer the bindings being always visible but alternating between disabled/enabled state than having them magically appear/disappear on the Motion Input tab based on whether the Nunchuk is selected as an extension on the main tab...

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 5, 2019

@mbc07 Sorry, not the best quoting there.

@iwubcode

This comment has been minimized.

Copy link
Contributor

iwubcode commented Nov 5, 2019

When I initially saw this, I too thought it was a bit crowded. Plus the wiimote solution split the input into two tabs but now for the Nunchuk it's all in one tab. That seems really confusing and unnecessary for users who may never touch that section.

Personally, I don't really mind what @mbc07 suggested but if that's not viable, I think the whole design needs to be rethought. If the whole point is to mirror a wiimote with possible extensions, we've already kinda broken that by introducing two tabs that are "wiimote"s.

I'm not a UI expert but my idea would be to hide all the "raw" mappings under a raw sub-group that can be toggled. I know I've seen this in UIs but can't think of what it was called. This would be consistent for both the wiimote and nunchuk screens. I also wouldn't be opposed to introducing another tab for the nunchuk raw mappings but not sure what that would look like.

I think this is one of those cool features that is unfortunately very difficult to come up with a good UI for. I appreciate you tackling it @rlnilsen !

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 5, 2019

Please feel free to ignore this long post. It's not important.

How the UI design ends up is not that important to me, but I will argue that putting the Nunchuk accelerometer controls as in the screenshot (in the PR description) is consistent with existing UI design:

First, three facts about the UI before any motion input support was added:

Fact 1: Both the Wiimote UI and the Nunchuk UI logically had at least these two sections:

  1. Non motion controls (buttons, axes, triggers)
  2. Motion simulation

Fact 2: The big difference between the Wiimote UI and the Nunchuk UI was in how they visually divided the sections. The Wiimote UI used tabs. The Nunchuk UI did not have visual dividers.

Fact 3: For both Wiimote and Nunchuk UIs, the sections had the same order, from left to right, as in the list shown under "Fact 1" above. Using tab ordering in the first case and position on screen in the second case.

So even though the visual organization of sections in each UI was different, they both had the same logical organization.

Given these facts, what is the natural way of adding a section to each UI?

It seems logical to add a new section by appending it to the ordered existing list of sections (shown earlier), right after "Motion simulation". The UI equivalents are:

For the Wiimote UI: Add a new tab to the right of the Motion Simulation tab in the tab header. The Motion Input tab does this.

For the Nunchuk UI: Add one or more new control groups to the right of the motion simulation section. The Accelerometer group does this, as shown in the screenshot in the PR description. This is the sole control group of the Nunchuk UI's motion input section.

Conclusion

The motion input sections of both Wiimote and Nunchuk UIs were added according to existing (pre motion input support) UI design patterns. In addition, the position of the motion input section within each UI is the same. So the following still holds: even though the visual organization of sections in each UI is different, they both have the same logical organization.

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 5, 2019

@iwubcode

If the whole point is to mirror a wiimote with possible extensions, we've already kinda broken that by introducing two tabs that are "wiimote"s.

Do you mean the Motion Simulation and Motion Input tabs, in addition to the General and Options tab?

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 6, 2019

Following @MayImilae's advice, I really think we should keep all extension controls inside the Extension tab. I believe this limits us to two ways of organizing the Nunchuk controls: flat layout (like shown in the screenshot in the PR description) and tabbed layout (shown below). Which layout do you prefer?

2019-11-06 01_58_23-vs2017 (1) - Remote Viewer
2019-11-06 01_58_48-vs2017 (1) - Remote Viewer
2019-11-06 01_58_54-vs2017 (1) - Remote Viewer

@mbc07

This comment has been minimized.

Copy link
Contributor

mbc07 commented Nov 6, 2019

I'm almost sure that having another set of tabs inside an existing tab is a no-no on the design guidelines of all OSes we support, and understandably as it sure looks very awkward. If having all bindings related to the extension grouped on the same tab is desired, the approach from the first post still looks clean and better than the other discussed solutions until now...

@jordan-woyak

This comment has been minimized.

Copy link
Member

jordan-woyak commented Nov 6, 2019

How about just a "Configure Motion Input" button added to the Extension tab when Nunchuk is selected? It opens a new dialog where the usual warning and accelerometer mappings are.

@Miksel12

This comment has been minimized.

Copy link
Contributor

Miksel12 commented Nov 6, 2019

I think adding 'Extension Motion Simulation' and 'Extension Motion Input' tabs on the right side of the 'Extension' tab when the nunchuk is selected could also work. This would also be in line with the Wiimote motion options and layout.

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 6, 2019

How about just a "Configure Motion Input" button added to the Extension tab when Nunchuk is selected? It opens a new dialog where the usual warning and accelerometer mappings are.

Any suggestion exactly where to place the button?

@jordan-woyak

This comment has been minimized.

Copy link
Member

jordan-woyak commented Nov 6, 2019

How about just a "Configure Motion Input" button added to the Extension tab when Nunchuk is selected? It opens a new dialog where the usual warning and accelerometer mappings are.

Any suggestion exactly where to place the button?

In another group under the "Shake" group maybe? There's a big space there :D

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 6, 2019

I'm almost sure that having another set of tabs inside an existing tab is a no-no on the design guidelines of all OSes we support, and understandably as it sure looks very awkward.

It doesn't look quite as bad as I thought it would, though. Probably because there's the Nunchuk group box header inbetween the two tab rows. There's a lot of frames inside each other though, which I also think most guidelines shun.

@iwubcode

This comment has been minimized.

Copy link
Contributor

iwubcode commented Nov 6, 2019

Do you mean the Motion Simulation and Motion Input tabs, in addition to the General and Options tab?

Correct

Following @MayImilae's advice, I really think we should keep all extension controls inside the Extension tab.

I'm still trying to decide what I think of that. I like the symmetry but also agree with @mbc07 and think it looks a bit weird. And what happens if a different extension is chosen?

I think adding 'Extension Motion Simulation' and 'Extension Motion Input' tabs on the right side of the 'Extension' tab when the nunchuk is selected could also work. This would also be in line with the Wiimote motion options and layout.

I did think of that but if a different extension is plugged in, what happens?

Though that is part of what @MayImilae said originally:

Alternatively, you can just spin things off into multiple tabs. It's not as good though, imo, as motion tab(s) would need to appear or disappear based on what extension is connected. That's never great, but, it's fine. There's room for more tabs

So it might work

How about just a "Configure Motion Input" button added to the Extension tab when Nunchuk is selected? It opens a new dialog where the usual warning and accelerometer mappings are.

Or remove Shake/Tilt/Swing and add two buttons: "Configure Motion Simulation" and "Configure Motion Input", with the former showing the shake/tilt/swing and the latter just showing the accelerometer?

With one button it seems like it might be weird to have it under shake but technically replace swing/tilt too...


Sorry I don't have any profound ideas. I'm still thinking through this..

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 6, 2019

Here's a variant on the tabs-within-tabs layout of my previous suggestion.

2019-11-06 13_09_33-vs2017 (1) - Remote Viewer
2019-11-06 12_59_32-vs2017 (1) - Remote Viewer
2019-11-06 13_18_55-vs2017 (1) - Remote Viewer

@Miksel12

This comment has been minimized.

Copy link
Contributor

Miksel12 commented Nov 6, 2019

Definitely not a fan of that. With the tabs in tabs, the users can see all the options at once. This layout just says: 'Oh look, there are more options. You have to find out for yourself what it contains'. Besides, this layout isn't used anywhere else while the tabs in tabs can be found in Game Config under Game Properties. I'm also not a big fan of using a button to go to the Motion mapping as this isn't used anywhere else in dolphin.

@JMC47

This comment has been minimized.

Copy link
Contributor

JMC47 commented Nov 6, 2019

I honestly liked the original idea that was posted more than these.

@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 6, 2019

Here's @Miksel12's suggestion.

With no extension selected (unchanged):

2019-11-06 18_46_52-vs2017 (1) - Remote Viewer

With Classic Controller selected as extension (also unchanged):

2019-11-06 18_47_48-vs2017 (1) - Remote Viewer

Finally with Nunchuk selected as extension:

2019-11-06 18_43_04-vs2017 (1) - Remote Viewer
2019-11-06 18_43_27-vs2017 (1) - Remote Viewer
2019-11-06 18_55_52-vs2017 (1) - Remote Viewer

@mbc07

This comment has been minimized.

Copy link
Contributor

mbc07 commented Nov 6, 2019

Both @Miksel12 approach and "everything on the same tab" approach from the first post looks good to me...

@iwubcode

This comment has been minimized.

Copy link
Contributor

iwubcode commented Nov 7, 2019

I think between the two I like the " @Miksel12 " approach best.

One variation on that is you could keep the current Nunchuk extension unchanged and add just a single tab "Extension Motion Input". Though that won't match the Wiimote as well. So sticking with what you have is probably best.

@rlnilsen rlnilsen force-pushed the rlnilsen:motion-input-nunchuk branch from 8217c99 to 5e2a82a Nov 7, 2019
@rlnilsen

This comment has been minimized.

Copy link
Contributor Author

rlnilsen commented Nov 7, 2019

The latest UI layout discussed seems to be widely accepted. The code and PR description has been updated to this UI layout.

This PR should now be ready for code review.

@rlnilsen rlnilsen force-pushed the rlnilsen:motion-input-nunchuk branch from 5e2a82a to cd90e2d Nov 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
6 participants
You can’t perform that action at this time.