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

RFC: Override NRCS Data — UI/UX #1289

Open
3 of 5 tasks
hummelstrand opened this issue Oct 17, 2024 · 6 comments
Open
3 of 5 tasks

RFC: Override NRCS Data — UI/UX #1289

hummelstrand opened this issue Oct 17, 2024 · 6 comments
Labels
Contribution from BBC Contributions sponsored by BBC (bbc.co.uk) Contribution RFC

Comments

@hummelstrand
Copy link
Member

hummelstrand commented Oct 17, 2024

About Me

This RFC is posted on behalf of the BBC.

Use Case

This is intended to be a UI/UX continuation of the RFC: Override NRCS Data in the Sofie GUI which mainly deals with the backend work.

Proposal

The plan is to begin by exposing all the properties in a Properties side panel. At a later stage we intend to add the possibility to directly edit properties by manipulating the pieces and segments in the main GUI.

Process

The Sofie Team will evaluate this RFC and open up a discussion about it, usually within a week.

  • RFC created
  • Sofie Team has evaluated the RFC
  • A workshop has been planned
  • RFC has been discussed in a workshop
  • A conclusion has been reached, see comments in thread
@hummelstrand
Copy link
Member Author

Iteration 1 of the Properties panel.
image

@hummelstrand
Copy link
Member Author

  • After workshopping this we've decided that it makes more sense to have all form fields being live, so any changes made in the panel will immediately take effect in the GUI. That means that the Cancel/Apply buttons will be removed.
  • While considering the future UX of how to do direct-manipulating of pieces/segments, the current thinking is that we want to avoid a "master Play/Edit mode" switch, but instead rather allow the user to edit directly by using the Alt/Option keyboard modifier.
  • We hope to be able to modify the GUI so that the panel will resize the main GUI instead of covering it.

@nytamin
Copy link
Contributor

nytamin commented Oct 21, 2024

Copying in my response from the previous thread, for visibility:

Let's set up a workshop, where you can present your current plans and we can have a discussion regarding the GUI side of things.
I propose that we have the workshop Wednesday, October 23rd at 13:00 CEST, I'll send calendar invites.

If anyone else wishes to join the workshop, please email me at [email protected]

@nytamin nytamin added the Contribution from BBC Contributions sponsored by BBC (bbc.co.uk) label Oct 21, 2024
@olzzon
Copy link
Contributor

olzzon commented Oct 21, 2024

Implementation of Properties panel is here:
https://github.com/bbc/sofie-core/tree/feat/ui-useredit-panel

Currently this implementation uses a hack in NotificationPanel (and its notification levels) and opens by right clicking. (together with the right-click menu)
This hack is in this branch, while we're implementing a good "selected element" in UI, and modifier clicking.

@nytamin
Copy link
Contributor

nytamin commented Oct 24, 2024

Notes from workshop 2024-10-23:

The notes below outlines what we discussed and concluded in the workshop:

About the name "Overrides"

Should we call this "User overrides", "User edits" or something else?

Discussion: There are arguments for not calling this "overrides" because sometimes you would "add" something and actually "edit" it, not really "overriding" anything existing.

No final conclusion, due to shortness of meeting time.

Editing interactions

There can be two types of editing interactions:

  • The "Properties Panel" (see the image in @hummelstrand 's post above) is a form-style panel that is populated from a Sofie-style JSON-schema exposed by the Blueprints.
    • The Properties Panel can be opened by a user to edit the Rundown, Segments, Parts or Pieces.
    • The plan is for the Properties Panel to be "instant", ie as soon as a user makes an edit (ie clicks a button, changes a text field), the edit is persisted and the GUI is updated instantly. (not 100% concluded yet)
  • "Interactive edits" are edits that are done directly in the GUI
    such as dragging a Part or segment to a different position, or changing the duration of a Part.

BBC will be focusing on the Properties Panel in the first phase, the interactive edits will possibly be looked into at a later stage.

About "Editing Mode"

The idea is to have an "Editing Mode", a GUI mode that the user activates either by toggling a radio button in the side-bar,
or it can be enabled/disabled/toggled by a UserAction (ie a keyboard shortcut, a streamdeck button etc).

When the Editing Mode is active:

  • When the user right-clicks a Segment/Part/Piece, they get additional editing options in the context menu, such as
    "Open Properties", "skip this part", "lock this piece" etc..
  • The Properties Panel displays the content form and the user can edit the content.
  • Interactive edits are enabled (and possibly: "GUI hints" are enabled, such as highlighting-on-hover, drag handles etc)

When the Editing Mode is inactive:

  • When the user right-clicks a Segment/Part/Piece, they only get the "Open Properties" option.
  • The Properties Panel displays the content form, but it is "greyed out" / disabled and cannot be edited.
  • Interactive edits are disabled ("GUI hints" are hidden)

This is not concluded, to be discussed further regarding the behavior and UX.

Other

  • NRK thinks that "Enabling user edits" should be an opt-in feature flag on the ShowStyle settings. If it's not enabled, all editing-related things should be hidden in the GUI.
  • Johan thinks that there should be a property on the Rundown/Segment/Part/Piece that indicates that it has been edited by a user, so that the GUI can show this to the user. Discussion whether this is a Sofie Core thing or if the blueprint should indicate this on their own, no clear conclusion.

Things to keep in mind

  • There is the preexisting "double click" action to play a piece, which might collide with a point-and-click-to-edit paradigm.
  • The GUI should not remove any playout-related features when in Editing Mode - ie it should be possible for a user to play a whole show while in edit mode.

Going forward

  • The participants will digest and think about the thoughts presented in this workshop, and will reach out to Johan if they have more questions or thoughts
    that warrants a follow-up workshop.
  • NRK says: We are very interested in being involved in the GUI/UX details, we'll keep in touch with the BBC reps.

The workshop was recorded in Teams, let me know if you'd like access to it.

@mint-dewit
Copy link
Contributor

A PR with the implementation of the Properties Panel has been made: #1342

Notable deviations:

  • There is no editing Rundown Level properties, this should not be a large addition should it be implemented by other contributors
  • A user has to confirm any changes made by clicking "Save"
  • There is no such thing as an "editing mode"
    • Presumably to be added when interactive edits are added since there is not much risk in leaving the current editing exposed at all times
  • The editing features can be disabled on a Studio level (rather than a showstyle level)

Regarding "interactive" edits we have 2 additional features upcoming:

  • Make it possible to drag an item from a mos plugin onto a Part
  • Allow dragging a piece on the timeline to retime it

The second one will probably require the aforementioned "Edit Mode" or an "Edit key". At this point in time I don't believe these require additional workshops but please let me know if that is wanted.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Contribution from BBC Contributions sponsored by BBC (bbc.co.uk) Contribution RFC
Projects
None yet
Development

No branches or pull requests

4 participants