RE: [Zope-dev] I feel your Wiki Pain ;-)
| 1. No threading. On several occasions I have made comments in a Wiki | that were subsequently ignored - I guess because they got lost in the
and from the WikiNG proposal:
For more elaborate editorial and commentary annotations, i can see layered documents, using mixin objects that provide a tailored view on other or contained objects. The mixin would be a layer by which annotations are associated with text passages in the rendered subject document, like "the crit system":http://crit.org does for arbitrary web pages.
Overall, document authors could use a particular annotation structure according to their needs. Eg, discussion objects for points which can be discussed, or brief editorial passages to give feedback, and author checkmarks for when they've satisfied or refute the suggestions, etc.
Annotation is a spiffy kind of threading.
I dont actually have anything against Wikis in general; I have used on very successfully for what I would describe as "document refinement", and a better annotation scheme will enhance that use of Wikis. The passage you quoted uses terms like "subject document", and at the moment I dont see that as the best model for a *debate*
| 2. No personal replies. On several occasions I would have liked to
From WikiNG:
- Attribution of changes for tracking
With attribution, you can identify and could respond directly to the author of a particular passage. It's useful for more, of course.
Cool, I missed that one.
| 3. No update notification. The one time I was update to
| 4. Hard to keep track of many Wikis: Each wiki has its own 'whats
The ability to subscribe for notification (above) and/or to track what you personally have seen, and not, is intended for this kind of thing.
It would keep me happy if the notification includes a link to the new content (rather than a link to the page that contains new content). Even better, the email notification could *include* the new content.
| 6. Too easy to miss the creation of a Wiki. On several occasions
My plans for notification subscriptions would be hierarchical, and enable you to subscribe to events like creations of new wikis within a hierarchy - so if you subscribe at the top of the wiki space, you find out about any new wikis, while if you subscribe within the developer's part of the space, you learn about new developers wikis. Etc. (This was not covered in the WikiNG proposal - i was trying to avoid including too many details, and failed miserably anyway...-)
Im happy.
| 9. I never get the structured text quoting of python source right | first time.
The only quoting you need to know is example::
The two colons after the word "example" indicate that this contained block is all quoted.
Ill remember that. Your proposed new attribution scheme would help too.
As i said in my last reply (but after you posted this, so you couldn't have taken it into account), mailling lists as they stand don't work for establishing growing structures.
But Wikis don't (for me, today) work for loosely structured commentry. Quoting from http://dev.zope.org/Fishbowl/Introduction.html
In some cases a mailing list will be setup for substantive, large-scale projects. Otherwise existing mailing lists can be leveraged (for now, use zope-dev for this).
Perhaps I should rephrase my objection..... The *real* problem is that this isnt happening - discussion is stored in Wiki pages like http://dev.zope.org/Wikis/DevSite/Proposals/XxxxDiscussion
<irony>At the WikiNG discussion page I wrote the following remarks, that I think not everyone will read</irony> IMHO there are too many issues muddling the discussions about wikis vs maillists vs discussion platforms. This problem is caused by the intermingling of too many different functions of a wiki. I'll go a bit at length to expose these and try to strike a balance, which should be in a combination (did I hear WikiDot?): 1.A mailing list is more convenient than a wiki because it is more instantaneous and more compelling because people get mail in their mail boxes. But mail discussions tend to wither away quickly. They go on for a day and if no one pins them down into a document they'll be forgotten. More so on a high volume list as the Zope list(s). I've seen this happen many times. Wikis have the quality of permanence both in (cyber)space and in time. 2.Discussion platforms like Squishdot, Wikis and what have you have the problem of getting out of attention of the people involved. They are permanent, but people have to perform separate actions to keep up with an online discussion and their mailboxes. Even if there is a mail-notification possibility, this leads to the situation that mails are sent as replies to the notification (by accident) and not to the forum itself (I'm not sure about Squishdot on this last point). 3.Both discussion platforms and mail lists are often too much of a sequential nature: proposals follow comments, follow counter proposals, follow comments etc. This leads to much inconclusion. A discussion is not per se over once it's withered away. A Wiki is (possibly; if used right) much more compelling in keeping discussions focused. 4.Some people think Wiki discussions are easily dispersed. Bad Wiki discussions are, but discussion products are almost always dispersed by nature. On many occasions I have (already) seen people summarize and structure maillist discussions into a Wiki web. 5.Wikis give the impression of being structured, but as is they lack structure. Both maillists and discussions have since long had the possibility of moderation. Wikis should have these too. The nice point about wikis is that you can determine which parts should be moderated (the central and the thought capturing documents for instance) and which ones are free for all (like discussions for example). The Wikis on the dev.zope site do a bit of this with delegating discussion to a discussion page. Most of these points are addressed in the proposal, but what I wanted to add is the notion of the necessity of integrating the three types of discussion into one product. That would make for a new generation. How would that look then: Make the wiki the central/anchor point for discussion. This means there should be a possibility for making central pages, spin off pages and discussion pages. - Wikis should be moderable on all levels (not editable, changes only after approval, free for all). The point up to which that is done is up to the owners/maintainers of the Wiki. - Include both a (threaded) discussion product for discussion. - Make this discussable from the web and from email. In the case of web discussion the advantages would be that discussions could take the form of annotations with a discussion. In the case of a maillist discussion this would mean instantaneous discussion. It should be possible to indicate in your email whether you want it included into the Wiki. This would also mean that there should be a structured way to integrate e-mails into a Wiki. The noding proposals (divide a wiki page into information nodes) above could well help to enable hooks for discussions. Perhaps even for determining which parts are discussable (namely only the one with a discussion node attached) not-completely-coherently-yours Rik
*This message was transferred with a trial version of CommuniGate(tm) Pro* On Fri, 15 Sep 2000, Rik Hoekstra wrote:
<irony>At the WikiNG discussion page I wrote the following remarks, that I think not everyone will read</irony>
(The territory is just ripe for irony, because we're talking about developing tools for conducting collaboration - including these kinds of discussions! I *really* appreciate that you put your comments in the wiki discussion page, and sent them to the list - i periodically check the discussion page for developments, but i lapse, too, and generally find it painful that i may wind up missing stuff. I think the best model, now, is to make changes and to notify people that they were made via this list - as you've done. (Not sure that will scale, but creating new lists for each proposal definitely won't scale. For a bit of nested irony, if i had time to do some more mailman-connected work, i might make it easier to create maillists - but i'm convinced that "content-based mailling lists" are a much better solution to the problem - eg, that's part of what i'm aiming for with WikiNG, and i'd rather spend whatever time becomes available on that then on tweaking the maillist side of things.))
Make the wiki the central/anchor point for discussion. This means there should be a possibility for making central pages, spin off pages and discussion pages. - Wikis should be moderable on all levels (not editable, changes only after approval, free for all). The point up to which that is done is up to the owners/maintainers of the Wiki.
Yes, this is something i also advocate, as you probably realize i did so in the proposal.
- Include both a (threaded) discussion product for discussion.
I have to think about it more, but offhand i much prefer more tightly coupling the discussion with the wiki content - make the "threading" based on changes to the wiki, and if weblog style is called for, use wiki structuring that restricts changes to the end of the existing content. (With allowance for having people with edit privilege that allows them to consolidate...) The thing is, if we had an annotation style wiki, where people are restricted to insertions, but anywhere in the text, and notifications indicated the changes, then the job of the consolidator would be **much** easier - all the editors would be involved in organizing their comments in the context of the document, as well as referring to relevant existing passages. I would expect this "closer coupling" to promote more salient collaboration - because people would have the burden of finding where their points fit, in the process uncovering points they might have missed if they just appeneded their comments to the end. By offering a view that shows the growth of a document, people can discern what's changed since they last grokked the whole thing, and as easily as possible keep track of the whole thing. Note that there's been a *number* of places in this recent WikiNG discussion where' i've cited existing passages that directly address people's points. I don't mean to complain - i think that's one cost increased by disconnecting the discussion and the document. I may be presuming too much, but i strongly suspect that if we were all making our points directly in the relevant context of the document, the reiteration would be necessary a lot less often - or structural flaws in the organization of the document would be exposed. It's this aspect of "building the stories" together where WikiNG ahs incredible promise, to me.
- Make this discussable from the web and from email. In the case of web discussion the advantages would be that discussions could take the form of annotations with a discussion. In the case of a maillist discussion this would mean instantaneous discussion. It should be possible to indicate in your email whether you want it included into the Wiki. This would also mean that there should be a structured way to integrate e-mails into a Wiki. The noding proposals (divide a wiki page into information nodes) above could well help to enable hooks for discussions. Perhaps even for determining which parts are discussable (namely only the one with a discussion node attached)
See my prior message on this subject. I do think these are great ideas - hope i'll get time before the end of the weekend to visit your comments in the wiki discussion so i can include my responses. If only the wiki took care of this for us!-) Ken klm@digicool.com
On Fri, 15 Sep 2000 11:27:33 -0400 (EDT), Ken Manheimer <klm@digicool.com> wrote:
(Not sure that will scale, but creating new lists for each proposal definitely won't scale.
I dont see this as a problem: You only create a new list when the traffic for that proposal gets too great for zope-dev. Threading is good enough before that point. You cant do that with todays Wikis, which need to capture the whole discussion right from the beginning (IMO)
Note that there's been a *number* of places in this recent WikiNG discussion where' i've cited existing passages that directly address people's points. I don't mean to complain - i think that's one cost increased by disconnecting the discussion and the document.
I think you (inadvertantly) provide evidence for my objection that Todays Wikis fragment discussion. Speaking as the person who started this thread, I didnt realise my comments would affect WikiNG until you suggested the issue. The inclusive nature of a mailing list is what makes it a useful community resource. Toby Dickenson tdickenson@geminidataloggers.com
Toby Dickenson wrote:
On Fri, 15 Sep 2000 11:27:33 -0400 (EDT), Ken Manheimer <klm@digicool.com> wrote:
(Not sure that will scale, but creating new lists for each proposal definitely won't scale.
I dont see this as a problem: You only create a new list when the traffic for that proposal gets too great for zope-dev. Threading is good enough before that point.
You cant do that with todays Wikis, which need to capture the whole discussion right from the beginning (IMO) [snip]
I think you could integrate both mailinglists and wikis. On the one hand, often we'd like to preserve a good posting in a mailing list as a wiki page. So we make a separate wiki@zope.org address that's subscribed to the mailing list, that keeps listening to the list and sees things like this in postings: Wiki:StructuredTextWiki:FooBarPage This is a bunch of text that should be added to FooBarPage. Wiki:end Or I see you posted something interesting, and *I* think it should be on the list: Wiki:StructuredTextWiki:FooBarPage
Something very interesting you wrote
Wiki:end It should strip off the quotes automatically in such a case. Some care should be taken so that replies don't add the same text to the wiki *again*. Anyway, so that's the mailinglist to wiki gateway. Now the wiki to mailinglist gateway. There's a very interesting discussion going on about ZFoobar on the MetaSyntaxWiki. So, someone presses the 'make this page into a discussion list' button, and the following happens: * A new mailinglist is created (with some name the user could fill in) * the wiki page is posted to the mailing list as the first message (perhaps after some editing) * if there is a notification system, the existence of the mailinglist is announced (ideally to all people who posted on that page). * the mailinglist is also listed in some central list somewhere on the Zope site. As people post interesting things to the mailing list, the wiki can be informed by the mechanism I described above. There should also be a rule for the list to be shut down as soon as the discussion has died down (no postings for a while, etc). I hope these ideas contribute to the discussion. I too find it harder to keep track of wikis than of a mailing list, and editing structured text in textareas through the web is not very unpleasant. I keep tripping up over structured text rules as well. (that gives me an idea that is fairly simple to implement: wiki@zope.org is an address you can mail to directly as well, and whatever you write is added to the wiki page you indicate; we get to use our own editors, parts can be forwarded from the list, and so on) Regards, Martijn
Toby Dickenson wrote:
I dont see this as a problem: You only create a new list when the traffic for that proposal gets too great for zope-dev. Threading is good enough before that point.
Yes, but zope-dev has a relatively high traffic load... Why should you have to put up with all that 'noise' if you're only interested in posts for your comparatively small discussion? Chris
On Thu, 28 Sep 2000, Chris Withers wrote:
Toby Dickenson wrote:
I dont see this as a problem: You only create a new list when the traffic for that proposal gets too great for zope-dev. Threading is good enough before that point.
Yes, but zope-dev has a relatively high traffic load... Why should you have to put up with all that 'noise' if you're only interested in posts for your comparatively small discussion?
Yeah - maillists flow by, and not everyone can follow all the traffic all the time!! The cool thing about "content-based" mailling lists, where people can subscribe to notifications about changes in subthreads, is that you just subscribe to the part of the discussion that has your interests!! -- Ken klm@digicool.com
Rik Hoekstra wrote:
maillists vs discussion platforms. This problem is caused by the intermingling of too many different functions of a wiki. I'll go a bit at length to expose these and try to strike a balance, which should be in a combination (did I hear WikiDot?):
Yes, well, that's the idea ;-)
Even if there is a mail-notification possibility, this leads to the situation that mails are sent as replies to the notification (by accident) and not to the forum itself (I'm not sure about Squishdot on this last point).
This is a real problem for Squishdot. I hate to think how many emails Butch has recieved at squishdot@yahoo.com because it's the default reply to address in the Squishdot demo sites. Swishdot will hopefull not have this problem when used in conjunction with ZMailIn.
4.Some people think Wiki discussions are easily dispersed. Bad Wiki discussions are, but discussion products are almost always dispersed by nature. On many occasions I have (already) seen people summarize and structure maillist discussions into a Wiki web.
Yes, but does that mean the Wiki is good for the initial discussion?
The Wikis on the dev.zope site do a bit of this with delegating discussion to a discussion page.
Yes, but that's only advisory, it's not enforced...
Most of these points are addressed in the proposal, but what I wanted to add is the notion of the necessity of integrating the three types of discussion into one product. That would make for a new generation. How would that look then:
<snip Memepool equivalent> Funny you should say that. Some other people I'm chatting to have come up with roughly the same ideas... cheers, Chris
On Thu, 28 Sep 2000, Chris Withers wrote:
4.Some people think Wiki discussions are easily dispersed. Bad Wiki discussions are, but discussion products are almost always dispersed by nature. On many occasions I have (already) seen people summarize and structure maillist discussions into a Wiki web.
Yes, but does that mean the Wiki is good for the initial discussion?
The point you've cited seems to be about something else (why wikis can work for discussions, not why they're good for setting them up). My response to your challenge is that the lack of a clearly designated document or other artifact as the focus of a discussion can, and, i think, usually does, lead to drift in the discussion. In weblogs, the document at the top anchors the discussion. In our proposals site, the proposals serve as (evolving) subjects of the discussion. I don't think anyone disagrees that wiki pages as they stand are imperfect for discussions. I strongly feel (with lots of experience) that mailling lists are also flawed, sorta complementarily, for getting definite results out of discussions. Both work with some effort, i think many of us feel that a insightful hybrid could reap more than the benefits of both.
The Wikis on the dev.zope site do a bit of this with delegating discussion to a discussion page.
Yes, but that's only advisory, it's not enforced...
What's your point? It seems to work, though there's possibility for it to breakdown. We recognize that possibility is significant, and would like to address it - hence the WikiNG proposal, and many other expressions of desire to fix these sorts of things. Actually, we're sorely chafing under lack of such fixes, but we can't afford to neglect our other commitments (clients, including zope community!) at the moment to do so. And we feel that we're better off, for the time being, with fixed points as the focus of proposal discussions, for instance.
Most of these points are addressed in the proposal, but what I wanted to add is the notion of the necessity of integrating the three types of discussion into one product. That would make for a new generation. How would that look then:
<snip Memepool equivalent>
Funny you should say that. Some other people I'm chatting to have come up with roughly the same ideas...
We discussed (in a off-list discussion) a point of karls, that the tracker and weblog can map onto eachother, with some structural provisions. I can see something very similar with wikis. (This came out of a discussion with ethan - we were wondering how the WikiNG stuff fits in with the PTK. We came up with a bunch of stuff that i really like, including this vision of integration with s{qu,w}ishdot - just a concept, to demonstrate the kinds of things that would be possible - i'm not looking to impose it on you if it doesn't seem suitable to you.) A weblog could constitute a wiki space, with the topic message being the FrontPage and the threads hanging off of it being nested wiki pages. The discussion pages would automatically get names, per their nesting status - LogSub1Sub2 or something, overridable by the page author to have semantic significance. The benefits: - Structured text. - Easy for authors to refer to other messages in the discussion by name, using wiki references. - Wiki organizational features - table-of-contents view, ability to adjust nesting situation in the discussion (modulo the weblogs policy - often the owner may disallow any such adjustment, but in some cases it would make sense). - With WikiNG's prospective notification mechanism, people could "subscribe" to email notifications for any changes - additions, edits, etc - within threads/subthreads, or just for additions at top levels of threads. The latter is like "executive summary" monitoring, wanting to know only when the uppermost parts of the discussions change, without having to worry about changes to the outlying parts of the discussion tree. - With email-in wiki pages [i have to comment on mj's proposal, i have similar ideas in the WikiNG proposal, but haven't had time to evaluate his specifics!], people could use their subscriptions to hierarchies within the weblog to make their contributions via email - often for submitting new messages, but perhaps sometimes for annotating existing ones, a la... - With WikiNG editing policy control, the weblog *could* have a policy that allows authors to amend their messages - eg, to insert or append comments to their existing messages. Or to edit their messages, if that fits the task at hand. (Eg, if what they're doing is collaboratively developing a document.) The basic case would not allow this, for more classic, conventional weblog conduct. Lots of good stuff. The essential thing in this perspective is seeing the weblog as a structured viewing mode for the contents of the wiki - or the wiki as being an substrate for the contents, with enriched content. I imagine this would generalize to other discussion formats. These are the kinds of things i'm hoping to get at with WikiNG - a smart content widget, with two essential features - good impedence matching to authoring structured, linked content (structured text plus wiki refs), and intrinsically determined and easily adjustable organization. Ken klm@digicool.com
Ken Manheimer wrote:
I don't think anyone disagrees that wiki pages as they stand are imperfect for discussions. I strongly feel (with lots of experience) that mailling lists are also flawed, sorta complementarily, for getting definite results out of discussions. Both work with some effort, i think many of us feel that a insightful hybrid could reap more than the benefits of both.
Yup, spot on :-)
The Wikis on the dev.zope site do a bit of this with delegating discussion to a discussion page.
Yes, but that's only advisory, it's not enforced...
What's your point?
Not point, just a comment ;-) As long as this as recognised it's not so bad...
We discussed (in a off-list discussion) a point of karls, that the tracker and weblog can map onto eachother, with some structural provisions. I can see something very similar with wikis.
Yup, hence WikiDot, for me to work on...
A weblog could constitute a wiki space, with the topic message being the FrontPage and the threads hanging off of it being nested wiki pages. The discussion pages would automatically get names, per their nesting status - LogSub1Sub2 or something, overridable by the page author to have semantic significance.
The names aren't so important to me but I think I see where you're going... I'm keen to have the structure of replies actually be a storage structure, unlike in traditional Wiki. This makes WikiName markup more difficult to handle, unfortunately...
- Wiki organizational features - table-of-contents view, ability to adjust nesting situation in the discussion (modulo the weblogs policy - often the owner may disallow any such adjustment, but in some cases it would make sense).
Good point.
- With WikiNG's prospective notification mechanism, people could "subscribe" to email notifications for any changes - additions, edits, etc - within threads/subthreads, or just for additions at top levels of threads. The latter is like "executive summary" monitoring, wanting to know only when the uppermost parts of the discussions change, without having to worry about changes to the outlying parts of the discussion tree.
Swishdot is going to have this stuff pluggable, so WikiDot could have something to match this...
- With WikiNG editing policy control, the weblog *could* have a policy that allows authors to amend their messages - eg, to insert or append comments to their existing messages. Or to edit their messages, if that fits the task at hand. (Eg, if what they're doing is collaboratively developing a document.) The basic case would not allow this, for more classic, conventional weblog conduct.
Another good point...
Lots of good stuff. The essential thing in this perspective is seeing the weblog as a structured viewing mode for the contents of the wiki -
yup...
These are the kinds of things i'm hoping to get at with WikiNG - a smart content widget, with two essential features - good impedence matching to authoring structured, linked content (structured text plus wiki refs),
A lot of people I know would disagree with the Structured Text bit, but I guess it'll have to do for now. Wysiwig editing on the web hasn't arrived yet :-(
and intrinsically determined and easily adjustable organization.
'Easily adjustable' could be difficult... cheers, Chris
On Thu, 28 Sep 2000, Chris Withers wrote:
These are the kinds of things i'm hoping to get at with WikiNG - a smart content widget, with two essential features - good impedence matching to authoring structured, linked content (structured text plus wiki refs),
A lot of people I know would disagree with the Structured Text bit, but I guess it'll have to do for now. Wysiwig editing on the web hasn't arrived yet :-(
(I wonder whether having a single quick ref page for structured text, linked to on every edit form, would go a long way to reducing those objections. Particularly if the quick ref page is clear and concise.)
and intrinsically determined and easily adjustable organization.
'Easily adjustable' could be difficult...
I was just referring to the ease of reparenting a page - if this isn't familiar to you, see the backlinks pages in any zope.org zwiki. Ken klm@digicool.com
Ken Manheimer wrote:
(I wonder whether having a single quick ref page for structured text, linked to on every edit form, would go a long way to reducing those objections. Particularly if the quick ref page is clear and concise.)
Not really... the fact that you even need one of those is why it's not really good enough...
and intrinsically determined and easily adjustable organization.
'Easily adjustable' could be difficult...
I was just referring to the ease of reparenting a page - if this isn't familiar to you, see the backlinks pages in any zope.org zwiki.
OK, the interface is easy, I was thinking of how I'd implement it. ...but now I think abotu that, it shouldn't be too hard either... :-) Chris
*This message was transferred with a trial version of CommuniGate(tm) Pro* [I'm running out of time here, so pardon the brief responses. Make no mistake, though - i'm glad to be having this discussion! It's good to be getting this input, seeing suggestions for other ways to look at this discussion problem...] On Fri, 15 Sep 2000, Toby Dickenson wrote:
I dont actually have anything against Wikis in general; I have used on very successfully for what I would describe as "document refinement", and a better annotation scheme will enhance that use of Wikis.
The passage you quoted uses terms like "subject document", and at the moment I dont see that as the best model for a *debate*
Do you feel that weblogs are bad models for debates? I think they're pretty good least-common-denominators. I would probably prefer the kind of annotation-based thing i described in my last message (and began to sketch in the WikiNG proposal) for collaborative generation of documents, but i can see the place for weblogs, just as i can see a place for network chats. With adequate integration of email (for notification and response), i see them as better than just email...
The ability to subscribe for notification (above) and/or to track what you personally have seen, and not, is intended for this kind of thing.
It would keep me happy if the notification includes a link to the new content (rather than a link to the page that contains new content). Even better, the email notification could *include* the new content.
Different options for different purposes - but we need at least notification!
But Wikis don't (for me, today) work for loosely structured commentry. Quoting from http://dev.zope.org/Fishbowl/Introduction.html
In some cases a mailing list will be setup for substantive, large-scale projects. Otherwise existing mailing lists can be leveraged (for now, use zope-dev for this).
Perhaps I should rephrase my objection..... The *real* problem is that this isnt happening - discussion is stored in Wiki pages like http://dev.zope.org/Wikis/DevSite/Proposals/XxxxDiscussion
I think we all agree this is a problem. We seem to have found a short term solution - though i'll tell you that with time constraints, i won't immediately have time to incorporate the points raised in the documents. Ken klm@digicool.com
On Fri, 15 Sep 2000 11:40:09 -0400 (EDT), Ken Manheimer <klm@digicool.com> wrote:
Do you feel that weblogs are bad models for debates?
I find the wiki and weblog tools available today to be inferior to mailman for debates, and it will take alot of work to develop WikiNG into a serious contender. I suspect the sticky points will be: 1. The ability to read without continuous network connection. 2. A user interface that is not encumbered with transatlantic http round-trips for each user interaction.
I think they're [weblogs] pretty good least-common-denominators.
i see them [weblogs and wikis] as better than just email...
(Ive snipped those two comments out of context, and I hope it doesnt misrepresent Ken) I agree email alone is inadequate.... Please dont misunderstand me: I am *not* advocating that. Wikis work well for consolidating documents once a rough concensus has been reached. My preference is that the discussion leading up to that concensus takes place on zope-dev. Toby Dickenson tdickenson@geminidataloggers.com
Do you feel that weblogs are bad models for debates? I think they're pretty good least-common-denominators. I would probably prefer the kind of annotation-based thing i described in my last message (and began to sketch in the WikiNG proposal) for collaborative generation of documents, but i can see the place for weblogs, just as i can see a place for network chats. With adequate integration of email (for notification and response), i see them as better than just email...
I like the email list proposal of Martijn Faassen earlier on this list. I added some comments to the Wiki discussion page, where someone proposed using XML for Wikis: I agree with Peter that the proposal is practically shouting XML all over the place. In a Zopish way this would mean dividing up a Wiki page in different objects (say Topics or Paragraphs or whatever). So a Wiki page would become an XML document, consisting of Wiki node documents. The advantage is that this would allow for a presentation in the form of - one or several continuous pages as in the OFWikis (OF=Old Fashioned as opposed to NG). - a presentation with 'folded' nodes (like in a folding editor) - a threaded discussion a la S[qu|w]ishdot or the Discussable thingy - an XML document (for who would want it) The editing could be in the form of Martijn Faassens XML Widgets editor: put a node point in front of a 'discussable' node, promote that one to the top when the 'node point' is clicked on and allow for editing. An example below, in which the o stands for an editable (=clickable) node point (for wiki reasons I have not put blank lines between them. <pre> o this is the first editable node
(user::time) this is a comment to it (user::time) and another comment to that (user::time) this another one (user::time) more comments o this the second one this one is not editable o this one is (user::time) a commennt to the last node </pre>
alternate view (in threaded discussion mode - probably know to all): (- is foldable; + is expandable) <pre> -This is the first editable node + this is a comment to it - this another one - and another one to that - this the second one this one is not editable +this one is </pre> another 2 cents Rik
Toby Dickenson wrote:
The ability to subscribe for notification (above) and/or to track what you personally have seen, and not, is intended for this kind of thing.
It would keep me happy if the notification includes a link to the new content (rather than a link to the page that contains new content). Even better, the email notification could *include* the new content.
...yes :-) Something like a diff would be great :-)
The only quoting you need to know is example::
The two colons after the word "example" indicate that this contained block is all quoted.
How is a 'contained block' delimited?
Perhaps I should rephrase my objection..... The *real* problem is that this isnt happening - discussion is stored in Wiki pages like http://dev.zope.org/Wikis/DevSite/Proposals/XxxxDiscussion
Good point :-)
On Thu, 28 Sep 2000, Chris Withers wrote:
The only quoting you need to know is example::
The two colons after the word "example" indicate that this contained block is all quoted.
How is a 'contained block' delimited?
As i did in my example, by indentation. (This is a primary component of the "structure" in StructuredText. Maybe we're not being clear enough about that in our explanations of structured text - i would expect that not knowing about it could make it much much harder to understand what's going on, in general, with StructuredText!) Ken klm@digicool.com
Ken Manheimer wrote:
As i did in my example, by indentation. (This is a primary component of the "structure" in StructuredText. Maybe we're not being clear enough about that in our explanations of structured text - i would expect that not knowing about it could make it much much harder to understand what's going on, in general, with StructuredText!)
Yup :-) This sort of thing is why I don't really like Structrued Text, but it's probably as good as can be done without nice Wysiwig editing on the browser side... cheers, Chris
participants (6)
-
Chris Withers -
Ken Manheimer -
Martijn Faassen -
Rik Hoekstra -
Toby Dickenson -
Toby Dickenson