[xwiki-users] XWiki scripting for end user (not Groovy)
Hi, First: I am rather new to XWiki. I am checking XWiki's scripting capabilities. The possibility of using Groovy and Velocity directly within pages is a nice feature. But I was wondering if there was an easier way to integrate dynamic contents into wiki pages. Groovy is easier than Java but you still need advanced programming skills to use it. In my opinion staying at the Groovy level is not user-friendly when you think that wikis are aimed for a broad audience. Most advanced wikis (TWiki or Deki Wiki for example) give simple scripting syntaxes thought for users with no programming skills. Is there anything like that foreseen for XWiki? The same applies to the form ant template system. It seems impossible for a normal user to use them. I was surprised to find the how-tos for these features in the developer guide, not the user guide. Thanks, William
Hi,
First: I am rather new to XWiki.
I am checking XWiki's scripting capabilities. The possibility of using Groovy and Velocity directly within pages is a nice feature. But I was wondering if there was an easier way to integrate dynamic contents into wiki pages. Groovy is easier than Java but you still need advanced programming skills to use it. In my opinion staying at the Groovy level is not user-friendly when you think that wikis are aimed for a broad audience. Most advanced wikis (TWiki or Deki Wiki for example) give simple scripting syntaxes thought for users with no programming skills.
Is there anything like that foreseen for XWiki?
The same applies to the form ant template system. It seems impossible for a normal user to use them. I was surprised to find the how-tos for these features in the developer guide, not the user guide.
Thanks, William
Hi William. I'm new to XWiki as well :) 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. 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. (The fact that the sourcecode development mailing list is called devs@xwiki.org makes this nice and confusing if I do say so). Paul D. Grodt TECORE Wireless Systems
Hi all. So I installed the Xar on my xwiki with no errors. It's tied to an sql dB... For some reason it still doesn't have the "Register" option at the top right of the screen. It has "administration" and "Log In". Obviously no user can log in, because there are no users. Administration doesn't ask for a user name an password. Have any of you run into this before? thanks!! -Rob
On Nov 16, 2007, at 6:03 PM, Paul Grodt wrote:
Hi,
First: I am rather new to XWiki.
I am checking XWiki's scripting capabilities. The possibility of using Groovy and Velocity directly within pages is a nice feature. But I was wondering if there was an easier way to integrate dynamic contents into wiki pages. Groovy is easier than Java but you still need advanced programming skills to use it. In my opinion staying at the Groovy level is not user-friendly when you think that wikis are aimed for a broad audience. Most advanced wikis (TWiki or Deki Wiki for example) give simple scripting syntaxes thought for users with no programming skills.
Is there anything like that foreseen for XWiki?
The same applies to the form ant template system. It seems impossible for a normal user to use them. I was surprised to find the how-tos for these features in the developer guide, not the user guide.
Thanks, William
Hi William. I'm new to XWiki as well :)
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.
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 devs@xwiki.org 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" Thanks -Vincent
Power user guide sounds good to me. Guillaume On 16/11/2007, Vincent Massol <vincent@massol.net> wrote:
On Nov 16, 2007, at 6:03 PM, Paul Grodt wrote:
Hi,
First: I am rather new to XWiki.
I am checking XWiki's scripting capabilities. The possibility of using Groovy and Velocity directly within pages is a nice feature. But I was wondering if there was an easier way to integrate dynamic contents into wiki pages. Groovy is easier than Java but you still need advanced programming skills to use it. In my opinion staying at the Groovy level is not user-friendly when you think that wikis are aimed for a broad audience. Most advanced wikis (TWiki or Deki Wiki for example) give simple scripting syntaxes thought for users with no programming skills.
Is there anything like that foreseen for XWiki?
The same applies to the form ant template system. It seems impossible for a normal user to use them. I was surprised to find the how-tos for these features in the developer guide, not the user guide.
Thanks, William
Hi William. I'm new to XWiki as well :)
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.
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 devs@xwiki.org 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"
Thanks -Vincent
_______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
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 devs@xwiki.org 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
Regarding the user guide, I'd split the feature presentation part (aimed to be a commercial content) and the real user guide. It confuses a bit (both users and prospectors) and doesn´t give the user a presentation of the features and how to use them in a step by step manner. Macros for instance are not present in the feature list while they're really nice to use. While internationalization is while it's not something you'd see in a user guide. Studying macros a bit more I realize they are that simple scripting language I was looking for. Some code snippets should be turned into macros like Child Page Snippet, Backlinks Snippet (or others) so advanced user can use them without fear, and without cluttering their wiki pages with real code. Macros could be part of the user guide or the "Advanced user" guide.
Hi, yep, in the end macros are exactly what your were looking for. They are designed to let people create quick ways to access features they use a lot (a nice css display for a floating box for instance). They leverage XWiki's scripting ability and make them available to end-users to perform simple tasks easily. I thought about it but your own reply was faster than mine ;-) BTW, I'd be interested to know how you found about XWiki and what are your impressions about it (besides its user guide... :-) Thanks for your feedback, Guillaume On 19/11/2007, William Lesguillier <wlesguillier@agaex.com> wrote:
Regarding the user guide, I'd split the feature presentation part (aimed to be a commercial content) and the real user guide. It confuses a bit (both users and prospectors) and doesn´t give the user a presentation of the features and how to use them in a step by step manner. Macros for instance are not present in the feature list while they're really nice to use. While internationalization is while it's not something you'd see in a user guide.
Studying macros a bit more I realize they are that simple scripting language I was looking for. Some code snippets should be turned into macros like Child Page Snippet, Backlinks Snippet (or others) so advanced user can use them without fear, and without cluttering their wiki pages with real code.
Macros could be part of the user guide or the "Advanced user" guide. _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
BTW, I'd be interested to know how you found about XWiki and what are your impressions about it (besides its user guide... :-)
I first discovered XWiki two years ago and it seemed a bit raw, I was looking for a corporate wiki and the features proposed fit my needs but the interface and user experience wasn't what I was looking for. I came back to XWiki a few weeks ago after having tested TWiki for quite a long time and Deki Wiki for a shorter period. I was quite amazed by the huge step forward XWiki had done. The company I work for (Andalusian Ministry of Economic and Finance) is looking for a corporate wiki for IT and possibly non-IT personal. We have strong technical requisite: Java platform and Oracle database since it would ease administration a lot. XWiki is nearly the only competitor in the field. As for feedback: first things first, XWiki is a really nice piece of software with very promising possibilities. Technically speaking it is hard to peep, it certainly is a nice playground for developers. As for user experience, all the wiki features one might need are offered but I think there is room for improvements on the ease of use. For what I could test, not a lot really, I find the WYSIWYG editor inconsistent, and I think it's a big problem, if you edit a page and then saves it various times without changing anything it sometimes comes up with new line breaks or style markups that often break formats or tables. It's annoying and will repel new wiki users. I saw you're working on a new editor based on GWT, I hope that will help. To add my two cents to the reflexion I would prevent the addition of "markups" (everything between {}) from the editor. Just limit it to strict wiki syntax, nothing else. TWiki works like this and it's great, you always have a consistency between wiki edition and WYSIWYG edition, this is not the case in XWiki (according to my experience). Some users prefer wiki syntax, some WYSIWYG, what happens if they edit the same page? For example, you have a font size option in the editor, it really should be removed by default, it inserts {style} markups that messes up the wiki syntax (since there is no wiki syntax for font size). Moreover this option is quite useless since font size doesn't matter with css and font size control in the browser, what matters is the relative font size not the absolute value. You use headers and special css styles to emphasize text, not fixed size. The Deki Wiki way of doing things is different: they don't have wiki syntax, you always have the editor and the pages are stored in xml. It's a nice solution too. As I said before some features are too complicated, forms and template for example. TWiki and Deki Wiki have dead simple mechanisms to make templates. I think it's because they're slightly different. XWiki templates allows you to create custom page structure while TWiki and Deki templates allows you to create pages with pre-filled content to complete. How can I do this in XWiki? Forms seems too complicated, I didn't try hard I must say, but I don't think they're wiki friendly. You have to manage dev jargon like classes and properties. TWiki forms work with a regular table in a wiki page. It's really easy to use and there's no need to learn anything new. To resume I think XWiki is a bit to dev oriented, it should care more about the end user and provide him with dead simple mechanisms for features that just work. Less fancy tech stuff and more pragmatic end user experience. Wiki adoption comes because wiki is simple and fun, not because you can embed Java code directly in pages (although the dev guys here love it). *I repeat, this is a first impression, I might be totally wrong.*
On Nov 20, 2007 10:18 AM, William Lesguillier <wlesguillier@agaex.com> wrote:
As I said before some features are too complicated, forms and template for example. TWiki and Deki Wiki have dead simple mechanisms to make templates. I think it's because they're slightly different. XWiki templates allows you to create custom page structure while TWiki and Deki templates allows you to create pages with pre-filled content to complete. How can I do this in XWiki?
Forms seems too complicated, I didn't try hard I must say, but I don't think they're wiki friendly. You have to manage dev jargon like classes and properties. TWiki forms work with a regular table in a wiki page. It's really easy to use and there's no need to le arn anything new.
A specification is currently written by xwiki developers to refactor the use of xwiki forms (objects&classes). I hope we'll be able to implement it soon. JV.
A specification is currently written by xwiki developers to refactor the use of xwiki forms (objects&classes). I hope we'll be able to implement it soon.
I'm happy to hear that. I hope I didn't seem to harsh on the feedback. I do think xwiki is a nice product! William
I'm happy to hear that. I hope I didn't seem to harsh on the feedback. I do think xwiki is a nice product!
then we hope you'll keep using it :-) Feedback isn't too harsh, it's important for us to be aware of how XWiki users feel about our software. And hopefully you'll be bringing improvements to it on your own soon ;-)
Guillaume William
_______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
Hello *, I quite agree with all that's been said in this topic about usability. I must say also as old 0.9 versions user, that usability, user-friendliness, have been considerably improved since these old versions, thanks to xwiki great team ;-) So I believe this will continue to evolve and be better and better with new releases. About scripting : in my team we had "basic" end-users (not quite participative to start with), and 2 admins (including me). As admins we added much dynamic features in many pages, scripting, groovy, HTML, SQL requests and so on ... Now end-users are much more participative, and problem is that : - we broke possibility of using WYSIWYG editor on these highly dynamic pages - for end-users, editing these kind of pages is an awful experience, because it's not human-readable anymore (accepting developers are not completely human ;) ). In my opinion with XWiki architecture it should be strongly advised to separate "pure content" pages and dynamic or complex pages, using macros for example. It's a good development practice anyway, but you might not think about it when you start working on a wiki site. Anyway I don't regret using XWiki because it's a great wiki IMO, and I really appreciate the way it evolves Jeremie ________________________________ From: users-bounces@xwiki.org [mailto:users-bounces@xwiki.org] On Behalf Of Guillaume Lerouge Sent: mercredi 21 novembre 2007 11:15 To: XWiki Users Subject: Re: [xwiki-users] XWiki scripting for end user (not Groovy) I'm happy to hear that. I hope I didn't seem to harsh on the feedback. I do think xwiki is a nice product!
then we hope you'll keep using it :-)
Feedback isn't too harsh, it's important for us to be aware of how XWiki users feel about our software. And hopefully you'll be bringing improvements to it on your own soon ;-)
Guillaume William _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users -- http://wikibc.blogspot.com/
Yep, about that the simplest thing to do is to put all your development pages in a /view/Dev/ space, and then use #includeTopic("Dev.ScriptPage") to display them in usual content-only wiki pages while preserving the ability to use the WYSIWYG editor for basic users... Once you do this the WYSIWYG editor starts becoming useful again... be sure to use the latest XWiki version too since it usually has had more bugs corrected :-) Guillaume On 21/11/2007, BOUSQUET Jeremie <Jeremie.BOUSQUET@gemalto.com> wrote:
Hello *,
I quite agree with all that's been said in this topic about usability. I must say also as old 0.9 versions user, that usability, user-friendliness, have been considerably improved since these old versions, thanks to xwiki great team ;-) So I believe this will continue to evolve and be better and better with new releases.
About scripting : in my team we had "basic" end-users (not quite participative to start with), and 2 admins (including me). As admins we added much dynamic features in many pages, scripting, groovy, HTML, SQL requests and so on … Now end-users are much more participative, and problem is that :
- we broke possibility of using WYSIWYG editor on these highly dynamic pages
- for end-users, editing these kind of pages is an awful experience, because it's not human-readable anymore (accepting developers are not completely human ;) ).
In my opinion with XWiki architecture it should be strongly advised to separate "pure content" pages and dynamic or complex pages, using macros for example. It's a good development practice anyway, but you might not think about it when you start working on a wiki site.
Anyway I don't regret using XWiki because it's a great wiki IMO, and I really appreciate the way it evolves
Jeremie
------------------------------
*From:* users-bounces@xwiki.org [mailto:users-bounces@xwiki.org] *On Behalf Of *Guillaume Lerouge *Sent:* mercredi 21 novembre 2007 11:15 *To:* XWiki Users *Subject:* Re: [xwiki-users] XWiki scripting for end user (not Groovy)
I'm happy to hear that. I hope I didn't seem to harsh on the feedback. I do think xwiki is a nice product!
then we hope you'll keep using it :-)
Feedback isn't too harsh, it's important for us to be aware of how XWiki users feel about our software. And hopefully you'll be bringing improvements to it on your own soon ;-)
Guillaume
William _______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
-- http://wikibc.blogspot.com/
_______________________________________________ users mailing list users@xwiki.org http://lists.xwiki.org/mailman/listinfo/users
about that the simplest thing to do is to put all your development pages in a /view/Dev/ space, and then use #includeTopic("Dev.ScriptPage") to display them in usual content-only wiki pages while preserving the ability to use the WYSIWYG editor for basic users...
Once you do this the WYSIWYG editor starts becoming useful again... be sure to use the latest XWiki version too since it usually has had more bugs corrected :-)
That's a nice trick used a lot in TWiki, plugins are based on this. Related to this there's a nice feature in TWiki I'd like to see in XWiki: section import. You can declare a section in a page and then only import that section of a page in another one. In this case it's really useful because you don't have to use multiple pages for each five lines of code to insert. In your plugin code page you create a page section for each plugin function. Then you can import those sections in your user pages. All code in one tidy place. In XWiki that could bedone with something like this: The declaration part: Some text in a page {section: MyFirstPageSection} some text in the section {section: MyFirstPageSection} Page continues... The include part: #includeTopic("Dev.ScriptPage|MyFirstPageSection") William
participants (8)
-
BOUSQUET Jeremie -
Guillaume Lerouge -
Jean-Vincent Drean -
Paul Grodt -
rob shelby -
Vincent Massol -
William Lesguillier -
William Lesguillier