10-27-2022 — SIG-UI-UX Office Hours (Sign Up in the comments)

[bhanuja-s]

SIG-UI-UX Office Hours for 10-27-2022

Hi,

We want to invite you to the SIG-UI-UX Office Hours & Design Review.

Date/Time: 10-27-2022 @ 9:00 PT (Timezone Converter)
Location: Discord SIG-UI-UX Voice Room
Moderator: SIG-UI-UX Committee
Note Taker: SIG-UI-UX Committee

The SIG-UI-UX Meetings repository contains the history past calls, including a link to the agenda, notes, and resources.

Sign Up

To sign up for the Office Hours, please add a comment to this ticket with the following information:

Discord Username:
Topic of Conversation:
Time Needed:
Specified UX Attendees?

You can sign up for future meetings in SIG-UI-UX's GitHub Issues.

Agenda

This weekly meeting, typically, covers the following items:

• The UX team demonstrates in-progress workflows.
• SIG-UI-UX provides feedback to others on their feature-design work.
• An open conversation on the UI/UX issues occurring in the pipeline.

How can I use the Office Hours?

• Request a "sign-off" on your project from the SIG.
• Demonstrate a review of your design or mockups.
• Discuss customer pain points or UX-related topics.
• Brainstorm ideas or solutions to a user problem or feature.
• Submit user research or design requests.

What should I bring to the Office Hours?

You're not required to bring anything, but a brief overview on your project would be helpful. This could include the following:

• A simple user problem statement. As a user, I want to ..., because ...
• Who is your target user? Who are the users affected by this change?
• What is your vision behind this change?
• What is your issue related to: user interface, usability testing, learnability, documentation, etc.?
• Any materials or workflows of the existing project, i.e. sketches, wireframes or prototypes.

[bhanuja-s]

Attendees:

• mrlee#8206
• Yuyi [Amazon]#4110
• bhanuja#3608
• Joshua Rainbolt [Amazon]#6715
• SCB_GameDesign#6435
• dg211#3120

Notes:

We discussed #11152; which tries to standardise the unit of rotation, see the comments below for detailed notes.

[amzn-leenguy]

Here are the notes below during office hours on our discussion for Euler Angles:

Suggestion:

• We have degrees as the default angle for our users.
• If possible: Could we have nodes automatically added if needed (or System figures it out for you in background)
• Could we have a drop down on the node, so the user can choose which one they want to choose?
• We should test these ideas with people that use these workflows, and see if it makes sense to them?

Goal:

• We support all types of angles with Euler Angles as the preferred type

Open question for Script Canvas @lsemp3d :

• Can we make the nodes not care about the angle they accept? E.g. Could you make it work with either Quaternion or Euler Angle? (hide it from the user and it just works)

Concerns:

• The different orderings for Euler Angles
• Different industries have different conventions? (Do we try and support all of these or not?)
• We would want to support wider industries like NASA, or Aero industries in the future
• There are few technical nuances with Euler Angles / Quaternions (that we should hide from our users) . You can have two sets of different numbers, but they represent the same angles
• Gimble locking is annoying
• Negative Quaternions mean the same thing to a positive one?

Things to Consider:

• There's many different Euler Angles
• Some nodes use Quaternions Angles, some use Euler Angles.
• The Transform Component is represented by Euler Angles, but it doesn't represent other angles well (Could we write an RFC for this?)

Tagging @hultonha and @greerdv so they can respond on what next steps are outside of this ticket

[amzn-leenguy]

Idea from @greerdv : Some global setting somewhere, where you can pick how you want to review the type of angle

[hultonha]

Thanks for the tag @amzn-leenguy but I'm not sure this is something I can drive (though happy to discuss and advise along with @greerdv)

[hultonha]

Also to clarify it seems like the original question (https://github.com/o3de/o3de/issues/11152) was purely about standardizing on using either radians or degrees consistently in Script Canvas (and across the Editor). That I think is a fine idea and would be good to do across the board (as an aside we could even use strong typing to help catch misuse of radians or degrees at compile time).

When it comes to angle representations though that's a much larger topic and could get very complicated. Can we at least disentangle these two first? We want to support the different representations for different contexts as they're each good at slightly different things.

[lsemp3d]

I agree that to do it across the board would be good, I would advocate for updating the rotation input widget to include a selector and let users decide whether they want the rotation to be applied in degrees/radians, or, at least an engine-wide .setreg option that controls and updates the front/backends accordingly.

[bhanuja-s]

I'm closing this ticket, the discussion seems to be continuing on https://github.com/o3de/o3de/issues/11152.

CC @ParasiteSt