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?
