Maximizing and unmaximizing a pinned widget should keep it pinned

[HarHarLinks]

Steps to reproduce

1. pin widget
2. maximize widget
3. unmaximize

Outcome

What did you expect?

widget is pinned

What happened instead?

widget is not pinned

Operating system

arch

Application version

Element Nightly version: 2022011101 Olm version: 3.2.8

How did you install the app?

aur/element-desktop-nightly-bin

Homeserver

No response

Will you send logs?

No

[jryans]

Thanks for the feedback. 🙂 It was an explicit choice during the design process to keep these separate, as in "pinned" and "maximised" are two separate "modes": a widget can only be in one or other (but not both), as that seemed like a simpler mental model.

Anyway, we did wonder if some might prefer it the way you are describing, so we'll need to collect more feedback like this first.

[HarHarLinks]

In that case let me explain my idea of workflow with it:

You are organizing or discussing something in a group, and you're keeping definite results in a widget which is pinned to always be visible, yet chat is mostly important. The widget might be an etherpad or doodle.com for example. While it's viewable when pinned, you might want to really get into it at one point, so you maximize. Then you're done, and it should go back to pinned.

I think about it similarly to a maximize button on a window on my computer screen. The unmaximize button feels more like exiting full screen or unmaximizing (green). In both cases the window stays visible. Traditionally there are also the minimize to taskbar button (red), and close X button (blue). Currently element's unmaximize feels more like "minimize to right panel" (similar to red) rather than what the symbol of contracting arrows communitcates (most similar to green).

[toger5]

I definitely can see how both options might be desired to be accessible from the top bar of a maximised widget:

• A: make pinned
• B: put into right panel/ hide the widget

I am not sure which icon would be best for which action. (I can see how minimise resulting in action B is un-intuitive if the maximisation was done from a pinned widget as you are describing and not from the right panel directly)
Two well suited icons for those two actions would be really great, I think. For my intuition and X for B and the minimize icon for A would make sense but there might be much better options. (the X icon might be a bad choice. Ppl could expect it to behave like: Remove for everyone)

[jryans]

I do think it's overall simpler to reason about if the place a widget goes next does not depend on whether it used to be pinned (which is the current way unmaximise operates), since after all you (or someone else) might have pinned it weeks ago before maximising it more recently, so it would feel awkward to have to recall the pinned state in order to guess what a single button will do.

So as @toger5 suggests above, perhaps a good compromise is having more buttons for the various locations a maximised widget can move to (pinned, right panel), each with specific icons and labels.

[HarHarLinks]

While that would be simple, I am not sure whether that meets the general UX expectation.

As a user, when I click to "exit fullscreen" I expect to go back to the view as it was before I entered fullscreen. This applies to Element's lightbox and video calls, but also to fullscreen in general (I don't want to be taken to the youtube homepage after exiting fullscreen). Even though this isn't a perfect analogy, I think they feel related.

At the same time I agree with the idea of having multiple buttons to essentially manage maximized and pinned states in one click.

In contrast to having a "close-to-pinned" and a "close to right panel", I want to mention the variant of having a toggle for the pinned state and another for the fullscreen state next to each other, both of which only and exclusively toggle their own function, contrary to current behavior.

does not depend on whether it used to be pinned (which is the current way unmaximize operates), since after all you (or someone else) might have pinned it weeks ago before maximising it more recently

Now, that is somewhat opposite of what you proposed: The UI now explicitly tracking the pinned status visibly by adding a green (if enabled, otherwise grey) pin icon to the border of the widget itself, instead of having it only in the right panel room info where it already is, rarely visible as the panel is collapsed/showing threads by default nowadays.

In fact there already is an Unpin option hidden in widget's ... options menu.

---

The behavior mostly needs to be communicated better than today. The first step would be to copy the 2 icons and their behaviour from the room info panel to the widget frame. The second step is to either visually clarify that these are mutually exclusive (are they, in room state?) or make them behave in not mutually exclusive way.

[toger5]

They are exclusive (maximization is another container (center container) and each widget can only be in one contianer)

[jryans]

In fact there already is an Unpin option hidden in widget's ... options menu.

This part is an oversight from the current implementation: the Unpin option shouldn't be there for a maximised widget, so matrix-org/matrix-react-sdk#7657 will remove it.

[jryans]

After reviewing this feedback with Design, we'd like to attempt resolving this use case by adding an additional Pin action to the widget frame, as that will allow sending it back to the top in one step, and also makes the widget frame actions more consistent with those on the right panel widget list.

I realise that is a bit different from the more stateful changes @HarHarLinks has proposed in their comments here, so I'll leave it up to them to decide whether this issue can be considered resolved for their use case once it has been implemented.

[HarHarLinks]

The issue with this UX expectation might be the "pin" terminology: If you call something "pin", I would expect it to "stick around", or in technical terms, "be stateful".

Another problem that I noticed is that pinning widgets overlaps with pinning messages, and these work completely differently and independent from each other (though I wish I could pin a message to have UI as pinned widgets have), yet use the same terminology and icon.

up to them to decide whether this issue can be considered resolved

Will come back here after said change drops on nightly and I've had the chance to try it for a bit. However I think above concerns apply regardless.

[uhoreg]

This can be confusing to new users who enter a room that has a pinned widget. If they maximise the widget and then unmaximise it, then the widget will just disappear without any clear way of getting the widget back.

I think that my expectation as a user would be that maximised implies that the widget is pinned, and unmaximising should keep the widget pinned regardless of what its state was before, but there can be another button (unpin, or hide?) that will unmaximise and unpin the widget in one click. Also, maybe after a widget is unpinned, there can be a popup somewhere telling the user how to get the widget back.

[jryans]

The issue with this UX expectation might be the "pin" terminology: If you call something "pin", I would expect it to "stick around", or in technical terms, "be stateful".

Yes, I agree that does touch on much of the confusion here. At the moment, all actions which pin / unpin widgets are implemented in terms of sending them to a deterministic location:

• Pin == send to the top half of room
• Unpin == remove from view, accessible from room info

Resolving this may require a more holistic rethinking of widget actions and locations, as historically they have grown organically for specific goals, which has led to the confusion we're seeing in this issue.

Another problem that I noticed is that pinning widgets overlaps with pinning messages, and these work completely differently and independent from each other (though I wish I could pin a message to have UI as pinned widgets have), yet use the same terminology and icon.

Yes, agreed it's confusing to use the same naming for these different concepts.

[jryans]

This can be confusing to new users who enter a room that has a pinned widget. If they maximise the widget and then unmaximise it, then the widget will just disappear without any clear way of getting the widget back.

Yes, indeed. I think my smaller-scoped tweak of offering several actions should still help with this, as you can at least choose where it goes, rather than having a single button which does a possibly surprising thing.

I think that my expectation as a user would be that maximised implies that the widget is pinned, and unmaximising should keep the widget pinned regardless of what its state was before, but there can be another button (unpin, or hide?) that will unmaximise and unpin the widget in one click.

Hmm... But if I maximise from the right panel, why would unmaximise send it to the top of the room? It seems odd to me.

Also, maybe after a widget is unpinned, there can be a popup somewhere telling the user how to get the widget back.

Yes, perhaps so... Though I think that touches on a more general issue that many aspects of widgets and their layouts are a bit difficult to discover and understand, so perhaps some rethinking may help with this as well.

[jryans]

An interesting meta-point of this issue is that multiple people are referring to the existing behaviour using the term "unmaximise", but the button is labelled as "close", and indeed that is what it does today.

I suppose though that many people expect a "maximise" action to be paired with an "unmaximise" action, and also the current icon suggests it does the reverse of maximise, even though it does not.

[jryans]

@HarHarLinks, @uhoreg, and others with feedback here: matrix-org/matrix-react-sdk#7734 is now on develop. This adds a separate pin action to the widget header and tries to clarify the overall state with highlighting.

Please give it a try and let us know how it feels for your workflows.

[HarHarLinks]

It has been a while, I've used it now and then, e.g. with otwsu streams. It might partially be because I learned how it is designed to work, but either way I feel pretty content with how the buttons work (and look!) now.

[tmissoni]

The same button should maximise and minimise (bring back to the original state) the Widget. The Pin button should pin it and unpin it from the room.
The maximise button cannot become a close button all of a sudden.

[nadonomy]

The same button should maximise and minimise (bring back to the original state) the Widget. The Pin button should pin it and unpin it from the room. The maximise button cannot become a close button all of a sudden.

From just dogfooding the latest implementation I agree. Both interactions are orthogonal, and it should be as simple as clicking the same button to undo. There's actually several oddities, I think:

1. Pin should toggle between Pin & Unpin, as is today.
2. Maximise should toggle between Maximise & Minimise. Minimising should return it to be 'Pinned' instead of hiding the widget outright.
3. TBD: Maximising from the right panel feels strange, and unexpectedly switches the info panel for chat. It might be better to separate concerns so (1) the right panel lets you pin stuff to rooms and (2) you interact with maximising/minimising directly on widgets in rooms (3) removing maximising from the right panel altogether.

Happy to talk through these and related edge cases with whoever ends up actioning this.

[HarHarLinks]

The maximise button cannot become a close button all of a sudden.

However it can be a "pin maximized" and "unpin maximized" button, if communicated correctly. For me, and with the background knowledge from this issue, the current implementation fullfills that. The wording (and icon) "fullscreen" is a sore spot though, as explained earlier, "fullscreening" something usually works differently than here.

[tmissoni]

The maximise button cannot become a close button all of a sudden.

However it can be a "pin maximized" and "unpin maximized" button, if communicated correctly. For me, and with the background knowledge from this issue, the current implementation fullfills that. The wording (and icon) "fullscreen" is a sore spot though, as explained earlier, "fullscreening" something usually works differently than here.

I agree that with background knowledge the workflow can be explained, but it is really counter-intuitive for a standard user. We will try to simplify it making it more coherent.

[weeman1337]

Done by matrix-org/matrix-react-sdk#8734

[HarHarLinks]

@weeman1337: the Unpin option appears to still be in the kebab menu (see above #20506 (comment))

There is also now an inconsistency: pin icon is used as a button in room info, but minus icon is used in the widget frame.

[weeman1337]

Thanks for mention that @HarHarLinks 👍 The current improvement changed the widget frame to behave more like how an OS application window does.

I am going to open issues to align the menu with the button / the room info sidebar.

[weeman1337]

See #22466 and #22465