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!
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:
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...
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 - 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:
Ability for wiki-page (and other document-content oriented
objects) to have exposed, user-settable and -configurable
properties.
Control over who can set and who can configure the
properties.
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:
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.
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).
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.
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.
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.
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
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.
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.
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
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. :)
|
