Hi,
I'd like to know who's current-ly maintaining and developing the wiki module.
I'm starting to work in a (maybe) improvement of the current wiki module and, as Martin suggested, would be wise to be in touch with the official wiki team to avoid colisions and maximize the development sinergy.
The development I'm planning involves two key issues:
1- wiki improvement. wich can be splitted in
- bug corrections
- (maybe ) one wiki format to rule them all. (a LOT of thinking to do here)
- enable an easy suport for image embeding into the wiki text.
- add extra wiki features ( discussion pages and other toys that you can find in mediawiki, the wikipedia software ). I used last course mediawiki in a course with 90 students and it proved to be great (but it is not designed to suport online courses)
2- Turn the wiki module in a backbone API to develop a content creation authoring, delivering, feedback-obtening and maintening ( and other big words ending in "ing" such as boing ) tool . But this is another story that should be told another day.
Suggestions? rules to follow? Advices ? Phantom menaces?
Cheers
Ludo
Hi Marc,
The guy to contact is Mike Churchward, as indicated in the modules page. He has lots o good ideas too.
- Enrique -
The guy to contact is Mike Churchward, as indicated in the modules page. He has lots o good ideas too.
- Enrique -
Hi Ludo -
A gentleman by the name of Michael Schneider did most of the ewiki work to convert it to Moodle. Unfortunately, he seems to have dropped out of the Moodle community
. I did the common Moodle module pieces and some of the lower custom work. For the last while, I have tried to maintain it, but my schedule has prevented me from keeping up with it and I have a long list of bug reports to get to....
I would welcome the assistance and contribution. What do you have in mind?
mike
A gentleman by the name of Michael Schneider did most of the ewiki work to convert it to Moodle. Unfortunately, he seems to have dropped out of the Moodle community
. I did the common Moodle module pieces and some of the lower custom work. For the last while, I have tried to maintain it, but my schedule has prevented me from keeping up with it and I have a long list of bug reports to get to....I would welcome the assistance and contribution. What do you have in mind?
mike
Hi Mike,
I'd like to engage a refactoring process of the wiki module. I have allerady a development team assembled ( a small group of students working on their degree projects, like we did with internalmail ). If is ok with you we would like to start poking on it.
The process I propose is:
- improvements and changes with we discussed in the this forum,
- we use to work in a XP cile of life, so we don't pay much attention to design, cause we are refactoring all the time
, so we dont have to discuss much of design floritures.
- We will post small releases every ( say about ) 2 or 3 weeks. I'll set up a testing site to allow the forum members to test the status of the project and make suggestions.
How do you see it?
Marc
I'd like to engage a refactoring process of the wiki module. I have allerady a development team assembled ( a small group of students working on their degree projects, like we did with internalmail ). If is ok with you we would like to start poking on it.
The process I propose is:
- improvements and changes with we discussed in the this forum,
- we use to work in a XP cile of life, so we don't pay much attention to design, cause we are refactoring all the time
, so we dont have to discuss much of design floritures. - We will post small releases every ( say about ) 2 or 3 weeks. I'll set up a testing site to allow the forum members to test the status of the project and make suggestions.
How do you see it?
Marc
Marc -
It would be great to have others work on the code.
It would be best if we discussed the changes here, first, to make sure they fit with the Moodle plans. Also, if you use CVS for your changes, that would help keep things in line. If you don't have access to CVS yet, post your changes here (or email them to me), and I'll get them committed for you, until you do have access.
Looking forward to the collaboration.
mike
It would be great to have others work on the code.
It would be best if we discussed the changes here, first, to make sure they fit with the Moodle plans. Also, if you use CVS for your changes, that would help keep things in line. If you don't have access to CVS yet, post your changes here (or email them to me), and I'll get them committed for you, until you do have access.
Looking forward to the collaboration.
mike
Hi Mike,
we have analized the current status of the wiki module and here is our plan: build a new wiki module from scratch, keeping only the integration with moodle part. The moodle code is very structured and organized but the ewiki code is "thick as a brick"... and very hard to maintain. So we want to start from scratch and progresively integrate the wiki functionalities.
I understant that this sounds weird, and that you must keep caution because at the end you'll have to deal with the maintance thing. But please have a litle faith, we'll do fine
We strongly need your advice on how to keep the moodle codig philosophy and to "walk the moodle way".
One word about Markups: the wiki engine we have designed is wiki-markup-language independent. Its our idea to have somne sort of plugin encoder to implement as many markups we like. But wich languages shall prevail ? e-wiki - html editor wiki - safe html? We like most the wikipedia-markup so we want to add it.
In one week or two we'll have a first alpha version, a test server and we'll be able to talk about code.
When you decide we have achieven a good and stable enouth version, we can pot it to the CVS and replace the current code.
Cheers
Marc
Can I offer my Swiki wishes here?
- User must be able to rename a page-title (and automatic also in the references to that page)
- user must be able to cut and paste references from one page to another
- in a group wiki users can lock a page
- user can get email or rss when a page is updated, by placing their moodle-email in a box of that page in edit mode
- when locked, the user must be able to put a commentbox on that page
- more sophisticated: it must be possible for a techer to create two views of a page: one in edit mode with prompts and fill-in boxes, the other showing only the content of the boxes, depending of the order of the boxes in the view mode..
Allpossible with: http://minnow.cc.gatech.edu/swiki
OK Ger,
your wishes have been added to ur list . Thank you.
Marc
your wishes have been added to ur list . Thank you.
Marc
I know that starting from scratch sounds always interesting (to us engineers anyway 
), but have you taken another look at integrating some other wiki engine to Moodle than eWiki? Is MediaWiki too much of a beast?
That way we would have the wiki engine development team (MediaWiki team), wiki integration team (you guys) and then the Moodle development team.
That way we would have the wiki engine development team (MediaWiki team), wiki integration team (you guys) and then the Moodle development team.
A few general thoughts if you want to get this into the main distribution:
- The Wiki should support exactly the same text formats in Moodle core as you find everywhere else (see weblib.php for standard functions, eg format_text). ie Moodle format, HTML format, Markdown, etc. Any new formats need to go in the core so they are available everywhere, and this needs to be discussed very well. We only JUST removed the old Wiki-like format to reduce confusion with the current Wiki and I don't want more of this confusion from a rushed implementation.
- Linking should support both CamelCase and [Bracket] styles, and also automatic linking on the fly (a la Glossary).
- Upgrading from the old system to any new one should be seamless and problem-free (this includes restoring old backups from 1.4, for example).
- The idea with eWiki was to build on the work of the eWiki team in future. Unfortunately, so many hacks needed to be made to their monolithic script that this became almost impossible. I would like to see a lot of thought put into a very cleanly-designed architecture for the Wiki in future, something that is easy to extend and maintain (and also to use).
- I really like MediaWiki, as this Wiki is
becoming a defacto standard (for good reason) and it would be good to be compatible in some way with it. Perhaps we can use part of it as a library for us. However, the Moodle Wiki is a COMPONENT within the larger Moodle system and has a very different focus to MediaWiki (which is designed for large standalone web sites) ... much thought should be given to making our Wiki work very closely with other modules, rather than another module that tries to do everything itself. It should do exactly what it needs to do and no more.
- Support for media in a very clean way is a must. This is probably my biggest criticism of the current eWiki version ... attaching images and video etc is really awkward and doesn't look good.
Wow. That's a big decision, and I won't say its the wrong one...
Erfurtwiki (ewiki) was used originally because it was built to be used as an add-on to other systems, and not as a stand-alone. Its plug-in nature made it easy to pare down or soup up. It has been a struggle to keep it working within Moodle even so.
Starting from scratch is not a bad decision, but it will take a lot of time, and require a lot of debugging. If you've got the resources, more power to you! I will certainly help in every way that I can.
Martin's covered some key issues in a response here. Another thing to keep in mind, don't redesign functionality from other Moodle modules - e.g. - we want to be able to add comments to wiki pages, so we should use a common comment feature, probably forums. Same with ratings and grades.
Error on the side of leanness. What I mean by that is lets start with necessary functions and only add on extras when they become necessary. We really want to avoid feature bloat, especially where duplication occurs.
Martin - is there anyway we could have a wiki, or section of one, to track design decisions?
mike
Erfurtwiki (ewiki) was used originally because it was built to be used as an add-on to other systems, and not as a stand-alone. Its plug-in nature made it easy to pare down or soup up. It has been a struggle to keep it working within Moodle even so.
Starting from scratch is not a bad decision, but it will take a lot of time, and require a lot of debugging. If you've got the resources, more power to you! I will certainly help in every way that I can.
Martin's covered some key issues in a response here. Another thing to keep in mind, don't redesign functionality from other Moodle modules - e.g. - we want to be able to add comments to wiki pages, so we should use a common comment feature, probably forums. Same with ratings and grades.
Error on the side of leanness. What I mean by that is lets start with necessary functions and only add on extras when they become necessary. We really want to avoid feature bloat, especially where duplication occurs.
Martin - is there anyway we could have a wiki, or section of one, to track design decisions?
mike
Hi everyone,
Debug power and so on: I have a 5 students in their degree project commited to this labour, I think that we can handle it. Even so, we allways work in a small release cicle and they are use to de less buggy.
Mediawiki is for me the best wiki software I kwnow but it has a very monolytic structure and its code y poorly documented. I adree with martin with the idea that we can use some mediwiki code, and we would be really glad to help in mediawiki development. But to squeeze mediawiki into moodle without adapting it to its component architecture is suicidal. Eve if we did it this way we would not be able to keep compatibility with the actual formats... unless we keep two implementations hidden within the code. And It would be impossible to maintain it.
Marc
Debug power and so on: I have a 5 students in their degree project commited to this labour, I think that we can handle it. Even so, we allways work in a small release cicle and they are use to de less buggy.
Mediawiki is for me the best wiki software I kwnow but it has a very monolytic structure and its code y poorly documented. I adree with martin with the idea that we can use some mediwiki code, and we would be really glad to help in mediawiki development. But to squeeze mediawiki into moodle without adapting it to its component architecture is suicidal. Eve if we did it this way we would not be able to keep compatibility with the actual formats... unless we keep two implementations hidden within the code. And It would be impossible to maintain it.
Marc
Hi Ludo, in our development we have found that sometimes it is better to see other tools as prototypes: things to use as UI and feature models.
I'd definitly agree that if you find the existing code has scalability/maintainability or other problems, you may be better off creating new code from 'scratch'.
After all, getting the feature set and UI right is often almost as hard as getting the code written (and if you build on the Moodle api* whenever possible, the code can often be written suprisingly fast.)
*IMO, this is highly important, students on projects sometimes want to build code to the latest buzzwords-object orientated, etc. and seem sometimes to want to do everything from scratch rather than work with the available API elements. Most of our coding is also done by student workers, but I have them take the time to learn and work within Moodle's structure whenever possible, and this up front investment seems to pay off quite well in the long run.
It's also a great (constructivist!) educational experience for the students, as in most 'real world' coding they will probably have to work with teams and with an established codebase (though not always as great a team or codebase as found in Moodle).
I'd definitly agree that if you find the existing code has scalability/maintainability or other problems, you may be better off creating new code from 'scratch'.
After all, getting the feature set and UI right is often almost as hard as getting the code written (and if you build on the Moodle api* whenever possible, the code can often be written suprisingly fast
*IMO, this is highly important, students on projects sometimes want to build code to the latest buzzwords-object orientated, etc. and seem sometimes to want to do everything from scratch rather than work with the available API elements. Most of our coding is also done by student workers, but I have them take the time to learn and work within Moodle's structure whenever possible, and this up front investment seems to pay off quite well in the long run.
It's also a great (constructivist!) educational experience for the students, as in most 'real world' coding they will probably have to work with teams and with an established codebase (though not always as great a team or codebase as found in Moodle
Hi Michael,
I completelly agree with you. I use a similar strategy with my student projects, the first thing that a developer must do is learn to read code. And yes, as we experiencied with internalmail ( and still do) developing with moodle API boosts the productivity and drecreasses the bugs.
I completelly agree with you. I use a similar strategy with my student projects, the first thing that a developer must do is learn to read code. And yes, as we experiencied with internalmail ( and still do) developing with moodle API boosts the productivity and drecreasses the bugs.
> Martin - is there anyway we could have a wiki, or section of one, to track design decisions?
Sure! Use the developer wiki in this course!
Sure! Use the developer wiki in this course!
Of course 
I have started a Wiki Development page in the current wiki. We can post our notes there.
(seems kind of cannibalistic. using the wiki to create a new wiki.)
I have started a Wiki Development page in the current wiki. We can post our notes there.
(seems kind of cannibalistic. using the wiki to create a new wiki.)
Ludo,
This is a *great* project. Personally, the wiki moduletogether with the upcoming blog module will be the backbone of whatI'll be pushing for use at my college, Earlham. One of my profs hasbeen using the current wiki module in his Biochemistry course forstudent created web sites. Despite it's limited feature set and clunkygraphics handling he's been very pleased with the results. I have usedthe Twiki stand alone system with a group of senior students and thismight give you an idea of one of the kinds of uses that I'd like to putthe wiki module to -http://www.earlham.edu/twiki/bin/view/Biology/BiologySeniorSeminar04
TheTwiki markup syntax makes creating the navigation tables quitestraightforward . Here's the markup for the 'home page ' navigation:
This is a *great* project. Personally, the wiki moduletogether with the upcoming blog module will be the backbone of whatI'll be pushing for use at my college, Earlham. One of my profs hasbeen using the current wiki module in his Biochemistry course forstudent created web sites. Despite it's limited feature set and clunkygraphics handling he's been very pleased with the results. I have usedthe Twiki stand alone system with a group of senior students and thismight give you an idea of one of the kinds of uses that I'd like to putthe wiki module to -http://www.earlham.edu/twiki/bin/view/Biology/BiologySeniorSeminar04
TheTwiki markup syntax makes creating the navigation tables quitestraightforward . Here's the markup for the 'home page ' navigation:
<H1> CONSERVATION and ECOTOURISM ISSUES in DEVELOPING COUNTRIES </H1>
---
| *Main Menu:* | *Home* | ConservationIssues][Conservation
| EcoTourism][Ecotourism | CaseStudies |
LiteratureCited][References | ClosingThoughts |
%TOC{depth="2"}%
Here's what it looks like:
Twiki has an easy way of generating Table of Contents as you can see.
I do think it's important to remember that wikis are in principle designed to work with a text markup system (rather than inline html)since the rendering is built in to the wiki itself. Since Moodle uses Markdown I wonder whether it makes sense to make Markdown the default text entry system (mybe with some sort of toolbar or help system).
Development:
What php edvelopment system are you planning to use? Have you tried Eclipse which is an Open Source system? Also, Atlassian Jira looks very interesting for bug tracking & project management andI'm sure that you could obtain a free licence for OPen Sourcedevelopment. I'm planning a development effort next spring with a groupof students (perhaps we'll work on the attendance module if no-one has taken it on by then) so I'm keen to find out what development softwareyou're using and how things are progressing. How long did it takestudents to pick up php and MySQL? I do have some good text books onthose subjects if you're interested.
Cheers
Mark
Just a few suggestions:
Currently some wiki features do not work reliably:
- search does not find page titles (so make sure that the page title is repeated somewhere within the page itself).
- export does not export all wiki content
- delete pages and strip pages often do not work. (the most common error message is: Course Module is incorrect
- moodle editor does not handle hyperlinks correctly. i.e. All links must be manually placed within square brackets rather than embedded as HTML links.