Moodle in English: Voting on NWiki vs OUWiki

Voting on NWiki vs OUWiki

by Martin Dougiamas - Monday, 4 February 2008, 4:29 PM

I really need to make a decision on which wiki to include in Moodle 2.0.

The existing Wiki (ewiki) code is being dumped because it's complex and buggy, and no-one wants to work on it in its current state.

The NWiki module has, as you probably know, had a huge amount of work poured into it over a long time. It has a lot of fancy features, and is designed to upgrade from the existing wiki (ewiki) in Moodle 1.9. However, the code still reflects the fact that it was built by a team of students and several core Moodle programmers have expressed their concerns to me about working with it as it is now.

OUWiki is much smaller and newer, doesn't have anywhere near the same number of features and does not currently upgrade existing wikis, but the foundation code is very clean and organised. It would need to have features added even to bring it up to par with ewiki.

Either way we (Moodle HQ) are going to end up doing a lot of work to put it into core (different kinds of work).

If you have any interest in Moodle wikis, it would really help me if everyone here could go and experiment with the two wikis and offer their opinion (via a choice) on which option they like.

Go here to choose: http://wiki.moodle.org

If there seems to be a clear consensus one way or another, then I'll run with that decision and put our team onto getting it into shape for Moodle 2.0. If the result seems fairly close then I'll just have to make the call.

Discussions / comments should be here in this forum. Thanks!

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Stefan Büchler - Monday, 4 February 2008, 7:25 PM

In the voting one will be asked, which wiki is more user friendly. I think this is the wrong question. It is very likely that a wiki with more features is less user friendly. This question this a very bad help for the decision!

I think one should include NWiki in Moodle because it uses a syntax similar to mediawiki. Mediawiki is a very often used standard, so it would be very nice to have the same. Maybe user friendliness can also be improved (if necessary).

OUWiki has to few features, it is too simple!

The installation of NWiki is now to complicated and there are too much possibilities for errors. It is important too included it in core.

Whether the code of NWiki is good or not - I can't decide. Maybe one has to encourage the supporting team.

Average of ratings: -

Ang: Voting on NWiki vs OUWiki

by Kalle Nielsen - Tuesday, 5 February 2008, 12:47 AM

For me it's quite simple - we do need a full-blown wiki in Moodle 2.0, as a matter of fact we needed it yesterday, and only NWiki has the features, and the look-and-feel we need.
It have to come in to core, and be able to migrate old wiki-content allmost perfectly.
I'm not using NWiki or OUWiki today, because I believe that dependency on core-competing modules is the wrong way to go - but we really do need a full-blown wiki - as soon as possible.
Questions about code - I leave it totally up to the experts

Average of ratings: -

Re: Ang: Voting on NWiki vs OUWiki

by Jestin VanScoyoc - Tuesday, 5 February 2008, 4:39 AM

I really like the feature set of NWIKI and it does seem to integrate nicely after installed. I use it A LOT for class Encyclopedias, Agendas, etc. I like working with wiki syntax -- even though im still learning. When I'm offline I can use a simple text editor and not have to use html tags.

I am not a dev. so unsure about that aspect. Even though students are working on it, Ludo and team do a good job of patching/fixing when needed.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by koen roggemans - Tuesday, 5 February 2008, 6:53 AM

For the test, I tried to use the wiki's as a student, not knowing the danger of using ' < & ... and not knowing how terrible Word is.

So I created a page "koen's test" and added a page for testing the paste of a word document. I found that students and teachers often do that - create a file in Word, past it in a wiki or recycling an old Word-document, past in a wiki page and then start modifying it. So it's nice if that works, if not perfect then at least without causing problems.

Results:

NWiki

using a ' in a page name, makes the page uneditable afterwards. using an é or an & is ok.
using a < in a page name, makes the rest of the title disappear
Pasting a Word-document removes all the markup, tables etc. The ewiki didn't do that. People won't like it, but at least this way it will gives clean and error free pages.
From a pedagogical point of view, it is nice that you need to learn Mediawiki markup for NWiki, but it makes the learning curve a little steeper. Don't know if it is ok for K12. Can anyone comment on that?
I found there is something wrong with the breadcrumb menu: Clicking on 'wikis' in the breadcrumb menu makes the menu disappear.
export to pdf: a very nice and desirable feature, but it throws error messages
Using the browser back button gives postdata warning message.
Page blocking works weird: even after saving I can't re-edit a page for a while

Conclusion: very feature rich, may be even too feature rich. I like features like the time line view and the PDF-export. In core it would definitely be necessary that an admin can switch unnecessary features and blocks off.

OUwiki

using a ' é < & in a page title works fine
Pasting a Word-document saves the markup, but on top of the page appears a bunch of characters after saving it. Using the "Clean Word" button doesn't help.
I like the history view a lot.
I couldn't make it throw error messages.

Conclusion: The OUwiki does what a wiki needs to do. The html-editor is a + in a situation where you just want the students to work with it, rather then also needing to teach them Mediawiki. Working with it, the code feels really stable: no errormessages and even back and forward browser buttons work.

According to documentation, there is no upgrade script yet from ewiki to ouwiki. That is really a blokker for bringing OUwiki to Moodle core.

I could not find a way to grade in both wiki's, which I miss in an application for teaching purposes.

I vote for the OUwiki, because I prefer stability above features.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Michael Penney - Tuesday, 5 February 2008, 9:52 AM

You can grade wikis in nWiki, those features have not been enabled on the sandbox site. Martin, it would be good to give teachers full access to the demo, so they can see how the evaluation/grading functions of nWiki work.

It also supports student peer review of each others work, which is a potentially very interesting feature.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Michael Penney - Tuesday, 5 February 2008, 9:36 AM

I'm confused by a couple of things here:

1) When I go to the wiki site - there is a choice in a section titled:

Vote for the wiki you would like to be included in Moodle 2.0:

But the choices offered is "Which wiki is more user-friendly?"?

In other words, I'm not asked which wiki I think is the best choice, instead I'm asked which wiki is more 'user-friendly'.

What about features and support for different teaching strategies/needs/pedagogies?

After all, if we had a "user friendly" quiz, it would only offer true and false questions, and they all all would be true big grin

.

2) The nwiki team were told that they would not be considered for Moodle core unless they upgraded cleanly from eWiki. This was a huge task and much work was put into it. Now we are told to compare their work to OUwiki, which doesn't upgrade from eWiki. This feels a bit unfair, to me.

By the way, if I upset anyone here is something about wikis from user friendly...(http://ars.userfriendly.org/cartoons/?id=20001014)

Average of ratings: Useful (1)

Re: Voting on NWiki vs OUWiki

by Lesli Smith - Tuesday, 5 February 2008, 9:53 AM

Oh, yes--and the upgrade issue. I have to admit that would be a deal-breaker for me, too. I need my course wikis to be able to upgrade without me needing to consult a coding specialist.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Tuesday, 5 February 2008, 6:19 PM

Thanks for making this poit for me Michael. I owe you a Beer.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Lesli Smith - Tuesday, 5 February 2008, 9:47 AM

Hmmm. I have to say I found it difficult to answer the usability question in simple "yes/no" terms. I like the blocks and layout of the Nwiki as it would be more intuitive for the age-group I work with. At the same time, there are so many features that it would need a pretty good "how to" roadmap for the average user to even begin to use it.

Also, it was a little confusing to figure out how to get it to flip to the HTML editor in Nwiki, but once I found that I could do that, I was much happier. The ability to use the full HTML editor would be a deal-breaker for my age-group.

So in the end, I would vote for the Nwiki, but I think we should also consider what features are absolutely necessary as it is a little much for the average user to navigate at the moment. In short--a simplified version of Nwiki gets my vote.

Of course, I can't AT ALL speak to code issues, so I'll leave that up to the experts, too.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Perry M - Tuesday, 5 February 2008, 1:43 PM

I’m new to Moodle – I’ve played with it 2 weeks now and will use it for instruction shortly.

Wiki is a great way for students to collaborate and quickly amass a great deal of information. This is a VERY critical task for my students.

There is but one winner here – nWiki. It is a “KISS” version of MediaWiki that has hundreds of thousands of folks who contribute to it and know some of the syntax. nWiki is just the right amount of syntax to allow a primitive Wiki to start and evolve. Later nWiki can just add more things from MediaWiki.

I vote for nWiki.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Perry M - Tuesday, 5 February 2008, 9:21 PM

I know one of the things that seems to be a deciding factor in this vote is an editor – I would not worry about that one second.

Watch any kid use their cell phone to text message something to another kid and you will quickly realize that formatting and nice text editors mean nothing to them. They can quickly use their thumbs and send messages that look just like MediWiki’s raw view of a posting.

Click this link http://en.wikipedia.org/w/index.php?title=Automobile&action=edit and you will see the raw source view of “Car” in Wikipedia. Wikipedia’s syntax (Which is MediaWiki) is just as complex as the kids text messaging - compare the two.

nWiki’s syntax takes someone 30 seconds to master – less time than they have spent mastering text messaging on a cell phone. The kids can easily handle this and nWiki is 100% compliant with MediaWiki’s syntax. Get the kids ready for contributing with Wikipedia with nWiki.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Paolo Oprandi - Wednesday, 6 February 2008, 12:03 AM

A couple of things I noticed.

When logged in as a guest I could see the nwiki, but not the ouwiki.

When logged in but not enrolled on the course I could contribute to the ouwiki (or at least the edit tab was available to me), but not the nwiki.

I found a bug (a database error) in the nwiki when attempting to edit "Martin's test" page.

I am a still worried if the nwiki can be production quality, but I do hope so.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Mauno Korpelainen - Tuesday, 5 February 2008, 6:58 PM

I like them both but have already voted for Nwiki http://tracker.moodle.org/browse/MDL-10895

A perfect solution could be an easy-to-use wiki that can be used in a simple mode (OUWiki) or advanced mode (NWiki). We may find similar arguments for editors (htmlarea/tinymce/fckeditor/yuirte), feedback/questionnaire,...almost any activity of moodle.

Michael,

I could not agree more! big grin

The good thing is that Nwiki and Ouwiki can be used at the same time. wink

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Sjaak Kamerling - Tuesday, 5 February 2008, 7:51 PM

A small contribution to this interesting discussion. I use wiki's for a couple of years with students aged 12-18. At first, environments like bloki and seedwiki. Later on, until now, ewiki within moodle. For students at this age, especially the younger ones, a clear editor-environment, is very important. They need to learn within an wiki-environment and it is no good to interrupt this learning-process, with learning commands to fill their wiki. They need to concentrate on learning other things. The main goal of wiki's is to give a way to communicate, to construct knowledge in different manners. This process of communication should not be disturbed by using special commands to enter your communication. Students of all ages must be able to communicate with their wiki's. So, Moodle without wiki-with-editor is no good. No good for my students and no good for me as a teacher. Using wiki's very often, Moodle without wiki-with-editor brings me back to seedwiki-like environments. So, when I vote, I will vote for OU-wiki.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Michael Penney - Wednesday, 6 February 2008, 5:26 AM

You can set Nwiki to use the Moodle html editor or the ewiki editor (or both).

Intel Education had a similar requirement - not to force the learning/use of wiki commands - in their case they wanted to remove the choice to use a wiki editor from the teacher's role. So we built a site level configuration setting that enables the site admin to set all nWiki's to use the Moodle html editor. We'll be contributing that and other nWiki code back.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Lesli Smith - Wednesday, 6 February 2008, 6:31 AM

Good to know. As I said in my earlier post, I sort of happened upon the ability to use the HTML editor in the Nwiki playground course by chance when I tested the "add a new page" block. For whatever reason, when I used that block to add the new page, it allowed me to choose the type of editor I wanted to use. This left me with the question about whether teachers would be able to force use of the HTML editor. I agree with S.Kammerling that students in th k-12 age range need fewer technical impediments to getting their info posted. Yes, I was able to teach them that square brackets would give them a new page, but it was a laborious process. Perry M's point that kids learn how to use text languages quickly enough on their cell phones is well-taken, but that is because they are motivated to do so for their own social networking. It is a MUCH different case when it is a skill that a teacher is demanding, and since I already have a hard time getting them to care where they put their commas, for instance, I really don't want to battle with them over whether knowing HTML will be necessary in their future (even if it will).

As this conversation has progressed, those who are more familiar with Nwiki are seeming to indicate that it is flexible enough to "turn off" features and limit choices for certain audiences while keeping those options available for later or for other audiences. Is this correct? (What did Martin Langhoff call that in a different thread? The "low floor/unlimited ceiling" principle?) Anyway, if the Nwiki is capable of adhering to this principle without too much user confusion (as in the admin can decide how many options the teachers and target population will be able to handle), then I feel much better about its implementation as the standard wiki.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Jiří Dlouhý - Tuesday, 5 February 2008, 8:05 PM

Hi,

the first trouble is, that the testing link http://wiki.moodle.org does not work, so I cannot compare.

We like to use wiki format in our courses very much and we see it as a very weak part of moodle till now.

I had tried to install NWiki in past but I had several problems and some content disappeared so we decided to use standart built-in wiki for "really internal texts" + external wiki running on MediaWiki sofware for those parts of materials, which can be public.

What I would like to see in standard Moodle 2.0 wiki:

1) It should be as similar to MediaWiki as possible - we do not need HTML etc. editors, because this causes problems - the advantage of standard MediaWiki editor is that it is clear and simple, you cannot copy there all the terrible Word formating etc. It makes troubles when the markup language etc is different different wikies.

2) It has to work with UTF-8 coding - this is the biggest trouble with build-in wiki now - there could be only Latin1 characters in the links - names of pages

3) It should be very reliable - I see problems with back-up and copying now

Jiri

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Séverin Terrier - Wednesday, 6 February 2008, 12:22 AM

Hello,

It seems you had a temporary problem, because i've got no problem to join http://wiki.moodle.org/

Séverin

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Paolo Oprandi - Wednesday, 6 February 2008, 12:54 AM

Hello Séverin,
I may not have explained myself clearly, I didn't have any problem joining the site, I just had different access rights to the wikis according to my enrolment status. NWiki seemed to work as I expected i.e. I could see nwiki entries but not participate, both when in as a guest or when logged in to the site but not enrolled on the course.

Paolo

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Jiří Dlouhý - Wednesday, 6 February 2008, 5:59 PM

Hi Paolo and others,

I managed to get editing rights in the "Playground" but by very strang way - when I tried to vote - step 4 in the first page - the system asked me, if I really want to enrole the course Playground - I said yes and from that time I have editing rights in the Playground.

Maybe, there could be some easier way to do this.

Jirka

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by David Mudrák - Friday, 8 February 2008, 6:02 AM

Hi Jirka,
the reason of your troubles is in course enrolment. When you came into the course for the first time, you had privileges of Guest user - because the course allows guests to come and look around. If you like the course and want to join, you have to enrol. You had to overlook the block with "Enrol me into this course".
So, this procedure is not a bug, it is a Moodle feature. If the course is open to guests, the feature allows regular users to come into a course they are not enrolled to yet and act like they were guests.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Jiří Dlouhý - Wednesday, 6 February 2008, 5:52 PM

Hi Séverin,

this was really temporary problem, now it works.

Jirka

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Wednesday, 6 February 2008, 3:49 AM

Data loss? One thing I cans say about NWiki and almost any wiki is that no data is lost because each edit does not destroy information but adds new rows to de database. As you may see in the history of the wikis.
Sometimes we have been reported data losses that are related to:
* groups: the user accesses the wiki from another group where the page does not exist. hence seems to be gone, but is in its proper group (the Page-list block is very usefull to locate where are the pages of the group's wiki)
* moodle upgrade: Nwiki is in reality called Wiki, so when you upgrade moodle you need to remove the mod/wiki directory otherwise will SEEM that the wikis are gone. You can fix it by re-copying the nwiki into your moodle installation.
Cheers
L.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Matt Campbell - Wednesday, 6 February 2008, 2:11 AM

Thanks for asking us for our opinions on this, Martin.

I thought about answering the choices over on the wiki site, but I think I'd rather put my opinions here and talk it out. This isn't very black and white, no matter how you look at it.

From a code view:

I don't consider myself a developer or programmer, merely an administrator that's learned enough about Moodle code in order to hack it enough to do what I want. Please consider this when I tell you that the OU Wiki code looks much cleaner and closer to what I'm used to seeing from Moodle. I think I could hack it and make it do something specific for my installs if I needed to.

Looking at NWiki, I feel totally lost. I could probably do a few things with it, but for the most part I think I'd spend forever digging through the code to figure out how to do what I want. Of course, Ludo and his crew have been very active in supporting it and would be likely to answer my questions.

From a usability view:

The OU Wiki is VERY similar to eWiki and would be easy to drop into Moodle with the least amount of confusion to teachers and students. It doesn't have a few features that eWiki currently has, like the ability to include files (not that I could see, anyway!) or some of the administration capabilities such as removing orphaned pages/links, etc. Moving to OU Wiki as it stands would be a step down, and not the direction I think Moodle should go.

NWiki is very feature-rich, perhaps too much so. They've got enough going on that it's almost like an entire Wiki platform inside of Moodle. There will be quite a bit of confusion as users try to figure it all out. Moving to NWIki as it stands would be a step up, and I think the right direction for Moodle.

In short, OU Wiki offers the least work for developers but the least capabilities for users. It is easier to work with and more familiar, but I think we would lose too much in the process. NWiki will be a challenge. The code needs to be streamlined and a number of options should probably be enabled/disabled at the site level, and defaults defined for the teachers ahead of time, much like what was done with the gradebook for 1.9.

So, my vote goes to NWiki.

Thanks,
Matt

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Bill Schreiter - Wednesday, 6 February 2008, 4:41 AM

Hi, I have been using NWiki for some time now and have posted questions in the Wiki forum looking for support. It was clear and to the point every time.

The only improvement that I would like to see is the ability for students to upload resources/file but not to delete or change files other than their own.

I love the product and have created hundreds of pages in it since first installing it.

It gets my vote.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Mark Pearson - Wednesday, 6 February 2008, 7:14 AM

The existing Wiki (ewiki) code is being dumped because it's complex and buggy, and no-one wants to work on it in its current state.

This has been the case since Moodle version 1.5, right?

The NWiki module has, as you probably know, had a huge amount of work poured into it over a long time. It has a lot of fancy features, and is designed to upgrade from the existing wiki (ewiki) in Moodle 1.9. However, the code still reflects the fact that it was built by a team of students and several core Moodle programmers have expressed their concerns to me about working with it as it is now.

OUWiki is much smaller and newer, doesn't have anywhere near the same number of features and does not currently upgrade existing wikis, but the foundation code is very clean and organised. It would need to have features added even to bring it up to par with ewiki.

Either way we (Moodle HQ) are going to end up doing a lot of work to put it into core (different kinds of work).

I place a huge amount of attention on what developers are keen to work on. It's what persuaded me that Elgg was the way to go for a blogging system. Without keen developers code has no longevity. So, looking at it from a coder's point of view, would I rather work on adding new features to a cleanly coded system to bring it up to par, and then continue to work on this foundation, or would I be happy to wrestle with student code to port it into Moodle 2.0? This will have implications for long term support. Nwiki may be function rich but if no-one wants to untangle code to fix bugs and ensure tight integration with the core then it will wither on the vine like the present ewiki. It seems to me that the core moodle developers cannot afford to get into the 'Workshop' situation where they are trying to support code which is clearly not up to the standard required.

Nwiki is clearly a more advanced system on the surface. But personally, I'd trade code solidity (however defined) and application reliability for a host of functionality.

In terms of migrating from ewiki, I know that Ludo and company have had a nightmarish time with this process. Is this a reasonable task? Should Moodle necessarily support moving wiki data in situ from ewiki to a new system?

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Séverin Terrier - Wednesday, 6 February 2008, 6:16 PM

Hello,

i just try to give my opinion, not involved or using any of the 2 wikis...

I really think that the new Wiki must support moving data from old wiki, because it's a core activity, and Moodle is made to never lose any data

Like you (even if i'm not really a programmer), i think that code has to be clean and extendible, for a good future.

I think we have to keep in mind that :
NWiki is "old", and lot of people already use it, and are happy with it (despite coding quality), that's not the case for OUWiki, more recent.

Something hasn't been clearly said : Martin gave informations about the wikis as they are now. For sure, they will both change in the future, to complete what they can't do today. One good question would also be to know how many people are involved in each development, and what are the roadmaps, because we're talking about the future of wiki in Moodle

Séverin

Average of ratings: Useful (1)

ouwiki information and future plans

by sam marshall - Thursday, 7 February 2008, 10:15 PM

1) If ouwiki is included in Moodle 2.0, it will automatically update from the current Moodle wiki. It doesn't do so at the moment, because we don't need this at the OU - I'm not spending time implementing it when it might not get used! I don't think we anticipate any particular problems in implementing that feature, just takes a little time.

2) Administrative features could definitely be improved (e.g. at the moment there is not even any automatic way to revert to a previous version, you have to go look at the previous version and copy/paste). We have some internal requests for this so I expect it will happen. However nothing is definitely confirmed yet. (Also I'm not too sure I see a need for some of the weirder ewiki features so I don't know if we'd want to implement absolutely everything.)

3) The next definite feature we are adding to ouwiki is improved reports - this replaces the 'user contributions' page with a better set of reports about how much the wiki was used in a group, how much each individual contributed, etc., including graphs. This should be complete and tested in time for our next release in April. It would presumably be sensible to add grading support via this feature however we haven't yet done so because we don't (yet) use moodle grading except on quiz.

Basically the key philosophy of ouwiki is to provide a very simple wiki that helps students to collaborate and doesn't require major effort to learn (students are learning about art history or music or project management or whatever - not wikis), and one that fits in nicely with the way other Moodle tools work.

We assume [backed up by our user testing] that few of our students have heard of a wiki except possibly Wikipedia, and even fewer (a microscopic fraction) have ever edited one. That's why we don't use wiki markup except for the double-square-brackets-around-links thing, which is explained right there on the editing page. (Wiki markup support could be added, but I'm sort of against it, because it's difficult to collaborate if some people are using wiki markup and some are using HTML - better to require everyone uses the same system.) That's also why there aren't lots of complicated features, and it's why we haven't attempted to create a system that lets the wiki take over the whole site.

ouwiki is designed to be a simplified wiki that carries out the basic communication function, for use in teaching and learning. We certainly wouldn't suggest that it is capable of replacing, say, MediaWiki, any more than the Moodle blog is going to replace Movable Type. (We use MediaWiki here as well; internally, not for students.)

One more thing, remember that even if your favoured wiki isn't selected for use in moodle 2, I expect you will still be able to choose it for your own site. Currently we expect to continue using ouwiki here, even if it's not included in Moodle 2, so it will still be maintained and available for anyone who wants to install it.

--sam

PS Some people, including me

don't read the wiki forum. Shouldn't information about the choice also be posted to the general developer forum and other forums?

PPS When evaluating the results of the choice vote, I think you might want to exclude everyone with IP addresses/emails from the Open University and from the university that created nwiki. Just a hunch.

Average of ratings: Useful (2)

Re: ouwiki information and future plans

by Neil Birt - Friday, 8 February 2008, 1:34 AM

The problem here is that if ouwiki is selected, I have to ask my users to settle for less functionality than they currently have. I understand the desire to want to have things simple but we already have tools available that do more and are being widely used. Less functionality feels like a step back.

I also understand that ouwiki will have more features than it does now, but what features and when? We are being asked to demo this wiki without being able to see what these features are or whether they will actually work. How can I make a reasonable selection?

Also, while I am sure the OU people are a great bunch and work very hard, I have been less than impressed with some of their other offerings. The OU My Stuff portfolio, for example, is superficially very wonderful to look at and each single piece seems to work well. However, I find it difficult to navigate and not very intuitive to use. I would not be in favor of a wiki that demonstrated the same characteristics.

That is why I want to see the features in action. We need to know not only that the features are there and that they work well but also that they work well together. We can't do that with the current ouwiki version.

Until such time as the promised features and functionality become available, how can we be expected to support it?

Average of ratings: -

Re: ouwiki information and future plans

by sam marshall - Friday, 8 February 2008, 2:40 AM

Wait, I am confused. What are the features the current wiki has that ouwiki does not?

1) Wiki markup

2) Some minor administrative features

3) ...?

I am not promising any features except that import of old wiki data will definitely be implemented if this is accepted into core, and wiki markup will be implemented if this is accepted into core if Martin makes us

[Looking at this thread, I suspect he will.]

In particular I really wouldn't anticipate adding anything that significantly complicates the interface.

The only other feature I've promised is improved user reports, which are coming in April. (Oh, and an existing feature that you can't see there is fulltext search - this currently doesn't work on MySQL, I discovered this today and am trying to fix it.)

--sam

PS I'm the lead developer for ouwiki, which was designed to work as expected for a Moodle module. I haven't been involved with the MyStuff portfolio project, which wasn't. There isn't any reason to draw lessons from one project about the other: they're done by different people and even if they were the same... well... I also wrote leafChat but that doesn't mean ouwiki is going to suddenly turn into a client-side Java application, or sprout leaf graphics.

Average of ratings: -

Re: ouwiki information and future plans

by Perry M - Saturday, 9 February 2008, 5:50 AM

I'm trying to review ouWiki again so I downloaded the latest Moodle 1.9+ and ouWiki this morning. Moved ouWiki to Mod folder and clicked Notifications. Nothing happens - no database entries were made. I'm using mySQL 5.0.45

Any idea what I should do next?

Thanks

Average of ratings: -

Re: ouwiki information and future plans

by sam marshall - Monday, 11 February 2008, 10:04 PM

That's odd. Could you check it is in the right place please? The folder should look like:

(your moodle root) / mod / ouwiki

and it should contain some files including version.php

For example it's possible that you accidentally ended up with

(your moodle root) / mod / ouwiki / mod / ouwiki

or something, which won't work.

I just installed ouwiki onto a new moodle 1.9 branch install running mysql 5 on Friday and it worked, I thought I did basically the same thing you said...

--sam

Average of ratings: -

Re: ouwiki information and future plans

by Perry M - Monday, 11 February 2008, 11:01 PM

I've been trying to get ouWiki up and running on my Moodle 1.9 Beta 4 and finally read the requirements - php 5. I use Powweb for hosting and they only support php 4.3.3 and don't plan on php 5 for quite a while.

I like Powweb since I can have 100+ web sites in just one account - they all are off the root directory and can have 75 mysql databases total for the one account. You only pay for ONE and the rest are FREE! I've got to stick with Powweb and their php 4.+

So I'm out of luck and I suggest that owWiki be compatible with Moodle's requirement for just php 4+

Average of ratings: -

Re: ouwiki information and future plans

by sam marshall - Tuesday, 12 February 2008, 12:42 AM

Moodle 2 requires PHP 5, so it's probably not relevant in this case. ouwiki definitely isn't going to be included (except as an option obviously, like now) in Moodle 1.9.

(I am personally not a believer of the 'use fantastically ancient software versions just so that it will still be OK even when people are using broken, cheap hosting providers' approach... but I'm pretty sure Martin is! Probably the judgement is that PHP 5 will in fact be fantastically ancient by the time Moodle 2 comes out.)

By the way apologies for your bad experience - I'll try to remember next time I update the contrib information page to make the PHP 5 requirement more obvious (in bold or something).

--sam

Average of ratings: -

Re: ouwiki information and future plans

by Perry M - Tuesday, 12 February 2008, 2:45 AM

I'm not sure why the Moodle folks want to trudge down php 5 but that's their decision. Someday Powweb will upgrade to php 5, but I trust their decision not to touch it with a 10' pole right now.

Average of ratings: -

Re: ouwiki information and future plans

by sam marshall - Tuesday, 12 February 2008, 7:28 PM

'I'm not sure why the Moodle folks want to trudge down php 5'

Because programming PHP4 is about as fun and as sensible as performing brain surgery, on yourself, with no anaesthetic - and an axe?

Just a hunch.

Seriously, PHP5 includes key language features, the most notable being exceptions, which - if adopted and used appropriately - can significantly improve error handling and reduce the chance that bugs are introduced because somebody forgot to check a return value. (With exceptions you generally don't have to check return values any more - so it's good for lazy programmers too.)

It's not like PHP5 is exactly cutting edge (or has been for the last year or two) - there's PHP6 now, and I'm sure Moodle won't be upgrading to that any time soon. (Never mind that they could be using a real language like... okay, I won't go there.)

--sam

Average of ratings: -

Re: ouwiki information and future plans

by Perry M - Tuesday, 12 February 2008, 10:36 PM

I can appreciate programmers wanting to use the most up to date tools available, it's the same reason I'm working with Moodle's Beta.

However, the end user has the final say so. If php 5 limits the number hosting companies Moodle has limited the number of possible end users of their product.

It's their decision.

Average of ratings: -

Re: ouwiki information and future plans

by sam marshall - Tuesday, 12 February 2008, 11:52 PM

Well, it only limits the number of possible end users among people who aren't willing to spend a little extra for additional hosting elsewhere, or else change hosting provider for all their content to one that does support PHP 5.

By the time Moodle 2 launches I would hope the number of hosting providers not offering PHP 5 becomes relatively small, but who knows.

--sam

Average of ratings: -

Re: ouwiki information and future plans

by David Scotson - Friday, 15 February 2008, 8:42 PM

The GoPHP5 'movement' seem to be pushing for 5.2 as a common minimum requirement, they exlplain why in their FAQ. They also have lists of other projects and web hosts that have commited to supporting 5.2 from now on.

Average of ratings: -

Re: ouwiki information and future plans

by Robert Brenstein - Wednesday, 13 February 2008, 12:55 AM

Many hosting companies support users switching to php5 upon request. A global move to php5 is also gaining momentum as I am seeing hosters giving advance warnings of the switching to php5 as the default. This may have to do with php.net's formally announcing end of life for php4 last summer.

Average of ratings: -

Re: ouwiki information and future plans

by Xavier de Pedro - Friday, 8 February 2008, 4:35 AM

Hi all:

It's been long since I had written to Moodle forums years ago... after many years as an outsider to Moodle community, I started months ago using Moodle in my own University campus (finally!), besides other software in other campuses.

Congratulations, Sam, for the work done so far with OuWiki, and the anounced roadmap. For sure, teachers using Moodle need some better report to see user contributions among different wiki pages of the same course, etc. And simpler usability (I got lost weeks ago when I first attempted to make a revisions of two versions in nWiki). Sorry to say that, ludo, but that was my impression. So, that's good knews to know about OU Wiki roadmap.

However, for what I've seen so far (on the testing site), my vote goes for nWiki current module, which still has to be fixed and improved on some aspects, for sure, as OU Wiki needs improvements to reach a minimum feature set that makes it usable for many pedagogical scenarios.

Maybe OU Wiki could make it for Moodle 3.0? (so that we can decide on a longer term evolution of code features, bug fixing speed along with more features are added to your code, and support to Moodle community as ludo's team have been doing for these years, and are willing to keep that support for longer, besides Moodle HQ...)

On the other side, and from wiki users and coders from outside Moodle world, a good compromise between wiki markup and html wysiwyg editor is using the wysiwym editor called WikiWizard (see it in action in this screencast), which is free software and takes the best of the wysiwyg and wiki markup. This allows using some visual editor (showing markup efect parsed in real time), and allow users to leave your hands on the keyboard (WikiWiki: quick and easy to write and edit afterwards..., not just a matter of technology but philosophy... allowing wiki markup in whatever editor in Moodle is a must, from my point of view)

Moreover, WikiWizard is using Wiki Creole 1.0 (http://www.wikicreole.org), the proposed wiki syntax standard for Wikis, since last Wikisym 2007 conference. A full explanation about the WikiCreole and the WikiWizard can be read at this paper on that wikisym07( C. Sauer, C. Smith, & T. Benz. WikiCreole: A Common Wiki Markup). Keep in mind that WikiWizard has been released as LGPL'd javascript editor to be easily usable in any wiki (or web application for mobile devices, etc), besides the java applet shown in the screencast. Unluckily Wikimedia foundation decided not to support Wiki Creole in mediawiki for the time being (afaik, too much work for them and troubles since so many people are using theri syntax in many sites around the globe), but this shouldn't be the reason to avoid using that Wiki CReole standard proposal... (should we all stop using free software and OpenOffice because M$ .doc is still the kind of standard de facto for our students and colleagues out there???)

As far as I've read, nWiki already has some support for Wiki Creole (another strategic vision and decission of nWiki team, beyond using mediawiki markup). Congratulations to ludo's team for that!

For sure, there is a lot to happen with OU Wiki in the future (and I'll like to see it and use it with my students, either testing of for production, who knows), but for the time being in Moodle 2.0, I would suggest to stick to nWiki, improve it (bugfixing code, usability, documentation), and for sure, improve nwiki reports to help assessment from teachers of individuals and groups quantity and quality of activity.

Other open source communities have evolved into nice and promising features... Maybe you want to have a look at that, in order to see what others have done on the reporting side, so that either OU Wiki and/or nWiki make it even better?
The references I know of:
http://doc.tikiwiki.org/Contribution
http://doc.tikiwiki.org/Action+log

So, from my point of view, congratulations Sam (and team) for your work with OU Wiki, and keep up the good work.

Congratulations ludo's team for your good work and support to community for these years, and keep steping forward in your roadmap.

And I'd love to see an improved nWiki module as the default Wiki module in Moodle 2.0.

Cheers

P.S. Attached a screenshot from the wisywym editor in WikiWizard . However, better idea can be taken of its power and usability from the screencast, which I suggest again here with the full url:
http://www.i3g.hs-heilbronn.de/webcasts/wikiwizard/wikiwizard_demo.html

Attachment wikiwizard_editor_wysiwym.png

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Tim Hunt - Friday, 8 February 2008, 7:37 PM

I place a huge amount of attention on what developers are keen to work on.

I think this is a very important point (but then I would, I am a developer), and I want to provide some feedback on what it is like working on sam's code.

Looking back, it sometimes seems that most of my career at the OU has consisted of taking over responsibility for sam's code, and maintaining and enhancing it. And I don't have any problem with that at all. sam writes good, well structured code that is easy to maintain and enhance. As a foundation for the future, I would happily start with sam's code, both in general, and in this case.

Note that sam wrote OU wiki after having spent over a year making lots of different customisations and bug-fixes to lots of different areas of Moodle. Therefore, it closely follows moodle coding standards and common practices. The nWiki team have been less involved in the wider Moodle community (as far as I have seen) but then this is probably mostly a result of native language, and so is an unfair basis for comparison.

In another post, Ludo says:

in the case of nwiki there are 3 developers [...] 3 Years working and giving suport has to count for something.

When I read this, it scares me. It means that nWiki took more than 5 developer-years to get where it is today, while OU wiki has taken less than 0.5. And we are thinking about what we want in Moodle 2.0, which is probably of the order of at most another 0.5 developer-years away, in terms of what Moodle HQ can afford to invest in incorporating whatever is chosen into core.

However, 3 years work and support is worth something. It has, presumably generated a lot of knowledge about what features work for teachers and students, and what doesn't. That knowledge is far more reusable than the current nWiki code.

Finally, I don't think that the current beauty contest approach to this decision in particularly helpful. It might have been better to start with a survey asking people what features they want in a wiki for use as a learning tool in courses, rather than leaping in and comparing two solutions. But then I am currently studying a course on requirements gathering, so perhaps I currently have an over-idealised view of processes should work.

Average of ratings: Useful (2)

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Friday, 8 February 2008, 9:08 PM

TIM,
3 years working does not mean working full time on it. The original DFWiki took 2 months for 3 programmers to develop and it works fine. It was coded using as sample the code of moodle 1.4 as it was back then.

The big issue in the wiki development is to suport the all current ewiki features ( I assure you that if they are missing some one is going to notice) and then the huge huge huge task is the migration from the old wiki to the new wiki. This is a monstruous problem that we have solved, and we have the test bateries and experience to keep it stable.

I do agree that knowledge is more reusable that any code. I have been in this forum for more than 3 years gathering requirements from df and n wiki users which have leaded to the features of nwiki.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Friday, 8 February 2008, 9:32 PM

'most of my career at the OU has consisted of taking over responsibility for sam's code'

OH GOD TIM I'M SO SORRY.

I should note I didn't pay Tim for those comments!

Also, certain parts of ouwiki will be developed by other people (for example the new report system is by Callum Lester) although I'm still leading it so it should remain consistent.

I also agree with Tim's comments about the 'beauty contest' particularly in regard to the polls that were set up. In my admittedly biased opinion, it seems obvious that ouwiki should win in the 'usability' poll. I haven't looked at nwiki code but from other comments it sounds like ouwiki would have a good shot at the 'code quality' poll. But there isn't a 'features' poll, which nwiki would obviously win by a mile - and it seems that users here value features above usability and code quality.

By the way, I won't be losing any sleep if ouwiki isn't chosen as the wiki for Moodle 2.0 - I think it would be a shame, obviously (and from my viewpoint it would also look like a mistake), but I'm actually pretty used to having my code thrown away -

--sam

PS I'm still a little surprised that people think ouwiki is missing features not compared to nwiki (which is obvious, it is) but compared to the existing wiki. ouwiki actually has several features that the existing wiki doesn't IIRC, including comments on pages and sections (much better than talk pages imo and ewiki didn't even have those), Atom/RSS feeds of changes to pages or entire wiki, ability to download entire wiki as word processor .rtf format, ability to create 'wiki templates' so that each group's wiki in a group setup is automatically set up to initial values, and probably other things I forgot. Apart from wiki markup and a few minor administrative features, I can't remember anything significant in ewiki that we don't have.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Neil Birt - Thursday, 7 February 2008, 1:40 AM

As someone who is responsible for managing a Moodle site, I think there are two things that are important to my users:

data preservation
functionality

These two points are particularly critical when it comes to activities like wikis. Something that separates wikis from other available activities is that a wiki can transcend the period of a course. It can be an ongoing activity that is added to by future users. This is not the case with assignments or quizzes for example. Some attempt at backward compatibility therefore is crucial to any wiki update.

Also, it seems counter-intuitive to me to accept the least functionality just because it is cleaner. Why should I have to accept even less functionality than what ewiki has to offer? If more functions are to be added, when will they be added? How much longer would we have to wait until we had a fully functional wiki module?

I am sorry if it is difficult for developers to make things work well and I appreciate that they have a difficult task. I also respect the amount of work that they have put in to making it work at all. That said, they are not our primary audience. These are the people we need to consider and these are the people we need to focus on when we make these types of decisions.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Mark Pearson - Thursday, 7 February 2008, 6:19 AM

Something that separates wikis from other available activities is that a wiki can transcend the period of a course. It can be an ongoing activity that is added to by future users. This is not the case with assignments or quizzes for example. Some attempt at backward compatibility therefore is crucial to any wiki update.

This has to be a clincher for the need for backward compatibility. So my initial premise that wiki migration didn't necessarily need to have backward compatibility was mistaken. But I have still to be convinced that Nwiki itself has cleared the upgrade hurdle. However, it's also clear that OUWiki would need to have ewiki import capability to be acceptable.

Personally, I would have pushed the Wiki Activity a lot more in previous years had Nwiki been available sooner. As it is, I'm now of the opinion that Elgg+Folio is a better wiki approach for us.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Martin Dougiamas - Thursday, 7 February 2008, 1:02 PM

Just to be clear, either module will have to support AT LEAST what ewiki supports to be viable (we won't go backwards in functionality). At this point the work required for rewriting nwiki or adding features to ouwiki is probably in the same ballpark.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by David Berry - Thursday, 7 February 2008, 3:15 PM

If the final "product" is a feature-rich wiki, then it doesn't matter to the end user which route is chosen. I suggest that the core developers choose which is easier for them.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Thursday, 7 February 2008, 5:45 PM

Don't forget that in the case of nwiki there are 3 developers (senior, they are not grad students anymore) and a project manager that come ith the package, and that CARE about having a good wiki in Moodle.
So not all the work should fall into the moodle core developers whomever they are . We want to keep doing what we have, we just need some hep to make it more neat.
3 Years working and giving suport has to count for something.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Josep M. Fontana - Thursday, 7 February 2008, 7:59 PM

Then, if the amount of work needed to do one thing or the other is pretty much the same, my ideal Moodle wiki would be what is now the Nwiki with all the fixing up that might need to be done to make it more stable, easier to maintain and more user friendly for those who are afraid of too many features.

I think that many of the features the NWiki has can be very useful. It's just a matter of making it easy for the person managing a course to be able to show more or less features depending on the kinds of users a given course is going to have. Maybe the default interface should be something simple like the OU wiki is now and then configure additional functions as desired via blocks or whatever.

IMO, however, one thing that any future wiki also *has to have* is a 'history' interface which is at least as good as the one that the OU wiki has now. I've had the oportunity to test the OU wiki a little bit and the one thing where it shines is in the interface it has to check the different versions of the wikis. That is a feature that I think MOST users would benefit from in an educational environment. If you don't make it easy for the average teacher to revise the evolution of the text and examine how the different users have contributed to its "final" state (quotation marks because a wiki is never finished), then you don't have a very useful wiki for the average teacher (if you take the "average teacher" to care about the process at least as much as the result, that is).

I don't think it would be too difficult to add the OU Wiki history/diff interface to the NWiki. Then you would have the best of both worlds.

If people say Nwiki has too many features (which as I said shouldn't be a problem as long as you can "hide" them selectively), this (the OU wiki history/diff view) is one feature that shouldn't disappear from the Moodle official wiki.

Anyway, this is yet another one of the many opinions contributed here.

Josep M.

Ah, I forgot to say that the HTML wysiwyg editor should be the editor that appears by default and that this HTML editor should be a better one than the one that Moodle has now.

Average of ratings: Useful (1)

Re: Voting on NWiki vs OUWiki

by Bernat Claramunt - Thursday, 7 February 2008, 8:57 PM

So, it seems that it really does not matter much where you start from. If cleaning the code of the already rich-featured Nwiki to make it stable takes the same amount of work than making the already stable OUwiki more rich-featured, we will probably end with a very similar official Moodle wiki, both in terms of code, features and stability.

As teachers, we need stability and features that we can administer in some way. I really believe that this decision must be taken by the experts.

Bernat

Average of ratings: Useful (1)

Re: Voting on NWiki vs OUWiki

by Perry M - Thursday, 7 February 2008, 10:02 PM

I remember the Ford Edsel – it designed by experts too. http://en.wikipedia.org/wiki/Edsel

“If they build it” consumers won’t necessarily use it. Wikis are becoming so common place now that there is a “Toy” level that must be exceeded or the consumer will be insulted and not use it or just look for an alternative. (That's what we have now) That alternative could get them into a lot of hot water but Moodle will get the blame.

Comparing the 2 Wikis still has me voting for nWiki. It has just enough features to be just outside the “Toy” label.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ger Tielemans - Thursday, 7 February 2008, 11:15 PM

I want to have both: OUwiki for the beginners, Nwiki with all these options for super-users.

I propose to vote strategic :

If we vote for nWiki, the OU will still maintain their own elegant, clear, student-centered OUwiki with a different flavour.
(at least, I would do if I was OU)

A small remark:

You can grade every Moodle activity by combining that activity with a not-on-the-computer-activity.

(Use the outline function and te naming of both to show their relation.)

A second remark: what I do like the least is the bad habit of nWiki, to "claim" the tables of another wiki. Call your tables nWiki and offer a decent import AND export option for users.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ger Tielemans - Friday, 8 February 2008, 12:02 AM

In this case: because the core wiki of Moodle will leave anyway, the take over of the tables is no longer a sever problem..

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Friday, 8 February 2008, 2:11 AM

As I mentioned earlier, you are probably correct that we will continue to maintain our version. I'm a bit disappointed to see that reduce our vote numbers though

Also on a more practical level, even though we will maintain it either way, having it as part of the core system would make it significantly easier for other people to fix issues we might have missed, or contribute features. So it might improve more slowly, and would definitely be less likely to cover any features that aren't of direct concern to the OU itself.

By the way just to mention it there is also a possibility to add support for wiki format markup (as a per-activity switch probably with per-site default) to ouwiki. So you could have either an html wiki (as at present, using the html editor or when editor is disabled, a blog-style 'html plus it does paragraphs for you' input format) or a wiki that uses mediawiki-style markup. (This would be fixed for the wiki and not changeable by students - it breaks collaboration when some students use HTML and some use the wiki format.)

Like import this is something we wouldn't implement unless it is in order to get the module into core, because we don't need it personally. I don't think it would be hugely difficult.

We are definitely not going to implement all the features nwiki has, though! Just saying that wiki markup usage could be an option if this is critical for other sites, I can imagine this feature might be made a requirement in order to get it into core.

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Jordi Piguillem - Friday, 8 February 2008, 5:47 PM

Hi Ger,

A second remark: what I do like the least is the bad habit of nWiki, to "claim" the tables of another wiki. Call your tables nWiki and offer a decent import AND export option for users.

This was not our decision, Moodle HQ asked for it.

DFWikiTeam,Pigui

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Michael Penney - Monday, 11 February 2008, 3:16 AM

So, if the work is about the same, then fixing up nWiki would mean a big leap forward in Wiki features, whearas the same number of hours into OUWiki would leave us at about the same place in terms of functionality?

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Petr Skoda - Monday, 11 February 2008, 7:22 AM

I personally do not care about new features just now, we need something solid to replace current wiki with asap - my personal requirements are:

clean code with usual coding style
secure
easy to use
maintainer (preferably until at least 2050)
upgrade code from current wiki included

I am afraid substantial parts of nwiki might have to be rewritten which could take months and a lot of help from at least one of core developers (Catalyst, Martin, Eloy or me), the benefit could be new people working on core code in future.

Ouwiki is much smaller and has fewer features which means it would only take weeks to add missing required features and cleanup/review the code. I am sure Sam is able to do that nearly alone with minimal help.

I understand users/teachers want as much features as possible. On the other hand Moodle maintainers would prefer the safest way to replace current ewiki with something that works and is not a pain to maintain.

And yes, I am the one who was blocking earlier inclusion of nwiki into core. We did the same mistake of putting unfinished code in main cvs several times already, it is my job now to sound the alarm when it is about to happen again, sorry. The code should be IMO nice and polished before including it in official distribution.

Anyway good luck to both wikis!

Petr

Average of ratings: Useful (2)

Re: Voting on NWiki vs OUWiki

by Robert Brenstein - Monday, 11 February 2008, 8:35 AM

Can't some code, like upgrade of data from old wiki, be moved from nwiki to ouwiki after some cleaning/rewriting? It'd be a shame to throw away the few years of work of the nwiki team but... if they use their expertise and code fragments to get ouwiki-based wiki up to speed (even if not all nwiki features are transferred right away) then we may have a dev path that should make most people happy.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Monday, 11 February 2008, 4:43 PM

I don't think so. NWiki and OU Wiki tables have different structure. And some migration routines are related to specific aspects of NWiki design. Anyway OUwiki dos not have any markup parser, so everything needs to be done. And when you have a functional wiki ... worry about features.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Monday, 11 February 2008, 10:07 PM

I'm thinking it should be pretty easy to convert at present - we can use ewiki's parser to produce the html, and that's it.

However it would be a bit more difficult if we did support wiki markup ourselves (unless it was compatible with ewiki, obviously) or if we wanted to do it without incorporating any ewiki code even for migration, which might be a factor.

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Michael Penney - Tuesday, 12 February 2008, 8:03 AM

we can use ewiki's parser to produce the html, and that's it.

Are you going to bring in the change history from eWiki? I think that would be a big problem for many people who are using wikis, if the upgrade lost their wiki history.

What about backups? Will course backups containing old wikis import correctly?

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Tuesday, 12 February 2008, 4:26 PM

Nwiki does

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Tuesday, 12 February 2008, 7:22 PM

Sure, all the versions are stored independently so there's no problem importing every version in the same way, as far as I can tell.

And yes, restore will have to work, won't it.

Good point, I always forget backups until somebody mentions it... I don't think it should be a huge deal though.

(To be honest I feel especially relaxed about saying this stuff won't be difficult to do because it doesn't look especially like I'm going to have to do it.

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Jordi Piguillem - Tuesday, 12 February 2008, 9:09 PM

I will mention them. Restore does not work. surprise

DFWikiTeam, Pigui.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Michael Penney - Monday, 11 February 2008, 9:15 AM

Thanks for making that point, Petr although if OUwiki is chosen I think enough budget should be allocated to provide lots of whatever Sam likes to drink while coding (and then afterward what he likes when finished coding) while he is working on the ewiki upgrade bit.

One other part of the equation is: more features in the wiki = greater adoption of Moodle = more money from the partners back to Moodle core to fix the problems that all those features cause.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Tim Hunt - Tuesday, 12 February 2008, 11:43 PM

That should be quite cheap. Sam mostly drinks water. Maybe the occasional orange juice.

Also, the equation is more complex than that. You need to take into account a combination of features, ease use and performance.

Actually I was reading something interesting the other week that was making the distinction between "easy to use" and "easy to learn".

An ATM (hole-in-the-wall machine, thing you use to get money out of the bank) needs to be easy to learn. Lots of people just walk up to it, and need to be able to work out how to use it without instructions.

A powerful tool like Photoshop, or Eclipse, needs to be easy to use. Expert users will use it in their work to perform complex tasks. It should provide powerful features to let them do those tasks efficiently, once they have gone through the days of training required to use it efficiently. Because they will use it a lot, they can afford to invest the training time to achieve optimum performance in the long term.

I think that for most moodle tools, easy to learn is the more important. Teachers needs to be able to introduce technology into their courses to support the learning without the technology being a big deal. It should just work intuitively.

Of course, the two concepts are not mutually exclusive. Firefox is a reasonably good example. It is easy to learn to use for basic web browsing, but there are more advanced options you can turn on if you are a power-user. But then those extra components like firebug are often in the form of third-party modules that have to be downloaded and installed.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Martín Langhoff - Thursday, 14 February 2008, 3:48 PM

> Actually I was reading something interesting the
> other week that was making the distinction
> between "easy to use" and "easy to learn".

I agree -- and there's another way of looking at it. For many programs/tools, new users are "new" only once. Photoshop and Eclipse, are in that category. The "newbie experience" is important, but catering for it cannot get in the way of the power users. Because most users are expected to become power users. Those UIs can be deep and rich.

In front of an ATM, we are always "new", and there's an expectation of "delivery" (of cash!) within a few seconds. There isn't much depth in functionality but there is a lot of pressure in keeping it simple, fast and unambiguous.

Moodle is somewhere in between -- luckily, learning is usually taken over longer periods of time and with more focus than what people expect to spend in front of the ATM

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Michael Penney - Friday, 15 February 2008, 2:04 AM

Hi Tim, yes more complex is what I was getting at: features + ease of use + performance = greater adoption of Moodle = more money from the partners.

It seems to me the Features part of the equation was undervalued. Comparing for instance what happened in the quality of code vs. features race with regard to MySpace vs. Friendster perhaps may prove informative.

Regarding 'ease of use' vs. 'easy to learn', I've more often seen this termed lately as 'usable' vs. 'learnable' (easy being so easily misunderstood). For example, niether Photoshop nor the Moodle Quiz module is "easy", however both are "learnable" as they use generally consistant and informative interfaces (having used Photoshop since vers 2.5 & the Quiz since 1.1, myself & having shown a number of people how to use both along the way).

It's also perhaps helpful to think about how 'easy to use' changes as an interface becomes widely used (so more users are using it at a young age & more users have been using it for years). For instance ATMs when they were first introduced were not generally considered 'easy to use' or 'usable', though most folks would say they are now - however the interface on most ATMs has changed very little in the last decade (at least here in the US). Both the example of Photoshop and the Quiz also demonstrate interface lock: as a application becomes popular the resistance to making major changes in the application also increases, as the user population moves from early adopters to general users, the resitance to change increases (Carl Berger has done some very interesting studies on the shifts in user types and attitudes as a user base changes from early adopters to the early majority, and so on).

Anyway, I could give a talk on this, I guess (actually I think I have given a few, however in the current context it may be important with regards to nWikis use of tabs where OUWiki uses links, the general set of features folks expect from a Moodle wiki, etc.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Tim Hunt - Friday, 15 February 2008, 7:03 PM

Great post Michael. Only one think I want to add:

I think the forum module is a good example of getting the balance between usabilty and learnability right for the educational context.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by User Name - Thursday, 7 February 2008, 11:14 PM

Here's my two cents worth.

First, I want to plainly state that I'm not trying to be a troll, or a know-it-all, or a basic cynic. Many on our campus use Moodle and find it a useful application. Its easy enough for me to manage that it isn't one of those systems that I resent having to manage! I respect and appreciate the great deal of work that has gone into it. I like it, OK? OK. Also, just given feedback I sometimes get, I may be sounding more snotty than I intend!

That said...

Suppose I'm going to write a web application called Moodle.

Since it is a web application, it will need a web server on which to run. Should I write a web server? No. There is a really good one out there already called Apache. I'll use that. Great.

I need a database back-end. Should I write a database? No. There are a number of really good ones out there already, namely Postgres and MySQL. I'll use one of those.

I need a number of scripts to make Moodle work. Should I write a scripting language that works well for web application development? No, I could use PHP, Java or a number of other languages. PHP looks good so I'll use that.

Now years later, this wiki thing is really taking off and there is a lot of interest in it. There are a number of mature open-source wikis in active development. Should I write my own Wiki to include in Moodle? You already know how I'd answer that riddle at this point.

Since stalling Moodle development for a complete re-tooling of some component isn't a good option, maybe the short term answer is to choose one of the ones people are voting on. But for the long term, a development strategy of integration and interoperability with other systems would better position Moodle for success. Because otherwise, a bloated system with underperforming bundled auxiliary functions/apps seems inevitable.

Thank you for your consideration,
Ted Fines
Macalester College

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Friday, 8 February 2008, 2:33 AM

That's an interesting development strategy but it's the complete opposite route to the one Moodle has taken. (So if you want that approach, use a different product! You probably want a portal and Random Other Crap (tm) linked to your LDAP.)

The main disadvantage of that approach is that you then end up with wildly different systems that share no interface or data aspects and are difficult to integrate in a coherent manner. This is what the OU had (and to some extent still has, at least unless we manage to kill First Class) and it's pretty crappy for students.

A middle ground is to take a component-based approach where you come up with an API that allows people to express web applications as separate web service-based components together with some kind of standardised interface language. This offers the potential that you might be able to build a wrapper so that standard tools (such as MediaWiki, Movable Type) could be incorporated into a VLE such as Sakai (yes this is more like a Sakai-type model than Moodle, as far as I understand Sakai, which isn't very far) while retaining a high degree of interface consistency and core features like shared user information. Again, although I think this is a good approach, it isn't the Moodle approach.

The Moodle approach is (or should be) to put together a collection of tools that are simplified (to the extent that they are suitable for teaching), fully usable, tightly integrated, and have a consistent interface.

In other words my personal view is that nobody should be trying to compete with MediaWiki within Moodle. Could I personally write a better wiki than MediaWiki? Sure, I think so. But that's absolutely not what I tried to do with the ouwiki - and not only because of obvious development time constraints. The best wiki within Moodle is not the same as the best wiki for general use - the difference is that it will be used for a specific purpose, teaching and learning, and usually only as a small component of a larger course that involves many tasks.

--sam

Average of ratings: Useful (1)

Re: Voting on NWiki vs OUWiki

by Martín Langhoff - Friday, 8 February 2008, 7:35 AM

Ted - I agree with Sam here. If you want MediaWiki, run it alongside Moodle - that's what we do: Luke Hudson @ Catalyst has even written an SSO plugin for MediaWiki to work with Moodle. However, there is a huge value in having a (perhaps more limited) wiki that is course-centric.

Perhaps we can reuse some of MediaWiki's libraries. Still, at the end of the day, the use model is quite specific and that's the value add of a Moodle module that does wiki-things.

After all, moodle mainly does forums, content-management, quizzes and polls. Yes - you could tie together a few webapps that do that, but you would lose the course/group-centric approach, the consistent UI and a whole lot of good things that come with that.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Joan Queralt - Saturday, 9 February 2008, 4:35 PM

I agree with you, Martin, when you say that you would lose the course/group-centric approach, the consistent UI and a whole lot of good things that come with Moodle.

As a teacher I prefer that my students have a hole vision of the course, so I like they concentrate in the course and don't distract. I've tried both wikis and I prefer Nwiki because is in moodle and allows a richer variety of learning activities. Sorry for OU, it's poorest in that point.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Martin Dougiamas - Friday, 8 February 2008, 12:12 PM

I actually agree with Ted AND Sam

The old wiki is actually a 3rd party wiki called EfurtWiki, which is designed to be embedded. Over time people added lots of Moodle features in response to teacher suggestions but it really wasn't designed for extension, with the result that we have a buggy forked mess today.

The problem is that a wiki in Moodle is quite unlike Mediawiki, there are different requirements. For example we want things like gradeable wiki-per-student and wiki-per-group, plus tight integration of users so that when you look in the history you see profile images and links to user profiles. We want logging in the Moodle log for statistics. Sometimes we want to use a proper HTML editor just like we use everywhere else. We want Moodle filters to work in Wiki texts. We want Moodle user accounts and roles to just work the same as the rest of the course. We want files to work the same as everywhere else. We need accessible interfaces that use our main theme. And so on and so on.

Mediawiki (for example) doesn't even come slightly close to this - it's a got a different set of assumptions - it's designed for lot of random people editing one giant public standalone web site with lots of incoming and outgoing links. That's why it was far more appropriate for Moodle Docs than our own Wiki.

In many other cases, I totally agree with Ted. For example, repositories and portfolios are two areas that do not belong in Moodle, and among the major work on the roadmap for Moodle 2.0 are new APIs that enable Moodle to integrate very well with external systems designed for this. Same with student information systems, authentication sources and so on. Moodle will integrate with any external system that makes sense.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ralf Hilgenstock - Monday, 11 February 2008, 4:19 PM

I agree with Martin. We had several discussions in forums about Mediawiki integration and I discussed this often with German users. Mainly the discussion was driven by "Mediawiki is a tool we know from using wikipedia as reader". Mostly they didn't discuss it from a pedagogical process and usabilty aspects for teachers.
Nobody wants to setup a own mediawiki for each course or a complex role und access handling for pages.

My main aspects for the new wiki are:
- easy setup for teachers
- flexible use: teacherwiki, group wiki, wiki in group mode, single user wiki
- same editor as in the Moodle instance
- stable with some hundred pages
- search feature
- history of changes
- grading of pages and whole wiki
- import of old wikis
There is one new feature that could be interested in my opinion: general global wiki for the whole Moodle system. (like global glossaries or central feedback).

Yesterday I tried to work with both tools:
Feedback for nwiki:

lots of features I did't need [' I know there will be others that need exactly the features i didn't need.']. The simplier a page is the better it will be for understanding.
The idea of a wiki course format is good.
Additional blocks will be sensefull in some cases in a wiki course format. We have too much blocks in most moodle courses.If we need a information about single wiki pages we should think about a menu block including all information from a course and not only from wiki.
Couldn't edit pages (no edit button)

Feedback for OU wiki:

Couldn't save a page
History is not correct. The history showed changes I never did, but an other person. (Could be related to the saving problem.) History information in header should have an option for disabling.
Only basic features are good for understanding the use of the wiki,
Some help files should be added
<h3 id="ouw_s10_0"> Hidden functions??
Smart and easy to use.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Monday, 11 February 2008, 7:54 PM

Hi Ralf,
thanks for your feedback.
About what you say:

My main aspects for the new wiki are:
- easy setup for teachers
- flexible use: teacherwiki, group wiki, wiki in group mode, single user wiki
- same editor as in the Moodle instance
- stable with some hundred pages
- search feature
- history of changes
- grading of pages and whole wiki
- import of old wikis

These bases are covered by NWiki. About the stability with hundreds of pages I've got a production site with huge wikis very active and abused by my students (250 of them all active in the wiki each semester 5 consecutive semesters editing) that you can see works fine.
http://morfeo.upc.es/crom/mod/wiki/view.php?id=2&page=view/Inici&gid=0&uid=0
http://morfeo.upc.es/crom/mod/wiki/view.php?id=2&page=view/Inici&gid=0&uid=0

About your feedback:
Too features: The wiki can be configured without using the features as simple as possible. see
http://wiki.moodle.org/mod/wiki/view.php?id=42

Additional blocks will be sensefull in some cases in a wiki course format. We have too much blocks in most moodle courses.If we need a information about single wiki pages we should think about a menu block including all information from a course and not only from wiki.

Nwiki blocks can be squeezed into the course, course blocks can be squeezed into the wiki

Couldn't edit pages (no edit button)

The edit button is in the Edit tab that you should see if you've got permisions. Like ewiki and mediawiki, and even ouwiki. Guest does not edit.

Thanks for the feedback
L.

Average of ratings: -

Edit-function for not enrolled users.

by Ralf Hilgenstock - Tuesday, 12 February 2008, 6:15 PM

Hi Ludo

Couldn't edit pages (no edit button)

The edit button is in the Edit tab that you should see if you've got permisions. Like ewiki and mediawiki, and even ouwiki. Guest does not edit.

you are right. I was not enrolled in the course when I tried to edit in nwiki. There is no "edit"-Button then. After enrolling I got the edit button.

It was confusing, because in ouwiki a not enrolled user sees the edit button, but storing changes creates an error related to the reported "search" feature. The history lists the changes from an unenroled user.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Monday, 11 February 2008, 10:00 PM

Thanks for your feedback about ouwiki. Sorry you couldn't save a page

The reason it is currently broken on wiki.moodle.org is that I, perhaps unwisely, asked for ousearch to be installed. This enables the indexed fulltext search. Unfortunately ousearch currently turns out to require the mbstring php extension, which is part of php but may not be enabled by default, and isn't enabled for wiki.moodle.org. I've asked for the extension to be enabled. [If this is a wide issue we might need to change ousearch to not require that extension, I don't know.]

Because Moodle as a project doesn't support transactions, when things go wrong partway through saving a page like that, it is possible for things to get in a slight confusion in the database, which could explain any incorrect history details. Actually, ouwiki does use transactions at the OU, but when running on core moodle, we have used a 'null_transaction_wrapper' object or somesuch, which basically doesn't do anything. Perhaps there will be some move toward transactions in moodle 2.0 (note: not all databases fully support transactions, for example oracle doesn't and maybe mysql too, however they should do enough for oumoodle to save a page safely).

By the way if all this sounds a bit unreliable, don't worry, it isn't. It might be some reassurance to know that in addition to our in-house testing, usage by staff to experiment, etc., ouwiki has been in use on two OU courses since last autumn (total ~400 students) with a further three that have just started using it although not sure the students have actually got to the wiki activities yet (an additional ~1150 students). So far we have not had any reports of serious bugs at all. Obviously that's not a massive amount of usage yet (it's increasing gradually as you'd expect) but this compares to the old wiki with which we had many problems, on a similar number/size of courses...

(Note: I excluded some courses from that list which are too hard to count for internal reasons, are likely to be small numbers of students, are only using ouwiki for tutors, etc.)

Finally, that 'hidden feature' is just IDs added to headings - these are provided to mark them as sections so you can edit as a section and in particular make comments on the section. Headings are assigned an ID so that you can move the heading around and the comments stay with it. (Unless you mess with the ID, or delete the heading - then any existing comments will migrate to the 'page' comment area.)

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by User Name - Monday, 11 February 2008, 11:43 PM

This thread has brought some good points to the surface. And since I said I wasn't a troll, ie someone who posts something provocative then leaves & watches the melee, here's how I would summarize some of the issues raised.

Using an external system brings UI (user interface) inconsistencies. The consensus is that a consistent UI is a high priority.
The "best" wiki for use with Moodle is not necessarily the "best" wiki according to some rating that just judges standalone wikis. The "best" wiki for Moodle would have features that specifically complement and enhance Moodle's functionality, e.g. the course/group-centric approach.
The grouping of functionality into a single system, giving users a complete view into the course & resources, is highly valued.
Set-up and use of whatever wiki is used needs to be flexible, easy and quick.
Moodle's feature set needs to be evaluated in terms of how it benefits teaching and learning; technical specs are secondary.

This all makes sense to me.

I've been thinking about this more as people have posted these and other good points. Consider the question, "What is the best <word processor/browser/etc.> available?" The answer to this question has changed over the years, not in terms of any specific product, but in terms of the appropriate response. 15 years ago, I would have answered with a particular product--Word, Ami Pro, whatever.

As I matured in my judgment, and as products became more and more of a commodity (though it was mostly I who did the growing up!), I came to realize my answer was wrong. To the question "What is the best <word processort/browser/etc.>?" I realized there were several answers:

"The one you know how to use." -- for those who had experience with more than one.
"The one that you are comfortable with and find least difficult." -- for a new user.
"The one that is the strongest at feature X." -- for someone who needed a lot of feature X.

So for most people now, since most people have some experience with a computer, the answer was, "The one you know how to use." for a long time. The question, "What are you trying to do?" needs to be asked too, sometime before they click 'purchase'! If I had a nickel for all the people who bought Photoshop just to crop/resize/de-redeye photos, I'd be...well, I'd be Adobe I guess.

That answer is still correct for many apps, mainly standalone ones for personal use. But the landscape has changed for multi-user apps such as Moodle, and other web apps. An additional criteria is interoperability -- how well an app can work and play nicely with other systems. Users expect a more seamless integration than they used to. Google's building of different web apps plus a well-documented API is a good example of the success/benefits of this.

At least interoperability is a big criteria for people like me, whose job it is to make systems work and play nicely together. I do not consider that the highest, or the only priority. If users can't use it, don't like it, or it doesn't make their jobs easier/more effective/better, the tech stuff is meaningless.

OK, I'll get back to this specific topic. Which approach (internal/external) would be better for Moodle's wiki in the long-term? I realize neither option is without its problems. I don't want Moodle to be big, cumbersome and bloated. It isn't now. Adding an internal wiki won't make it so either, but over time, adding app. after app. probably will.

I guess that was the reason for my post -- we've all seen code bloat happen to so many good software projects, and I don't want that to happen to Moodle.

Thanks again everyone for your thoughts and insights,
Ted Fines
Macalester College

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by David Scotson - Monday, 11 February 2008, 11:20 PM

I'd like to propose a third way. I don't think this will be popular (for reasons I'll outline) but think it's still worth thinking about.

In short: the OUWiki should be added to the core, but should be renamed something completely different from wiki e.g. "Collaboration" or "Hypertext" activity. The NWiki should continue to be developed as a 3rd party add-on for people who need a more traditional wiki, but can't have their needs met by installing Mediawiki alongside Moodle.

I like the OU module. It's simple and clean and effective, apparently the code is too. If you look at it from the point of view of "we need to let students create documents collaboratively" then I'd say the OU module is the answer. If you say "we need a wiki" then I don't think it qualifies. Personally, despite being a big fan of wikis in general, I think for most uses the former is more important.

But if a Wiki is required then I think wiki markup (with or without javascript-based editing help) is an essential requirement. Preferably the markup and interface would be as close to Mediawiki as possible. And this seems to be what NWiki is aiming at.

I think splitting the modules so that one has an HTML editor and no wiki-markup and the other is vice versa could save a lot of programming time and effort.

The unpopularity comes from:

You'd effectively be killing wiki as a core module
you'd not be able to claim Moodle core has a 'wiki' (though it would have a similar/better/easier-to-use alternative)
existing Moodle wiki users need to use a 3rd party add-on to migrate data forward (unless you add a one time HTML export of the latest version into the new OU module)
you know pretty much what you're going to get right now (this naturally compares poorly to whatever you hope either module will be like after 'doing a lot of work')

I'd much rather see two good modules that concentrate on what they're good at/for, even if one is non-core, than see people expend effort changing and expanding one perfectly good module in order to become a partial replacement for another and be left sitting between two stools.

(a tangent inspired by the suggestion of "Hypertext" as a module name: I don't suppose the OU/Sam/anyone else is interested in producing a single user 'resource' version of the OUWiki that lets teachers create multiple inter-linked pages similar to the Book module? Student's would only be able to read. I know you could probably do this with roles, but a seperate resource/activity would communicate what was going on better).

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Tuesday, 12 February 2008, 12:38 AM

Re last part: yes you can do that with roles (with both ouwiki and nwiki I'm sure), in fact it's quite trivial. One of the major points of roles is that we don't need to come up with completely new software every time somebody comes up with a use case like that

If there is a problem with management of roles then it should be dealt with by improvements to the role system IMO (I have a vague idea for override templates, maybe I filed a moodle bug for it at one point, but we haven't done it yet) and not by creating duplicate activities, even if the duplicates can be made to share all the same code.

ouwiki also lets you prevent students editing without using roles - you can set the 'end date' to something before now, iirc it will still let teachers edit. (The end date is really intended for create-a-wiki type assignments that have a deadline.)

Re your main point, maybe it's a good idea, not sure (personally I do sort of think a simple wiki is more appropriate for core, with a more advanced, full-featured option available to those who need it, rather than the other way around - but that seems to be the opposite to the general view). Changing the name might make sense, I agree it might remove some of those expectations for wiki markup - it depends whether an institution's policies are buzzword-led or not. Obviously it is possible for anyone to change the name at their site, thanks to the wonders of language files ('OU wiki' is just 'Wiki' here, while 'Wiki' is 'Old wiki').

(And I really don't think it should be a major problem to import html from old wiki, of course time will tell.)

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by David Scotson - Tuesday, 12 February 2008, 7:55 PM

Thanks for the response, I continued my thoughts over in the General Developers Forum, as I'm not really just thinking about Wikis, but about collaborative editing with history and undo generally in Moodle:

http://moodle.org/mod/forum/discuss.php?d=90237

My main point is that hopefully the code may be reused but for the smoothest possible user experience the built in help, the options and the presentation would ideally be different. And that's not something roles was designed to do.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Julian Ridden - Tuesday, 12 February 2008, 9:03 AM

I am really torn on this issue.

I have installed NWiki and had it in use for some time. It was installed due to "Teacher demand". No specifically for that product, but for the features that it has added. So part of me is voting this direction as I want to provide effective support for my faculty staff.

However, I personally (Martin won't believe this) don't want to go all cowboy and launch code that is not well written or has known bugs. The clean approach provided by the OUWiki s well as knowing that OU will want to continue supporting it's own product has me very much in favor with this approach.

For Moodle, I believe it is best to go with the most stable wiki. While I do love and intend to continue running NWiki, I think that a product we keep in the core needs to be simple, clean and efficient. It will however NEED to support an upgrade from the existing wiki. That is a "deal killer".

Keep NWiki as an alternative for those seeking the additional functionality. I would hate to see support for NWiki decline if OUWiki goes core. At the moment both are needed.

Just my 2 cents

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Jordi Piguillem - Tuesday, 12 February 2008, 9:02 PM

Support? What I've doing every day last 2 years? Cultivating onions and tomatoes in my office?

DFWikiTeam, Pigui

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Wednesday, 13 February 2008, 1:05 AM

Off course ... for Gazpacho... is what we do in spain didn't you notice?

Average of ratings: -

A WORD ABOUT STABILITY

by Ludo (Marc Alier) - Tuesday, 12 February 2008, 4:40 PM

I've been reading so many times that there is the feelling that NWiki is cool but is not stable. I'm sick of it.

THAT IS NOT TRUE

Check this forum, and see the reports: NWiki is stable and never loses data nor fails to deliver functionality.

The issues that has NWiki come in the installation/migration process due to literally hundreds of possibles scenarios (versions of moodle, databases, php, and fancy uses of wiki (groups, student, visible, separate)).

We have been dealing with this problem for a very long time. And is NOT a problem of coding using butterflies (I'm sure Sam does

). Is about testing and testing and testing, and then test a little more. Is about working within the community, giving support to users day, after day, after day, after day.

We have in our backoffice the testground to migrate wikis. Lots of users have sent their backups to us asking for help which they got.

Our stability comes out of heavy testing for a LOONG TIME.

That's it

Ludo

ps. Julian, I'm afraid that if we miss this one we wont keep much illusion in this project (and that's what drives it, is not our job). I'll bring it to a stable phase and face new challenges.

Average of ratings: -

Re: A WORD ABOUT STABILITY

by Julian Ridden - Tuesday, 12 February 2008, 8:32 PM

You know what, that hasn't really been said enough and I totally agree.

From a user perspective (the front-end) I have had no complaints with the current version from either myself or my staff. It does run bug free from that perspective.

I think the reference to unclean code come from analysing the code itself in more depth by those with far more knowledge than myself.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Roberta Militello - Wednesday, 13 February 2008, 4:46 AM

Two major requirements emerged when reading these discussions. There is a need for a feature-rich wiki specific to the needs of multiple educational audiences (k-12, higher, etc.). There is also a need for a solid, well-documented, and maintainable code base that is integrated into the Moodle architecture and takes into account upgrade issues. The sand box link (wiki.moodle.org) is a great start in that it gives the Moodle community a change to explore new products. But I don't think it is helpful to compare Napples with OUranges. OU wiki is very vanilla and doesn't have any upgrade issues because it is a new product entirely. It may more constructive to let the Moodle community collaborate in developing a list (tabular rather than post form) of requirements/features they would like to have. I think this approach could be a more constructive lens for evaluation and more in keeping with the spirit of open source collaboration.

I have not tried OUwiki yet, but we did try the upgrade to Nwiki on one of our test environments a couple of weeks ago. I think Nwiiki has several good ideas (grading, file uploads, etc.), though we encountered several frustrating issues.

- If was difficult finding a definitive download site and installation instructions for Nwiki. There were many broken links and the Nwiki upgrade was not listed on the official Moodle module page.

- the installation procedure is only listed for moodle 1.6. The installation procedure did not work as written for our version of moodle (1.8.2).

- md5 verification of source is not offered

- Wiki Conversion did function correctly. We can see the titles to the preexisting wikis, but the content does not transfer correctly. As a result, we decided not to upgrade our current production system even though the existing wiki is very buggy.

- The is no concise documentation regarding sites using a virtual host (this seems to be a Moodle issue in general).

- Browser testing information is was not available.

That's my 2 cents. Keep up the hard work. I hope to see a great wiki for Moodle in the near future.

Roberta

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Wednesday, 13 February 2008, 4:55 PM

Thanks for the feedback Roberta,
definitivelly some things we have to improve in our site.
Ciao
L.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Martin Dougiamas - Wednesday, 13 February 2008, 5:23 PM

Actually, I was just thinking we needed a big table of features too approve

How about something like http://docs.moodle.org/en/Development:Wiki_features?

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Martin Dougiamas - Tuesday, 26 February 2008, 1:48 PM

Please put all your wishes here (or they definitely will not happen):

http://docs.moodle.org/en/Development:Wiki_features

And please enjoy Mediawiki's way of doing tables

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Wednesday, 13 February 2008, 7:06 PM

I have now lost this message twice. HO HUM. I think there must be a Firefox bug with Mac keybindings in edit mode as Command-Left should go to start of line when editing, not go back to previous page...

ouwiki browser support not documented either, sorry; it is tested in IE6, IE7, Firefox; at some points we briefly checked in Safari, Opera and it was ok at that time but isn't properly tested; html editor currently doesn't work in safari, opera though which is a bit of a downer.

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Frank Fulchiero - Friday, 15 February 2008, 1:12 AM

There have been many good comments, and I thought I'd put in a few cents. I have supported about 12 course wikis using MediaWiki, at the college level.

1. Ease of Use vs. Ease of Learning: I think it's possible to have both. For example, I have taught hundreds of students and faculty how to use Photoshop only for simple scanning, cropping, adjust brightness/contrast (or use Levels, even better), and resize/resample. Most users never had a problem with all the other tools, they can be safely ignored. I would much rather have a full-featured wiki than a simple one, especially after using MediaWiki, which is already pretty basic when compared to some of the commercially available ones.

I have not seen much software with two different "toggable" user levels: basic and advanced, not sure how much programming effort would be needed to implement this in a wiki, but the time might be better spent developing other requirements. Just because a tool is there does not mean you have to use it.

Teaching college-level students and faculty to use MediaWiki takes us 25-45 minutes, depending on the level of detail we want to get into. Hands-on tutorials are best. I don't think you can expect someone unfamiliar with any software package to just sit down and use it without any training or introduction.

2. User interface: To me, the ideal would be WYSIWYG, like in PBWiki, or in a more limited version Wikispaces. Yes, I love wiki markup (I fondly call it HTML for dummies) and it has its charm, but most people just want to create and edit, and it gets in the way. WYSISWYG would also reduce training time.

3. Rich media use: many students want to do more than just write, they also want to include images, video and audio files. Even if they don't, it could be a requirement in cases where it will enhance the wiki.

The wiki should support #3. We need control over image placement (at least left, middle, right) and resize. Supported media formats can start with open standards, such as mp3, mp4 for audio, and mp4 for video.

I realize I'm probably talking about the next-generation of open-source wiki software, but many of the above features are already available in commercial wikis. Not to criticize the wonderful work all the open source volunteers are doing.

Just my $.02

Frank Fulchiero
Digital Media Specialist
Connecticut College

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Eric Carlson - Friday, 15 February 2008, 1:51 AM

From a functionality perspective, the current eWiki does what I need it to do (collaboration, interaction, figures, equations, tables) . That said, my first experience using groups (1 wiki, 10 groups) is having issues. I can work around these, but the problems certainly diminish the appreciation the students will have for wikis. The primary problem, viewing figures that were uploaded as attachments, does not occur when the wiki is set up for the entire class. Clearly the issue has to do with interaction between the wiki module and Moodle.

In the end, I think the choice has to be based on 1. the ability of the wiki to integrate with the Moodle framework, and 2. how easy it will be to maintain integration as Moodle morphs in the future. If there is an obvious answer, go with the wiki that plays best with Moodle. If there is no obvious answer, either include both as suggested previously or take a poll of the Moodle community and go with the one deemed as having the most important features.

I have evaluated each of the proposed wikis. I see things to love about each, and deficiencies in each. I presume that missing features could be added.

For example:
NWiki
pros - 1. Perpetual view of index for fast navigation 2. Can use MediaWiki standards 3. Ease of using pictures and attachments (when using the non-html editors) 4. linking to sections of the page or other wiki pages
cons - 1. Discussion of pages does not allow view of page while creating comments 2. Would be nice to flip between editors, instead of being forced to use the choice designated by the original creator/editor 3. not clear if Moodle latex filters will be used or internal equation filters will be used or ...

OUWiki
pros - 1. Comments 2. Simplicity 3. reported ability to set editing deadlines
cons - 1. can pictures/attachments be uploaded?

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Friday, 15 February 2008, 3:00 AM

Thanks for your comments, and yes the 'reported' ability to set editing deadlines is genuine. It really works, I know, just the other day somebody came to see me about a 'bug' and how they couldn't edit the wiki, when they had in fact turned on the editing deadline by accident.

To answer your question, no it is not currently possible to upload pictures (or other attachments). Since the old wiki apparently supports attachments - I never saw this actually working, but maybe that's because we usually use group mode here - and ouwiki currently doesn't, I presume we would have to add support for this facility if ouwiki were adopted in core. Otherwise we can't make the upgrade work properly.

By the way, our current OU plans call for a general solution to this issue rather than a feature specific to the wiki - we plan to make it possible for students to upload images in a course context, anywhere in the system, via the HTML editor. This is separate from the repository plan because the images are not seen as the student's; they are still connected to the course (so images are backed up with the course and so on, and you have to be logged in to the course to see them, so this can't be used for wide-scale piracy or to run a porn site or whatever), but managed so that students can't overwrite each other's, we know who uploaded each image, images would be automatically resized if they are too large for onscreen viewing, etc.

Anyway, not only has this not been done yet (or even specified!) but also we have no agreement with Moodle.com to put this facility in core. I plan to have another argument with them about it now that I have come up with new, more convincing reasons (oh, and a fully functional intercontinental ballistic missile aimed at Perth) but it's entirely possible that we will lose... So uh, don't take this as something that will happen - I'm just posting it to explain why we didn't put an image upload feature into ouwiki yet! (And why we won't add one, unless it's adopted for core.)

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ralf Hilgenstock - Friday, 15 February 2008, 5:04 AM

Hi Sam,

OU has developed lots of features and code and funded several developments in the last years. Thank you for this to all the people who makes this possible. This are big steps forward for moodle. Tim makes a great job in maintaining the quiz module.

There is a point I think about. What about conflicts in interests if the plans for developing modules or code in OU and in the community are different? How do you think to handle developments from community developers that include features OU don't want to use?

I think it won't be easy for you to combine the wishes and discussions in OU and in the community.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Tim Hunt - Friday, 15 February 2008, 7:33 PM

The way we solve potential conflicts is to keep our own copy of the code - let's call it OU Moodle - separate from the official Moodle code.

We can do whatever we like with OU Moodle. We can only do things in official Moodle that the community agree with.

Now, it is much easier for us if OU Moodle and official Moodle are as similar as possible. The main reason is so that when there is a new Moodle release, it is easy for us to combine those changes into OU Moodle.

And it is good for the community if, when the OU have done something generally useful, that goes into core Moodle.

So really, not much conflict, but quite a lot of pain for us every 3-6 months doing code merges, followed by testing and bug-fixing.

However, it is not as painful as it might be, because of Moodle's architecture. I lot of things can be done as plugins (ouwiki, resourcepage, studycal course format, workflow block, many admin reports, ...) without changing the Moodle core.

Yes, there are sometimes technical arguments about how things should be done in official Moodle, or whether or not they should be done at all. But my experience is that the Moodle community is a great place to have these debates, because there are a lot of knowledgeable people here, the arguments tend to focus on the issues, and everyone had a common goal of making Moodle as good as possible. Sometimes, the decision is not what is most convenient for the OU, but there is normally a sound reason, so you accept it, and often, during the debate, you learn something.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Friday, 15 February 2008, 7:36 PM

Thanks for acknowledging the OU's contribution. Unfortunately our special funding for the transition to Moodle runs out soon (we will still be maintaining things, of course, and developing new stuff but at a slower pace) but there are still a couple more things which are coming up that will be released into contrib for others to use: the 'vote' module (a full-featured replacement for Choice, with lots more 'question types' and the ability to allow tutors to create polls just for their tutor group, etc), which is being tested now, and the 'oublog' module (a replacement for the blog feature that provides a different way to organise individual and course-specific blogs), which is currently being developed. Both of these were initially designed by me but the development was outsourced. Then there's what I personally am working on now (or should be!) which is a new 'shared activities' system that lets any student create their own activity from specific types (such as forum, ouwiki) and invite people from anywhere on the system to join in. If any of these sound interesting, keep an eye on the general developer forum as I will post once those are available. (Hopefully in April/May.)

As for if we were to be maintainers for an ouwiki module included in core (which seems unlikely, but hey):

There's no problem if a suggested feature that somebody else wants to develop is a good feature, coded well, and makes sense from a user interface point of view. If the OU actively wants to not have a feature even though it's a good feature, then we could request that it includes a sitewide configuration flag or something. (Presumably we would have a good reason for not wanting it - so it might be an option that other institutions would also welcome.)

Where there'd be a problem is if the contributor thinks something is a good idea, but we think it's a crap idea (not just that the OU doesn't want it).

Or if something's been developed but the code is poor. However that would always be an issue... Hopefully it could be minimised by encouraging people to contact the maintainer (me, likely, to begin with anyhow) to discuss any plans before development so that we could agree a way for them to implement the change that would fit well into the module. Obviously in the final case Martin D can make decisions as to what goes into Moodle and what doesn't.

As noted, I think the above is looking rather hypothetical.

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ralf Hilgenstock - Friday, 15 February 2008, 8:13 PM

Hi Tim, hi Sam,

thanks for your explanations. this makes the things clearer for me.

Ralf

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Friday, 15 February 2008, 9:13 PM

OUBlogs ? Where can I get these? I'm a fan of using blogs in student activities and moodle blogs are @#@¢∞¢¢¢###¢∞∞##!!!!!
I will love to try it
Cheers
L.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Friday, 15 February 2008, 10:14 PM

Glad you're interested. The software doesn't actually exist yet, but is being written now. Not quite sure I am allowed to say who's doing the work, we sometimes have bizarre restrictions, although it's probably okay... but just in case, it is a competent development company that's quite well known in the moodle community, so I think it will be a good job.

Hopefully the resulting module will be pretty good! There are definitely course teams here that are eager to have it.

We're planning to release it (in our system and as contrib) in April, after testing etc. I'll post about it in the general developer forum once it's available.

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Derek Chirnside - Tuesday, 13 May 2008, 7:34 AM

Sam.
Just saw this post.
OUBlogs.
Any progress??
-- Derek

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Eric Carlson - Friday, 15 February 2008, 7:38 AM

Thanks for confirming the image uploading shortcoming with OUWiki.

As of one hour ago, after having flawless Moodle operation for over 3 years of intensive use, a mass amount of wiki activity crashed my (virtual) server. I guess I will need to make the migration to NWiki sooner than I wanted to do it (but I am oh-so-rooting for success with OUWiki if for no other reason than to explore alternative interesting interfaces/features)

Regards,
Eric Carlson

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Steve Wright - Thursday, 21 February 2008, 2:53 AM

For what it's worth I see real issues with both:

nWiki - Used it, love it BUT every time I've installed it or had it installed or an upgrade it's gone hideously worng and the underlying code seems very buggy. This is a REAL issue in that reliabuility is important...

however it's features have allowed some very clever and innovative uses - if the code could be cleaned it's real good.

OU wiki - file attachments? That's be a deal breaker... eWiki migration - essential... OU search...?

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ray Lawrence - Monday, 25 February 2008, 5:41 AM

I can't vote as the choice is closed.

My (attempted) trial of both wikis was disappointing. I apparently created 2 new pages in Nwiki but couldn't edit them. I tried to create a new page in OU wiki but it crashed (Fatal error: Call to undefined function mb_regex_encoding() in /home/wiki/public_html/blocks/ousearch/searchlib.php on line 356)

Ewiki may be creaking but it works! Both of these must do better. My comments are made without the experience of a successful trial of either contender.

There are clearly some wiki power users here, however, most users are bowled over by what the current wiki can offer and just don't need a complex wiki to create effective and useful activities.
OU wiki must have at least the options in the current wiki and must support a seamless upgrade. It already exceeds the current wiki in implementation of some features.
I support the easy to learn, easy to use case made by Tim earlier in the discussion.
Marc you will be sick of me expressing this view again, but my concern persists about the ability of your team to maintain this. Also, having seen you respond with tremendous gusto to new feature requests over the development period, I'm also concerned that this would become bloat-wiki. In fairness your development journey has been in the public domian and the OU's less so.
I find that users are ultimately more concerned about reliability and sustainability than every feature under the sun.

So my vote is for adopting the wiki that is:

Sustainable
Reliable
Provides the best base for organic addition of functionality

(Equivalent feature set and seamless migration being assumed prerequisites).

Average of ratings: -

why ouwiki on wiki.moodle.org is screwed

by sam marshall - Monday, 25 February 2008, 9:56 PM

Just to clarify, the reason for ouwiki not currently working on the test site [you can't save changes to anything - well you sort of can but it doesn't work properly] is that the ousearch block was installed at my, perhaps slightly foolish, request. This turns out to require the mbstring PHP extension which is not enabled on that site, as the error message indicates.

There is no reliability issue in that regard (although there might be a requirement to change ousearch so that it doesn't require that extension, if it were adopted by the community).

I suggested that the mbstring extension should be enabled, or the ousearch block deleted, but I guess the test site is not in use any more so it doesn't matter.

--sam

Average of ratings: -

Re: why ouwiki on wiki.moodle.org is screwed

by Ray Lawrence - Monday, 25 February 2008, 10:37 PM

Ok, thanks for the update.

Average of ratings: -

Re: why ouwiki on wiki.moodle.org is screwed

by Steve Wright - Tuesday, 26 February 2008, 12:51 AM

This is a bit of a recap and hope it doesn't appear as trolling in its ending...

Early on in this Mark Pearson said

"I place a huge amount of attention on what developers are keen to work on. It's what persuaded me that Elgg was the way to go for a blogging system. Without keen developers code has no longevity. So, looking at it from a coder's point of view, would I rather work on adding new features to a cleanly coded system to bring it up to par, and then continue to work on this foundation, or would I be happy to wrestle with student code to port it into Moodle 2.0? This will have implications for long term support. Nwiki may be function rich but if no-one wants to untangle code to fix bugs and ensure tight integration with the core then it will wither on the vine like the present ewiki. It seems to me that the core moodle developers cannot afford to get into the 'Workshop' situation where they are trying to support code which is clearly not up to the standard required."

Sam Marshall asked:

" Wait, I am confused. What are the features the current wiki has that ouwiki does not?

1) Wiki markup

2) Some minor administrative features

3) ...?"

To which I'd add:

file upload (ideally to a sudent repository that the wiki could then act as a customisable, evolvable interface to)
easy rolling back
working search

I agree with Tim hunt's observations:

"3 years work and support is worth something. It has, presumably generated a lot of knowledge about what features work for teachers and students, and what doesn't. That knowledge is far more reusable than the current nWiki code.

Finally, I don't think that the current beauty contest approach to this decision in particularly helpful. It might have been better to start with a survey asking people what features they want in a wiki for use as a learning tool in courses, rather than leaping in and comparing two solutions. But then I am currently studying a course on requirements gathering, so perhaps I currently have an over-idealised view of processes should work."

HOWEVER given as Sam Marshall has said:

"One more thing, remember that even if your favoured wiki isn't selected for use in moodle 2, I expect you will still be able to choose it for your own site. Currently we expect to continue using ouwiki here, even if it's not included in Moodle 2, so it will still be maintained and available for anyone who wants to install it."

There is an option open to have our cake AND eat it by having nWiki core and OU wiki added on...

From my perspective this consultation has 2 issues with it - 1 is the question on the poll "user friendly vs best" - two arguably different dimensons.

The other is the changed status of the discussion in light of continued OU wiki development/availibility - as we could have both isn't the real question in fact (*at the risk of sounding like a troll):

"Is nWiki reliable enough to become core and replace eWiki or should we have OU wiki instead?"

Now in light of Ludo's clear exasperation when he says

"I've been reading so many times that there is the feelling that NWiki is cool but is not stable. I'm sick of it.

THAT IS NOT TRUE"

I can only speak from repeated experience:

1/ I LOVE nWiki,
2/ I fear installing it almost as much as i love using it...!

I won't upgrade it myself anymore as it's been hugely problematic on 3 occasions so I now ask (very nicely) for our hosts at pteppic to install it and then fix the site as a result which has resulted in losing my admin panel, losing site search, losing the entire wiki with a core upgrade and whatever else will go wrong this time when i finish posting this...

I'd like whatever replaces the limited but easy eWiki to have the sophisticated navigation blocks options of nWiki which allow a lot of customisation and innovative use. Ideally i'd like files to go to a central repository that could be interfaced to in different ways (linked to in forums, as files/resources/from the wiki).

Given how complex this post has been to put together I can't wait for a multi-quote function to come in to the Moodle forums a la vBulletin etc!

Steve

Average of ratings: -

Re: why ouwiki on wiki.moodle.org is screwed

by sam marshall - Tuesday, 26 February 2008, 1:54 AM

Just to comment on those missing features:

2. I know about easy rollback, that was in the 'minor administrative features' - it won't be a problem to add and we will probably do that (eventually) even if it doesn't go into Moodle core.

3. Search does work. It works great! Well, okay, there are some limitations - but fundamentally it's a completely indexed fulltext search, so for example it's feasible [and actually implemented, though only as a backend] to search in one go through every wiki that a student has access to. There isn't a problem with search working, there's a problem with it requiring a particular php extension that isn't on wiki.moodle.org.

and finally feature 1 (attachments) - yes at the time I had written the first post I didn't even realise that ewiki supported attachments! Well I knew it did but I had never got it to work... So yes you are correct I missed that one, and this would need to be added if ouwiki were included in core, which wouldn't be a big deal. However I agree it would be better to handle attachments in some kind of repository-like fashion. On the other hand it is not a typical portfolio (files that a user places in a wiki are not really the user's! they logically belong to the course like the rest of the wiki's text content does, this is what ewiki/nwiki attachments achieve).

Here at the OU we plan to handle this by adding an option to the image upload window in an html editor so that you can upload [initially] images to any tool, not just wiki, and they will be resized automatically if needed, stored alongside the course from the point of view of backups etc., and so on.

If some kind of similar approach is adopted by core moodle then it may remove the need to support attachments specifically in the wiki (depending on whether it also allows other files like .doc or whatever you want to upload to your wiki). So I wouldn't expect to see the wiki itself - whichever one - becoming a vastly complicated repository, rather I expect it to just duplicate a basic attachment feature as necessary to support ewiki upgrades.

(And to comment on the 'multi-quote' forum feature you asked for - ARGH PLEASE NO GOD NO - we actually have that feature in our slightly-customised forums, it's called 'summarise', it's only available to tutors thankfully, and it's a god damn mess.

Then again, perhaps it could be implemented better... however I do tend to think that with threaded forums it's almost always better to make several small replies. Of course I have a particular opinion as to how forums should work...)

--sam

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Martin Dougiamas - Tuesday, 26 February 2008, 1:52 PM

Well, I think the overall result of the votes and the discussions seems to be oriented towards working on nWiki (hope most of you agree!) so that's what we'll be doing. Just a warning though, we'll be refactoring nWiki quite a lot to bring it up to scratch before handing it back to Ludo's team for maintenance.

It would really really help if everyone could complete this list to help give us an overview of what it should end up like:

http://docs.moodle.org/en/Development:Wiki_features

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Tuesday, 26 February 2008, 6:29 PM

Cool

Thanks to all those who voted for either wiki and have given their feedback. And thanks also th Sam for givin'g us such a kick in the butt. I should have whatched more the code my students where writting, Pigui has been telling me for a lot of time that we should refactor (we tried once but many things came in the way) My mistake ojo amoratado

. Sam I hope to meet you in a moot and buy you a beer or a mojito if we meet ins spain (mojitos are mandatory in spanish moodlemoots )

Now there's a lot of work to be done to get the wiki moodle deserves.

In the next week or so we will send to the moodle contrib cvs the latest version of nwiki for 1.9. with suport for gradebook and tags. Then we will stand down and wait for the refactoring.

We are at your disposal for anything you should need.

Ludo

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by sam marshall - Wednesday, 27 February 2008, 2:06 AM

Congrats to the nwiki team.

And congrats to me as well for having less work to do

I'm a little disappointed [obviously not at all surprised!] but given that no significant OU-developed feature has ever been adopted in moodle core*, it's really no different from what I spend the rest of my time doing, so I'll live!

As already mentioned, ouwiki will continue to be available as contrib so the few people who preferred it will still have the option to use it. Because it doesn't have an upgrade feature, you can safely use it alongside 1.9's ewiki, or alongside 2.0's nwiki, without affecting anything.

--sam

* A number of minor OU-developed features have been included, though. And some things that we didn't develop but did pay for, such as the ever-popular roles system... ;)

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Martín Langhoff - Wednesday, 27 February 2008, 5:58 AM

Congrats to the nwiki team.

And congrats to me as well for having less work to do

I concur! Congrats to all around. Now, the NWiki team is in for a biiig rewrite I think

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Julian Ridden - Wednesday, 27 February 2008, 5:44 PM

I do think Nwiki is the right decision. Good to see it won the vote. Will be awesome once it is tidied up (easy for me to say since I m completely incapable of doing it).

I have no fear that we will continue to see more awesome OU code in the future.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Séverin Terrier - Wednesday, 27 February 2008, 11:46 PM

Congrats to all *wiki developpers for the work done, and to come

I think that this forum's introduction can now be changed

Average of ratings: -

Nwiki vs OU Wiki - in algebraic form

by Steve Wright - Wednesday, 27 February 2008, 9:22 PM

Summary of decision:

(Core = (nWiki + major code rewrite)) + (OU Wiki = (non-interfering system + continued development))

= (having cake) + (eating it)

=

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Thursday, 28 February 2008, 2:37 AM

Thank you guys!
The moodle community is a place where is worth spending time and energy... now there's work to be done!
L.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by João Fernandes - Tuesday, 11 March 2008, 7:43 PM

Parabéns Ludo e à tua equipa wink

(I believe you will understand the words above, as catalan as some similarities with portuguese. For the non-speaking, it means congratulations to Ludo and his team.)
Finally we will have a nice wiki to work with!
Sam, thank you also for your work.
Regards
J

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ulrike Montgomery - Thursday, 28 February 2008, 1:18 AM

Congratulations, Ludo

At my school we are looking forward to using the NWiki and I will also install the OU wiki - so the teachers will have a good choice.

I'm looking forward to meeting you soon in Heidelberg at the German moot - We don't have mojitos but I'll buy you either a Wein or a Bier (both mandatory in German moots).

---Ulrike

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Ludo (Marc Alier) - Thursday, 28 February 2008, 2:33 AM

Thanks Ulrike,
I'm really looking fordward to come to Heidelberg. I'm in the organization of the Spanish moodlemoot and will be great to see how you guys do it.
I'm sure that german beer and the wein (I love the ice wine of the Mosel) will be a great substitute for mojitos!!!
L.

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Juan Marín - Thursday, 28 February 2008, 4:28 AM

OH!!! I came so late in this discussion, but my vote was for NWIKI. Features and support were like I have need during this 3 years: a very good work of DF TEAM . I'm very Happy to see that NWiki would be the "NEW 2.0 Wiki". approve

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Paolo Oprandi - Thursday, 28 February 2008, 5:01 AM

I sure there is a touch of heart over common sense in this decision, but I am glad the romance of moodle is still alive!!!

Average of ratings: -

Re: Voting on NWiki vs OUWiki

by Julian Ridden - Thursday, 28 February 2008, 11:32 AM

Romance is like chivalry. It isn't dead, just a prolonged coma

Average of ratings: -