> > I'm no dev, but I would argue that even if velocity or groovy are a > > little awkward, it's better to learn a standardized scripting language > > than have to pick up a new proprietary scripting syntax for every wiki > > project (or any other application that stands to benefit from scripting) > > I use. Such proprietary scripting languages are generally severely > > restricted. It's not terribly difficult to do simple things under > > groovy or velocity, and it's often impossible to do complicated things > > under proprietary syntaxes. So I'm personally satisfied with the > > current system.
I get your point, it's nice to have a standardized scripting syntax, even better as some might know it at first. The problem is groovy is still to tecky for end users. When you set up a corporate wiki, you're willing to give as much customization possibilities to end users without heavy formation, or no formation at all. A real easy scripting language will help low tech users (no coding skills, no algorithm skills, no html skills, Word skills) building dynamic contents on the wiki without help from IT. For example: TWiki uses simple, one line syntaxes to do custom searches, no loops needed in the script, just a "function" and some parameters. You can easily format the output using regular TWiki syntax. Sure, proprietary syntax is limited, it has to be "learned" (though it's focused on easiness) but if the functionalities are well chosen, a few can address a whole lot of use cases. > > > As far as what goes into which guide, the lines are a bit blurry. The > > > website uses "dev" in the sense of developing a customized 2nd > > > generation wiki application/system. This means creating your own > > > forms > > > and classes which you provide to users so they may add/edit content. > > > Once a "user" starts editing/creating > > > classes/templates/forms/macros/code snippets they graduate to the > > > classification of "dev" for a particular XWiki project instance. The > > > website designates this "dev" classification as separate from the > > > "community" space, which is provided for development of the XWiki > > > project at the sourcecode level. > > > > Spot on! :) > > > > > (The fact that the sourcecode > > > development mailing list is called [EMAIL PROTECTED] makes this nice and > > > confusing if I do say so). > > > > Never thought about this and the confusion it could create... > > > > Maybe we should change: > > > > * "User Guide" --> "Basic User Guide" > > * "Dev Guide" --> "Advanced User Guide" > > > > or > > > > * "User Guide" --> "User Guide" > > * "Dev Guide" --> "Advanced User Guide" / "Power User Guide" I repeat, I'm new to XWiki so it's a first impression I'm exposing here, but in my opinion some XWiki functionalities are too complicated. The dev guide is a real dev guide, it talks about API, Data model, Groovy scripting, Classes, Plugin development etc... These are real developer concerns, not "Advanced" or "Power user" concerns. The problem is not on the naming convention used but on the approach. If we try to identify the actors of a corporate wiki we might get: - users: everyone who makes content. Their needs for a guide are: what's a wiki, why is it good for me, what typical use case of a wiki, how do I edit/create/link pages, how do I subscribe to wiki content, how do I comment, how do I attach files... - power/advanced users or animators or section manager or whatever you want to call them: people responsible to coordinate a part of the wiki, they help organizing the wiki, suggest new contents, give a hand to new users. They don't have any advanced IT skills only advanced responsibilities. They are from the business, they often volunteer. Their guide covers: how do I create a new wiki space, how do I customize a space layout, how do I manage space access rights, how do I create dynamic content for the space homepage, how do I create a custom (dynamic) navigation portlet for my wiki space, how do I integrate macros, how do I integrate code snippets, how do I create templates, how do I create forms... - administrators: they install and maintain the technical infrastructure. Guide: how do I install twiki, how do I install plugins, how do I backup the system... - developers: address special user needs that need coding and extend core functionalities of wiki through the community. Recurring to developers to address user needs must be as limited as possible as it has a significant cost and goes against the "do it yourself" wiki philosophy. Guide: what's the API, what's the data model, how do I develop a plugin... XWiki already has the user guide, the admin guide and the dev guide and they're nice. The problem is this "advanced user guide". In my opinion the audience is definitely low tech. The functionalities exposed must be low tech oriented. A template needs no classes or properties being defined. Nor should a form. Scripting syntax must be easy and straightforward. Code snippets use this syntax and are short with no loops (out of the low tech user's league). The guide is full of real life examples. With this guide in hand, non-IT users get a real hand on the second generation wiki functionalities. William _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users
