Re: more on collaboration
We would benefit greatly from a "google docs" version of Lyx. We frequently write papers and proposals collaboratively and we lose a fair amount of time by having to wait for someone else to release the document for editing or we end up with multiple authors editing at the same time and creating havoc. I also lead about a dozen student teams and they would benefit from a collaborative UI for Lyx.
Re: more on collaboration
2010/9/27 Gregory Jefferis : > On 2010-09-25 06:51, "Jose Quesada" wrote: > >> I tried Gobby. it's as simple as notepad, so for serious programming/writing >> it'd feel a bit limited. But the deal breaker is no undo. Yes, you hear that >> right. I think Gobby is actually feature-wise worse than in-browser >> alternatives. > > For anyone who wants to do real time latex editing, then I have come across > two possibilities. > > 1) SubEthaEdit > > as already mentioned, really nice collaborative editing for many users, > simple to setup, fairly simple latex mode, macosx only, commercial > > 2) Eclipse + Texlipse + Eclipse Communication Framework (ECF) and in > particular the DocShare plugin. > > basic collaborative editing, appears to be limited to 2 people, a bit of a > pain to setup, good latex support, cross-platform, open source > > ECF provides an example of how building a collaborative editor can be > layered on top of existing work. See: > > http://wiki.eclipse.org/RT_Shared_Editing For completeness, http://www.emacswiki.org/emacs/CollaborativeEditing describes collaborative editing possibilities in emacs. I tried Rudel just for fun, but couldn't get it to work, seems a bit rough around the edges. I guess multi-tty is the best method, similar to sharing a GNU Screen session (which would also work for collaboration in VIM or any terminal-based editor), but I think one would have to be very trusting of collaborators to do that... best regards, Kevin
Re: more on collaboration
On 2010-09-25 06:51, "Jose Quesada" wrote: > I tried Gobby. it's as simple as notepad, so for serious programming/writing > it'd feel a bit limited. But the deal breaker is no undo. Yes, you hear that > right. I think Gobby is actually feature-wise worse than in-browser > alternatives. For anyone who wants to do real time latex editing, then I have come across two possibilities. 1) SubEthaEdit as already mentioned, really nice collaborative editing for many users, simple to setup, fairly simple latex mode, macosx only, commercial 2) Eclipse + Texlipse + Eclipse Communication Framework (ECF) and in particular the DocShare plugin. basic collaborative editing, appears to be limited to 2 people, a bit of a pain to setup, good latex support, cross-platform, open source ECF provides an example of how building a collaborative editor can be layered on top of existing work. See: http://wiki.eclipse.org/RT_Shared_Editing I guess if LyX had a round-trip consistent latex export/import these might even provide an option for online collaborative editing of text from a LyX document. Best, Greg.
Re: more on collaboration
Gregory Jefferis wrote: > > Gregory Jefferis wrote: > >> We use version control (git) + to write papers in the lab. It works fine > >> but handling merge conflicts is still difficult; the chaps in the lab are > > > > in one project we 'solved' this via locking. the document could be split > > into childern (=chapters/sections) so multiple people can still work > > simultaneously. > > Thanks for the suggestion. I can see that could work but it does seem a bit > of a blunt instrument. We would need to change VCS (git has no locking > AFAIK). But I'll keep it in mind. yes, sorry this suggestion was for subversion. when working with geeky people this is not much needed, they know ho to resolve merge conflicts. however for non geeky people svn locking seems to me the only weapon how to avoid the problems with conflicts, moreover when lyx has builtin support for locks... > >> LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is > >> only > >> partly solved in 2.0. > > See: > > http://www.lyx.org/trac/ticket/6058 > > And in particular my post (+patch) which tries to explain why what has been > implemented for Lyx 2.0 is still fragile: > > http://www.mail-archive.com/lyx-de...@lists.lyx.org/msg153396.html yes i remember the thread. you unfortunately took too long hiatus and Vincent disappeared meanwhile... ;) i will reopen the ticket with the comments above, so there is still chance to get this into 2.0. i see also you didnt responded to Andre's comments... pavel
Re: more on collaboration
On 2010-09-26 17:07, "Pavel Sanda" wrote: > Gregory Jefferis wrote: >> We use version control (git) + to write papers in the lab. It works fine >> but handling merge conflicts is still difficult; the chaps in the lab are > > in one project we 'solved' this via locking. the document could be split > into childern (=chapters/sections) so multiple people can still work > simultaneously. Thanks for the suggestion. I can see that could work but it does seem a bit of a blunt instrument. We would need to change VCS (git has no locking AFAIK). But I'll keep it in mind. >> LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is only >> partly solved in 2.0. See: http://www.lyx.org/trac/ticket/6058 And in particular my post (+patch) which tries to explain why what has been implemented for Lyx 2.0 is still fragile: http://www.mail-archive.com/lyx-de...@lists.lyx.org/msg153396.html In brief, if you have a document under version control and two users turn on track changes, then their changes will get confused in both 1.6.X and 2.0. In 2.0 this can be avoided if the first user pushes (in git terminology) and the second under pulls before the second user turns on track changes. However in practise this will often be violated (e.g. when you ask all co-authors to edit/comment on a given draft).
Re: more on collaboration
Richard Heck wrote: > That said, if we're talking *nix, I wonder how hard it would be to use > LyX's multiple windows feature to implement some kind of collaborative > editing. You only need to get that second window onto your collaborator's > screen somehow. we have talked about this in devel list multiple times. the most elegant way (from the lyx's point of view) would be just ask qt to use different DISPLAY where the particular window goes. as reported by Andre qt does not allow this and it won't happen any time soon. there are other and more difficult possibilities how to implement, but i would just repeat the thread... pavel
Re: more on collaboration
Gregory Jefferis wrote: > We use version control (git) + to write papers in the lab. It works fine > but handling merge conflicts is still difficult; the chaps in the lab are in one project we 'solved' this via locking. the document could be split into childern (=chapters/sections) so multiple people can still work simultaneously. > LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is only > partly solved in 2.0. can you be more specific here? pavel
Re: more on collaboration
2010/9/25 Wolfgang Keller : > Hello, > >> A decent latex editor built on top of google docs. > > "Decent" and "Google apps" are mutually exclusive. > > Google apps is just yet another proof how ridiculously unusable _all_ "web > apps" are for getting actual work done efficiently. And all that with > ridiculously high development effort and equally ridiculous run-time > ressource requirements. > >> Thoughts? > > "Online" collaboration is a totally useless gadget exclusively favored by > freaks who don't do actual work with the application. Kent Beck once told of how a certain type of web form had been shown by A/B testing[1] to get a lot more registered users, to which a developer said "Oh those web forms suck, I'd never make those". Beck replies: "What business are you in? I'd like to compete with you..." -- what users actually do and what developers imagine they would do is often quite different ;-) My girlfriend is finishing up a six-year clinical psychology program, and she and most of her fellow students are using Google Docs on their final theses (not for the print version, but when collaborating on individual chapters). I have carefully tried to argue for version control and real editors over Google Docs, but why should they bother with solving merge conflicts when they could be getting some actual writing done... Of course, if the intended audience of LyX is people who already are familiar with version control, there is probably no reason to look at what non-programmers do. best regards, Kevin Brubeck Unhammer [1] http://en.wikipedia.org/wiki/A/B_Testing
Re: more on collaboration
Hello, > A decent latex editor built on top of google docs. "Decent" and "Google apps" are mutually exclusive. Google apps is just yet another proof how ridiculously unusable _all_ "web apps" are for getting actual work done efficiently. And all that with ridiculously high development effort and equally ridiculous run-time ressource requirements. > Thoughts? "Online" collaboration is a totally useless gadget exclusively favored by freaks who don't do actual work with the application. "Offline" collaboration using SVN is an absolute must where actual work is done with _any_ application. This is the opinion of someone who has been intensively doing information work to earn his life for 20 years now. Sincerely, Wolfgang
Re: more on collaboration
Hi, I think Greg's post is key here. Even if the two users are never editing at the same time, having always the latest version with all merges applied is reassuring. @Rob: "Yet, I've never actually met anyone who writes with others in real time." I think this is because the tech didn't even exist a year ago. Any tech takes a while to get adopted. Most people don't even know it exists, and the ones who do don't know why they need it. Plus, leaving the tech aside, I can imagine there's a mental change when writing this way. I'm using abiword to collaborate on a paper. Will report how things went after a few days. Btw, the latex on gDocs thing is way too beta to be usable. It lost edits, crashed, etc. It's just a pity that abiword is so limited in other features (search, adding references, etc), but it looks really promising. Best, -Jose Jose Quesada, PhD. Research scientist, Max Planck Institute, Center for Adaptive Behavior and Cognition, Berlin http://www.josequesada.name/ http://twitter.com/Quesada On Sat, Sep 25, 2010 at 7:51 AM, Jose Quesada wrote: > Hi Kevin, > I tried Gobby. it's as simple as notepad, so for serious > programming/writing it'd feel a bit limited. But the deal breaker is no > undo. Yes, you hear that right. I think Gobby is actually feature-wise worse > than in-browser alternatives. > > Best, > -Jose > > Jose Quesada, PhD. > Research scientist, > Max Planck Institute, > Center for Adaptive Behavior and Cognition, > Berlin > http://www.josequesada.name/ > http://twitter.com/Quesada > > > On Fri, Sep 24, 2010 at 8:21 PM, Kevin Brubeck Unhammer < > kun...@student.uib.no> wrote: > >> 2010/9/24 Gregory Jefferis : >> > Non-interactive collaborative editing means that there can always be one >> > live version of a document to which anyone can apply changes that are >> > versioned, identified and much more likely. Essentially it solves the >> > conflicting merge problem by automatically merging all the time so that >> you >> > are always looking at the latest version (and can be alerted to recent >> > changes). You can try and do this with traditional version control >> > arrangements but you will always run into a conflict if the system isn't >> > designed for the possibility of interactive collaborative editing. >> >> And this is the reason why most users love Google Docs and will never >> use git (even though as we all know, merging with git is Fun and >> Easy). >> >> >> I think the ideal situation would look like Gobby[1] running inside >> LyX (not necessarily with chat features, but at least showing where >> the other user is editing), but I can understand how that would be a >> lot of work to implement. Sponsorship project? ;-) >> >> >> -Kevin >> >> >> [1] http://gobby.0x539.de >> > >
Re: more on collaboration
Hi Kevin, I tried Gobby. it's as simple as notepad, so for serious programming/writing it'd feel a bit limited. But the deal breaker is no undo. Yes, you hear that right. I think Gobby is actually feature-wise worse than in-browser alternatives. Best, -Jose Jose Quesada, PhD. Research scientist, Max Planck Institute, Center for Adaptive Behavior and Cognition, Berlin http://www.josequesada.name/ http://twitter.com/Quesada On Fri, Sep 24, 2010 at 8:21 PM, Kevin Brubeck Unhammer < kun...@student.uib.no> wrote: > 2010/9/24 Gregory Jefferis : > > Non-interactive collaborative editing means that there can always be one > > live version of a document to which anyone can apply changes that are > > versioned, identified and much more likely. Essentially it solves the > > conflicting merge problem by automatically merging all the time so that > you > > are always looking at the latest version (and can be alerted to recent > > changes). You can try and do this with traditional version control > > arrangements but you will always run into a conflict if the system isn't > > designed for the possibility of interactive collaborative editing. > > And this is the reason why most users love Google Docs and will never > use git (even though as we all know, merging with git is Fun and > Easy). > > > I think the ideal situation would look like Gobby[1] running inside > LyX (not necessarily with chat features, but at least showing where > the other user is editing), but I can understand how that would be a > lot of work to implement. Sponsorship project? ;-) > > > -Kevin > > > [1] http://gobby.0x539.de >
Re: more on collaboration
On 09/24/2010 05:34 PM, Julien Rioux wrote: On 24/09/2010 3:01 PM, Richard Heck wrote: This could almost be done without any changes to LyX. Here's how. 1. Set up a cron job that does "svn up filename.lyx" every two minutes. 2. Set up another cron job that watches filename.lyx and, if it changes, does "svn ci filename.lyx". If I was crazy about such a feature, this is exactly how I would set it up. Or I would use dropbox, which essentially does the "file watching" itself. But, once your file has been updated on disk by svn up, how do you automatically update the displayed document within lyx? Is it currently possible? No, it's not. That's why it's "almost". LyX will warn you when you try to save it, but that's all. rh
Re: more on collaboration
On 24/09/2010 3:01 PM, Richard Heck wrote: This could almost be done without any changes to LyX. Here's how. 1. Set up a cron job that does "svn up filename.lyx" every two minutes. 2. Set up another cron job that watches filename.lyx and, if it changes, does "svn ci filename.lyx". If I was crazy about such a feature, this is exactly how I would set it up. Or I would use dropbox, which essentially does the "file watching" itself. But, once your file has been updated on disk by svn up, how do you automatically update the displayed document within lyx? Is it currently possible? Julien
Re: more on collaboration
On 09/24/2010 01:34 PM, Gregory Jefferis wrote: Non-interactive collaborative editing means that there can always be one live version of a document to which anyone can apply changes that are versioned, identified and much more likely. Essentially it solves the conflicting merge problem by automatically merging all the time so that you are always looking at the latest version (and can be alerted to recent changes). You can try and do this with traditional version control arrangements but you will always run into a conflict if the system isn't designed for the possibility of interactive collaborative editing. Surely the way this works could be mimicked with VC. What you need to have is some kind of push going on, so that, whenever a document is saved, it is /automatically/ VC'd. And then you need to have some kind of system for signalling when a new version has been committed. An even lower-tech solution would involve some kind of polling. I think this would actually be relatively /easy/ to integrate into LyX. Here's the idea. When we have a version controlled file and "collaborative editing" is enabled, we run "svn up filename.lyx" in the background from time to time and see if we get anything back. This is not wholly trivial because we don't want to lose our local edits. But this could be handled by covertly saving the Buffer before doing svn up; we can backup the original and restore it if need be. Maybe the best way to do this would be to clone the local repository into LyX's temporary directory and do all the work there, only touching the "real" directory when the user saves the file. Anyway, something like that will work. What do we do, though, if there is a conflict between the newly saved file and the local edits? I guess we report the issue and give the user options, e.g., open both documents. In LyX 2.0, we could even use the new comparison feature to show the user the differences between them. Going the other way, we could commit all changes whenever they are saved, again reporting any issues we might run into. Then the most current version is always on the server. This could almost be done without any changes to LyX. Here's how. 1. Set up a cron job that does "svn up filename.lyx" every two minutes. 2. Set up another cron job that watches filename.lyx and, if it changes, does "svn ci filename.lyx". If people aren't often editing the very same part of the document at the very same time, then this will work fine. Richard
Re: more on collaboration
On 09/24/2010 02:21 PM, Kevin Brubeck Unhammer wrote: I think the ideal situation would look like Gobby[1] running inside LyX (not necessarily with chat features, but at least showing where the other user is editing), but I can understand how that would be a lot of work to implement. Sponsorship project? ;-) I see that there is also a Kobby (KDE, of course), which gets you closer to something LyX could handle. Both of these are built on libinfinity, libqinfinity in Kobby's case, which again is something that could conceivably be integrated into LyX. That's the "interactive collaborative editing" version, of course. Richard
Re: more on collaboration
Steve, > All Unleashed books are written by a main author and lots of contributing > authors. However, it's carved up by chapter, so no chapter is collaborative. While this may well be true in general, the two books I have collaborated on (my only book experience) I contributed to every chapter, writing some sections as well as heavy editing of the content written by the main author (or the other authors). Certainly this wasn't live collaboration, and relied on the track changes features of Word. I have done the same thing with Lyx and co-authoring Technical reports. We also tried a Skype/Google Apps approach for live editing, but it didn't work very well because of how slow the Skype connection was. But this was more of brainstorming exercise trying to flesh out a Report outline. The books are: http://www.amazon.com/Effects-Extensions-Ecology-Statistics-Biology/dp/0387874577/ref=sr_1_1?s=books&ie=UTF8&qid=1285353221&sr=1-1 and http://www.amazon.com/Analysing-Ecological-Statistics-Biology-Health/dp/0387459677/ref=sr_1_2?s=books&ie=UTF8&qid=1285353262&sr=1-2 Graham
Re: more on collaboration
I would simply like to say that I think going too far down this road could lead to a lot of effort, and only a marginal return. I think we do need to make LyX better, but I don't think it needs to be too multi-purpose. You know the whole Swiss-Army knife versus a tool that does one thing, but does it well debate. I think we would be best to improve how well LyX does its primary job: document processing. We can leave other jobs to other tools. That said, as soon as there's a good tool to say, track versions of a file (like subversion), we can provide meaningful integration with that tool (and have). I have used Google docs collaboratively, but would personally be very unlikely to use LyX in such a way. I can get up-to-date copies of my document out to people with Subversion or dropbox well enough. Just my two bits. -Jacob On Fri, Sep 24, 2010 at 12:21 PM, Kevin Brubeck Unhammer < kun...@student.uib.no> wrote: > 2010/9/24 Gregory Jefferis : > > Non-interactive collaborative editing means that there can always be one > > live version of a document to which anyone can apply changes that are > > versioned, identified and much more likely. Essentially it solves the > > conflicting merge problem by automatically merging all the time so that > you > > are always looking at the latest version (and can be alerted to recent > > changes). You can try and do this with traditional version control > > arrangements but you will always run into a conflict if the system isn't > > designed for the possibility of interactive collaborative editing. > > And this is the reason why most users love Google Docs and will never > use git (even though as we all know, merging with git is Fun and > Easy). > > > I think the ideal situation would look like Gobby[1] running inside > LyX (not necessarily with chat features, but at least showing where > the other user is editing), but I can understand how that would be a > lot of work to implement. Sponsorship project? ;-) > > > -Kevin > > > [1] http://gobby.0x539.de >
Re: more on collaboration
2010/9/24 Gregory Jefferis : > Non-interactive collaborative editing means that there can always be one > live version of a document to which anyone can apply changes that are > versioned, identified and much more likely. Essentially it solves the > conflicting merge problem by automatically merging all the time so that you > are always looking at the latest version (and can be alerted to recent > changes). You can try and do this with traditional version control > arrangements but you will always run into a conflict if the system isn't > designed for the possibility of interactive collaborative editing. And this is the reason why most users love Google Docs and will never use git (even though as we all know, merging with git is Fun and Easy). I think the ideal situation would look like Gobby[1] running inside LyX (not necessarily with chat features, but at least showing where the other user is editing), but I can understand how that would be a lot of work to implement. Sponsorship project? ;-) -Kevin [1] http://gobby.0x539.de
Re: more on collaboration
On Friday 24 September 2010 11:29:10 Rob Oakes wrote: > Hi Jose and other LyX-Users, > > Very interesting articles, thanks for sending them. > > While trying to digest the ideas, though, I found myself asking two > questions and I'd be interested in your feedback. The first question, of > course is spurred by pure skepticism. > > In what instances do you think this feature would be useful? > > For my part, I'm not a collaborative writer. I don't think well in the > presence of others and I hate writing with an audience. All Unleashed books are written by a main author and lots of contributing authors. However, it's carved up by chapter, so no chapter is collaborative. I see collaborative situations as a meeting where everyone's trying to design something. For years the VimOutliner project has tried to build in collaboration, but it's very difficult. You can always do poor man's collaboration. Have ten people in a room, each with their own VNC client, and have them all work on a single instance of a single program. I can't for the life of me see why a document writing software like LyX should be collaborative above and beyond being able to farm out chapters to different people, which it can already do. SteveT Steve Litt Recession Relief Package http://www.recession-relief.US Twitter: http://www.twitter.com/stevelitt
Re: more on collaboration
On Friday 24 September 2010 10:18:30 Kevin Brubeck Unhammer wrote: > 2010/9/24 Jose Quesada : > > Hi, > > We've had previous discussions on whether or not it's useful to have some > > kind of real-time collaboration in LyX. > > The death of wave seemed to reinforce the idea that this is not a killer > > feature, and people don't need it. Collaboration using a VCS is > > sufficient. > > I think the problem with Wave is that... well... what's it for really? > It's not an editor, not a chat program, not...anything...except a tech > demonstration. Aw contrair. Google Wave was techs greatest status symbol. Who got it first? How many invitations did you get? This was the first time since the IPO of VA Linux that you could be a true tech snob. :-) SteveT Steve Litt Recession Relief Package http://www.recession-relief.US Twitter: http://www.twitter.com/stevelitt
Re: more on collaboration
Hi all, I would distinguish two kinds of collaborative editing. * interactive collaborative editing - 2 or more people working simultaneously on a document * non-interactive collaborative editing - only one person actually modifying the document at any one time BUT others always having live access to the latest version if required. I think typically you would spend 5% of writing time in the first mode but that implementing it solves nasty problems with collaborating in the second mode. More specifically: On 2010-09-24 17:41, "Richard Heck" wrote: > On 09/24/2010 11:43 AM, Les Denham wrote: >> On Friday 24 September 2010 10:29:10 Rob Oakes wrote: > I have to confess that I too am somewhat puzzled by this, but I can see > a use case that would be good for me. Say I've written a paper with a > collaborator. We are now at a pretty late stage in the process. It might > be useful to be able to read through the document together and make > changes we can both see "in real time". I'm not saying this really would > be all that great, but I can see using it. This is the kind of situation where actively using real time editing is really useful and for me it crops up whenever I am writing something with a colleague for another institution. It is incredibly motivating and leads to better writing if you can skype and write in an _interactive_ and collaborative fashion. There are potential low tech ways to do this using screen sharing, but they do lose the significant benefit of attaching edits. Furthermore since you don't usually want to have a permanent share of your desktop you can't leave them on the whole time and that for me is the problem - in my view the real benefit of a rich collaborative editing implementation is that allows much easier and more consistent - non-interactive collaborative editing. Non-interactive collaborative editing means that there can always be one live version of a document to which anyone can apply changes that are versioned, identified and much more likely. Essentially it solves the conflicting merge problem by automatically merging all the time so that you are always looking at the latest version (and can be alerted to recent changes). You can try and do this with traditional version control arrangements but you will always run into a conflict if the system isn't designed for the possibility of interactive collaborative editing. Does this seem reasonable to others? Or have other people found ways to solve the non-interactive collaborative writing situation when people end up modifying the same document. In my experience this happens often enough that it's a problem and existing software that I am aware of makes it too hard to solve for most researchers. Greg.
Re: more on collaboration
Hi Les, > I had no idea people were asking for this kind of feature. Real-time > collaboration on a document seems to me to be a formula for a colossal waste > of time, extending the concept of endless meetings to an online equivalent. I'm not sure if ti's people in general or just people that I know. But I've seen it come up quite frequently in the past few months. Particularly on blogs and in discussion of software tools. When it arises in face to face communication, as it did during a meeting a month ago, I really try to sit up and pay attention. In the meeting, people were bitching about long-distance collaboration and the slow turn around of document exchange. Several options were suggested: VCS, Google Docs, chat, phone conferences, WebEx, etc. It was a very good discussion and even got a little heated. But then, I'm on the fringes of academics and written documents (particularly reports) are extremely important. It's how we get money and share the results of our work. > In the organizations I'm involved in, written documents of all kinds seem to > be actively discouraged by most managers. The most common kind of "report" > is > an incoherent PowerPoint presentation put together with thought processes and > artistic taste worthy of a four-year-old. > > Writing of any kind is so rare I can't imagine there being any demand for > collaborative writing. Since I've been trying to move toward industry and private consulting, I've also noticed this as well. For that reason, I might be experiencing the effects of an echo chamber. To reiterate my other email, I'm extremely skeptical of the real time collab solutions in general. But if there is a clear use-case where it can be helpful, count me interested. I'd just like to see it done "right." Cheers, Rob
Re: more on collaboration
On 24 September 2010 12:41, Richard Heck wrote: > > Still, I have to agree with Rob that doing this at the level of each > program just seems wrong in principle. Having some very generic > client-server model, where the program's display could show up here there > and everywhere, and the program could take its input too from various > sources, that would be much more general and much more useful. > > I think TeamViewer and similar products (DimDim, Webex) allow this use case without any change. TeamViewer is even available for MacOS and Linux, and there is a free version. Basically, they are all screen-sharing applications, with some kind of communication features (phone-in, IM, VoIP, webcam chat). Control can be given to any participant, in a format similar to VNC. Setup is usually trivial (starting a program and giving-out your IP address). I have used Webex and TeamViewer for this and other collaboration tasks and it is truly useful. Best regards, Tennessee Carmel-Veilleux, ing. jr (OIQ) Electrical engineering masters student, ETS (http://www.etsmtl.ca) Project AREXIMAS (http://areximas.etsmtl.ca)
Re: more on collaboration
On 09/24/2010 11:43 AM, Les Denham wrote: On Friday 24 September 2010 10:29:10 Rob Oakes wrote: Anyone else have any thoughts? Rob, I had no idea people were asking for this kind of feature. Real-time collaboration on a document seems to me to be a formula for a colossal waste of time, extending the concept of endless meetings to an online equivalent. In the organizations I'm involved in, written documents of all kinds seem to be actively discouraged by most managers. The most common kind of "report" is an incoherent PowerPoint presentation put together with thought processes and artistic taste worthy of a four-year-old. Writing of any kind is so rare I can't imagine there being any demand for collaborative writing. I have to confess that I too am somewhat puzzled by this, but I can see a use case that would be good for me. Say I've written a paper with a collaborator. We are now at a pretty late stage in the process. It might be useful to be able to read through the document together and make changes we can both see "in real time". I'm not saying this really would be all that great, but I can see using it. Still, I have to agree with Rob that doing this at the level of each program just seems wrong in principle. Having some very generic client-server model, where the program's display could show up here there and everywhere, and the program could take its input too from various sources, that would be much more general and much more useful. That said, if we're talking *nix, I wonder how hard it would be to use LyX's multiple windows feature to implement some kind of collaborative editing. You only need to get that second window onto your collaborator's screen somehow. Richard
Re: more on collaboration
On Friday 24 September 2010 10:29:10 Rob Oakes wrote: > Anyone else have any thoughts? > Rob, I had no idea people were asking for this kind of feature. Real-time collaboration on a document seems to me to be a formula for a colossal waste of time, extending the concept of endless meetings to an online equivalent. In the organizations I'm involved in, written documents of all kinds seem to be actively discouraged by most managers. The most common kind of "report" is an incoherent PowerPoint presentation put together with thought processes and artistic taste worthy of a four-year-old. Writing of any kind is so rare I can't imagine there being any demand for collaborative writing. -- .. Les Denham
Re: more on collaboration
Hi Jose and other LyX-Users, Very interesting articles, thanks for sending them. While trying to digest the ideas, though, I found myself asking two questions and I'd be interested in your feedback. The first question, of course is spurred by pure skepticism. In what instances do you think this feature would be useful? For my part, I'm not a collaborative writer. I don't think well in the presence of others and I hate writing with an audience. My one and only experience with Google Wave was a nightmare. People could see just how much backspacing was involved in my replies! It was deeply humiliating and I'm quite glad that Wave died. (Unfortunately, this whole real time collaboration thing is the next major front in online communication, and I'm sure others will take up the mantle. Pity.) But I'm probably not representative of the general population. Even VCS collaboration often feels too "real time" for me (though I use it and heartily recommend it to others). I much prefer distinct drafts (PDF) sent via email. Even better is paper sent via post. This allows for me to organize my commentary and deliver an overall impression and specific recommendations (To be clear, I prefer this arrangement when editing and when receiving feedback.) However, with all that said, real time collaboration is becoming an expected feature. AbiWord and Google Docs have it, OpenOffice is talking about it, and MS Word even has a rudimentary option. I have several colleagues that have moved to Google Docs specifically because of the real time collaboration options. Even though they've never actually used them, at least to the best of my knowledge and the editing experience is hideous in every other respect. The people I've talked to take solace in knowing that they are present and "would never move to a platform that didn't have them." I've even heard this from the small cadre of users I've converted to LyX. In effect, real time document collaboration is a marketing feature. Unfortunately, marketing features matter. They differentiate program A from program B and providing a talking point. And because they're talked about, such features become part of the criteria by which a program is judged. If you need an example, look at what Google Docs has done for real time collaboration. The presence/lack of a collaboration feature has become a standard review of any word processor. Microsoft Word 2007 was knocked on ZdNet because it wasn't present. MS Word 2010 was lauded because it was (even though it sucks). Yet, I've never actually met anyone who writes with others in real time. The only counterexample I can think of was an exchange with Michael Foord, who uses it to start program documentation. But when I pressed him, what Michael described was more of an outlining tool and could easily be created via an interactive whiteboard rather than a full-featured real-time editing environment. Which leads to my second question. What should real time collaboration look like in order to be helpful? Should it be built into an IM client (ala screensharing) with voice and video? Or would it be better as an online service? Is integration into a desktop writing program necessary? Or would an implementation similar to the MS Word 2010 version be more appropriate, which is a hybrid approach? You have advocated for this strongly and I would love to hear your opinions on the above questions. What would be most helpful for your work? Based on other implementations, what doesn't work quite so well? As more tools release similar real time solutions, I think calls for something similar in LyX will increase. Not necessarily because it's useful, but because it's expected. And yes, I know that this is a terrible reason to add new features. Which is actually my general point. Current implementations of real-time editing are generally terrible. A desktop level approach would be infinitely superior to the approach we are seeing now where each word processor does its own thing. So, if the feature doesn't fit within LyX, perhaps we could send the use case scenarios and discussion to another project where it did fit? The natural fit, at least to my mind, would be one of the IM clients. Perhaps Empathy? Anyone else have any thoughts? Cheers, Rob Oakes
Re: more on collaboration
Hi Kevin, Jose et al, We use version control (git) + to write papers in the lab. It works fine but handling merge conflicts is still difficult; the chaps in the lab are all very computer literate but I regularly have to help out with a broken merge. It's certainly too complicated for me to insist on with external collaborators. For them I initially suggested LyX + track changes. However LyX's track changes plays very poorly with VCS in LyX 1.6.X and this is only partly solved in 2.0. The beauty of real time editing is that it handles merge conflicts in a way that is easy to understand and really pretty transparent. Of course for it to be transparent, there has to be a clear way to see who (and ideally when) last edited any piece of text. For my group and colleagues beyond the lab, collaborative editing (a la SubEthaEdit) would be the killer feature that would really expand the audience for LyX. I hope that at some point this will resonate with one of the developers with the skills to implement this kind of feature. Best, Greg. -- Gregory Jefferis, PhD Division of Neurobiology MRC Laboratory of Molecular Biology, Hills Road, Cambridge, CB2 0QH, UK. http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis http://www.neuroscience.cam.ac.uk/directory/profile.php?gsxej2 http://flybrain.stanford.edu
Re: more on collaboration
2010/9/24 Jose Quesada : > Hi, > We've had previous discussions on whether or not it's useful to have some > kind of real-time collaboration in LyX. > The death of wave seemed to reinforce the idea that this is not a killer > feature, and people don't need it. Collaboration using a VCS is sufficient. I think the problem with Wave is that... well... what's it for really? It's not an editor, not a chat program, not...anything...except a tech demonstration. Not likely to win the public over. > Well, recently I found two counterexamples. > One is http://docs.latexlab.org > A decent latex editor built on top of google docs. > The other one is... abiword. surprised :) ? > While being a crappy word processor, it's actually better than anything > built within a browser: > http://msevior.livejournal.com/28805.html > http://www.abisource.com/wiki/AbiCollab > > I still think LyX would benefit from such functionality. > Thoughts? For myself, I doubt I would use it much, however: I'm a geek and I love version control. For other users, I think collaborative editing would be a killer feature. Not long ago I held a little demonstration of Zotero for some rather non-geekier people, and the thing that really sold them (and got them off Endnote) was the collaborative features. They thought the plugins for OpenOffice and LyX sounded convenient, but were really disappointed that there was no true Google Docs integration, as all of them were mainly using Google Docs to write their master's theses... again because they could edit the same document at the same time as the rest of their group. Even the ones who plan on eventually getting a LyX document in the end insist on copy-pasting back and forth between Google Docs and LyX, just because it's supposedly so much more convenient (yes, they lose formatting and have to re-add references; they still do it). Even from the slightly geekier camp I've had lots of requests to install SubEthaEdit back when I ran OS X, so it's not just the non-geeks who get hooked on that stuff. best regards, Kevin Brubeck Unhammer
