Re: [libreoffice-design] Minutes from the UX/design meeting 2024-Aug-22

On 22/08/2024 22:11, Heiko Tietze wrote:
> Present: Sahil, Rafael, Heiko
> Comments: Eyal,
>
> Tickets/Topics
>
>   * Add deck with choice of slide layouts to the sidebar
>     + https://bugs.documentfoundation.org/show_bug.cgi?id=162420

For some historical context, let's remember the sidebar without the
decks from 10 years ago...

https://www.youtube.com/watch?v=4B1TjAfRwQ4&pp=ygUZc2xpZGUgbGF5b3V0cyBsaWJyZW9mZmljZQ%3D%3D


>     + always show master/layout options (Eyal)

This mis-quotes me.


>     + access together with master slides or remove from sidebar (Heiko)

Re second option, of removing from sidebar: Then where is the user
supposed to see the slide layouts? The sidebar is absolutely the right
place for it.

(By the way, if one uses the tabbed UI, there seems to be a
dialog-button which does show you various slide layouts; but not with
the menus.)


>     + layout is not part of the master (though requested) (Regina)

Yes, but that argument was made in favor of placing layouts on a
different deck. IIANM.

>     + no objection to layout with master but still need to have it
>       at slide properties (Cor)

>     + Layouts are not that much useful as they are not intelligent;

1. Layouts are quite useful, and people use them as much, and probably
much more, than masters.
2. What are "intelligent layouts"? Not minuted...
3. Don't see any open bug regarding the removal or rework of layouts
into something else.

So, I don't believe an argument regarding how layouts could perhaps be
improved or made more intelligent weighs against making them accessible
on a separate deck.

>       precious space would be wasted (Rafael)

What precious space would be wasted? On the contrary, we currently have
empty space for sidebar decks, which we could use. That is, we are
currently wasting space.

>     + proposal makes sense; pane could be collapsed to save space
(Sahil)>     + character, list, paragraph still visible when in slide
context?
> (Heiko)
>       + why show it if not applicable? (Sahil)
>       + so what would be different from the current situation (Heiko)
>     + should all the slide attributes be available too?
>       + makes not too much sense since it's not a per-slide option (Sahil)
>       + totally against bloating the sidebar (Heiko)
>     + MSO allows to change the layout via context menu but also only if not
>       in any other context than the slide

Not sure what this discussion was about, but it's certainly not about my
suggestion.

>     => WF

You have not presented even a shred of an argument as to why it makes
sense to have a sidebar deck for inter-slide transitions (without having
selected multiple slides) - but not for slide layouts. (And of course, I
did pose that challenge for whoever opposes confirming the request.)
Quite annoying.

>   * Ability to assign comments / tracked changes to a different
author>     + https://bugs.documentfoundation.org/show_bug.cgi?id=162424
>     + https://bugs.documentfoundation.org/show_bug.cgi?id=162423
>     + rather avoid changes to or at least clearly indicate authorship
> (Heiko)

Clearly indicating the authorship - as the document editor wants it to
be indicated - is exactly what this feature request facilitates.

>     + reasonable use cases such as name not set (Eyal)
>     + documents with comments are not legal binding (Rafael)
>     + protecting TC and comments outweighs flexibility and
>       convenience (Heiko, Rafael, Sahil)

"Protecting comments" and changing author information don't contradict.
You can make it more difficult to change comments; but once the user has
clearly indicated they want to change comments, they should be able to
change authorship as well as contents.

>     + makes sense as extension and should list all comment authors allowing
>       to take over one of those
>     => do per extension

To say that something "makes sense as an extension" one needs to
establish (among other things) that:

1. use-cases are niche enough to not merit the app catering to them
2. functionality not required for comprehensive ability of editing ODT files
3. Possibility of implementation via extension

In our case, point (3.) is probably valid, but points (1.) and (2.) do not.

>   * Ability to make multiple adjacent row or column cell merges>    
+ https://bugs.documentfoundation.org/show_bug.cgi?id=162333
>     + use case A1 = first name, B1 = second name => merge to combine (Eyal)
>     + simply do =A1 & " " & B1 (Heiko)
>     => WF

Agreed (for a change...)


--
To unsubscribe e-mail to: design+unsubscribe@global.libreoffice.org
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.libreoffice.org/global/design/
Privacy Policy: https://www.documentfoundation.org/privacy