Comments

making sidebars sounds absolutely great for developers and very experienced wiki users. but: as it is now nearly everyone can edit a page and sees what's going on. because of this elegance i was able to get even sociology students to work with wiki! maybe there's a solution to satisfy both worlds - what about making two edit modes. one for advanced users and one for normal users. some sections on a wiki page would be just shown if the user is in advanced editing mode. -- BenediktEckhard

I think I'm starting to get this. My initial reaction was the same as Benedikt's: wikis should be simple, and this makes them more complex. But now I'm realizing that what David is proposing is an alternate mechanism for creating extensions (behaviors), one that will be interpreted by the wiki itself. So this is not something that normal users would do...but neither is writing a new behavior, and we allow that. This would simply make writing new behaviors easier. Frankly, I think it's an amazingly powerful and cool idea, done properly. One only has to look as far as emacs to see what sorts of neat stuff self-interpretation allows. -- CraigAndera

Oh. That's what this is about.... Thank's for clearing things up! -- BenediktEckhard

I got to see this in action a couple of days ago. It is very powerful and exciting. But it will be possible to allow this BehaviorExpressionLanguage to exist in individual pages of the wiki. So normal users might very well be exposed to it, even though we don't expect them to write it. On the other hand, we're already doing some complex things with the @@blah()@@ behaviors and that hasn't been a major problem. -- TommyWilliams

I think putting code for navigation in the wiki doc or doing panels, buttons and stuff like this has one main disadvantage: it would break the seperation between content and behaviour. so far all the behaviours create some content that could be formatted very easy in a pdf or doc or whatever. if complex behaviours would add behaviours like searching, buttons, navigation panels, etc. they would require a very tight coupeling to the formatters and the clients for putting out some javascript or whatever. I also think that it would make one WikiPage look much more frightening for beginners. -- BenediktEckhard

Like TommyWilliams, I had a chance to see this in action the other day. After the demo Tommy asked DavidOrnstein if he had ever thought about making certain properties invisible to editors in Edit mode, by default. He reasoned, rhetorically I think, that advanced properties and behaviors might be confusing to some users. I agree. So here's a scenario: you drop into edit mode and the only WikiText you see is simple text. In the WikiPane on right, under Formatting Tips is a button entitled, DisplayAdvancedWikiText or something of the sort. You click it and things like {TopicIndexBehavior} and Version: appear in the edit pane. It's that simple. Going one step further, I think that all .wiki topics need a page behind. Currently, we have .wiki and .awiki ('a' for archive) files in the WikiBase. I propose that there be a third .*wiki file called .pwiki ('p' for properties). Each .pwiki file could contain information that might otherwise appear in the .wiki file but which does not necessarily have to. Example properties include keywords, owner, summary, parent, relative, previous, next, datecreated, datemodified, and whatever else you can imagine. -- KorbyParnell

I strongly disagree with this. We are already treading on dangerous ground, adding syntax that unsophisticated users can't author. I think the advanced syntax is justified, because of the places where it will be used (summary pages, indexes, special use pages). However, adding a layer of indirection like this moves us even further from what makes the wiki so powerful and effective...simplicity. The very correspondance between what you type and what you see is part of that phenomenon. Or as some people argue it, "View Source" is what made the web grow so fast. -- CraigAndera

I just read through the various pages regarding WikiTalk. Its a quite intriguing concept. Assuming that casual users had a way to benefit without directly enountering its complexities, it is easy to see that more and more wiki functionality could be implemented and exposed this way, progressively layering on and extending a very simple core engine. That said, assuming I'm interpreting things correctly based on what I've read, something about the way WikiTalk appears to have been implemented is rubbing me the wrong way - as a little language with its own types, where those types resemble .NET types but may not be the actual types (inferred from reports of bugs that don't exist in the native types). Again, assuming I'm reading things right, I have to wonder why a little language is being built and why basic types are being re-implemented when instead an object model for the various wiki constructs could be built and then exposed for scripting via any .NET language. No new little language to learn, full reuse of framework types, performance of compiled code, etc. I can think of one reason for the current design, that being to try to create a standard that can extend past FlexWiki and .NET, but can someone shed more light on the reasoning behind the WikiTalk design? -- JeremyGray

I agree with CraigAndera. The Idea with the Code behind isnt that good. Basicly its not a bad idea, but it isnt very helpful. Korby is talking about Example properties: keywords, ... but it is very important that normal users can easily set those properties itself. Currently it is solved with the WikiPageProperties, and thats ok and simple. But the potentialities of WikiTalk in "Special use pages" is very remarkable. I have programmed my own Borders (see _NormalBordersRightOnly). I am not familiar with C - Like programming Languages, but I could make my own Borders. Otherwise, no normal User is making IndexPages. May it will also be useful with Templates (if they will be implemented sometime) -- SimonSchmid

WikiTalk is .NET at its finest. Not everyone can write WikiTalk but they don't need to. That's where the WikiGnomes that Ward at c2.com talk about, come in. People who know WikiTalk can refactor pages and create pages dynamically when needed. It's a higher level of wiki. No one who writes in a wiki even needs to use it. WikiPedia has some built-in code that I'm not interested in learning. The only thing I want to do is type. But, if I was a manager of WikiPedia, I would want a code that could help manage pages dynamically. I see WikiTalk fulfilling that purpose in FlexWiki. -- AstralisLux