I'm very excited about this module and have watched it grow with anticipation.
I look forward to documents that students build with wikis, but probably even more, the chance to provide in-line comments to student wikis, thus helping them revise their writing. The versioning aspect will be just great.
My only fear is the jargon and the remaining wiki feel. I appreciate the way that wiki links are disappearing and being replaced by Moodle help buttons, etc., but I wonder whether it is time to be more radical and to lose more of the wiki jargon. Maybe it is too soon in development and I'm talking about superficial language issues, but I'm still a bit intimidated by this interface. Similar, perhaps, to the way that I'm spooked by the complexity of the workshop module.
Let me start with this suggestion: why not call it the collaborative writing module? Do we benefit from teaching students about the wiki concept/history at all? ... should they care?
What about the drop-down menus? Wikis are flexible, but users need the simplest functions in the clearest spaces.
How about this in the bottom right corner of the /moodle/mod/wiki/view.php?id= page?
Maybe the History link could open up in a new page (like a help link). This window should simply state who made the revisions and when. Perhaps, the history that is used in the quiz module (/moodle/mod/quiz/report.php?id=) could provide a friendlier format.
Maybe admins would have more control:
where the third link could open up another new page (like a help link) that includes the remove pages, etc..
This leaves only the "choose wiki links" menu to translate/relocate. Couldn't those be available via a small statistics icon? Again, a pop-up page could offer a list of data about "orphaned pages" etc., but I would much rather avoid having to see or teach lingo. (Another possibility is that this info could be linked from the History help page).
Finally, (I am a real pain), I was hoping to lose text like this:
I like the clean look of moodle/mod/journal/edit.php?id=. Especially with the "save changes" button at the bottom.
Thanks,
Tom
p.s. Speaking of buttons, I've never been a huge fan of the preview (I suspect Ger will disagree). Everything is so easy to edit again, it just seems like an unnecessary feature.
p.s.s. I know the wiki naming convention will probably have to remain, but it is weird enough that it would be great if it were the only foreign item in the module...
p.s.s.s. Ignore this post, if it is frustrating. I sure appreciate the potential of the wiki functionality in any form.
I like the name collab writing tool (I agree: do not bother them with a Wiki concept and then have to explain weuse it a little bit different.) For the same reason I renamed lesson in Action Matrix /FlashCards..
In Swiki I had no preview, so I had to save any trial to view it AND when I (or somene else) was working on the same page was pressing the save button, the slowest one got a conflict message: In eWiki the page gets blocked for others when someone opens it for editing: fantastic!! (And then the preview is very useful: until that user saves the page really, it stays blocked. Makes life for a teacher much easier..)
Organise Pages? Everyone can do that by cutting outr a piece of text (including CamelCases) and paste it on another page: should work there too..
A teacher can insert a comment starting with his name
(TEACHER TOM: Why not put in a description etc...),
A student can read, use it, and remove it.
You need a commentbox on the moment that the student can lock the page for others.
Not frustrating, Tom, useful.
Comments can be added in-line for now. With HTML, you can differentiate them. I am planning on adding a more formal comment mechanism, like some other wiki products, but I'm not sure when I'll get to it. Also, I'm not sure whether I should try to integrate it with the existing forum mechanism or not.
The 'wiki way' is not complex - just the opposite. In fact it was created to be used by people who didn't have a lot of time to learn new technologies. The basic premise is to create a page, name it. 'If you name it, it will come.'
I don't have a problem renaming it - you can call it what you want in your language file. But it is an implementation of the ewiki open source, so I think we should at least acknowledge that.
I like your menu ideas; looks cleaner. Michael and I will look into those.
I haven't looked at the journal, but what would you want instead of the 'Edit this page ...'?
I think the preview should stay. The wiki naming convention must remain, but you don't need to use it. If you enclose any word(s) in '[]' (square brackets), it becomes a page.
mike
Thanks, Mike for your comments.
I think you are already there with inline comments. I plan to just use a different font color when I edit the page. Also, I have an ambitious scheme to create a kind of pop-up palette of "common composition, grammar, and punctuation errors" (maybe ones that are stored in a glossary and that can be inserted in the way smileys are added in a non-html window).
I hear what you are saying about linking a forum to a wiki for comments. That is one way (I was thinking about it myself when I posted feature request, bug 463). Another way might be to create a kind of glossary (contained to the particular wiki), that allows you to highlight words or phrases and to create a kind of annotated comment on the side. (My feature request, bug 1341 talks about this a bit... but I'm sure it would be a pain to introduce...)
I agree with the idea that wiki-way editing is far simpler than html mark-up, but I suspect the HTML editor is even simpler.
As for the difference between the edit pages of the wiki and the journal, I think, simply, that when you reach the editing moment in wiki, it is odd to look at a line that says "edit this page." The user has already clicked the edit button, he is currently editing, it seems like a disorienting reminder to do so again. I'm probably saying this in a really convoluted way -- please excuse me.
Thanks again, Mike, collaborative writing is a critical element of Moodle that continues to transform possibilities for teaching.
-Tom
p.s. I approached an HTML designated wiki in your last build with a browser that doesn't allow for an editor. It hung. Is there a way for it to recognize such browsers and to offer up the html code instead?
I think you are already there with inline comments. I plan to just use a different font color when I edit the page. Also, I have an ambitious scheme to create a kind of pop-up palette of "common composition, grammar, and punctuation errors" (maybe ones that are stored in a glossary and that can be inserted in the way smileys are added in a non-html window).
I hear what you are saying about linking a forum to a wiki for comments. That is one way (I was thinking about it myself when I posted feature request, bug 463). Another way might be to create a kind of glossary (contained to the particular wiki), that allows you to highlight words or phrases and to create a kind of annotated comment on the side. (My feature request, bug 1341 talks about this a bit... but I'm sure it would be a pain to introduce...)
I agree with the idea that wiki-way editing is far simpler than html mark-up, but I suspect the HTML editor is even simpler.
As for the difference between the edit pages of the wiki and the journal, I think, simply, that when you reach the editing moment in wiki, it is odd to look at a line that says "edit this page." The user has already clicked the edit button, he is currently editing, it seems like a disorienting reminder to do so again. I'm probably saying this in a really convoluted way -- please excuse me.
Thanks again, Mike, collaborative writing is a critical element of Moodle that continues to transform possibilities for teaching.
-Tom
p.s. I approached an HTML designated wiki in your last build with a browser that doesn't allow for an editor. It hung. Is there a way for it to recognize such browsers and to offer up the html code instead?
Wiki is another way of thinking about collab webpage creation, I support that idea.
Suggestion: Why not change the label "How to Wiki" into "WikiWhat"
- you refer to the attitude of first-timers
- you show your first CamelCaseWord, the soul of Wiki
The route I've taken with the Wiki in my company is to give it a name and acknowledge that it is a Wiki i.e. "CollabWriting is what we are calling our implementation of a Wiki." In general disscussion we would then call it CollabWeb, CollabWriting pages, etc. Many of our pages and actions have been retitled to suit us too(we don't use the title in action-links for example). Our help pages talked only about what WE have decided to do until reccently when, with the increase of Wikis in the news, (see Business Week, June 7th, 2003, "Something Wiki this Way Comes") we realized that we could talk about the wikiness of the system. I reccently gave a presentation to about half the company which was partially focused on "The WikiWay," and included topics like refactoring and navigation by backlinks.
I would suggest a similar approach, call the module whatever you like, but acknowledge that it is a Wiki so that users familiar with Wikis can understand that they have one. Don't explain Wikis too much, but include some links for those that care like a link to Wards Wiki or the WikiPedia. Make pages with more detailed information on topics like Refactoring available on the Moodle site so that users who find a need for them can add them to Wikis that have developed enough of a culture to use them.
on the postscripts:
* Preview is great and happens to be where eWiki links in the spell checker. Also some users will be nervous with the markup if every variation they try is saved.
* You can remove the Wiki naming convention, but I wouldn't. WikiWords are easy to guess and remember leading to good references in long-lived Wikis (like a class wiki carried forward from year to year).
* This post is just the kind of reaction I got from my boss when I first said the word "Wiki," He has since come around. Definately the Wiki plugin should blend with Moodle in every way possible, eWiki is designed for just that kind of embbending and we would accept patches needed to make it more embbedable. Some of the strangeness may become comfortable and useful with time.
AndyFundinger
I would suggest a similar approach, call the module whatever you like, but acknowledge that it is a Wiki so that users familiar with Wikis can understand that they have one. Don't explain Wikis too much, but include some links for those that care like a link to Wards Wiki or the WikiPedia. Make pages with more detailed information on topics like Refactoring available on the Moodle site so that users who find a need for them can add them to Wikis that have developed enough of a culture to use them.
on the postscripts:
* Preview is great and happens to be where eWiki links in the spell checker. Also some users will be nervous with the markup if every variation they try is saved.
* You can remove the Wiki naming convention, but I wouldn't. WikiWords are easy to guess and remember leading to good references in long-lived Wikis (like a class wiki carried forward from year to year).
* This post is just the kind of reaction I got from my boss when I first said the word "Wiki," He has since come around. Definately the Wiki plugin should blend with Moodle in every way possible, eWiki is designed for just that kind of embbending and we would accept patches needed to make it more embbedable. Some of the strangeness may become comfortable and useful with time.
AndyFundinger
(Hmm, I thought I'd already written a reply to this but I must have closed the tab before posting it. Anyhow ..)
Thanks, Tom. I agree that there is a lot that could be done to polish and clarify the interface and taking it a feature at a time seems to be a good way to do this. Keep up the suggestions - you're very much in the "zone" for using this module to it's fullest.
However, I'm not sure about calling it Collaborative writing, firstly because it seems the name Wiki is gaining some traction now ... but also because there are probably other things that it can be used for apart from collaborative writing, such as simple publishing or individual webs.
Thanks, Tom. I agree that there is a lot that could be done to polish and clarify the interface and taking it a feature at a time seems to be a good way to do this. Keep up the suggestions - you're very much in the "zone" for using this module to it's fullest.
However, I'm not sure about calling it Collaborative writing, firstly because it seems the name Wiki is gaining some traction now ... but also because there are probably other things that it can be used for apart from collaborative writing, such as simple publishing or individual webs.
Since we're making suggestions, I would like to propose de-CamelCasing the headers on pages by adding spaces between the words.
It makes sense to use the CamelCase to make the links but after that do we need to see them?
It makes sense to use the CamelCase to make the links but after that do we need to see them?
I think it's usefull to show them as an example to beginning wiki-users. It reminds them, every time they see one, how to and how easy it is to start a new page, to avoid too long and too off-topic pages.
I like that: In English all the words of a header may start with an uppercase, In Dutch it is habit to write only the first word in uppercase (but do not change this for me )
Or let the user choose how a CamelCaseHeader will be presented ?(checkbox options again?)
[OT]: Martin, How can I activate that file attachment option on a Wiki page?
Exactly, Martin. 
This would hide the engine under the hood (bonnet?) of the car better.
I know CamelCase is a swift way of creating pages, but why would the page have to be called SomethingSilly forever? Moreover, when other parts of Moodle link to wiki pages, it will be strange to have to remember two conventions. (e.g. Now where was that page? was it Threedogs or Three dogs?).
Why bother with the convention -- after creation of the page -- (especially when teaching language to students), when Moodle can turn it into proper grammar? Students will take every opportunity to slide their language skills, including (r u there) shortcuts.
-Tom
I know CamelCase is a swift way of creating pages, but why would the page have to be called SomethingSilly forever? Moreover, when other parts of Moodle link to wiki pages, it will be strange to have to remember two conventions. (e.g. Now where was that page? was it Threedogs or Three dogs?).
Why bother with the convention -- after creation of the page -- (especially when teaching language to students), when Moodle can turn it into proper grammar? Students will take every opportunity to slide their language skills, including (r u there) shortcuts.
-Tom
NO Tom, the VISUAL presentation will be Camel Case Word,
but the engine can better stay CamelCaseWord.
Why? Because no other system is using CamelCase for that purpose. If you invent another mechanism,like a word between two **, then that interferes with the writing of users that use ** to *stress* the meaning of a word, etc... (If I copy a text from Brian to my old Swiki I have that problem)
Any improvement will end up in more work for the user. That user must realise that he is in another area: page versions and previews are only supprted in Wiki, etc..
In summary: you have the Moodle area and the wiki area (o yes, and the SCORM area)
I think in fact you are talking about the same thing as Tom (the engine would not change ... only the display of page titles)
Tom was also referring to the new filter that creates links throughout all of Moodle to Wiki pages. These should definitely NOT be searching for CamelCase.
Tom was also referring to the new filter that creates links throughout all of Moodle to Wiki pages. These should definitely NOT be searching for CamelCase.
Can you explain me how the search will work then? I thought it will search the database and there the words will be stored as CamelCases.... or are you thinking of a trick to do a conversion before the store? And you do a reconversion again when the page opens in edit-mode?
The TITLE of a page can be converted, and in VIEW MODE you can show the words as Moodle Hyperlinks with spaces, but all the in-line references on that page in EDIT MODE should stay CamelCases, otherwise you make it very complex for users (it would interfere with the functions of the HTML-editior that has also a hyperlink function ) and you would drift away from the concept Wiki.
As you say, we will see wikis more and more in the future. (And I think like Tom that the HTML-editor will replace the easy-editing-folklore of Wiki also in the other wiki-products, but this very clever CamelCaseForLinksInEditModeIdea will surivive, so stay compatible in edit mode..)
First off, for a wiki, the page title cannot change after is has been created. A wiki page name is it's identity. To do this would break all the links to it. This is equivalent to changing the file name of an HTML page - you need to go back and change all the links. Or changing the MySQL 'id' number of a module. (So Tom, once named SillyPage, always named SillyPage).
We could de-camelize 
a page title before displaying it as a page title, but we would have to make assumptions. In other words, if the title had mixed case, we would have to automatically assume that it was CamelCase, and not something else.
Keep in mind, you can now name a page without using Camel Case, as long as you enclose in '[ ]'.
I don't think its a good idea to display the page title as anything other than what it was named. I think that would be too presumptious of us.
As to using CamelCase, I think we need to always have it. It is the backbone of a Wiki, even if it isn't needed any more. And, some people actually can learn it faster than teaching them to use square brackets (really).
mike
Wait a minute, are you saying that Tom already can do what he wishes,
as long as he embraces his [Page title names with spaces] with brackets?
as long as he embraces his [Page title names with spaces] with brackets?
I think I've been aware of this idea. And I'm certainly good with it. I really also like the idea of creating new pages on the fly by typing WordsTogether, too.
Sorry I've been incoherent about my wishes. I think they have been evolving as I've been learning from this discussion.
I now wonder whether the CamelCase could be parsed (as it is created) and stored as a title like "Words Together" -- just like a page title that was created between brackets[]. That way, it wouldn't STAY funky in the Moodle system. It would just have a funky birth.
Again, I think the best modules allow people to think they are doing something simple: maybe writing a journal. Then, in time, the users realize that the journal can be versioned, can be linked, can create additional pages on the fly...wow! But if a user sits down at a wiki with a big dashboard of flight controls, I suspect there will be a kind of paralysis. Likewise, a dashboard of permanently FunkyTitles SuddenlyMakes a SimpleJournal FeelLike a ForeignVehicle.
Mike, you are ever-patient to listen to any of these ideas. I'll step away from the machine and let others share view points.
Thanks so much,
Tom
Sorry I've been incoherent about my wishes. I think they have been evolving as I've been learning from this discussion.
I now wonder whether the CamelCase could be parsed (as it is created) and stored as a title like "Words Together" -- just like a page title that was created between brackets[]. That way, it wouldn't STAY funky in the Moodle system. It would just have a funky birth.
Again, I think the best modules allow people to think they are doing something simple: maybe writing a journal. Then, in time, the users realize that the journal can be versioned, can be linked, can create additional pages on the fly...wow! But if a user sits down at a wiki with a big dashboard of flight controls, I suspect there will be a kind of paralysis. Likewise, a dashboard of permanently FunkyTitles SuddenlyMakes a SimpleJournal FeelLike a ForeignVehicle.
Mike, you are ever-patient to listen to any of these ideas. I'll step away from the machine and let others share view points.
Thanks so much,
Tom
Tom writes: I now wonder whether the CamelCase could be parsed (as it is created)
and stored as a title like "Words Together" -- just like a page title
that was created between brackets[]. That way, it wouldn't STAY funky
in the Moodle system. It would just have a funky birth.
At first glance, this sounds like a great idea to me!
In addition, I prefer the [brackets method] so much more that I think the CamelCase linking should be severely demoted in the documentation. I'm all for keeping it so old-time Wiki-enthusiasts can continue to use it, but it should really not be presented as the main method.
Speaking of which - who wrote this in the How to Wiki docs!?
"While language purists hate Wikis for that naming scheme, it is very common in the
computing world and well known to most programmers."
At first glance, this sounds like a great idea to me!
In addition, I prefer the [brackets method] so much more that I think the CamelCase linking should be severely demoted in the documentation. I'm all for keeping it so old-time Wiki-enthusiasts can continue to use it, but it should really not be presented as the main method.
Speaking of which - who wrote this in the How to Wiki docs!?
I promise I didn't touch the wiki docs! 
That was from the original help file. Sounds like a translation of a translation. I massaged a lot of the text - but not all of it.
Its basically trying to say that wiki page names are based on programming variable naming schemes.
It probably, really, doesn't have a place in this document... 
The idea of parsing the CamelCase into Camel Case upon creation, sounds interesting, and probably could be done, but I think that makes it even more difficult than using square brackets. Either we are forcing the writer to stop midstream, and remove spaces of titles they want to use as pages, just so those spaces can be reintroduced, or we are changing what they write. I really think that teaching them the square brackets method will make more sense. They still have to do a bit of backtracking, but they don't need to change what they've written.
I'll take a look at demphasizing CamelCase in the help files.
mike
There are two significant problems with parsing CamelCase at display time, you may avoid these, but I suggest thinking about them:
If you do go this route, consider doing a save-time mangle with an edit_save plugin to look at the page text being saved and replace any simple CamelCase with ["{Target Page}"{TargetPage}]. That would give authors full capability to correct the mangling and allow the plugin to be turned off at anytime without affecting current pages. See the /plugins/feature/timestamp.php plugin for an example edit_save mangler.
AndyFundinger
eWiki Developer
- MyPage and [My Page] would be displayed the same. Users who wish to make a link would have to hover around trying to find out what it is they need to link to, even in the normal case.
- Would you want to display EUCouncilofMinisters as "E U Councilof Ministers?" "EU Councilof Ministers?" Teaching people to manage the mangler might prove non-trivial. I use a similar mangling on titles(not text) for my Wiki and the incidence of mis-mangled titles is rather high.
If you do go this route, consider doing a save-time mangle with an edit_save plugin to look at the page text being saved and replace any simple CamelCase with ["{Target Page}"{TargetPage}]. That would give authors full capability to correct the mangling and allow the plugin to be turned off at anytime without affecting current pages. See the /plugins/feature/timestamp.php plugin for an example edit_save mangler.
AndyFundinger
eWiki Developer
First let me say that I like the concept of a Wiki. I like its idealistic roots and the monitored anybody can edit mentality. I think it is a concept deserving recognition and as such should keep its own name: wiki.
For any users it takes a bit of time to learn how to use a wiki. The idea of creating pages on the fly, using certain codes to do the markup of the page, etc.
I do not think that there is a lot of difference in the difficulty of teaching somebody to use CamelCase or teaching them to use brackets. Both of them are not intuitive and need to be taught. I would probably go for the method that is used in most other Wikis on the web,
One thing I will never get used to though is the way that CamelCase looks on the page. I can't stand to see the titles of my pages and do not think they will be taken seriously by anybody who is not in the know about Wikis.
I do not have enough knowledge about how the wiki module work, or how things are stored in the database, but there must be some sensible way of showing Normal Titles in display mode and WeirdLookingTitles in edit mode.
For any users it takes a bit of time to learn how to use a wiki. The idea of creating pages on the fly, using certain codes to do the markup of the page, etc.
I do not think that there is a lot of difference in the difficulty of teaching somebody to use CamelCase or teaching them to use brackets. Both of them are not intuitive and need to be taught. I would probably go for the method that is used in most other Wikis on the web,
One thing I will never get used to though is the way that CamelCase looks on the page. I can't stand to see the titles of my pages and do not think they will be taken seriously by anybody who is not in the know about Wikis.
I do not have enough knowledge about how the wiki module work, or how things are stored in the database, but there must be some sensible way of showing Normal Titles in display mode and WeirdLookingTitles in edit mode.
Tom, your suggestions on how to make the user interface of the wiki pages more user-friendly by removing the drop-down lists are so emminently sensible that I have submitted a feature request for them on the bug tracker, bug 1539.
buttons instead of dropdown could do the job..
they could, but Tom's suggestion of making the interface the same as in the forum module seems much more convincing.
But it is a different environment... So, how do you cue to the user that he is in a different area with different rules?? (It should look different, it should look wiki..)
Why should it "look wiki"? Users need to know that they can edit the page and that they can look at its history. Quite straightforward. Why make it look exotic?
Wiki is more then writing a document, it is collab writing, together with others, that brings in all kind of mental shifts, so give them cues for this mental shift. (Page locking, versioning, back to a previous version of my page before Gustav changed all my work etc..
OOps: Gustav and W found something very irritating: The Documentation to the wiki says, that in HTML-Mode no WikiWords are parsed. Why not ?
Is someone already working in this field or is it just a problem of the documentation ?
We should take care that wikiwords are not parsed inside of Links, but outside it should be ok...
Is someone already working in this field or is it just a problem of the documentation ?
We should take care that wikiwords are not parsed inside of Links, but outside it should be ok...
The reason why the wiki documentation says that in "HTML only" mode no WikiWords are parsed is that that makes the most sense. I think the point of having a "HTML only" mode was so that it works the way HTML always works.
The power of the HTML editor is that one can copy bits of web pages and other documents and paste it straight into the editor. Now, as the wiki documentation says rightly about CamelCase: "it is very common in the computing world". So it can happen that the bit one cuts and paste contains CamelCase words. It would be very annoying if these are all converted to links to new pages.
People who want CamelCase converted to links can use the "Safe HTML" mode. Or if someone absolutely requires it there could even be a "HTML with WikiNames" mode.
And new pages are created by using the [Link Here] method ?
You know, I am a big fan of CamelCase
You know, I am a big fan of CamelCase
Hello All!
Sometimes I think I am getting a handle on this Wiki stuff and then at other times I cannot really understand what is going on with the mod. Anyway, for those of you who get lost with the jargon at times I found a page regarding "CamelCase". If anyone has a better reference please post it,
http://c2.com/cgi/wiki?CamelCase
If anyone has the time or the chance, would you please take a look at an issue posted yesterday,
Wiki is acting a bit Wacky
http://moodle.org/mod/forum/discuss.php?d=8767
Thanks in advance.
WP1
Sometimes I think I am getting a handle on this Wiki stuff and then at other times I cannot really understand what is going on with the mod. Anyway, for those of you who get lost with the jargon at times I found a page regarding "CamelCase". If anyone has a better reference please post it,
http://c2.com/cgi/wiki?CamelCase
If anyone has the time or the chance, would you please take a look at an issue posted yesterday,
Wiki is acting a bit Wacky
http://moodle.org/mod/forum/discuss.php?d=8767
Thanks in advance.
WP1
I've never run eWiki in HTML only mode, but I will note that new pages do not require any recognized link to create. Just edit a page that doesn't exist (view with auto-edit on) and it will be created when you save. Thus <a href=script.php?MyNewPage></a> would be a fine way to create pages. Is there anything you need for html markup that SafeHTML doesn't support? If you are tracking the changes in our CVS you'll notice that the flags on the render kernel are being adjusted and perhaps we could get a set of flags coded in to meet your needs.
AndyFundinger
AndyFundinger
Michael, I am not trying to take away your CamelCase in all modes. Only in the "HTML only" mode. And yes, leave the [Link Here] method.
I have to disagree that CamelCase is really that widely used in programming, and that there is really a problem allowing this in the HTML editor.
Firstly, this would mean any Wiki in existence would have the same problem when used to display/discuss programming code... and secondly, even if you do paste in code that contains CamelCase it will just show little questionmarks beside them (not a big problem). Maybe we can add <nolink> tags in Wiki too, to do the same thing as other auto-linking in Moodle?
I don't really want to promote CamelCase but I can still see the sense in retaining it for the wiki-heads.
Firstly, this would mean any Wiki in existence would have the same problem when used to display/discuss programming code... and secondly, even if you do paste in code that contains CamelCase it will just show little questionmarks beside them (not a big problem). Maybe we can add <nolink> tags in Wiki too, to do the same thing as other auto-linking in Moodle?
I don't really want to promote CamelCase but I can still see the sense in retaining it for the wiki-heads.
The programming language thing is a holdover from the Pascal/C days. But it really has no relevence to a Wiki now - only as an historical footnote of why it came about.
Whether or not you want to use Camel Case, I think it has to remain as is, with its functionality. Otherwise, we really are opening a can of worms.
Besides, any automatic link (camel case, [], or !http) can be prevented by prepending it with an '!' or a '~' character. That character tells the wiki engine to not link the following text.
mike
I appear to have been particularly unclear in my postings in this thread:
I am NOT proposing to take CamelCase away from anybody. I was only saying that there is no reason why the wiki should not ALSO have a "HTML only" mode in which the formatting is as close to what the user is used to from other places in Moodle as possible.
I was not actually concerned with programming code. Rather I cut and pasted some text from a web page as I am used to doing in the HTML editor. This page happened to have words like WeBWork and LaTeX on it.
Of course it was possible to fix this by putting ~ in front of all those names. But it would have been more convenient if the HTML only mode had left the HTML as it was.
Hi Gustav -
I just re-read the help file on HTML-Only mode, and it seems to say what you are saying. However it works differently. It allows HTML tags and wiki tags.
My preference is for the way it works. I like being able to use both formatting methods. The HTML editor is much more familiar to a lot of my users and results in more success with formatting the documents. The extra wiki formatting codes (bold, italics, etc.) I could live without, but the simple linking and page creation mechanism is critical. Its much easier to teach people that they can create and link new pages just by naming them (whether in camel case or in [] ).
As for cutting an pasting, again, because this is a wiki (not an HTML document), I expect wiki link codes to work as wiki links when I paste them in. That way, I could actually create wiki structures off-line, paste them into the wiki, and have them work as expected.
So, for me:
- HTML editor for easy text formatting,
- wiki words for easy link definition.
mike
How about having two modes:
"HTML and Wiki" provides both HTML and Wiki markup side by side and allows link creation with both CamelCase and [..]
"HTML only" provides only HTML markup and allows link creation only with [....]
This way we will all be happy.
If you do, please use <nolink /> for those of us using the the editor on MSIE (which converts everyting to XHTML
.
Three comments:
- If I import pieces with CamelCases in it then eWiki will only convert them After I click on that questionmark oneby one.
- If I reorganise a wiki by cutting and pasting pieces of webpages including CamelCases and [your links] then the editor should not interfere with that!!
(eWiki would lose a very powerful flexilbilty if it would be stripped or so!) - It still would be wise to differentiate between internal links and external links: If I change the name of an internal page, the references on many pages are also changed? How do I recognise them quick in the forest of the external links? Maybe by their special back?
I use it in HTML-Mode almost exclusively. And I can create links on the fly with both CamelCase and '[]'. I'm sot sure why the documentation says this.
I see no reason to not do this. Its still a wiki, with extra formatting.
mike
In the "HTML only" mode there should be no extra formatting. Otherwise the mode shouldn't be called "HTML only". Having wiki formatting in the "HTML only" mode is a problem when cutting and pasting from other documents into the HTML editor. One looses the nice feature of the HTML editor that it preserves the formatting of the pasted text.
I have no objections to introducing an extra mode "HTML and Wiki", although I don't quite see the usefullness of having both markups available at the same time.
Hi Gustav:
One page with two or more users at different levels of sophistication vis a vi HTML.
I have not experimented with the HTML editor as I have yet to get access to a Moodle running a WIKI module.
Thanks,
John
We have now several ideas with pros and cons, 2 bug reports and a feature request. How is the process for us developers in such a situation ? Do we have something like a voting ? Shall we suggest some possible implementations ?
Hi Michael -
I've been waiting for the dust to clear to figure out where we are.
I'm going to start a new discussion to summarize what's been requested. Can you check it, and see that I've captured everything?
mike
It is your Module, so you have the right to choose.
(I only hope that you stay compatible with other Wiki's, especially phpWIki.. )