On Tue, 8 Dec 2009, Pavel Sanda wrote:
To make things more clear, my main interest with Wave in connection with
LyX is that I think there are interesting things in Wave as a concept
which we eventually could incorporate into LyX. (I don't advocate us using
Wave at this time for developer communication, maybe I never will)
Now, in order for other LyX developers to have the opportunity to see
what's possible in Wave, you need an account, for which you need an
invite.
Christian Ridderström wrote:
feeling for how easy, or difficult, it is to work on one document when
there are multiple cursors moving around on the screen. In my opinion
i think that all people around agree that having this in lyx would be
fine, we dont need google wave to tell us - this idea is around for a
long time. the problem is - who is going to code it? :)
Oh, I was under the impression that not everyone thought it would actually
work in practice to have several people editing the same piece of text
simultaneously. So I thought the UI experience would be an illuminating
experience. In addition, as the mechanisms in wave are documented (the
APIs), it might save us some effort in coming up with clever algorithms.
PS. There is one use case for wave which we would benefit from. If we
are to decide on a new LyX meeting, a wave is _perfect_ for discussing
where to hold it, and who is coming and all those details.
sorry to be moron, but i fail to see in what sense our mailing list+wiki is
insufficient.
I like wikis (obviously!), but they do have some drawbacks compared to a
wave. Please bear with me when I explain an advantage with a wave, I'll
later talk about using that concept in LyX.
In the case of arranging a meeting, we discuss issues while simultaneously
recording what we have agreed upon. To give a specific case, consider the
discussions about when to hold the meeting, while keeping track of who is
able/willing to attend at that point. We today do this using the wiki + a
mailing list, where we eventually copy the current table of
dates/participants from the wiki into multiple posts on the mailing lists,
where the discussion takes place. This is how it works in practice today.
A minor issue is the extra work involved in copy&paste, but a larger
drawack is that the copied table of dates/participants in the mailing list
won't update as people make modifications to the table in the wiki.
If a wave had been used, the discussion would take place very close to the
table of dates/participants, which is updated in real time. We could of
course have kept all of our discussions inside the wiki and obtained more
or less the same advantages, but as I think you may have noticed, it's not
that fun to do conversations in a wiki. (It doesn't have nice automatic
mechanisms to shows and record time stamps of when you said something, or
who said it etc).
Anyway, the above example is an example of conversations taking place
inside the document that records the results. Furthermore, the
conversations are likely to pertain to the results, so they might be
worthwhile to be able to restore with a reasonable effort. Actually, I
think it could be very valuable to have document specific discussions
recorded and kept together with the actual document. (It would also be
practical while creating the document, but that's separate).
There is actually already almost a LyX equivalent which we don't have in
our wiki (a "fix" could probably be added to the wiki). Let's say you and
I jointly work on a document that we shuffle back and forth. Then say that
I've changed a paragraph but I've got some question regarding my change.
What I could do then is to add a LyX note, in which I pose my question or
perhaps comment on why I did the change. You could then "reply" to my
comment in the note by adding a new note. In practice this would be minor
conversation regarding a very specific part of the document, taking place
in the document. The advantage I see for certaind kinds of discussions is
that if the document is version controlled, the discussion will also have
been kept in the VCS. This could be important if the discussion for
instance concerned design decisions that you later will wonder about.
To make conversation nicer, we could have a special kind of inset (which
can be inset into itself), that automatically records the time at which it
was added, by whom, and when the blip was last modified. All to make it
more like minor messages/statements from a person.
moreover - i suspect that you will have hard time to convince many of
us, why should we should drop beautiful combination of terminal+mutt+vim
in sake of some web oriented environment :)
Ah, but there is already a reference implementation that uses an interface
that is just like pine/alpine :-)
best regards
/Christian
--
Christian Ridderström +46 70 687 39 44
