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 to
collaborate, necessarily. But perhaps I'm being overly pessimistic here.


Other thoughts
--------------

16. There needs to be an "oblivion threshold" mechanism, so that as the
document gets edited further, older changes are "forgotten", i.e.
accepted as part of the baseline, and only new ones showing. The trigger
could be time, or switching to someplace else in the document, or a
combination of those. Sometimes nothing is forgotten, sometimes you only
want to see the last few sentences of editing a person is working on, to
see what's undergoing change right now, and the rest is just done.

17. We could also consider some kind of indication of the age of
changes: From just-now to ancient-history. But maybe that's too much.

18. The implementation should support viewer-only collaborators, which
can only see what others are doing, and perhaps, at most, indicate
locations for others to notice (i.e. have their own cursor within the
document).

19. In my mind's eye, people share invitations-to-edit over existing
communications apps and platforms, similarly to invitations to Zoom
sessions. But we may want to be able to invite to a _session_, and to
have continued access to a (document,user,location) tuple. And maybe to
other things.

20. Two-way collaboration would use plain-vanilla TCP or UDP between the
two parties. It will get complicated with multiple collaborators; I
suppose we would need a know P2P-libraries for establishing multi-way
communications without using any central server. I wonder which
libraries are relevant... this is not my forte.
https://github.com/kareldonk/QuantumGate is interesting; maybe
https://libp2p.io .

21. We could in principle support both pure-P2P and server-assisted
usage scenarios, but I'm not sure there's enough of a benefit in doing
that.



On 11/07/2024 16:25, Heiko Tietze wrote:
> Present:  Sahil, Michael, Heiko
>
> Tickets/Topics
>
> *P2P collaboration*
>
> _User Stories_
>
> * Simon wants to run a business meeting. He invites co-workers into the
> editing
>    of a milestone document with text, numbers, and charts. After
> finalizing the
>    content together, he as well as all colleagues add their signature so
> the
>    document does not need to cycle through the company anymore.
> * Kryztina has to complete a form with a lot of bureaucratic text, and she
>    struggles to understand all details as a person with migration
> background. She
>    invites Christian into the editing to help her.
> * Maurizio works on a document with sensitive content. He needs help to
>    accomplish a task but is not allowed to share the document publicly.
> So he
>    invites Olivier to assist.
> * Eve has to insert some numbers in a spreadsheet but lacks on all data
> sources.
>    She invites Benjamin to add his information while editing her own
> content.
>
> _Requirements_
>
> * Easy to use: inviting a person is done as known from chat programs
> * Secure: privacy is always guaranteed
> * Fast: interaction feels never misplaced; no need for additional conflict
>    handling as you always see the current state of the document
> * Reliability: everybody has a full copy of the document locally; and
> retrieves
>    it when (re-)connecting; maybe it is necessary in some situations to
> protect
>    the ownership and block storing the document on other participant's
> computer
>
> _Mockup_
>
> * https://i.imgur.com/qywXe2t.png
>    + (1) modifications are done likewise asynchronous tracked changes
>    + (2) list of participants with an Add button to get the dialog (3)
>    + (3) address book-like dialog to pick communication channels to
> invite people
>
> _Questions_
>
> * How about special configurations like macros being disabled on one
> machine?
> * Relative links within the local file system wont work, and maybe need
> some
>    additional work.
> * Have audio/video sharing additional to P2P collaboration?
> * Can this communication be standardized so any office application could
> join?