Help course authors understand the context of the text and problems they are editing.
Problem: The new text and problem editors take over the entire browser window, obscuring the context of the unit being edited.
Use Case:
Imagine a case where I am copying and pasting a text or a problem from one section in a course to another. I intended to modify the copied version in its new place in the course. While I’m in the process I lose my focus momentarily, perhaps looking up a reference online. On returning to my editor tab, I can no longer tell which problem I have open, because I can’t tell where I am in the course.
Or worse, a user who is working on multiple courses in different tabs can’t even tell which course they are working on.
Workarounds like opening editors in a new tab are foiled by how the buttons are implemented in Studio.
Discovery: Can editors appear in an iframe instead of a new window? If there is a concern about screen real estate, the iframe could be expanded. And/or, if allowed to, to open in a new tab.
Comments
Thanks for the context, @Jeremy Ristau ! If that’s the case, then we will have the new Unit Page MFE ready for Teak, so we could explore a modal solution/design for Teak. In fact, we are implementing the editors as modals in Libraries - can we leverage/transfer that same work for courses? cc @Braden MacDonald
Another thought on approach - I wonder if there are UI solutions that could help here, too. For example, adding a breadcrumb trail at the top of the editor to indicate 1) Where in the course outline the problem lives and 2) Which course it belongs to. cc @Sam Daitzman for any high level UI thoughts?
I like contextualizing where you are - with fully qualified breadcrumbs - directly on the editor experience itself. That feels even more helpful than an iframe which may obscure the underlying nav.
With the Library relaunch in Sumac, we implemented an in-context modal for all of the editors, so that authors can still see the page they are on while working in the editor:
The easiest thing to do would be to lift that experience into the new unit MFE, which will be live in Teak. @Shilpa Idnani Would this suffice as a first-pass solution?
I think this is exactly what we should do for the course unit editor in Teak. What do we need to do to consider this “approved” for Teak?
Is there a product proposal anywhere for the solution to this problem? If not we probably need to make one, which seems like it doesn’t need to be very big (probably more of an inform for tracking purposes) and we can get everyone aligned on it.
I”ll pull everything into a GH ticket. There’s already one partially in progress on the Libraries board.
@Sarina Canelake @Jenna Makowski There is a GH ticket tracking this proposal: https://github.com/openedx/platform-roadmap/issues/385 .
I’ll take on the Coordinator role.
The proposed changes for Teak seem especially uncontroversial and the ticket’s state is already “Being Developed”, so unless someone says otherwise, I think we can consider this approved and move forward.
Is this not the product proposal?
Sorry, I meant a GH ticket, and you linked it - ty!
@Jenna Makowski I believe the only reason we were unable to open editors in a modal is because of the transition between domains (going from legacy Studio unit page to Authoring MFE editor). If the new Unit Page is rolled out, then it is my understanding that this would modal behavior be relatively straightforward.