Z Object Publishing Environment

Search | Download | Documentation | Resources | Members




Join Zope.org
Log in

Developer Home
Get Involved!
The Fishbowl

 Zope Exits

Zope Newbies

page served by app1

Proposals Table of Contents Last edited on Jan 20, 2001 3:07 pm

Wiki Next-Generation Discussion

Owner - KenManheimer

This is the place for comments and discussion about the WikiNG proposal.

Please include your name and the date with your entries, and please email zope-dev@zope.org list and/or klm@digicool.com after you've made any additions.

  • klm 7/24/00 - Don't forget to include your name and date in your comments! If you're not seeing the option to edit the page (in the footer), you probably need to login to your zope.org member account.

  • simon 7/25/00 - very nice discussion of where we are and where we might go. Lots in that proposal!

    • klm 07/26/2000 - Thanks, simon! I'm hoping we'll be able to go forward with it, and that you would be interested in being involved!

  • ggardiner 2000-07-26 - good, thanks, covers most needs for simple page management and reviewing while retaining simplicity for users. In addition, however, we really need a simple mechanism for uploading graphics and inlining local and remote graphics.

    • klm 07/26/2000 - Ah - addressing this, in part, is something i accidentally cut out of my proposal in the process of condensing it. I've put back a minimal suggestion of it in the bullet about Through-the-web object management.

      I agree about the need for inlined image references. I'm not sure about the right way - we could just make wiki's specialization of StructuredTextWiki:StructuredTextNG so it always inlined images, or we could invent some idiom for expressing inlining of WikiName references. We'd need to look at Use Cases, to see what's needed...

  • ChrisW 26/7/00 - Here goes:

    One of the things we (NIP) would really like is the ability to rename Wiki pages. Renaming a Wiki page should:

    • Rename the Wiki Page (obviously ;-)

    • Change all uses of the Wiki Page's name as appropriate.

    klm 07/26/2000 - This also is (begun to be) addressed in the Through-the-web object management bullet. I covered it at greater length in my original notes - see KLMNotesWiki:FinerWikiControls for more details. One note - i think in some cases changing the incoming links may not be the desired behavior - i think, instead, some kind of forwarding information needs to be retained, with provisions for immediate change or later change, at the behest of the people traversing the stale links, or no change at all - a policy issue...

    • Chris (again ;-) - Oops, you got me mid comment ;-)

      • ken - whoops!-) kinda cool, though, corresponding this way.

    I think you'd always want to rename for simplicity and in keeping with the way Wikis work: If a WikiName exists as a page, ti will link to it, so if you rename the page, the link should be changed. It keeps the programming simpler too ;-)

    On the whole I think the proposal is really cool. The discussion mix thing just confused me, perhaps it could be explained more? Also crit.org is down for me...The apps in the deliverable seem way beyond what Wiki's are good for. Maybe the phrasing is just off. What'd be nice is to include wiki pages(probably folders) in those systems rather than writing those systems in Wiki...

    • klm 07/26/2000 Good feedback. I'll have to wait for time and mandate before elaborating about the discussion mixin, but seeing crit.org (when it's back) may clear up the picture. As for "including wiki pages in those systems", as opposed to being the basis - the key to the proposal is that we would depend on some pretty power-packed capabilities - history, workflow, notification, organization, StructuredText - from zope. Ideally, the deliverables will entail refining the wiki to hook up with these capabilities, as a low-impedence, well-integrated UI, to put it all together like building blocks. Of course, it won't be as quite as simple as that - but it's a worthwhile aim, and i think, reachable at least in some significant measure.

  • hellmann 30 July 2000 - StructuredText (or StructuredTextWiki:StructuredTextNG) is a great way for creating wiki nodes easily. We have found in our use of a wiki to document our development process that things like images, PDF files, or other non-text files are sometimes just as important. Often these sorts of documents come to us from outside sources (e.g., a partner delivers their specification to us as a Word or PDF file).

    We do not want to rewrite the document in StructuredText, and in some cases could not achieve the same results. We do, however, want to store the document in our wiki so we can link to it from other sources. We are doing this now by storing them in the wiki folder or a sub-folder. This currently requires knowledge of how to access and use the Zope management interface. While the wiki by itself is something easy enough for non-technical users to handle, I am not comfortable giving access to the Zope management interface to many of the people using our wiki.

    I would suggest some way to integrate wiki nodes of different types. Rather than assuming that a new node should be created as a wiki node object, it should be possible to create any type of Zope object directly from a wiki. My feeling is that the user should be prompted for the node type, although there may be some way to know automatically.

    Obviously support for linking back to the wiki from a non-text node would depend on the level of integration of the document. Often backlinking is not useful (in the case of a document created externally) or used (in the case of a document stored in the wiki but shared with users who do not have access to the wiki) so this is not really a requirement.

    • *klm 07/30/2000 - The through-the-web object management bullet briefly addresses this - it's something we see as key to our integration of wiki with larger content management capabilities. We also need to focus on the process of creating a page, which currently establishes the page too early, before content has been committed. Also, i see it as completely consistent for the other types of content - file uploads, discussion objects, etc - to have some features of wiki pages, like backlinks, parents, and even outgoing links and offspring.

      Rather than crowd this discussion with more elaboration, i'm putting details in WikiNGDiscussionAltTypes.

      • hellmann 31 July 2000 - It sounds like you have some good ideas on how to put multiple document types into a wiki. My comments about backlinks assumed documents which could not be modified or displayed in a web browser (PDF).

  • hellmann 31 July 2000 - Another feature which would be useful is to have an interface for creating properties on wiki nodes. One way I would use this is to create one or more classification attributes to allow me to create indexing pages. Some classification types might be "use case", "personal", "status report", "schedule", etc. The specific attributes and values aren't important, though, if it is easy to add properties to a wiki node. It seems that each user creating nodes should not have to remember which properties to create, so the property definitions should come from the wiki folder, or some other managing object. This sounds similar to ZClassesx, though, so I wonder if there is some way to subclass the regular wiki node to add what is needed? Maybe this is more along the lines of configuration, like what is available with the Tracker, and less subclassing?

    • klm 07/31/2000 - I'm also interested in this one - it's something i meant to refer to in the bullet concerning wiki node classification. You bringing it up independently helps to substantiate and flesh out the need. (Of course, it helps that we've been working in the project wiki together, with some similar aims and approaches.-)

      I can see some taking some lessons from the tracker about user-extensible attribute fields ("traits" in the tracker ), but rather than having the attribute fields be wiki-wide, once again i see following the nesting hierarchy for propagation of the attribute fields layout, with policies about whether or not subnodes can extend/restrict the set of attributes and their values, and who is permitted to impose changes, etc. Restricting variability in the layout means hardening form-style of subpages.

      Promising territory, to be mined.

    • *hellmann 2 Aug * One potential problem I see with hierarchically imposed restrictions is what if I first reference a new node from one spot in the hierarchy, and then reference it from another? Which set of "required" attributes would be applied? Part of the point of the wiki is that it doesn't matter where a node is, right? We've added hierarchy for our own organizational needs, but in a way which makes it very easy to flexibly change the imposed structure.

      Perhaps an alternative to the hierarchy is to combine the two ideas for having different node types and for having nodes with properties. If the wiki machinery made it easy to define a node-type which has specific properties, then when a new node is created the appropriate properties can be assigned. This is sounding more and more like exposing ZClassx behavior within the wiki somehow.

    • klm 08/02/2000 - Ah - i had some trouble figuring out what exactly was at issue here, but i'm coming to realize that there are actually three distinct issues here, only one of which i was addressing:

      1. Ability for wiki-page (and other document-content oriented objects) to have exposed, user-settable and -configurable properties.

      2. Control over who can set and who can configure the properties.

      3. The default set of user-controllable properties and setting and configuration policies which obtain for a new page.

      #3 is the one that i was sort of jumping ahead to address with my nesting-oriented propagation comments, above, giving short shrift to the others.

      Is #1, the ability to have user settable and user configurable wiki page properties, what you're referring to by "exposing the ZClassx behavior within the wiki"? Specifically, do you mean ZClassx property sheets? I do think we'd want to expose something along those lines interface for configuring the properties (but probably with some streamlining), and something simple and more immediate for displaying and setting the fields - eg, right on the main content page.

      #2 would be part of the security interface, for designating who can and can't do what.

      #3 is about how the policies (who can and can't, as well as the default collection) for a new page are established when it's created. I think defaulting from the originating page - the default parent - according to its propagation policies is the right thing to do, because the parent represents specialization of properties configuration and policy that characterize that "region" of the wiki.

      There would be elaborations of these behaviors, depending on the settings, but the basic behavior would be very simple - duplicate the parent's configuration during node creation, providing gradual "regional" specialization without particular fuss. Users can produce more elaborate behaviors, controlling whether or not and who can change settings and/or configuration, etc, if they're willing to go out of their way to establish more elaborate configurations and policies. I think this would enable all sorts of forms workflow, particularly in conjunction with the workflow features that are another proposed thrust of this effort.

  • klm 08/02/2000 - I'm getting some ideas about using the wiki for discussions in the course of using the wiki for this one.

    In particular, i think it would be very suitable and conducive if editor adding comment in this discussion were constrained to only add lines, not change existing ones that other people had added. (Some editor or editors would be privileged to edit existing lines, in order to cook down and condense portions, once they're clearly settled...). In conjunction with a history mechanism that identified who made what edit, and made it easy to see changes, we'd have a well-controlled, traceable, and intricate forum for discussion - much like the one we're having now, but with much more reliable and traceable preservation of the info.

    An even simpler version would constrain people to adding entries at the bottom. This appending version would inherently be easier to trace, but would make it much harder to connect new comments with older (further back in the log) entries. The ability to interject new comments in arbitrary places - right next to their subject entries - would enable much better connection, and Zope's emerging history differencing and attribution tools would enable activity tracing as good as (or better than) the simpler, appending version.

    A more elaborate annotation system, like the one at http://crit.org, means less flow interruption of the subject document, but can make it harder to follow layered comments on comments. At the moment i'm leaning towards preferring the interspersed additions scheme, above, with edits of already existing lines limited to document creators responsible for cooking down the discussions. In this context, a document viewing knob could offer the reader control over their exposure to comments according to "depth", so they can choose to view just the base document (with glyphs to indicate the presence of comments, and maybe mouse-over bubble text previewing the comment substance), or twist the knob to open up and view progressively more recent comment layers.

  • tom.deprez@uz.kuleuven.ac.be - 09/12/00

    just my thoughts: I'm not a fan of wiki. ie. the most thing I hate about it, is that everybody can place anyware some text. This makes it hard to find out what has changed from the last time you visited the wiki page. Of course, I think that this is just also the strenght of Wiki. Because of this, I don't really like discussions with Wiki.

    • * klm 09/16/2000 * I have similar reservations. I'm not sure, but i think the sort of thing i sketched out just above this entry - look for 8/02/2000 - describes something along extremely similar lines. I guess you didn't see it - there is a lot of stuff in the proposal. More below.

    • * mutende 10/Jan/2001 * WhyClublet has a cool feature that makes it easy to spot the latest changes. See WhyClublet:GoldBar.

    However, recently I thought on a very interesting idea by what Wiki would be very, very usefull. Think of people writing a book. A writer can publish his chapter on the net. People can react and send some corrections, additions to the writer. It is not that easy to do so, because, or you've to copy the whole text and write the correction in it, or you say at line 309, word 7... This is not that handy. Wiki (with some modification) would come very handy here. For instance, let an writer publish his chapter on a wiki page. No people can access this page and change things in it. However! The original text may not be changed (the writer still has the last word). The changed things would appear in another color next to it. This way, the writer can read the changed thing and incorporate it (or remove it) when he things so. You could also think in layers. That is every person who changes something in the text has his/her own layer (on top of the real text) on what he can do what he wants. Later on, the writer can set these layers on/off for his/her purpose and change according.

    I don't know if I explained my example very well and if you can see the possible important role wiki's can play in such applications. What do you all think about this?

    • * klm Sept 16, 2000 * - I also like this idea, a lot. I mention above my 08/02/2000 entry, with similar thrust. I think the stuff in the original proposal concerning annotation is also very much along the same lines. I'm very excited about the possibilities of this approach - together with notification, it would enable what i'm calling content-based mailling lists. I think i see the benefits in a very similar way as you do - i wrote this in an exchange about the subject on zope-dev, yesterday (before i saw your discussion of it):

      • "The thing is, if we had an annotation style wiki, where commentators 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 commentators 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, increasing the likelihood that they would uncovering points they might have missed if they just appended 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."

      The layering that you refer to is what i call annotation, and would correspond to threads in weblog style discussions - with the benefit of gradual development of context, rather than accretion of layers of weakly interconnected commentary. I like the idea of using colors and other cues - i suggest in the proposal that attribution of text is important, i like various ways of indicating the attribution.

    • cwitty (Sep 25, 2000) I think Tom's idea is more interesting than insert-only annotations (my apologies, Tom, if I didn't understand what you meant). In collaborative document creation, you want it to be as easy as possible to suggest changes. For that reason, readers should be able to modify the existing text, rather than just make an annotation. If I'm reading a document, and I see somewhere that says "it's" rather than "its", I'm a lot more likely to report it if I can just edit the text than if I have to say "The third occurrence of "it's" in the above paragraph should be "its"." (Of course, if I have to find the author link at the bottom of the page, and e-mail the author, you can just forget it.)

      The idea with the "layers" is that people can (somehow) choose to see the original version, or the version with some set of changes applied.

      I've wanted a system like I'm describing for collaborative document development for a long time. To make it even easier to provide feedback, you could have a button "edit this paragraph" next to every paragraph; that gives you a page with an edit box for that paragraph, but the rest of the document is "normal" (so you don't have to scroll through the whole document to find the place to edit).

      • klm 09/29/2000 I like the idea of being able to edit the text, and have the system keep track of changes and provide the means to review and adjust them. This may be the right way to do things in some cases, and not in others. In one common sort of situation i see there being primary document editors, with last word on accepting or rejecting changes and additions, and more general people able to make suggestions.

        In this situation, i think it would be handy for the people having input to be able to add a line, right below the target line, like so:

                  the bird tucked it's head under it's wing
                  ~               its             its

        The system keeps track of who made the suggestion, and notifying whoever is concerned about its (not "it's":) addition. The editors have the prerogative to edit the lines.

        The advantage here is that the suggestors can easily see the established parts of the document and the pending suggestions. If the editors are way behind, the suggestions may make clutter. But that's sort of a self-regulating thing - it's bad for suggestors to be making suggestions about other people suggestions, assuming they're referring to established, sanctioned text...

        Now, when there are many people in the editors roles, it's certainly good to have the system keep track of who made what changes, and make it easy to trace what the changes are. (I've used such features in MS Word, and i'm sure i've seen such things in Lotus WordProx ((which i prefer)) and other such things.)

        The thing is, there are tradeoffs in the processes as you change the proportion of editors and suggestors. I don't think emphasis on one situation is inherently better than the other - rather, you need to balance them for the kind of collaboration you're doing. (And, while we seem to be making do without them, wouldn't it be handy to have any of these features, just for managing this discussion of the WikiNG proposal!-)

Rik Hoekstra (rik.hoekstra@inghist.nl :: 14/09/2000)

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:

  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 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.

    • klm 09/16/2000 - 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.

  • 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)

  • * klm 09/16/2000 * I think we're all converging, with enthusiasm, on an option for controlled editing (annotation) as a refinement for wiki changes. I suppose this all can be replicated by editing an emailled copy and emailling it back. The system would take care of diffing and identifying the changes (and qualifying them according to the change privileges for the role).

    I would concentrate first on the simpler case of editing on the web, and sending out notifications of changes with a link for further editing. Given zope site email reception capabilities (including authentication!), submitting edits via email should be an easy step.

    I have to say, i'm not sure what you're referring to by "noding proposals". It may (or may not) relate to something interesting that ethan and i discussed today:

    I should have known, but hadn't realized, that the nodes in squishdot/swishdot discussions are separate documents. What if the documents were wiki nodes, tailored for a discussion object? New nodes would have their thread parents as wiki parents, and the node names - their ids - would be auto-created but resettable by the node author. Thus the discussion nodes could include wiki refs to eachother and other docs in the wiki, and vice versa. The node authors could even allow annotations and revisions in their nodes, if the prevailing policy allows them to open it up, and they desire to do so...

    The idea generalizes, with "wiki widgets" that can be used as documents in composite objects, like discussions. Wiki features like easy authoring, wiki refs, and the nesting organization (so suitable for threading) come free...

Peter Hansen (phansen@kaval.com :: 2000-09-17)

I've noted a number of places where people are discussing "diffing" and the difficulty of inserting (or preventing insertion) of text in the middle of a Wiki, and so forth. Has anybody with an understanding of Wiki, Zope, and XML put any thought into whether and how the internal representation for ZWikis could be XML-based instead of StructuredText-based?

It would seem to support many, many different aspects of this discussion (which, BTW, is too large! Time to refactor?), such as marking sections as not editable, more easily supporting diffs, more easily allowing simultaneous editing with fewer collisions (and easier handling in case of collisions), better searching, etc., etc., and so on. I can barely begin to think of the different ways in which this would improve the situation.

I'm quite familiar with XML and Wikis, but still a rank beginner in terms of understanding Zope (gadzooks what a learning curve! :-). Maybe there would be serious complications I haven't foreseen, but if not it would seem that focusing on XML would vastly ease the burden of providing essentially all the features discussed elsewhere.

(Update: I stumbled over http://www.alphaWorks.ibm.com/tech/xmldiffmerge?open&l;=xmlin,t=gr,tech=x in the comp.text.xml newsgroup. Too bad it's in Java.)

* klm 09/29/2000 *

I love the idea of internally representing wiki nodes - and other zope documentation objects - in the DOM, rather than as text! See my entry below the next one (oh, if they only were real entries). I know you're not suggesting it, but i want to be clear - i wouldn't want to type in XML - i think StructureTextx is the cats pajamas for expressing structure textually, maybe we could allow whatever expression format people want to offer, with the common denominator of the DOM for internal representation.

Rik Hoekstra (rik.hoekstra@inghist.nl :: 25/09/00)

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 OFWikisx (OF=Old Fashioned as opposed to NG).

  • a presentation with folded nodes (like in a folding editor)

  • a threaded discussion a la Squ|wxishdot 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.

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

alternate view (in threaded discussion mode - probably know to all): (- is foldable; + is expandable)

-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

  • klm 09/29/2000 *

I agree that representing wiki nodes with XML (actually, the DOM), would be a great - great for controlled editing, diffing, etc. I suspect we're going to see some support for that kind of thing in general in Zope, as folks around digital creations are starting to see this point in many contexts. I'm hopeful WikiNG will be able to buy into it in a big way, with low cost. Rik, i also like the idea of structured text nomenclature for representing editable vs non-editable. StructuredTextNGx should make it easy to do something like that, building on the basic StructuredText implementation...

Jeff Archambeault (jarchambeault@uswest.net)

I must not get around much...just found this!

At The Open Idea Project (www.openideaproject.org) we will be trying to migrate tp Zope 2.2.2, Swishdot (Squishdot for PTK), and PTK itself. My concern is storage:

  • PTK stores objects created by users in each users directory.

    • PTK can manage objects accessability (public/private)

    • Additional rights will be needed for read-only and read/write access

  • ZWikiNGx should be ZCatalogx friendly

    • Ability to have local 'remote wikis' - each wiki object should know which wiki-group it is a member of, as a part of it's meta-data.

      • DublinCorex friendly

        • XML as a side-effect

    • ZCatalogx should be able to handle the indexing in case (a pointer to?) a wiki-object exists in more than 1 wiki-group

  • ZWikiNGx should be able to use PTK's user data

    • login/out

    • data storage, as above

    • edit-locking...on what scale has been discussed months ago ;)

These are pretty much the same issues for dealing with a Chat feature. Each user stores the chats they post. Each post knows which room it belongs in.

I believe that everything will mature at about the same rate, and everything will just start working together with sure maturity. Zope is way cool, and I still have alot to learn, but it's easy and fun. :)

View source WikiNGDiscussion
Advanced Actions / History
Visitor: Anonymous User
Jump to:
... by pagename prefix or search term.
For a plain search:
Privacy policy       Printable Page       Feedback about Zope.org