Last modified: 2014-11-04 18:50:13 UTC
It took us (IT engineers) 30 seconds to understand that one page can have many pads (sessions?) opened at once. Our mistake was to share the address from the browser address bar (index.php?title=User:Bedhed&action=edit) instead of the pad address provided within the editor (index.php?title=User%3ABedhed&action=edit&collaborate=true&padId=81). This feature is great and very powerful, but perhaps too much. Also, even if I see the benefits of sessions, I wonder if the related use cases are so important, in comparison to the possible UX issues, and also merging issues. On top of my head : multiple sessions should be an advanced option. Users editing one page share only one default pad. By expanding the sessions menu, a user can then click a link that explicitly says "Open a new session". Once he did, he then have the relative pad url available. And to conclude, a choice should be made between "PAD" and "SESSION", using two words to say one thing is confusing.
Hrm. I guess it's possible that I've overstepped the necessary complexity with this one. I'll add Erik on, he had a similar sentiment, so maybe he can chime in. My current theory is that having multiple sessions would be helpful because users may not want to edit with the people in the default session. Maybe I'm blowing this out of proportion, but I see it as a distinct situation from the normal editing process, because you're working much more closely with the other people. Getting your edits vandalised asynchronously is a lot less irritating, in my opinion, than getting your edits deleted in real-time. With that said, I can see that this might not be the best way to go forward. If Erik agrees that the session list should be an advanced option, enabled in user preferences, I can hack up a patch later today. It would mean one less control on the far right, and one less complexity in the "share link" field. Thanks for reporting this! (and I only see one message in the i18n file with the word "pad", which is irritating, but easily fixable--do you mean the query string parameter? could I trouble you to file a bug saying where you see "pad" so I can more easily fix them?)
A Preferences setting is a solution that goes towards user friendliness, as newbies will have a far lighter editor (without any mention of sessions). But it makes your great session feature far harder to use (as one should know about it and activate it in Preferences to use it). A middle ground, with an initial default pad and the discrete possibility to open new sessions from the editor, could be considered. I'll wait for Erik piece of mind and keep myself available. (I did mean the 'padid' query string parameter, which is minor, as nobody but geeky would use the url as a way to understand an action. But, for the sake of being the devil advocate here, I would consider replacing "session" by "pad" everywhere. In regard of a sentence I find clever: "This is the primary data unit in Etherpad Lite, and we preserved the use of that term" on http://www.mediawiki.org/wiki/Extension:EtherEditor/How_to_Use. I don't think filling another bug is useful yet, as I guess a few usability decision should be made here first)
To me, the primary motivation for having the session manager is data recovery, i.e. being able to obtain session information from recent pads relevant to a page easily (in order to play back pad history, recover a pad with which forever reason got lost before saving, etc.). It can also be useful to deal with bugs in the software or the Etherpad server (which will occur), i.e. if for some reason I get connected to an earlier pad, I can use it to select the correct pad. I see the "I want to collaborate with a separate group of people" as a different and less common motivation. It's potentially useful for edge cases but not the primary reason to have this feature exposed in the UI. IMO focusing on fixing any UI confusion that makes it hard for people to join the correct session in the first place should help resolve any confusion about this feature. Did clicking on "Collaborate" after editing the page not connect you to the correct session?
Erik's idea is to use the hash fragment to store the session ID, also, so if we do stick with the idea of "there are many sessions", we can go with that option to avoid confusion about the share URL and possibly make things generally nicer. Also, it would mean adding history entries (I think) for each session you visit, which may be a nice thing. I think this will be pretty quick, provided core has the jquery hashchange library. Else I'll need to add it to the repository....well, actually, that would also be pretty quick. So no problem.
- Did clicking on "Collaborate" after editing the page not connect you to the correct session? No, we were two, visited the page from the regular url (action=edit), checked "colaborate" and got two separated pads.
OK, so if I read this correctly, this is my current plan for fixing this bug and various other annoyances that, really, everyone who uses this extension has had: 1. No more of this "split session" crap. One session per page, that's all. 2. When a user goes to edit a page, and chooses to collaborate, we check if there are users in that page's session. If there are, we just connect them. If there aren't, we wipe out the session on the Etherpad Lite side, and put in the current page text. 3. When we wipe out the session text, it doesn't disappear, we just put the text (or maybe the new session address, so we can store it on the ep-lite side) into the database. It's probably better to use our database, actually, since there's no real reason to save the ep-lite data. That old session thenClément goes into the session list, with the same data. Clicking on it doesn't load a different session, it just replaces the text in the current one. This means: * Everyone joins the same session (finally!) * No need to track session changes, so padId and hash changes are unnecessary. Simply passing collaborate=true should bring everyone to the right spot. * Smaller ep-lite database and server usage footprint. ep-lite will only need to save old versions in text format, no revisions get saved. Only one session is ever being used for each page, which lessens the load a bit. * The extension database footprint is smaller because contribs only need to be listed for one session per page, or maybe not at all (since there's now a way to list contribs via the ep-lite HTTP API), and because I only need to update the "old version" entries twice: once when they're stored, once when they're retrieved (and subsequently deleted) I'd like for Erik and Clément to confirm that this isn't an awful idea, I'm going to start the day by chasing down the webkit CSS bug, I'll come back to this bug later.
I'm not sure I fully understand your strategy for the use of the session menu to recover old text. How would different versions of the page interact with the Etherpad-level change history? I do think simplification is definitely a good idea; if we can get away with only ever worrying about connected/not-connected users on a per-page level, rather than a per-pad-per-page level, that seems like a huge win. So far the use cases for "joining two different sessions for the same page" seem pretty limited at best.
We're working on this now, in https://gerrit.wikimedia.org/r/43100 Basically the strategy is to remove the session concept altogether, then possibly build extra features from there. We can add in e.g. recovering old text from a solid base. We may also just offer a "hey, update this pad to the latest version of the page" button that will only work if everyone in the pad clicks it. That's an acceptable thought, but I guess it will take some time. Sucheta and I will strategize.
Change 43100 abandoned by MarkTraceur: Use only one pad per page Reason: Ugh, screw it, this will never get merged. WMF has basically discontinued support for this extension, nobody else seems to be working on it. https://gerrit.wikimedia.org/r/43100
