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
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
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
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.
It makes sense to use the CamelCase to make the links but after that do we need to see them?
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?
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)
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
as long as he embraces his [Page title names with spaces] with brackets?
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
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."
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
- 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
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.
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.
You know, I am a big fan of CamelCase
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
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.
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.
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
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.. )