Re: Fwd: [libreoffice-design] Re: Questions on UX/Design category on Discourse

[Eyal Rozenberg]

On 13/05/2022 19:40, Heiko Tietze wrote:

Discourse is no bells and whistles


It has:

* Moving content
* Dozens of pictures in the window
* Hundreds of visual elements, if we include all of the labels, and
badges, and what-not

That's bells and whistles.

TBH though, I haven't seen what the LO discourse looks like, so
theoretically you may have turned some of them off - though I doubt it.


but a modern frontend replacing the classic list archive.


Replacing the _list archives_? Surely, you jest. That's like saying a...
say, karaoke bar is a "modern front-end replacing the classic library".


It has the additional benefit of being a
discussion forum, actually forums since we can have categories.


It's not a discussion forum. It's a hierarchy of chat channels. Not at
all the same thing.


There was an open discussion for month whether or not and how we should
introduce it. This cookie has been eaten.


How was that discussion open? I'm on 3 LO-related channels and nobody
informed any of them that such a discussion was taking place.

--
To unsubscribe e-mail to: design+unsubscr...@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

Re: Fwd: [libreoffice-design] Re: Questions on UX/Design category on Discourse

[Eyal Rozenberg]

Ok, so, I have to take back what I said, because I conflated Discourse
with Discord (https://www.youtube.com/watch?v=1zSXh4a_1eg shows you what
Discord is like)

I take it that the LO discourse would look like this:

https://ask.libreoffice.org/

but not for users to ask support questions?

And design will be a subforum in Discourse, with its associated feed of
updates and daily digest email of posts?


I'm not saying I'm accepting the opposite position than I had before,
just that I was arguing based on a completely false notion...

Eyal

--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2022-May-19

[Eyal Rozenberg]

So, about https://bugs.documentfoundation.org/show_bug.cgi?id=143197 ...

The bug author, ajlittoz, wrote:

> to be honest, it took me years to develop a satisfactory mental
model, though I read thoroughly the available documentation

I had asked on the bug page regarding whether or not this "mental model"
was ever properly decided upon and documented - not just for users to be
able to read the documentation.

For example, I'd like to know whether, when it was adopted, that was
fully a conscious decision with a lot of buy-in, or whether it just sort
of happened gradually as functionality got implemented.

Another reason is that I couldn't tell you with any certainty what the
differences are between LO and MS Word's model for paragraph numbering,
outline level and lists.

Finally, when the current state of affairs is clearly and succinctly
presented, it would be easier to propose changes to it. For example, I,
don't like all paragraphs with the same list style are considered part
of the same list (except sometimes they don't seem to); and am wondering
whether lists should be more explicitly manageable in Writer.

Eyal



On 19/05/2022 15:31, Heiko Tietze wrote:

Present: Heiko
Comments: ajlittoz, Miklos, Mike, Maxim

Tickets/Topics

  * Writer: hidden link between list and chapter numbering
    + https://bugs.documentfoundation.org/show_bug.cgi?id=143197
    + unlikely to solve (ajlittoz)
    + perhaps disable F12 shortcut (Mike)
    + keep F12 and restrict the LS to chapter numbering, meaning to
  disable all inappropriate options (as today) and block also all LS
  for outlines; don't allow using this LS on ordinary paragraphs;
  ultimately the software should handle proper LS and the user must
  not be required to think what options to pick (Heiko)
    => comment

  * "Object" property dialog (and Navigator and UI elements) should be
    retitled "OLE Object"
    + https://bugs.documentfoundation.org/show_bug.cgi?id=149018
    + no objection to proposal in c19
    => do it

  * Should .uno:ObjectMenue be shown in the Customize dialog?
    + https://bugs.documentfoundation.org/show_bug.cgi?id=149047
    + consider Windows where OLE works differently (Miklos)
    + filled dynamically with content (Maxim)
    => resolved fixed with the "OLE Object" modification

  * Add button or context menu for (Un)Grouping in dialogue Pivot Table
Layout
    + https://bugs.documentfoundation.org/show_bug.cgi?id=112867
    => unclear workflow, WF/NAB

  * ability to draw callout with line extending from top or bottom of
text box
    + https://bugs.documentfoundation.org/show_bug.cgi?id=141085
    => unclear workflow, WF/NAB



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] UX/Design meeting on Wed Jul/13 with PolyPoly about collecting user data

[Eyal Rozenberg]

I am staunchly opposed to LO shipping with any sort of data collection
by default. It's better not to have user metrics then to install spyware.

I would only accept something which meets the following criteria:

1. An add-on; not included in the default installer.
2. Not directly suggested to users upon installation (i.e. no "Would you
like to help us blah blah blah?" which installs the spyware; that's
manipulative).
3. Every single transmission of data requires explicit authorization,
with a review dialog that gives a good enough idea of what data is
transmitted. Alternatively, prominent visual indication on the LO
windows that activity info is being gathered.
4. Personally-identifying information scrubbing mechanism, before
transmission.
5. Easy to remove the spyware.

Will try to make the meeting.

Eyal

PS - Once you install spyware, the tendency is to spy on more and more
activity. Let's not go down that road.




On 30/06/2022 11:51, Heiko Tietze wrote:

Hi all,

this is a very early invitation to a meeting in two weeks, which
hopefully allows you to schedule this slot.

PolyPoly [1] is a start-up company with the goal to collect user data in
a fair and transparent way and to allow combining information by keeping
full control. Bjoern had a talk at the LibreOffice conference and
recommended it for LibreOffice. In fact we need user metrics for various
questions, for example the default UI [3], while we clearly have
problems with representativity in own surveys [4].

The plan for this meeting is to collect ideas, outline areas for
investigation, and prepare the next steps. As always: Everyone is
welcome to join the call and share their opinion. The meeting will be
held on Wednesday, July/13, 20:00 CEST/GMT+2 resp. 6pm UTC at
https://jitsi.documentfoundation.org/design.

Cheers,
Heiko

[1] https://polypoly.org
[2] https://peertube.opencloud.lu/w/koPJCc1NYkoi2wADvbvhb2
[3] https://bugs.documentfoundation.org/show_bug.cgi?id=135501
[4]
https://design.blog.documentfoundation.org/2021/10/18/results-from-the-survey-about-libreoffice-calc/



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2022-Jul-13

[Eyal Rozenberg]

There are a more concerns, and questions, and potential answers to
questions. These include additions I've made after the session
concluded, based partially on my points in the chat, and as suggested I
do by Heiko. For now I'll just add the Questions section after my additions.

Questions

+ Why is it necessary to collect LO user data?
+ What LO user data (or aggregation-of-data) is it necessary to
collect?
   + wouldn't it be better to not collect data at all (rather than doing
 the PP approach)
 + open source community tried with Discourse, for example, but
better we reclaim data; data is key for many questions; PP is neutral
and transparent
+ Is the list of investors in PP, and how much they invested,
publicly accessible?
+ Will the revenues and specific revenue sources of the cooperative
be accessible to the public?
 + PP does not own the data; PP is a cooperative, all income will
be shared
 + Shared by the investors in PP?
   + is PP open source / what license
 + yes, dual-licensing
   + what would be the scenario when PP becomes included
 + probably a question "Do you want to share data..." as opt-in
 + That's manipulative and inappropriate:
1. Many people just click "yes yes yes" to get through
installations, assuming it's all benign.
2. People will be presented an imbalanced, overly positive
description of what this data collection will mean. Why? Because TDF
expects to gain something from data collection, i.e. has an interest in
people saying yes. Possibly also because TDF stands to collect money
from Yes clicks.
Something more than an extension - and not one that the installer
prompts the user to install - is problematic.
   + amount of data is frightening
   + 10 years of extensive Google usage is about 100MB
   + This is a Red Herring. What's frightening is that information
about people's habits, choices, tendencies, proclivities - maybe even
aspects of the contents of their documents, determined indirectly - will
be collected. Delicate personal information may sometimes require only a
single sentence - 100 B, not 100 MB - to express.
   + an option might be to keep raw data for only a short period and
condense then
   + feedback channel, something that allows the individual to compare
with the average
 + could be something for the future
   + include questionaires eg to split user types
 + demographics are included already
 + identification with brands is built-in
   + any legal constraints
 + LibreOffice sends crash reports to TDF
 + Such data collection may get LO kicked off of platforms/systems
with commitment to user privacy.
 + Such data collection may also prevent LO use in organizations,
as a potential security hazard (e.g. governments, large organizations
with IT privacy policies)
   + what are the next steps
 + Unless there is A clear characterization of user data that must,
or should, be collected, that has been approved by an appropriate body
of TDF, I believe it is illegitimate to proceed further at all.
 + involve the ESC
 + write a blog post and involve the community




--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2022-Jul-13

[Eyal Rozenberg]

On 14/07/2022 0:44, John Mills wrote:

Do you consider people manipulated by asking them an unambiguous
question that would default to no?


"Would you like to place a bet of 100 EUR on a die roll, winning an
extra 100 on a 6 and losing otherwise? [N/Y]: N_

Suppose I ask a million people this question. Some non-negligible
percentage will say Yes. Some of them have misread; some have
misunderstood; maybe they didn't read at all and just assumed they
should say Y for LO installation questions. Maybe the actually
momentarily in a betting mood and I caught them in this moment of
weakness. But I've manipulated all of these people.

And that's with a question that's worded fairly; your question won't be.
How do I know this? Because you've basically indicated what phrasing you
expect to have:


Also are LibreOffice users too
'stupid' to understand that they are empowering innovation by answering
a request that would not collect and personaliy identifiable data?


I'm sure that's how you'll sell them onto accepting your data collection
+ money-making scheme. And many people will click "yes" without
realizing what this means.


Why is it unreasonable to collect data with the express permission of
users


In my example above, you will be collecting X% of people's 100 EUR after
they have given express permission. Plus, like I said, you will likely
manipulate people into giving their permission, so it won't be _that_
express. It will make LO another one of those shady applications that
you have to warn people about.

> with the sole aim of improving the application and user experience?

But this is not _quite_ the sole aim, now is it? Or did polypoly stop
being a for-profit organization while I wasn't looking?


Look, even if someone might convince me some data collection is
appropriate (which is not impossible, but hasn't happened yet), your
rhetoric so far makes me feel it's probably for the best if polypoly
were not involved in it.

--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Agenda for the design/UX meeting 2022-Oct-12 (WED)

[Eyal Rozenberg]

Hello Heiko and list denizens,

I'm going to _try_ and make it to this week's meeting, but it's unlikely
I'll be available before 21:00 CEST. I realize that the meeting is held
when it is held, and a later time may not be convenient for you, but if
it so happens that some of you (or Heiko, if he's the only participant
today) can accommodate this, I would be very grateful. Alternatively, if
you would be willing to reschedule some of "my" tickets for next time
that would also be nice.


Sorry,
Eyal

On 10/10/2022 16:22, Heiko Tietze wrote:

Hello all,

the next design/UX meeting is on Wednesday, Oct/12,
20:00 CEST/GMT+2 resp. 6pm UTC.


Here is the agenda:

  * GALLERY: Option to add files to a "Favourites" theme in gallery
    + https://bugs.documentfoundation.org/show_bug.cgi?id=151222
    + is there need for such a shortcut in the current workflow (which of
  users wouldn't be familiar with)

  * Size submenu of table selection context menu not clear enough
    + https://bugs.documentfoundation.org/show_bug.cgi?id=151284
    + change "size" and/or split into row/col or WF/NAB

  * Consider adding "Move to Top" and "Move to Bottom" buttons under
effects list
    + https://bugs.documentfoundation.org/show_bug.cgi?id=151345
    + is Move To Top/Button a requirement?

  * Need mechanism for re-centering "Slides pane" onto current slide with
    edit focus
    + https://bugs.documentfoundation.org/show_bug.cgi?id=151170

  * New Paste Special Operations: Maximum, Minimum
    + https://bugs.documentfoundation.org/show_bug.cgi?id=151205
    + introduce another paste special operation similar to Add, Subtract...
  to either keep the target or use the source depending on min/max?

  * Add ability to toggle a reader / reading view (mode) in Writer
    + https://bugs.documentfoundation.org/show_bug.cgi?id=151320
    + introduce a special reading mode or improve the web view mode
  with muted colors


Full pad including backlog is here:
https://pad.documentfoundation.org/p/design

Hope to see you on Jitsi at https://jitsi.documentfoundation.org/design

Cheers,
Heiko


--
To unsubscribe e-mail to: design+unsubscr...@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

[libreoffice-design] Re: [New post] Community support needed: We want to use our users personal data

[Eyal Rozenberg]

What, this again?

polypoly is a commercial enterprise planning to make money by selling 
the results of spying on people. Not to mention that it makes 
Euro-nationalist arguments about how it's important for European 
commercial entities rather than non-European ones to profit from spying 
on people.


Why are we exposing our users to their propaganda via the blog? Before I 
address that post on the merits, I would really like to ask you all, and 
particularly Heiko, to take that blog post down.


Eyal



On 01/11/2022 17:16, LibreOffice Design Team wrote:
Site logo image 	Heiko Tietze posted: "What comes to your mind, when you 
ask yourself why people use LibreOffice? A "stunning user experience" is 
likely not in the top list. And unfortunately we share this problem with 
a lot of user facing Free Software. And there is a common reason: We 
val" LibreOffice Design Team 	



  Community support needed: We want to use our users personal data
  




Heiko Tietze

Nov 1

What comes to your mind, when you ask yourself why people use 
LibreOffice? A "stunning user experience" is likely not in the top list. 
And unfortunately we share this problem with a lot of user facing Free 
Software.


And there is a common reason: *We value the privacy of our 
users.*


Empty walkway in green field 



Photo by Erik Mclean at Pexels 



While our proprietary competitors constantly (mis)use user data to 
improve the UX of their products, we are maneuvering in thick fog. And 
whenever we try to reach out to our users to decide about design 
directions, we mainly get feedback from white, male nerds [1 
]. You hopefully see the problems this implies.


The only solution is: We need to be able to evaluate usage information 
from everyone else too. While preserving the privacy of our users of course.


We need to be totally clear here, as we are touching common ground of 
Free Software Communities. Data protection and control over own data is 
a major driver for a large fraction of our community [2 
]. And it is for us too. Only when it comes to avoiding data in the first place, we do have to state, that we need aggregated personal data to able to do our work. We do not think creating data is bad per se.



  Is there a third way?

The current data economy is set up to send out personal data to the 
algorithms. Unfortunately data can easily be copied, and once it leaves 
your property, you lose all control over it. So, today, you either 
surrender and give up on your personal data or have to avoid producing 
data in the first place, which is hard work.


But how about a third way, where all personal data is stored locally on 
users' devices and only the algorithms are sent to the data to learn? 
Then we only have to assure that the algorithm is not harming the 
privacy in anyway, that the results from those algorithms cannot be 
de-anonymized anymore and we can use the aggregated data of our users 
without compromising the integrity of a single user's privacy.


The good news: We believe that we have found a partner project, 
polypoly.coop  that creates exactly the 
infrastructure for this third way.


With this post we ask you, the community for your help and support for 
collaboration. We need you as a critical partner to watch out all we do 
aligns with our values. We, the UX team need the results of this 
collaboration to understand and reflect the needs of our diverse 
community. And we need your technical excellence to make sure we keep 
the basic promise: Any single user's privacy is preserved.


You can find a lot of information about /polypoly/ on their website. We 
still want to highlight a few aspects that make us think polypoly is the 
right project to partner with:


  * /polypoly/ is legally organized as a cooperative. Only individuals
can become members. Each member has one vote, no matter how many
shares are owned. This assures that /polypoly/ will always work for
and in the interest of the users and can never be bought by big money.
  * /polypoly/ is Free Software, following a dual licencing model that
allows the commercial world to use the infrastructure in proprietary
products. You can find the source code here:
https://github.com/polypoly-eu/polyPod

  * the dual licenc

Re: [libreoffice-design] Re: [New post] Community support needed: We want to use our users personal data

[Eyal Rozenberg]

Heiko, that post speaks in the collective first person, "we", and extols 
polypoly - while hiding its commercial nature and interests. This should 
not be posted on the blog - where posts ostensibly represent the 
project's decisions and position. For a discussion, we have mailing 
lists and jitsi sessions. And we have, in fact, had somewhat of a 
discussion, which did not result in an agreement to accept this 
proposal, nor an agreement on the premise of the proposal.


So - I ask that the post be removed.

Eyal


On 01/11/2022 18:05, Heiko Tietze wrote:
Your opinion is welcome, of course. Besides disliking the phrasing of 
your concerns I wonder what alternatives you have in mind. Or do you 
reject the need for user data? All good questions to discuss at the 
right place, and that's what the blog post is for.


On 01.11.22 16:34, Eyal Rozenberg wrote:

What, this again?

polypoly is a commercial enterprise planning to make money by selling 
the results of spying on people. Not to mention that it makes 
Euro-nationalist arguments about how it's important for European 
commercial entities rather than non-European ones to profit from 
spying on people.


Why are we exposing our users to their propaganda via the blog? Before 
I address that post on the merits, I would really like to ask you all, 
and particularly Heiko, to take that blog post down.


Eyal



On 01/11/2022 17:16, LibreOffice Design Team wrote:
Site logo image Heiko Tietze posted: "What comes to your mind, 
when you ask yourself why people use LibreOffice? A "stunning user 
experience" is likely not in the top list. And unfortunately we share 
this problem with a lot of user facing Free Software. And there is a 
common reason: We val" LibreOffice Design Team 
<https://design.blog.documentfoundation.org>



  Community support needed: We want to use our users personal data
<https://design.blog.documentfoundation.org/2022/11/01/community-support-needed-we-want-to-use-our-users-personal-data/>



Heiko Tietze

Nov 1

What comes to your mind, when you ask yourself why people use 
LibreOffice? A "stunning user experience" is likely not in the top 
list. And unfortunately we share this problem with a lot of user 
facing Free Software.


And there is a common reason: *We value the privacy of our 
users.<https://design.blog.documentfoundation.org/wp-content/uploads/sites/2/2022/11/pexels-erik-mclean-4751200.jpg>*


Empty walkway in green field 
<https://design.blog.documentfoundation.org/wp-content/uploads/sites/2/2022/11/pexels-erik-mclean-4751200-1.jpg>


Photo by Erik Mclean at Pexels 
<https://www.pexels.com/photo/empty-walkway-in-green-field-4751200/>


While our proprietary competitors constantly (mis)use user data to 
improve the UX of their products, we are maneuvering in thick fog. 
And whenever we try to reach out to our users to decide about design 
directions, we mainly get feedback from white, male nerds [1 
<https://design.blog.documentfoundation.org/2021/10/18/results-from-the-survey-about-libreoffice-calc/>]. You hopefully see the problems this implies.


The only solution is: We need to be able to evaluate usage 
information from everyone else too. While preserving the privacy of 
our users of course.


We need to be totally clear here, as we are touching common ground of 
Free Software Communities. Data protection and control over own data 
is a major driver for a large fraction of our community [2 
<https://design.blog.documentfoundation.org/2017/09/13/open-source-means-libreoffice-users/>]. And it is for us too. Only when it comes to avoiding data in the first place, we do have to state, that we need aggregated personal data to able to do our work. We do not think creating data is bad per se.



  Is there a third way?

The current data economy is set up to send out personal data to the 
algorithms. Unfortunately data can easily be copied, and once it 
leaves your property, you lose all control over it. So, today, you 
either surrender and give up on your personal data or have to avoid 
producing data in the first place, which is hard work.


But how about a third way, where all personal data is stored locally 
on users' devices and only the algorithms are sent to the data to 
learn? Then we only have to assure that the algorithm is not harming 
the privacy in anyway, that the results from those algorithms cannot 
be de-anonymized anymore and we can use the aggregated data of our 
users without compromising the integrity of a single user's privacy.


The good news: We believe that we have found a partner project, 
polypoly.coop <http://polypoly.coop> that creates exactly the 
infrastructure for this third way.


With this post we ask you, the community for your help and support 
for collaboration. We need you as a critical partner to watch out all 
we do aligns with our values. We, the UX team need the results

Re: [libreoffice-design] Minutes from the UX/design meeting 2022-Nov-03

[Eyal Rozenberg]

On 03/11/2022 15:20, Heiko Tietze wrote:

  * Writer: Caption strings should be set to document language instead
    of UI language
    + https://bugs.documentfoundation.org/show_bug.cgi?id=151020
    + use translation from PS for variable names requested on ask.libo 
(André)
    + not much of a problem, users can change category names manually 
(Dieter)

    + unclear set-up of document / UI language (Eyal)
    => keep the ticket with low priority for reference


Since I could attend the meeting, I'll mention I've opened a separate 
issue about the more general question of whether we actually have a 
"document language":


https://bugs.documentfoundation.org/show_bug.cgi?id=151906

Eyal

--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2022-Nov-17

[Eyal Rozenberg]

On 17/11/2022 16:28, Heiko Tietze wrote:

  * Allow regular deletion of selection containing an entire
    generated index/table
    + https://bugs.documentfoundation.org/show_bug.cgi?id=152030
    + at creation time and later it is possible to unset the protection 
flag

    + the context menu provides delete
    => not deleting protected content is a safety measure


For tables/indices - no, it isn't:

1. It's not a safety measure, since these tables/indices are generated 
content, which can later be re-generated. In fact, it is _safer_ to 
delete a generated table/index than any other piece of content.


2. It's not a measure against deleting the content, it's intended to 
prevent selective alteration of it.


And I should also mention the "safety measure" claim has already been 
made and replied to on the bug page.


I'm sorry I couldn't attend, I was at work.

Eyal

--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] New LibreOffice user experience designer

[Eyal Rozenberg]

I have some suggestions on more self-educative work, if I may, rather 
than helping with something concrete:


1. Obligatory pitch due to being an RTL language guy: Our languages, as 
well as CJK languages, have many particular issues with LO, which are 
usually due to original software developers or UI designers not having 
taken these languages (or quirks thereof) into consideration when 
working on some feature or piece of UI. I recommend that you check out a 
few presentations at LO conferences about this. Specifically, the two 
from this year's LibOCon:


https://events.documentfoundation.org/media/libreoffice-conference-2022/submissions/YNNRCV/resources/2022-09_Rozenberg_Eyal_-_State__Z8YSSPz.pdf

https://events.documentfoundation.org/media/libreoffice-conference-2022/submissions/83UJJG/resources/State_of_CJK_issues_of_LibreOff_kXy1cOh.pdf

2. Look for some UI/UX bugs which have seen spirited/intense debates, 
where the debates were not merely splitting hairs but about conflicting 
expectations and considerations. There bug pages are tedious to read 
through but also informative in learning how people often don't simply 
disagree, but have different visions, motivating principles or 
considerations underlying their positions on UI/UX choices; and how as a 
project officer you can help by making the different considerations more 
explicit and clear to everyone when discussions are had.


Perhaps the most famous, though flame-full, example would be:

https://bugs.documentfoundation.org/show_bug.cgi?id=135501

3. Trivial, but still worth suggesting: Take some time to try out LO 
modules which you use less frequently in your daily life, and features 
within those modules you use less frequently. In LO, Writer gets most of 
the attention, then Impress and Calc, and all the rest sometimes feel 
like an afterthought w.r.t. QA work. Even true for me personally, I'm 
afraid.


Wishing you all the best with your new role,
Eyal


On 17/11/2022 20:33, Lizzie Kim wrote:

Hi Heiko,

My name is Liz, I am the new UX designer with LibreOffice! Is there
anything I can immediately help with? I am planning to attend the UX design
meeting next week, but until then I can help with anything else as well. I
look forward to working with you!

Best,
Liz Kim



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Jan-12

[Eyal Rozenberg]

I have to protest meeting in which most bugs up for discussion are ones I've 
either filed or have been part of the discussion on, scheduled without 
consulting me regarding the time. I'm at work in the afternoon and can usually 
not attend at these hours. And then of course when I'm not there, naturally, 
there is typically nobody to argue for the idea nor to address reservations 
which are first brought up in the design meeting rather than on the bug page.

> Sent: Thursday, January 12, 2023 at 3:43 PM
> From: "Heiko Tietze" 
> To: "LibO Dev" , "LibO QA" 
> , "LibO Design" 
> 
> Subject: [libreoffice-design] Minutes from the UX/design meeting 2023-Jan-12
>
> Present: Cor, Heiko
> Comments: Stuart, Eyal, Seth, Dieter, Mike
> 
> Tickets/Topics
> 
>   * PS formatting gets lost, if you paste text into an new document
> with same name of PS, but different settings
> + https://bugs.documentfoundation.org/show_bug.cgi?id=138786
> + keep target style when pasting a source with the same PS (Heiko)
>   or let the user confirm (Dieter) or provide some kind of
>   paste special option (Mike)
> + unclear use case (Heiko)
> + is a bug: pasting styled content should take the formatting
>   from the source if the style is unused, otherwise the target style
>   + works for some but not all styles (Cor)
> => bug for the particular style
> 
>   * "Drawing Style" should be renamed "Drawing Object Style"
> + https://bugs.documentfoundation.org/show_bug.cgi?id=152656
> + +1 (Stuart), -1 (Roman, Heiko), challenge for "Default Drawing Style"
> + "Default Object Style" or "Default Style" or
>   "Default Drawing-Object Style" (Eyal)
> + not worth the effort (Cor)
> => resolve WF
> 
>   * Change "outline level" to "heading level" in UI and help pages for Writer
> + https://bugs.documentfoundation.org/show_bug.cgi?id=152605
> + "Chapter and Outline Numbering", here "Heading Level" (Stuart)
> + "Heading and Outline Numbering" (Eyal) misleading as the request is 
> about
>   *Outline Level* supposedly named "Heading Level" (Seth)
> + just "Level"; the Level is defined in a "*Chapter* numbering"
>   dialog; could be "Numbering level" (Heiko)
>   + no improvement so rather keep it (Heiko)
> + agree to "Heading Level" but we also have a frame label; and the tab 
> itself
>   is named "Outline & List" (Cor)
> + afraid of unknown consequences (Cor)
> => recommend to keep "outline level"
> 
>   * Introduce a Slide/Page style category in Impress
> + https://bugs.documentfoundation.org/show_bug.cgi?id=152655
> + provide kind of direct formatting opportunity via sidebar
>   for many different options (Eyal)
> + unclear relation to master slides, everything should be covered (Cor)
> + introducing a new style means to trigger the standardization and
>   to add the new feature ultimately to every application (Heiko)
> + it will bring _more_ complexity to the users..
>   + better improve gaps in master slide implementation (Cor)
> => invalid request
> 
>   * "Hybrid PDF" must share embedded media between the ODT and the proper PDF
> + https://bugs.documentfoundation.org/show_bug.cgi?id=152661
> + excessive increase in size (Eyal)
> + do understand the issue - would be nice if that can be avoided, but..
> + PDF and ODF are different formats, keeping both at full length
>   has its value (Stuart, Heiko)
> + likely requires to change every PDF reader to access media from
>   a shared-data section - or to update all ODF writer/reader and the
>   standardization to do so (Cor)
> => WF
> 
> -- 
> To unsubscribe e-mail to: design+unsubscr...@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
> 

-- 
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Feb-15

[Eyal Rozenberg]

Heiko, you again scheduled bugs of mine for a discussion without taking 
a moment to check whether I can join the meeting.


I asked you not to do that and I'm asking you again. This is unfair, 
especially after I've explicitly asked that you not do that.


The treatment of these bugs is usually entirely different based on 
whether I attend the session or not. What seems to happen when I'm not 
there is that the case for the issue is not made seriously, and thus 
objections or claims which I would probably be able to convincingly 
rebut or disprove are stated and accepted with no retort or objection.


Now, I won't deny that this is not something specific to bugs I file: A 
user who does not have design committee participant support from the 
get-go, and who does not attend a committee session, will often not have 
any participant serve as the advocate or champion for that bug / that 
user - and may not get a "fair shake" in the evaluation of their bug.


The difference in my case that you know that I can occasionally - but 
not always nor most times - attend. And session agendae are announced 
just a single day in advance, and not on the relevant bug pages - so, 
not enough time for me to notice. Finally, it is usually the case that 
multiple bugs I have filed are placed on the agenda for the same 
session, i.e. there are "Eyal's filings sessions", which are scheduled 
without me being able to react.


This is quite inappropriate and I again ask that you stop doing that. 
Either ping me before scheduling my filings, or make the announcement a 
good number of days in advance.


Also, and for the benefit of other bug filers, it would not be a bad 
idea to post a comment on the pages of bugs which are about to come up 
in committee, about the upcoming committee session.


Eyal




On 15/02/2023 22:21, Heiko Tietze wrote:

Present: John, Cor, Heiko
Comments: Stuart, John, Pedro, Rafael

Tickets/Topics

  * Styles Preview should be able to show a grid of list
    styles (Tabbed UI)
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153525
    + a "More..." button could open the Stylist in the
  sidebar (Stuart, Heiko)
    + could be a small expander button on the lower right edge (Cor)
    + strong support for a Tabbed NB in general and completely
  implemented features in particular (John, Pedro, Rafael)
    + take the full space is easy to achieve, expanding into a list
  might a bit more difficult
    => do it

  * Most bundled page styles are nonsensical and/or redundant
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153534
    + every single page style has a use case (Cor)
    + never had any problems with the list of page styles (John)
    + the (small) list can also be filtered (Heiko)
    => resolve WF/NAB

  * Style organizer's "Next style"'s function not clear to user
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153600
    + label and help is clear (John)
    + labeling it "Next paragraph style" adds no information and
  it's reasonably clear what the dialog/label is talking
  about (Cor)
    => resolve WF/NAB

  * Editing:- Feature Request "go to - special" feature needed
    + https://bugs.documentfoundation.org/show_bug.cgi?id=149933
    + introduce function to search for special content like blanks,
  constants etc. sounds like a good idea (Cor)
    + would be a comfortable shortcut for many searches (Heiko)
    + alternatively we could have a special entry in the sidebar
  + would be inconsistent as blank evaluates data while the
    existing Navigator options detect model content (Cor)
    => do it

  * Change "heading level" to "outline level"
    + https://bugs.documentfoundation.org/show_bug.cgi?id=152605
  + see comment 14 for (tentatively accepted) proposal
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153499
  + use index level for index entry outlines
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153596
  + see also ToC dialog
    => consistency in naming is good, go for it

  * Permit "No User Input" as a data validation which would then
    permit filter sorting
    + https://bugs.documentfoundation.org/show_bug.cgi?id=149497
    + reasonable request
    + (Standard/Auto-) Filter work on protected sheets
    + Sorting should work too, at least optional (Cor)
    + afraid of data integrity issues aka references to a certain
  cell that changes after sorting (Heiko)
    + option should not be at data validation but at the
  protect sheet dialog among the other exceptions (Heiko)
  + has the drawback that it applies to the whole sheet (Cor)
    => allow users to permit sorting



--
To unsubscribe e-mail to: design+unsubscr...@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 Polic

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Feb-15

[Eyal Rozenberg]

I was making a point about procedure and conduct, but - I'll bite :-)

* I use the term "bug" because we use "bugzilla" where everything is a 
"bug". I was referring to issues more generally - either bugs or RFEs.


* The question whether something is a proper bug or an RFE is often up 
for debate (i.e. "does this _have_ to change or would it only be 
_better_if this changed").


* You're assuming that issues discussed in design committee sessions 
take into account what's said on the bug page. That is often not the 
case. Session participants often did not read the bug page when it comes 
up for discussion, or only skimmed it, or only read the first comment. 
That is how one often finds comments in the minutes which are, in fact, 
already addressed on the bug page.


* When a bug/issue is missing a significant piece of information, say 
not addressing a major likely downside - that may be because of lack of 
rigor by the reporter; or because they had failed to notice such a 
downside; or possibly because the downside is actually unlikely (or not 
a downside), and was perceived only due to a misunderstanding / 
miscommunication.


* Issue reporters should absolutely not be expected to demonstrate an 
understanding of how and why the current state of affairs exists. This 
typically (not always) helps when reporting a bug or RFE, but it 
perfectly acceptable to file issues based solely on user experience 
and/or common-sense reasoning, without getting inside the head of 
whoever set the current state of affairs.




On 16/02/2023 1:39, toki wrote:

On 15/02/2023 21:41, Eyal Rozenberg wrote:

objections or claims which I would probably be able to convincingly 
rebut or disprove are stated and accepted with no retort or objection.


An RFE masquerading as a bug report has to stand on its own merits.
It has to provide a number of datapoints:
* What the benefits of the enhancement are;
* What the downsides of the enhancement are;
* How to minimize the negative impact of those downsides;
* How to minimize the negative impact of the enhancement;
* Reasons why the enhancement would be declined;
** Explain why the reasons for declining the enhancement are 
insufficient to warrant doing so;

* Present multiple use-cases showing how the enhancement aids usage;
* Provide alternative choices of action to attain the desired outcome(s) 
that the RFE requests;

* Demonstrate an understanding of how and why the current framework exists;

jonathon




--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Feb-15

[Eyal Rozenberg]

Announcement 30 hours before the session is not announcement in advance. 
People - who do not work on LibreOffice on a daily basis and may have 
all sorts of things going on in their life - cannot be expected to 
reply, let alone make themselves available, at 30-hours' notice. If it 
were, say, a week - then you could say there's notice in advance.


Also, again, there's a difference between one issue by a person coming 
up for discussion, and several, constituting most of the session.


As for the two topics - the shorthand minutes entries about them suggest 
that the two issues were not discussed seriously, IMNSHO. At any rate, I 
commented on the bug pages to address both new comments and the relevant 
parts of the session minutes.


Eyal



On 16/02/2023 9:07, Heiko Tietze wrote:
the meeting agenda is always announced in advance. This time it was on 
Wednesday what I assume to be possible for you. You could have sent a 
notice to postpone a topic.


Flagging tickets as to-be-discussed sounds easy but adds noise to the 
report and wouldn't solve your problem.


For the two topics from yesterday I think one was unanimously 
resolved/NAB and the other considered to not benefit the modification. 
Please don't understand input from UX as a gatekeeper to the 
development, you are free to reopen tickets and seek for response from 
other people.


Cheers,
Heiko

On 15.02.23 22:41, Eyal Rozenberg wrote:
Heiko, you again scheduled bugs of mine for a discussion without 
taking a moment to check whether I can join the meeting.


I asked you not to do that and I'm asking you again. This is unfair, 
especially after I've explicitly asked that you not do that.


The treatment of these bugs is usually entirely different based on 
whether I attend the session or not. What seems to happen when I'm not 
there is that the case for the issue is not made seriously, and thus 
objections or claims which I would probably be able to convincingly 
rebut or disprove are stated and accepted with no retort or objection.


Now, I won't deny that this is not something specific to bugs I file: 
A user who does not have design committee participant support from the 
get-go, and who does not attend a committee session, will often not 
have any participant serve as the advocate or champion for that bug / 
that user - and may not get a "fair shake" in the evaluation of their 
bug.


The difference in my case that you know that I can occasionally - but 
not always nor most times - attend. And session agendae are announced 
just a single day in advance, and not on the relevant bug pages - so, 
not enough time for me to notice. Finally, it is usually the case that 
multiple bugs I have filed are placed on the agenda for the same 
session, i.e. there are "Eyal's filings sessions", which are scheduled 
without me being able to react.


This is quite inappropriate and I again ask that you stop doing that. 
Either ping me before scheduling my filings, or make the announcement 
a good number of days in advance.


Also, and for the benefit of other bug filers, it would not be a bad 
idea to post a comment on the pages of bugs which are about to come up 
in committee, about the upcoming committee session.


Eyal




On 15/02/2023 22:21, Heiko Tietze wrote:

Present: John, Cor, Heiko
Comments: Stuart, John, Pedro, Rafael

Tickets/Topics

  * Styles Preview should be able to show a grid of list
    styles (Tabbed UI)
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153525
    + a "More..." button could open the Stylist in the
  sidebar (Stuart, Heiko)
    + could be a small expander button on the lower right edge (Cor)
    + strong support for a Tabbed NB in general and completely
  implemented features in particular (John, Pedro, Rafael)
    + take the full space is easy to achieve, expanding into a list
  might a bit more difficult
    => do it

  * Most bundled page styles are nonsensical and/or redundant
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153534
    + every single page style has a use case (Cor)
    + never had any problems with the list of page styles (John)
    + the (small) list can also be filtered (Heiko)
    => resolve WF/NAB

  * Style organizer's "Next style"'s function not clear to user
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153600
    + label and help is clear (John)
    + labeling it "Next paragraph style" adds no information and
  it's reasonably clear what the dialog/label is talking
  about (Cor)
    => resolve WF/NAB

  * Editing:- Feature Request "go to - special" feature needed
    + https://bugs.documentfoundation.org/show_bug.cgi?id=149933
    + introduce function to search for special content like blanks,
  constants etc. sounds like a good idea (Cor)
    + would be a comfortable shortcut for many searches (H

Re: [libreoffice-design] Agenda for the design/UX meeting 2023-Mar-15 (WED)

[Eyal Rozenberg]

Thanks for posting this a week in advance.

Can I ask for a deferment of discussion of the issues I've opened (all 
of these I think) to a week later? I will be traveling for a family 
occasion between the 14th and the 17th and will not be able to make it. 
I promise not to complain about other issues coming up instead :-)


Eyal

On 07/03/2023 14:36, Heiko Tietze wrote:

Hello all,

the design/UX meeting *next week* is

on: Wednesday, Mar/15, 20:00 CET+1 resp. 7pm UTC
at: https://jitsi.documentfoundation.org/design


Here is the agenda:

  * No UI for flipping the column order of a table
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153995
    + move column left/right or have a dialog with more flexibility

  * When selecting a cell or table row/column, "Position & Size"
    regards entire table
    + https://bugs.documentfoundation.org/show_bug.cgi?id=151338
    + need for precise cell size, and if how to realize the interaction

  * Use of "numbering" instead of "bullets"/"bulleting" for bulleted list
    + https://bugs.documentfoundation.org/show_bug.cgi?id=153986
    + Bullets & NUmbering > Position/Customize "number*" for
  unordered types?

  * Export as PDF only exports text selected (if text selected)
    + https://bugs.documentfoundation.org/show_bug.cgi?id=152304
    + revise bug 54908 or make the selection more clear

  * Show small preview in Position & Size dialog
    + https://bugs.documentfoundation.org/show_bug.cgi?id=154026


All topics being on the agenda are collected at this list: 
https://bugs.documentfoundation.org/buglist.cgi?cmdtype=dorem&namedcmd=meeting&remaction=run&sharer_id=32942
The next meeting is on Thursday Mar/09, agenda can be found here: 
https://listarchives.libreoffice.org/global/design/2023/msg00023.html


Cheers,
Heiko


--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Moving to LibreOffice 8?

[Eyal Rozenberg]

I respectfully disagree with Italo.

First, about the "frame of reference". In my opinion, decisions such as 
major version number bumping are not, first and foremost, marketing 
decisions. That is a _consideration_, since the version number is 
declarative than technical. But - such an action should be "truthful" 
before being "marketable".


It is more important, in my opinion, that users and potential users 
receive trustworthy signaling from the project - not just w.r.t. version 
numbers, but generally - than for the media to get a gimmick for coverage.


A second point is that bumping a version number without a major 
innovation moves you a few more steps into the category of, say, Firefox 
and such, where versions just increase automatically with no meaning 
whatsoever. Italo, you said we are perceived as a "real innovator"; 
well, when a real innovator starts having hollow version number bumping, 
that perception fades.


Finally, everyone who likes the marketing potential of version 8 - 
great, but - keep that benefit for when we have a significant step 
forward to celebrate. Don't squander it.



Eyal

PS:  availability on a new platform is not a reason to bump a version 
number. It's the "same" software, but built for another target, so same 
version as before. IMHO anyway.




On 27/03/2023 20:11, Italo Vignoli wrote:
Moving to LibreOffice 8 (instead of 7.6) makes sense for marketing 
purposes, as media is looking at LibreOffice as the real innovator in 
the open source office suite market, and the feeling of journalists is 
that we are forever stuck at 7.x.


We all know that the next version will not include any significant 
innovation which can justify the change of version, apart from the new 
build system for Windows and the availability of LibreOffice for Arm 
processors on Windows (which has not been announced).


Playing with the number 8, which can be rotated 90° to become the 
"infinite" symbol, we can frame the next version as LibreOffice for an 
infinite number of users, as we cover all hardware platforms and all 
operating systems for personal productivity.


This is my opinion. If the community wants to stick with 7.6, I won't 
insist. I have received enough insults both public and private for the 
marketing plan, and I am still receiving them from a few people, that I 
am not willing to enter into that process again (even if the decision on 
the "community" tag has not been mine, but it looks like people have a 
very short memory).


Looking forward to your thoughts.


--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Mar-29

[Eyal Rozenberg]

Regarding bug 153899, "Clone format of unmerged cells breaks up merging, 
applies to first unmerged cell only"


So the two pertinent questions brought up in the bug (in comment 4) are:

Q1: Should "being merged" be considered one of the formatting properties 
of a cell?


Q2: If "being merged" _is_ a formatting property, then should the 
clone-formatting apply to all the separating cells getting unmerged or 
just to the first?


I don't see an answer in the meeting minutes. Here's what the minutes say:


    + merging cells with the keep option does exactly this, we
  must not format hidden cells


this bug does not regard the merging action, so either this sentence is 
incorrect or I misunderstand it.



    + copying/cloning merged cells takes merge state into account,
  however, applying a format via cell style, which is the supposed
  workflow does not


I'm sorry, that does not make sense. This bug is about "clone 
formatting". If it takes the merge state into account, the answer to Q1 
is affirmative. Now, what about Q2?



    + cloning the merged state is a convenience feature


I don't understand this sentence. Cloning is a feature in LO calc, and 
you guys decided it also applies the merged or unmerged state. What does 
it matter whether cloning is a "convenience feature" or not?


Given your position, the obvious decision is for the format to apply to 
all unmerged cells. I haven't read any argument for the alternative in 
the minutes. And thus I don't understand why you concluded



    => WF/NAB


rather than will-fix, is-a-bug.

-

Regarding bug 154080: "Comment indicator is too small, non-circumspect, 
easy to miss"



    + indicators have changed recently and are easy to spot at 100%


They're not _easy_ to spot, but it's certainly better than before, so I 
can live with it.


>   but still somewhat harder at 200%

you mean, because they coalesce with the text overflow triangles?


    => move checkboxes and colors for text overflow and comment indicator
  into application color (easy hack w. medium to interesting 
difficulty)


What will this achieve? Or rather, how will it help this issue?


--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-marketing] Re: [libreoffice-design] Moving to LibreOffice 8?

[Eyal Rozenberg]

Gustavo, it seems that what you're saying is that the _reality_ is a bit 
"boring" - a long sequence of minor releases without a 
fundamental/breakthrough change; and there is a desire to make it more 
interesting/exciting using a major version bump.


That is exactly what I'm opposing. Let's assume that the real situation 
is "boring" (I'm not sure that's the case, but still) and that, indeed, 
the changes since 7 are not fundamental enough to merit a version bump 
on their own (and I realize this is not in consensus either). In this 
state of affairs, evoking artificial interest in a new major version 
without substance behind it is a _marketing trick_, a psychological 
manipulation. One could even say it's mis-informing our users. It hurts 
user trust. Sure, it's not terrible to play with version numbers, but - 
I don't think that's something our users, current and potential, would 
like us to do.


"I guess the message of this version could be consolidation" - but what 
is consolidated about the code right now as opposed to 7.5 ?


Remember also, that as time progresses - an office suite's rate of 
change decreases. It is to be expected that major versions become 
farther between, and the release cycle becomes more "boring". Your 
reasoning, and this fact, combine to result in major version number 
inflation, which is the other thing I was cautioning about.


Eyal



On 06/04/2023 0:05, Gustavo Buzzatti Pacheco wrote:

Hi Eyal, all!

  I also respectfully disagree with you on some points. ;D

  I like the idea to move to 8, even with no big technical innovation 
(if we have, for sure it will be better).


  IMHO, long sequences of minor releases (7.6, in the current case) are 
getting boring and not important for the users (for both enterprise and 
individual profiles).


  I'm not saying that we should embrace the Firefox approach, but 
thinking about Italo's idea (8 <-> infinite), I guess the message of 
this version could be consolidation, not exactly innovation.


Best
Gustavo


On Tue, Mar 28, 2023 at 4:23 AM Eyal Rozenberg <mailto:eyalr...@gmx.com>> wrote:


I respectfully disagree with Italo.

First, about the "frame of reference". In my opinion, decisions such as
major version number bumping are not, first and foremost, marketing
decisions. That is a _consideration_, since the version number is
declarative than technical. But - such an action should be "truthful"
before being "marketable".

It is more important, in my opinion, that users and potential users
receive trustworthy signaling from the project - not just w.r.t.
version
numbers, but generally - than for the media to get a gimmick for
coverage.

A second point is that bumping a version number without a major
innovation moves you a few more steps into the category of, say,
Firefox
and such, where versions just increase automatically with no meaning
whatsoever. Italo, you said we are perceived as a "real innovator";
well, when a real innovator starts having hollow version number
bumping,
that perception fades.

Finally, everyone who likes the marketing potential of version 8 -
great, but - keep that benefit for when we have a significant step
forward to celebrate. Don't squander it.


Eyal

PS:  availability on a new platform is not a reason to bump a version
number. It's the "same" software, but built for another target, so same
version as before. IMHO anyway.



On 27/03/2023 20:11, Italo Vignoli wrote:
 > Moving to LibreOffice 8 (instead of 7.6) makes sense for marketing
 > purposes, as media is looking at LibreOffice as the real
innovator in
 > the open source office suite market, and the feeling of
journalists is
 > that we are forever stuck at 7.x.
 >
 > We all know that the next version will not include any significant
 > innovation which can justify the change of version, apart from
the new
 > build system for Windows and the availability of LibreOffice for Arm
 > processors on Windows (which has not been announced).
 >
 > Playing with the number 8, which can be rotated 90° to become the
 > "infinite" symbol, we can frame the next version as LibreOffice
for an
 > infinite number of users, as we cover all hardware platforms and all
 > operating systems for personal productivity.
 >
 > This is my opinion. If the community wants to stick with 7.6, I
won't
 > insist. I have received enough insults both public and private
for the
 > marketing plan, and I am still receiving them from a few people,
that I
 > am not willing to enter into that process again (even if the
decision o

Re: [libreoffice-marketing] Re: [libreoffice-design] Moving to LibreOffice 8?

[Eyal Rozenberg]

To put last thing first: I'm not staunchly opposed to bumping the 
version number to 8. So think of this as a theoretical discussion.


Anyway...

Noting Italo's explanation that:
> 80% (and probably more) of what we communicate is targeted to 
"normal" software users, and not to community members or to people with 
a technical background, who are already using LibreOffice.


, it seems to me that the strongest argument in favor of 
higher-frequency major version bumps is that it can increase 
media/Internet visibility for the new version somewhat, and thus likely 
to attract the attention of more potential new users, which is a good thing.


I find other arguments, though, to undermine this position more than 
buttress it.


Nigel Verity wrote:
> If I see that some software I use regularly has gone from 7.5 to 7.6, 
say, I wouldn't rush to upgrade


Great, what's the problem? Why should we be in a rush to get existing 
users to upgrade from 7.5 to 7.6? we're not failing to meet our 
quarterly sales targets in The Big Office Corporation (TM). It's 
actually better if we don't pretend it's important to upgrade to the 
next minor version if it isn't.


Italo Vignoli wrote:
> major releases of Microsoft Office are managed by marketing

Microsoft office is a commercial product, a commodity. And the company 
developing it is a vehicle for securing profits for its investors, not 
benefit to humanity (nor the users of office productivity suites). So, 
we should be at least skeptical about copying MS behavior regarding MSO 
in which their marketing wing is calling the shots.


Moreover - MSO versioning is kind of a mess; and even though I use MSO 
quite a bit (for reasons not relevant to this email) - for the life of 
me I can't tell what exactly changes between versions and whether I 
should bother to make sure and use a newer one.


> managed by marketing and not by developers

This is a false dichotomy. I'm not an LO developer; I didn't suggest the 
developers take over the version numbering; and I don't know that that 
would be a good thing. But decisions by marketers solely may also not be 
so great.


> marketing

about that...

LibreOffice is not a commodity. We don't exchange copies or licenses to 
use LibreOffice for money. And the set of people and organizations who 
use office suites, and the office suites they use, are not a market. 
_Some_  of that space is a market, but not our part (and there's also 
the ecosystem around LO, some of which is market-ish.) And while 
marketing experience is certainly useful in promoting the adoption and 
use of LO, there are still fundamental differences between doing that 
and "marketing" it. Some of them are practical (i.e. what "works" for 
commercial software isn't exactly what "works" for pitching LibreOffice 
use) but some of them are matters of principle and the kind of 
relationship and commitments between projects/producers/developers and 
users, or even non-users.


The major version number is not some sacred part of these commitments. 
But - like Jan Dittirch says - what would our users think of us if they 
had been aware that we bump version numbers as a "stimulus-evoking 
action" to rile up some of the "animals", and have the other "herd 
animals" follow? (And yes, I know those terms have not been repeated by 
other discussants.)


Paul Hofseth wrote:
> For Libre office number eight it might suffice to claim the usual 
"the changes will assure your improved experience and safety"


But it would be mostly a falsehood. I mean, any commit improves the 
experience of some people to some extent, but it's not true that the 
changes of 7.5 to 7.6 "assure your improved experience and safety". 
Moreover, people notice this kind of rhetoric - even non-tech-savvy 
newbies. And they realize that "Oh, so LibreOffice is another one of 
_those_ initiatives. The ones alienated and estranged from us, whose 
communiques must be carefully scrutinized for exaggerations and 
misrepresentations."


I would rather we not be that.

--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Apr-12

[Eyal Rozenberg]

Sorry for missing the session today... I'll have to comment offline. 
It's always difficult to "argue" with the minutes, but I guess there's 
no getting around it.


So, here is the part of the minutes I am concerned about:

On 12/04/2023 21:44, Heiko Tietze wrote:

  * Rename Presentation Styles to Drawing Style
    + https://bugs.documentfoundation.org/show_bug.cgi?id=154492
    + presentation styles are used in the master view primarily (Regina)
  + but changing the background color or the bullets is always
    possible (Heiko)
    + renaming might be an option but it would still be used as a style
  + disagree with renaming (Roman)
    + changing master attributes in the normal edit mode is a desired
  feature; it is understood as a style and changing the name wont
  alter workflow or design
    + the documentation could deserve some improvement, see
  https://help.libreoffice.org/latest/lo/text/simpress/01/0510.html
    => forward to documentation


Let's start by noting that the bug was not about "Rename Presentation 
Styles to Drawing Styles": That's not the bug title, and was never 
suggested (and it can't make sense since we already have this category). 
The ask, as of the latest comment on the bug, is renaming to "Slide 
Master Elements".


No participant defended the claim that the "Presentation Styles" are 
styles of presentations. No participants claimed that "Slide Master 
Elements" is an incorrect name for the category.


One person opposed the suggested rename - but that was in a comment on 
the bug, not in the design meeting, and without an argument against the 
rename, nor an argument for the validity of the existing name, nor a 
suggestion of an alternative solution to the problem.


As for the documentation:

* It was clarified on the bug page that the bug is not about 
documentation, so any documentation change does not, and cannot even in 
principle, resolve the bug.
* Saying that the "documentation could deserve some improvement" is a 
mis-representation. The documentation for this is partially missing and 
the rest is incorrect and entirely unhelpful (details on the bug page)


More importantly - it is a UX conundrum to have a style category of 
non-styles. And let's not talk about what happens when you try to add a 
new "Presentation style"...


Bottom line: IMHO, this bug did not see useful discussion in the meeting 
(as far as the minutes tell us at least) and no conclusion about it was 
reached. Suggest bringing it up again next time, and I'll try to attend.


--
To unsubscribe e-mail to: design+unsubscr...@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

[libreoffice-design] Re: Minutes from the UX/design meeting 2023-Jun-15

[Eyal Rozenberg]

On 15/06/2023 18:29, Heiko Tietze wrote:

Present: Happy, Hossein, Heiko
Comments: Mike, Dieter, Eyal


Tickets/Topics


  * More centralized endnote/footnote settings
    + make footnote numbering page-style-specific, rename the Insert > F&E
  dialog "Out-of-order Note" or "Special Note", provide access to
Page Style
  from F&E (Eyal)
    + off topic here, depends on bug 155712; if footnotes were bound to
  page style it would be confusing for left/right varying styles


"Left/Right varying styles" are already super-confusing and broken, see:

https://bugs.documentfoundation.org/show_bug.cgi?id=153534

and especially comments 5 and 11.

Eyal



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Jul-13

[Eyal Rozenberg]

Oh, no, no, no, come on... I know I wasn't in the session (which I
couldn't since it was in the middle of a workday), but - there had been
extensive discussion on the bug pages, and the session itself seems to
have just ignore it all. This is really exasperating.


--


>   * Autocorrect replaces " - " with " – " instead of " — "
> (en-dash instead of em-dash)
> + typically two hyphen is an EN-dash, three EM (Heiko)

I've explained several times on the bug page that this bug is not about
when people are trying to explicitly express a choice between the two
kinds of longer dashes.

> + two dashes with / without spaces is kind of standard and
>   working like this in MSO (Hossein)

Same point. Heiko had definitely read the bug page, so he should have
known this already; Hossein - perhaps the bug was mis-described in the
Jitsi session and you didn't have the time to read the comments?

> + maybe drop the conversion of single hyphen (Stuart)

(This is not a misinterpretation, but it may be inspired by the
misinterpretation above) Of course not drop the conversion of a single
hyphen! That's an very important autocorrect feature: Most people use
minus/dash because they are unaware of the different types of dashes, or
because they don't know / haven't thought about how to insert different
kinds of dashes (or because they're lazy). This autocorrection helps
improve the typesetting quality of the work of "lay users".

> + clearly described in
> https://help.libreoffice.org/latest/en-US/text/shared/01/06040100.html

1. It clearly says in the help page that space,minus,space is replaced
with space,en-dash,space. Which is the behavior I'm suggesting be changed.
2. Help contents is never a justification for a choice of behavior of
the app itself.

> + two dashes without spaces like 1--2 is not correctly
>   converted (Heiko)

That's interesting - but unrelated to this bug. Open a separate bug...
No "bug hijacking" with something which is clearly not part of the scope
of the original bug.

> => bug; do not change the behavior as described in the help

How does this conclusion relate even to what you guys were saying before?!

And other than Stewart's position (which I disagree with but nullifies
the question in this bug) - none of the discussants even tried to argue
that it is better for text to have space,en-dash,space's instead of
space,em-dash,space's.


--


  * Support distinction rather than override of conflicting
    subdocument styles
    + https://bugs.documentfoundation.org/show_bug.cgi?id=155740
    + unclear use case (David)
    + some confirmation per document (Shu)
  + if we better go with a global master switch (Heiko)
    + master documents are a special workflow aiming for style
  consistency, WF (Mike, Hossein)


No, they aren't. A single document is the workflow for absolute style
consistency. Master documents are workflows for composing a larger
document from smaller documents, _which well be valid documents on their
own_.


    + unclear use case (David)


Second time this is said. Actually, third time, since this was said on
the bug page, and I clarified. What about that did not seem clear?


    + copy/paste could solve alternative workflows (Shu)


If it could, we wouldn't need master documents in the first place.

And, again, that's just a repetition of points which had been made, and
rebutted, on the bug page. To make them again, one must address and
reject the rebuttal.

---


  * When setting the Heading/Outline Numbering for a level to "None",
    still getting separators
    + https://bugs.documentfoundation.org/show_bug.cgi?id=156089
    + works like in MSO, WF (Justin)
    + no reason to block, WF (Heiko)
    + asking to _clear_ the separator fields in case of None (Eyal)
  + remembering "Chapter/:" is not a (good) solution since users may
    change it for None into "-/>", or the like, making it very
    difficult to follow
    + behavior existing for years shouldn't change without
  good reasons (Hossein)
    + list style is something you shouldn't change multiple times


Less frustrated about the objections here, but - the basic argument,
which was not rebutted, is that our current behavior is the opposite of
what the user expects to happen.

An especially problematic argument is "this has been the behavior for
years". Most of the bugs we consider in the design sessions are about
behaviors LO has had for years. That's not an argument against
addressing them, it's just a sign of the limitation of our resources.


--
To unsubscribe e-mail to: design+unsubscr...@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 

[libreoffice-design] The Gallery and shapes, following the UX/design meeting 2023-Nov-30

[Eyal Rozenberg]

In this week's design meeting, bug 158253 came up:

Shapes-via-Gallery is problematic & partially redundant with the Shapes
sub-toolbars and sidebar
https://bugs.documentfoundation.org/show_bug.cgi?id=158253

I was not available to attend (it was during my work hours); but since
this is not really about a bug, and since I believe the meeting saw
anything but a serious discussion of this matter, I thought I'd reply to
the list. I'll try to address some points regarding the issue of "Basic
Shapes" vs "Gallery", and problems with what the Gallery has. I think
this is relevant enough to bring this up on our mailing list even, since
it's not about a specific bug but a large(ish) feature in our UI.

So, A clip-art or media item gallery is certainly a useful thing to
have. I'm not entirely sure it's important to have one built-in to the
office app UI, but let's say we take that as a given.

However - we should look at what our gallery actually contains: It's not
just poor categorization. Just look at what's in there, and ask yourself
if this is what we want to show users... but let me expand on that with
a few examples:


'curved-left-arrow', 'curved-right-arrow' etc.


These four items in the Arrows category are all the exact same shape,
but rotated in 4 directions and each with different coloring. We see
this phenomenon a lot across the gallery: Artificially inflating the
number of shapes with faux variety, which serves to obscures what the
gallery actually offers.

This shape is a sort of a  "flattened-3D-stripe" kind of arrow, making a
U-turn or 180-degree turn. There's a non-3D shape making a U-turn (item
3 in the arrow category) - with more flexible controls than the
3D-stripe shapes, i.e. you give up flexibility for a 3D-effect. This
feels like a weird choice to need to make.

What's entirely missing, though, are shapes other than a U-turn arrow
with a similar 3D effect. Even, say, a 90-degree circular-arc stripe
rather 180 degrees, or a more straight-angle turn. Or more decorative
gallery items which complement the use of this effect.

More importantly, though, is the fact that these shapes are not
finalized media one puts into a gallery for display: They are
building-blocks for drawing diagrams. In a media gallery, I would not
expect to even have control points. So, if you look at the 'oval-arrow'
shape, or the shape named 'top-arrows' - they have no control points; it
might be a lot of fun if we could pull and tug and scale different
aspects of it, but - we can't; it's a finalized, albeit vectorized,
piece of clipart. We can take it apart and play with its sub-components,
but it's not in itself intended as a flexible component.

'right-arrow', 'left-arrow', 'down-arrow', 'up-arrow'
--

This is another example of four shapes, which are really just one shape
with fake variety. For simple arrows, the gallery offers a one-sided and
a two-sided arrow, and that's it. But this quadruplet of duplicates is
an important example for another reason: It's a shape that's already
part of "Basic Shapes", in the "Block Arrows" category. So, all four
shapes are just duplicates of another shape, which we already have
available in a more accessible way.

... except that the situation is actually worse than that. If you'll
compare the gallery block-arrow and the "Block Arrows" block-arrow from
the toolbar, you'll notice that the latter has a single control point,
for the arrow shaft width; but the former has both that control point,
and the one for arrowhead length.

So not only do we have internal redundancy within the gallery; and not
only is there redundancy between the gallery and the Basic Shapes; but
"Basic Shapes" has been neglected in this respect, with a better version
of a shape having been placed in the gallery instead of where it belongs.


Shapes: 'textbox', 'header', 'title'
--
These shapes are just textboxes, each with a string of text, and at a
different font size. Supposedly, they stand for plain textbox, textbox
that corresponds to your presentation's header text font, and textbox
that corresponds to your presentation title font. In actuality, they're
nothing of the kind: It's just Liberation Sans in three specific sizes.
If you change the presentation styles or use a template - these shapes
won't adapt; and their names will just be misleading.

This is another example of a set of shapes which have artificial
variation; but they are also three shapes that will never be used,
except perhaps by mistake; and of shapes which, I argue, no user would
consider placing in their clipart or media gallery, because of their
complete triviality. It is as though the Gallery populators decided to
pack some shapes for us, in case we got stranded on a deserted island
where the toolbars and menus don't work, and we can only use the gallery
to insert anything these three are at

[libreoffice-design] Re: Minutes from the UX/design meeting 2023-Dec-20

[Eyal Rozenberg]

I want to draw our attention to the first bug which was on the agenda in
yesterday's design meeting:

https://bugs.documentfoundation.org/show_bug.cgi?id=158588

I would say that bug is misnamed. It should be called:

"LibreOffice unexpectedly and strangely modifies an ODT file without
they user having done anything, and embedding unnecessary fonts nobody
asked it to."

IMHO it's several non-trivial issues rolled into one:

* LO's "contract" with the user as an ODT editor
* Where does the UI regarding font embedding choices belong?
* Does LO "know" about the actual use of different languages in a document?

I've commented on the bug myself but would encourage more of us to have
another look at it.

Eyal

PS - Sorry for missing the meeting :-(

On 20/12/2023 23:00, Heiko Tietze wrote:

Present: Sahil, Rafael, John, Heiko
Comments: Dieter, Stuart

Tickets/Topics

  * Redesign font embedding options in
sfx2/uiconfig/ui/documentfontspage.ui
    + https://bugs.documentfoundation.org/show_bug.cgi?id=158588
    + improve help (Dieter, bug 130185)
    + dummy text with no embedded font = 28k, with all options on = 22000k
  with "only used" 927k, with all but limited to latin = 1800k
    + disable CTL & CJK depending on options and
    + check by default and disable the "Only used fonts" unless
  the first option "Embed fonts" is activated (Heiko)
    + if the document contains and CTL/CJK font it would be
  pointless to exclude them when saving used fonts only;
  and the other option makes not much sense alone (Rafael)
    + font scripts options needs a dev check
    => do it





  * FORMCONTROLS Enhancement: Fill Cell with Text Box in Calc
    + https://bugs.documentfoundation.org/show_bug.cgi?id=158273
    + check/enable anchor to cell (resize with cell) and fit to cell size
  by default (Heiko)
    + changing this makes users needy and they may ask for better chart
  positioning, for example; how about a dedicated command to
  achieve the goal (Rafael)
    + could also be done per macro (Sahil)
    + goal was here to insert/manipulate many form controls; the workflow
  with copy/paste is tedious as cursor down or enter does not
  behave like at normal cells; which could be changed (Heiko)
   => comment

  * Incorrectly export number 0 form calc to PDF
    + https://bugs.documentfoundation.org/show_bug.cgi?id=158533
    + option to show/include zero is on by default and one has to disable
  it intentionally
    + same behavior on Excel
    + dependency to some archived PDF format is unclear
    => ask the ESC

  * New sidebar deck for comments
    + https://bugs.documentfoundation.org/show_bug.cgi?id=106316
    + splitter to expand the comments margin (Jim)
    + comments in margin is sufficient for ordinary users (John)
    + vertical space in margin is not enough for academia; management
  is missing, eg. to find unresolved comments (Rafael)
    + sidebar has limited vertical space
  + but allows the list being unsynchronized ie. many comments on one
  single page overlapping each other
    + requirements: add filter by status, eg. resolved
  no urgent need for the procrastination option "hide temporarily"
    + mockup design: take the Onlyoffice example
https://bug-attachments.documentfoundation.org/attachment.cgi?id=191371;
sort is
  missing; referenced text should be visible in the sidebar pane
    + enhancements: predefined responses? might be useful for some
(Rafael),
  but should be done resp. the list filled by users (Sahil)
    + replace the comments in margin or amends it (John)
    => improve the mockup and ask the community in a blog post


--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Re: Minutes from the UX/design meeting 2023-Dec-20

[Eyal Rozenberg]

The font embedding is an example of a deeper issue:

If LibreOffice is a 'native' ODT editor;
and if you open an ODT in it;
and if you don't effect any changes in that ODT, but just save;
is it legitimate for the resulting ODT to be in any way different than
the original (other than meta-data regarding modification date etc.) ?


On 22/12/2023 9:11, Heiko Tietze wrote:

On 21.12.23 20:05, Eyal Rozenberg wrote:

"LibreOffice unexpectedly and strangely modifies an ODT file without
they user having done anything, and embedding unnecessary fonts nobody
asked it to."


Sounds like another facet of the font embedding. I would treat bug
158588 about what fonts are embedded (CTL/CJK/Lat and used) and handle
the situation of shared documents on another. I haven't tested what
happens when one checks the embed fonts option and shares this document
with another person. Assuming her fonts would also be included,
silently, this is at least a privacy issue.



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Join us at the first „FOSS Backstage Design“

[Eyal Rozenberg]

Will sessions be recorded? Or even live-streamed?

Eyal

On 01/02/2024 18:32, Alexander Brateanu wrote:

Dear LibreOffice design-team,

we would be thrilled to welcome participants from LibreOffice design at
our new event *FOSS Backstage Design* where we want to take a deep dive
into UX Design in free and open source software.

The one day event takes place on March 6th, the day after FOSS
Backstage, in Berlin at the Wikimedia Germany office.


  _The program_

**The single track event features 13 sessions from 16 international
speakers who will be presenting on topics such as: *design methods*,
*user research*, how to incorporate *Design*into *product development*,
writing good *documentation*, testing and measuring *usability*and even
how to *design for XR*leveraging the power of OSS tools.

We will kick off the event with a keynote by Aparna Sundar
 in which she
will share her experience on how to increase the human element in open
source software. Aparna willdiscuss the ways in which software engineers
or developers, designers, community and product managers can adopt and
incorporate research practices in software design.

In addition to our amazing line-up of speakers and sessions there will
be plenty of *space and opportunity to exchange ideas*, discuss
challenges and meet other *people who care deeply about designing*for
*great user experience*

Checkout the full program on our website
 and read
what our design experts *Eriol Fox*and *Scott Jenson*have to say about
why we
should
elevate design in FOSS
.


  _FOSS Backstage D_*_esign Tickets_***


  **

**Tickets for #fossdesign are now available
. *A
Standard Ticket is 25€*but we also offer Reduced Tickets as well as
Supporter Tickets.
In case you also want to join the main conference on March 4-5 at bUm,
you can *add a discounted FOSS Backstage Design Ticket to your FOSS
Backstage ticket*order.

We hope to welcome attendees from LibreOffice design at FOSS Backstage
Design!

best regards,
The FOSS Backstage Design orga team – Anne, Sven, Paul & Alex

PS: #fossback and #fossdesign wouldn’t be possible without the support
of our partners. Learn more about sponsoring opportunities for both
eventshere  — We are
also always happy to discuss options that are tailor made for your needs
and budget!



--
To unsubscribe e-mail to: design+unsubscr...@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

[libreoffice-design] Re: Minutes from the UX/design meeting 2023-Feb-22

[Eyal Rozenberg]

On 22/02/2024 16:46, Heiko Tietze wrote:

  * Simplified options dialogs


You seem to have ignored the basic problem with how this bug has been
handled, which I pointed out in comment:
https://bugs.documentfoundation.org/show_bug.cgi?id=90989#c9


    + name, icons, interface, colors, ui lang, locale, and recovery should
  be sufficient (Heiko)


Sufficient for what? I don't know, that sounds fishy.


    + RTL/CTL/CJK is important (Hossein) but should follow the locale
(Heiko),


Nope, shouldn't follow the locale. And that's because:

1. Very often, RTL/CTL-focused language users use computers with a
non-RTL/CTL locale - either on their own computers or others' computers.
2. People may be reading, or even writing, RTL/CTL content despite that
not being their locale-relevant language (e.g. immigrants and the
language of their country of origin).


  and if a more complex setup is needed the advanced mode is a click
away


I am wary that relegating settings to "advanced mode" is a way of
avoiding the problem of dialog simplicity rather than actually tackling
it. That's generally. For RTL/CTL specifically, I _know_ that this is
the case - because all of those RTL/CTL(/CJK) users will need the
"advanced" mode even when they don't want to "advanced" thing.


    + could be done conditionally depending on locale setting (Sahil)


Again, not good enough.


    + more tabs might be required in future (Hossein); possibly easier
to use
  than a scrolling window (Sahil)


Let's start by separating out the app-wide & module-wide settings from
the document-specific settings.

And then, we should probably separate out the default-template-ish
settings out of there too, like default fonts and stuff.


--
To unsubscribe e-mail to: design+unsubscr...@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

[libreoffice-design] Re: Minutes from the UX/design meeting 2023-Apr-24

[Eyal Rozenberg]

Sorry for missing a meeting with a few of "my own" bug reports...


On 24/04/2024 21:58, Heiko Tietze wrote:

  * Want indication of whether a master slide is in use or not
    + https://bugs.documentfoundation.org/show_bug.cgi?id=160403
    + MSO Powerpoints shows the number of slides in a tooltip (Stephane)
    + additional boolean indication would be nice (Eyal)
    + tooltip sounds good and is not harmful (John)
    + not much useful since "Delete Master" is only available if the
  slide master is not in use (Cor)


... but you only see that if you right-click the master. The boolean
indication suggestion would make you aware of this about all visible
masters at once. But I agree with the low priority.


    => no objection, low priority

  * When right-clicking a font family combo-box, offer font meta-data
    + https://bugs.documentfoundation.org/show_bug.cgi?id=152487
    + unclear use case and much likely off-topic being available in
  font management tools (Heiko)


I will have to make the use case clearer on the bug page. Again, sorry
for not being around to make that case.



    + info dialog sounds good but rather via special characters or
  in the character properties dialog (Stuart)
    + only use case is compatibility with some other font (John)


That's an interesting use case, but not what I had in mind.



  + likely not part of the meta data
    + the Internet returns all search results (Cor)


The point is to help the user select an item on a list, while the list
is open - so that the user doesn't have to search for information
elsewhere (e.g. the Internet).

>     => idea does not find support; WF>

  * Make possible 2 or more impress in fullscreen each on a dedicated
    monitor AND each seekable independently with user-defined hotkeys
    per each file
    + https://bugs.documentfoundation.org/show_bug.cgi?id=160242


First of all, I really think this bug report should have been split up
into several ones - and the issues were sort of mapped on the bug page:

A. run two presentations full-screen at same time (on two monitors)
B. Keyboard-navigate in two running full-screen presentation (i.e.
different shortcuts)
C. Same as B, but arbitrary number of presentations
D. Support per-presentation navigation shortcut choices, persisted in
the ODP file

>     + start Impress twice (Stephane)

When you start Impress twice you're still left with just the one
instance running. I guess you can force a second instance (with a
different profile folder perhaps?) but even then, IIANM, Impress is
"imperialistic" when in Full-Screen mode. Op claimed this doesn't work
right now.


workflow is supported with a third   monitor (John)


1. Is it? Can you elaborate on the bug page?
2. What about two monitors?

>     + too niche, better suited for an extension (Stephane, Sahil)

I partially disagree, considering the breakdown above:

A: Not so niche, in my opinion. Occasionally you want to show slides
from different presentations on different monitors - without having
combined them into a multi-monitor-targeting presentation (do we even
have that?). Happened to me already.

B: If Alt-Tab worked (which we can't know, since A is not possible yet),
then this would be kind of niche.

C, D: That's the niche part.


>     => WF

Disagree!

It looks like (some of) the ask changes app behavior rather than
enhancing it. The per-file shortcuts sounds like extension material to
me though.

Suggest breakup instead then INVALID (or MOVED) on this one. I would say

A - NEW
B - UNCONFIRMED (or LATER?)
C, D - WONTFIX


--
To unsubscribe e-mail to: design+unsubscr...@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

[libreoffice-design] Re: Minutes from the UX/design meeting re P2P collaboration 2023-Jul-11

[Eyal Rozenberg]

Comments following the UX/design meeting re P2P collaboration
held on July 11th, 2023
https://listarchives.libreoffice.org/global/design/2024/msg00064.html


(Numbering is for possible reference only and does not indicate importance)

1. I would not start off with the "business" scenario, nor one which is
complex in terms of content. On the contrary, let's start with the
second scenario, and simplify it further, to cater to even more novice
users.

2. All the names are European, and three of them are religious. In fact,
two of the names are practically "Christ".  :-(

3. Let's simplify the second scenario: "Sathvik is working on a story he
is writing as a school homework assignment, and wants to consult his
friend Naya, who has more writing experience, about his work. He
contacts her on an instant messaging app and invites her to join his
editing session, to help him."


Requirements


4. I strongly oppose the requirements:
  - "no need for additional conflict handling"
  - "you always see the current state of the document"
  just the opposite. Prefer simplicity and robustness of protocol and
implementation, and do not require perfectly-synchronized state.
Acknowledge that when two people are trying to edit the same place in
the text - they may get in each other's way, and that is tolerable, even
acceptable.

5. More generally, the "fast" requirement is desirable in some sense;
but we must remember that LibreOffice is a slow application, and even
more importantly: It is not engineered to be low-latency. This is easy
to forget in these days of strong CPUs with many cores, but just start
working on a weaker machine, with a large complex document, and you'll
feel it. Or just think about the amount of time it takes to load, which
in principle, could require almost no work before being able to take
user input. So I would rather pose requirements regarding the added
overhead, or added latency, of online interaction on top of LO's current
behavior.

6. I would add the following requirements:
  - "Does not create nor induce its own separate network of users and
connections"
  - "Does not require any central server for any kind of functionality,
including the setting-up of sessions"
  - "Does not depend on the presence/availability of any particular one
messaging, networking or communications app or platform"
  - "Usable with current _and future_ messaging, networking and
communications apps and platforms" (and note I didn't say easily usable)
  - "Able to handle low-bandwidth communication settings"
  - "Able to handle high-latency communication settings, including
complete interruptions"
  - Able to accept an offline "diff", i.e. an indication another
collaborator has made certain changes, without establishing a
connection, e.g. via a file, a single large message etc.
  - Support at least two modes: fully-tracked-changes mode and
all-authors-are-as-one mode


The mock-up
---

7. I like how it is based on "track changes" as it stands now.
8. I like how we do not see any chat functionality added to LibreOffice
itself.
9. I'm not quite sure that a list of all is a tenable thing to maintain
in the UI; or that it is useful enough to put on the sidebar.
10. We need to think about what happens when different people are
looking at different parts of the document. Will the person looking at
page 1 have no indication of what the person looking at page 2 is doing?
11. I'm wary of creating an address book / contact manager component
that is part of LibreOffice. Can we / should we not use something else
available on the machine?


End-of-session questions


12. "How about special configurations like macros being disabled on one
machine?" - The real question is what happens when one user runs a
macro. Does this trigger something like a macro run for the other users?
Or perhaps they can just see the changes resulting from running the macro?

13. "Relative links within the local file system wont work, and maybe
need some additional work." <- Any links might fail to work. Absolute
and relative, and even global web links don't necessarily resolve to the
same thing: Different DNSes may resolve differently, servers may provide
different response to different requests, firewalls and traffic
analyzers different for each collaborator, etc.

14. "Have audio/video sharing additional to P2P collaboration?" <- I
say: no! Let's not reinvent the wheel. People will do that using other
apps - Matrix, Zoom, Jitsi, MS Teams, IRC, whatever.

15. "Can this communication be standardized so any office application
could join?" <- This would be a very tall order, since that means the
protocol would need to commit to a standard of what a document is, how
it is represented, what an action on a document is, which may be no less
of a challenge than standardizing ODF. In fact, I'm not sure we want to
commit even to two different versions of LibreOffice being able t

Re: [libreoffice-design] Re: Minutes from the UX/design meeting re P2P collaboration 2023-Jul-11

[Eyal Rozenberg]

Well,

* Multiple untracked collaborators parallels the toggling of "Track
Changes" for single-editor changes
* Some collaborators will want to avoid a record of their collaboration
to be kept as part of the document; and since we don't know when their
collaboration ends, it stands to reason the document be made not to
reflect it.

That being said - One could argue this is more of an important feature
than an absolute requirement.

Eyal

On 25/07/2024 9:58, Heiko Tietze wrote:

On 24.07.24 10:29 PM, Eyal Rozenberg wrote:

   - Support at least two modes: fully-tracked-changes mode and
all-authors-are-as-one mode

Why that?



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Re: Minutes from the UX/design meeting re P2P collaboration 2023-Jul-11

[Eyal Rozenberg]

1.

Suppose Alice is working on a formal letter which she intends to send to
scary company Bob Corporation. Charlie is helping Alice draft her
letter, but Charlie has his own history with BobCo, and so does not want
his name to be mentioned on the document in any way.

Now, Alice can tell Bob: "Don't worry, I'll finalize the letter before
sending it so that your name won't appear on it." but Charlie, who is
not a techy person and is not experienced with "track changes" and such,
is not easy with having to rely on her promise that "it will be ok". He
sees his name all over the text: "Charlie wrote:", "Charlie says:" ...
and is scared.

2.

Similar scenario, but now it's a group of collaborators, and Charlie of
them does not trust that everyone will be discreet enough to avoid
sharing a link to the document, with the changes still tracked, with others.


On 25/07/2024 18:54, Heiko Tietze wrote:

On 25.07.24 1:34 PM, Eyal Rozenberg wrote:

* Some collaborators will want to avoid a record of their collaboration
to be kept as part of the document...

Sounds like a Schroedinger's argument. I just don't buy this use case.
The P2P workflow would be the same as of today but synchronously.



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Re: Minutes from the UX/design meeting re P2P collaboration 2023-Jul-11

[Eyal Rozenberg]

Let me start by pointing out that that was one out of 21 points I made.
If there is disagreement about this being a requirement - ok.

Anyway, my reason for suggesting that as a requirement was twofold:

* The parallelism with tracking vs non-tracking of changes in
single-user editing sessions (i.e. how LO works right now).

* The sense that if we don't satisfy users of there being decent
identity-scrubbing for collaborative editing, this will deter some
people in some circumstances of utilizing this feature; for which reason
it should be more than an afterthought and a consideration from the
get-go. Remember that one of the benefits this approach will offer over
centralized, third-party-server-based collaboration is exactly that of
better privacy or anonymity.

Michael Hawkins provided some additional scenarios from more corporate
settings. Mine are more "personal", and are actually based in real life
situations of people I know. Naturally, they were not doing
collaborative on-line editing, but there was collaboration whose
participants wanted to keep discreet.

Eyal


On 26/07/2024 14:20, Felix Queisler wrote:

@Eyal: Is the scenario based in something other than fantasy? Right now
it seems more like feature creep to me.

If it can be validated, then it seems to me there could simply be an
export flag to create a sanitized document. Like you can export photos
in some software excluding metadata for privacy reasons.

Best,
Felix
Am 25. Juli 2024, 18:11 +0200 schrieb Eyal Rozenberg :


1.

Suppose Alice is working on a formal letter which she intends to send to
scary company Bob Corporation. Charlie is helping Alice draft her
letter, but Charlie has his own history with BobCo, and so does not want
his name to be mentioned on the document in any way.

Now, Alice can tell Bob: "Don't worry, I'll finalize the letter before
sending it so that your name won't appear on it." but Charlie, who is
not a techy person and is not experienced with "track changes" and such,
is not easy with having to rely on her promise that "it will be ok". He
sees his name all over the text: "Charlie wrote:", "Charlie says:" ...
and is scared.

2.

Similar scenario, but now it's a group of collaborators, and Charlie of
them does not trust that everyone will be discreet enough to avoid
sharing a link to the document, with the changes still tracked, with
others.


On 25/07/2024 18:54, Heiko Tietze wrote:

On 25.07.24 1:34 PM, Eyal Rozenberg wrote:

* Some collaborators will want to avoid a record of their collaboration
to be kept as part of the document...

Sounds like a Schroedinger's argument. I just don't buy this use case.
The P2P workflow would be the same as of today but synchronously.



--
To unsubscribe e-mail to: design+unsubscr...@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


--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Agenda for the design/UX meeting 2024-Aug-08 (THU)

[Eyal Rozenberg]

Why is the active cell rectangle situation not on the agenda? Neither
for this week nor even for next? It wasn't backed out yet, and degrades
a version that is in RC state, in a highly conspicuous way. That's bad.

Eyal

On 30/07/2024 18:38, Heiko Tietze wrote:

Hello everyone,

the design/UX meeting *next week* is

on: Thursday, August/08, 14:00 CEST resp. 12pm/noon UTC
at: https://jitsi.documentfoundation.org/design

Here is the agenda:

  * "Text direction" in page style dialog, with both Asian and RTL-CTL,
     is inconsistent and confusing
     + https://bugs.documentfoundation.org/show_bug.cgi?id=162200
  * Table > Properties > Text Flow > Text Orientation is misphrased and
confusing
    + https://bugs.documentfoundation.org/show_bug.cgi?id=162201

  * STYLES pane -- duplicate style (an additional option beside the
existing
    new style from selection
    + https://bugs.documentfoundation.org/show_bug.cgi?id=162209
    + WF'ed before on bug 152189

  * Terrible usability of AutoText dialog when creating new AutoText
    + https://bugs.documentfoundation.org/show_bug.cgi?id=52607


All topics being on the agenda are collected at this list:
https://bugs.documentfoundation.org/buglist.cgi?cmdtype=dorem&namedcmd=meeting&remaction=run&sharer_id=32942

The meeting *this week* is tomorrow, Wednesday Jul/31. The agenda can be
found at
https://listarchives.libreoffice.org/global/design/2024/msg00067.html

Cheers,
Heiko


--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Agenda for the design/UX meeting 2024-Aug-08 (THU)

[Eyal Rozenberg]

Stuart, bug 161709 should definitely not be closed - because its initial
scope, which was an aesthetic complaint ("it's ugly") was expanded to
discuss the more fundamental, and grave, problem with the new active
cell rectangle: The hiding of content:

https://bug-attachments.documentfoundation.org/attachment.cgi?id=194910

(see the difference between 24.2 and 24.8)

that was initially filed as bug 161740, but by Rafael's suggestion and
your insistence, we merged that into 161709. This was not resolved;
there was some tweaking done, but the essential problem remains:

https://bug-attachments.documentfoundation.org/attachment.cgi?id=195452

because of the degradation, the user cannot tell whether any of the two
(and in extreme cases 4) the adjacent cells are empty or not!

I don't understand how you can say that there is "NO UI/UX justification
to revert".

Eyal



On 31/07/2024 21:37, V Stuart Foote wrote:



On 2024-07-31 13:49, Eyal Rozenberg wrote:

Why is the active cell rectangle situation not on the agenda? Neither
for this week nor even for next? It wasn't backed out yet, and degrades
a version that is in RC state, in a highly conspicuous way. That's bad.

Eyal

On 30/07/2024 18:38, Heiko Tietze wrote:

Hello everyone,



That would be bug 161709, which frankly should be closed now!
Adjusting the UpdateCUrsorOverely() follow-ups to bug 161234 and bug 143733

I see *NO* UI/UX justification to revert implemented dev effort(s) which
on principle would be highly counter productive.

=-ref-=
https://bugs.documentfoundation.org/show_bug.cgi?id=161709
https://bugs.documentfoundation.org/show_bug.cgi?id=161234
https://bugs.documentfoundation.org/show_bug.cgi?id=143733



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Aug-08

[Eyal Rozenberg]

Come on, Heiko and Cor! Another example of not giving proper attention
to the discussion on the bug page.

On 08/08/2024 16:36, Heiko Tietze wrote:

  * "Text direction" in page style dialog, with both Asian and RTL-CTL,
     is inconsistent and confusing


you left out a key part of the title: "doesn't always set the actual
direction".


     + https://bugs.documentfoundation.org/show_bug.cgi?id=162200
     + agree with Regina on keep status but write better help (Cor)
     => WF
  * Table > Properties > Text Flow > Text Orientation is misphrased and
confusing
    + https://bugs.documentfoundation.org/show_bug.cgi?id=162201
    + better "writing mode" (Regina)
  => follow the expert's advice


First, let us return to a point that I thought was already settled:
Changes to help/documentation text are not a solution for problems with
the LibreOffice UI. If a control or a label is confusing or
inconsistent, that needs to be improved in the app itself, as best we
can; and whatever the UI has - the documentation is for elaboration in
greater detail, with more context and examples.

Second, we're past confusion or poor wording: We have "Text Direction"
control, which, for vertical writing modes - does not set the text
direction (!) and - there isn't another control in the dialog which sets
it, either. (For horizontal writing modes, the control does set the
direction.)

Finally - there are concrete suggestions for some improvements, and
they are not even all dependent on each other. The design meeting
minutes do not list any argument regarding why any of them are a bad
idea (and Regina's comments do not argue against these suggestions either).

Let me rephrase the suggested changes briefly, here:

* Split off writing mode control from direction control, using
consistent and clearly-phrased labels.

* Improve the preview graph to illustrate how lines look and progress.


Eyal





  * STYLES pane -- duplicate style (an additional option beside the
existing
    new style from selection
    + https://bugs.documentfoundation.org/show_bug.cgi?id=162209
    + WF'ed before on bug 152189
    + duplication would be like new but on the same level in the hierarchy,
  support the request (Cor)
    => do it

  * Terrible usability of AutoText dialog when creating new AutoText
    + https://bugs.documentfoundation.org/show_bug.cgi?id=52607
    + Source > Clipboard (added newly) should not be done as the AT
  needs to be verified in the context (Cor)
    + preview window: zoom slider for preview (Gerry)
  + disagree; the actual issue should be fixed (Heiko)
    + AutoText dialog should be amodal
  + agreed (Cor, Heiko)
    + does it make sense to modify the category while creating a new AT
(Cor)
  + we should carefully avoid mixing individual attributes from one AT
    with information on the list of ATs such as categories and path;
    therefore these are split out of the AT dialog/s (Heiko)
    + is "Create AutoText out of selection" (directly) possible? (Gerry)
  + requires a category and unless we just add all new content to
    some "Standard" it needs this selection first (Heiko)
    => wait for volunteers to implement



--
To unsubscribe e-mail to: design+unsubscr...@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

Re: [libreoffice-design] Minutes from the UX/design meeting 2023-Aug-08

[Eyal Rozenberg]

Hello Patrick :-)

Since you replied rather passionately - let me add a few more words.

I love LibreOffice! It's a great endeavor and massively useful suite of
applications, and it's getting better (almost) every day. I try to
convince more people to use it all the time, and wear the T-shirts a lot
to attract more attention to it. And it is our wonderful developers,
designers, and other content contributors - like yourself and like Heiko
- who make this happen.

I also think LibreOffice has all sorts of problems, failures and
deficiencies. Or to put it more bluntly, if you will: LibreOffice
"sucks" in some ways. That's also true for the processes of work on the
project, and for our foundation as well: Some aspects of our collective
conduct "suck" [1]. In fact, in 2010, the people around the project
thought that things sucked so bad that they needed to fork it - and
that's how LibreOffice was born from OpenOffice.

Do you know, Patrick, why I joined the TDF? I actually was reluctant to
do so, because I expected I would get into arguments because of my
tendency to hold strong opinions and try to argue for them (stubbornly,
one might say). So why get into this headache in the first place? In a
project which isn't even one of those I contribute code to?

Well, one reason is that Heiko strongly encouraged me to do it. I can't
speak for him of course, but I'm sure he will tell you that design
meetings are much more lively and interesting, and somewhat more likely
to have useful insights, with participants who have strong intuitions
about aspects of UI and UX; and try to play "devil's advocate" for
less-eloquent bug posters (rather than just pushing my own suggestions).
And you should also note the number of people present in design
meetings: It's someone just two (or two-plus-me); and not all
participants opine on any given issue. So, I guess he thought the
benefits outweigh the detriments, and that other voices with other,
let's say, "organizational personalities" are worth bringing in. I hope
he still thinks so :-)

Another reason has to do with my being from the RTL languages community
[2]. There are very few of us RTL-writers using LO, relative to our
numbers in the world! More importantly, there are extremely few active
users who do RTL-related QA work. And that means, that to express our
collective needs and grievances (to the extent that I can presume to do
so) - it behooves us to be insistent, rather than wait for a bunch of
other people to eventually, someday, make the same complaint and carry
the argument. So expect insistence and push-back on RTL-related issues
from me, in the future as well, and - in good faith. I also hope I'm
offering an RTL-language-minded perspective as a trustee as well.


Eyal

PS - If you think I complain about everything than you have no idea of
how many more things there are to complain about :-P


[1] : And I don't mean the auditors' findings last year; although that's
one criterion we could use.
[2] : Admittedly, a particularly over-privileged part of that community.
What's happening in Gaza is a terrible crime against all of humanity,
and I'm trying to challenge it in the public sphere by helping to
organize demonstrations, that get repeatedly suppressed by the Israeli
police.

On 09/08/2024 5:19, Patrick Luby wrote:

Hi Eyal,

I was wondering when you would turn your focus to the developer list. I have 
been watching your posts on the board discussion mailing list and, frankly, I 
still have no idea what you do except complain about literally everything.

Look man, I’ve been working with the LibreOffice (and its predecessor  
OpenOffice) for 20+ years and I’ve seen a parade of pushy people like you swoop 
in, tell us we all suck, and then demand we all conform to your wishes. To 
quote Michael Meeks, you are good at identifying problems but very poor at 
resolving any of them.

There are a thousand or more things I’d like to improve. But here’s the deal:  
TDF doesn’t actually have any developers. Heiko doesn’t have an army of 
developers waiting for your insight. He relies on volunteers like me to figure 
out what can change without pissing users off. Problem is that volunteers like 
me don’t really like dealing wth overbearing people like you.

I admire Heiko’s patience and professionalism. He’s in a difficult spot with 
zero funding. I get it, shouting and belittling TDF staff is your way of trying 
t get people to do what you want. But, like most users, you provide absolutely 
nothing to hire the staff that you really want. I for one have decided that I 
just don’t like you and will ensure that I never work on your wants in the 
future.

Patrick


On Aug 8, 2024, at 5:42 PM, Eyal Rozenberg  wrote:

Come on, Heiko and Cor! Another example of not giving proper attention
to the discussion on the bug page.

On 08/08/2024 16:36, Heiko Tietze wrote:

 

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

[Eyal Rozenberg]

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+unsubscr...@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