8 Nov
2010
8 Nov
'10
9:16 a.m.
On Nov 8, 2010, at 1:44 AM, Ludovic Dubost wrote:
Le 07/11/10 21:24, Sergiu Dumitriu a écrit :
I think a wiki is in general a terrible tool for discussions. It's good for creating
content collaboratively but bad for discussion. The proof is that you want to send
notifications by mail which proves mail is still the best place for discussions.
Personally I'd never take the time to open a wiki, navigate to the page, write
something in there, just to have my feedback sent by mail. I'd directly write that
mail or respond to a previous mail. Unless it was as easy to do it in the wiki as it is in
my email client (see below).
However I agree that notifications is important but again I don't think that email is
good. Actually it's quite bad. We're trying hard with various tool to remove email
clutter. This is why we have RSS feeds, Tweets, etc.
So while I agree it's good to have the possibility in the watchlist to send email
notifications whenever a document is modified, this must be chosen by the user and not
forced onto him. I envision a workflow like this one:
- I'm writing a page and I want to invite people to it. I send a mail to them
- In that mail (or on the page that the mail opens when you click on the link),
there's a button to add the page to one's watchlist. Thus the user can choose to
receive email notification either immediatly when there are changes or at his own pace. He
can also decide to subscribe by RSS feed in which case he'll also receive immediate
notifications.
Again IMO the wiki is not a discussion tool and it's not meant to be a place for rapid
discussions. There are way better tools for this:
- mailing list or mailing groups (average response time == few hours)
- chat (average response time == minutes)
For the wiki the average response time is around days IMO.
Now if we really wanted discussions to happen in the wiki we would need to make a mailing
list bridge or IM bridge so that when people reply to mails or chat messages the content
gets added to the wiki. We would need a way to separate content modification (ie the
content is modified in the wiki page) from comments (either added inline as an annotation
or at the bottom) in some ways.
Another idea which I love is to do like zapplets were doing (back around 2000) and receive
an HTML email containing the full page with the ability on the email client side to make
modifications directly to the page inside the mail client and send that modification to
the server. And when the email is refreshed you can also see the modified content from the
server. Zapplets were really great tools and I loved them at the time.
Anyway I'm not strongly opposed to any of what"s been discussed. We just need to
be careful that we need to release the mailto feature today so that we don't miss our
XE 2.6 deadline, so we need a minimal first implementation that works and we can add new
features later on in the 3.x cycle.
Thanks
-Vincent
I don't like this, it's intrusive.
Personally I wouldn't like at all
being forcefully invited into a conversation. There are other ways of
doing this which don't involve waking up with 30 emails in my inbox,
most of which will be implemented in the 3.x cycle as part of the social
improvements.
I don't agree with you that the social improvements do anything in this area
or maybe I'm missing something. If it's activity streams or other real time
features, oin many cases, you can't go all the time to the wiki to check if an
important document is evolving, for which the discussion needs to be fast.
You might not like it, but this really creates dynamicity when discussing on a wiki
document.
The lack of such a features leads to discussions staying in email exchanges and therefore
no work on the wiki document itself (when it was at all created).
Think about a discussion about a feature in the devs mailing list. None of it is captured
in the wiki page where the feature is described.
Think also about non technical people that need to learn how to work with wikis. Concerning being forced in a conversation, you can
drop out in one click if you don't like it and it's the responsibility of the
person sending the notification to actually decide to do that push.
Of course this should not be done by default on all documents as this is meant for
important docs for which a discussion is really needed, like a project manager bringing in
3 people he works with in a discussion. Managers need to be sure that what they want to do
reaches their target. If editing the wiki page or commenting on a wiki page is not sure to
reach it's target, the manager will reach out to other means (email, skype or even
telephone). Once this happens you have lost of lot of valuable content.
Without the forcing, you can be sure that since some people will be missing the
discussion won't work as well.
In any case please don't think about this feature for public discussions. It's
meant for business users so that they can get the work done.
I agree that it's
some work and might be too much for this version.
email usage should move from being the actual place of discussion to a
notification tool.
It's still a good notification tool for the important ones. Clearly if you are
overloaded in one of your channels, then it's stops being effective.
But well done it's a good notification tool. RSS or Twitter which are good at being
notification tool for massive amounts of information are actually bad for the smaller
amounts of important information.
In my view it's about learning how to use a combination of these tools for that.
Back to the wiki, my objective here is not to move the discussion to emails, but to make
sure that any discussion in the wiki get the same efficiency as email when it comes to
notification of the discussion events. As for capturing responses in emails into the wiki
this is to ease transition from email to wiki. I would expect that experiences users would
click on the link to comment in the wiki since you would have more features there.
Ludovic
I agree about a "notify me of changes"
checkbox under the action
buttons, if Vincent doesn't think it crowds the editor UI.
That's definitively already usefull as any editor/commentor can decide to get
instant notifications.
But the minute you are not sure that the other user will get your comment, people will
loose confident is this way of discussing.
Finally
we could add an email box so that we can load comments sent as a
reply to an email sent by the wiki.
Yep, this is also an idea kept in the
background, but too complex to be
included inside the "email this page" development. The
rationale for this feature is that when working on a document that
requires some discussion and validation, the email discussion is not
captured and the changes in the wiki are not triggering a fast enough
reaction thus slowing down the discussion around the document (I know
the Watch List exists, but since it requires manual subscription, most
participants won't do it and the speed of notification of the watch list
is not fast enough for discussion).
One idea of improvement for the watchlist was
to have instant
notifications, but this is another topic. In summary:
- add a new level for the watchlist which sends notifications as soon as
a document is sent (as implementation, it will use the observation
mechanism and not a scheduler job)
- the current notification interval configuration will be kept as the
default
- for each item in the watchlist it will be possible to specify its own
interval setting
Isn't your last paragraph contradicting your proposal? Email is slow and
deprecated, and one of the main points when presenting XWiki is how much
better it is than emails. Why would moving the discussion to emails help
collaborative writing?