Wiki on a Stick Official Forums

I'll be playing with UbuWiki all day, I'm sure!

Do we have a way of storing and passing variables, like tracking answers on a quiz? One way, I suppose, would be to track page access sequences through the history, and construct the sequences so that the route taken determines the success of the journey. But it would be slicker to store and update some variables -- treasure, lifepoints, keys, weapons (in the mode of adventure games). This would allow the course designer to control the student's access to information (and remediation!) based on the student's knowledge and progress through the course material.

UbuWiki was a big source of inspiration for me. The first thing that impressed me was the use of graphics all over. I hadn't figured out how to get graphics into my wiki because the embedding isn't working for me. I ended up using Base64 to encode the images and then paste the resulting [g]img[/b] tag containing the code into a page named after the image. I then do an [[Include::Images::ImageName]] tag wherever I want the image to go. How exciting a wiki can be with some graphics! (:

Just yesterday I spent the day creating an idiot-proof version of my Book on a Stick because some family members found the actual version too difficult to use. I riuthlessly removed most of the help pages, all but one of the example pages, all access to settings, wrote a one-page graphical help section, created a link to a listing of a few additional more detailed help pages in case they're feeling ambitious, and put some large buttons in the menu. I then removed the ability to edit the menu entirely. Now it's a rather crippled, but fully functional writing tool, and I figure if they get frustrated with its lack of ability, they can graduate to the fancier version.

Storing and passing variables is definitely doable, and it depends on what you want to do with them. At first I was thinking you could put a hit counter on each page, which would tell you which pages were being accessed. I highly recommend StatCounter as a hit counter. I've used it for years and I really like how detailed the information is. Not only does it tell you which pages were hit, but it tells you how long a person was on them. But when you mentioned actual control over access, that requires a bit more creativity.

I suppose you could put in a JavaScript quiz on each page, or at the end of each section, and only if they get the right answer(s) will the wiki move on to the next section. Of course the only problem with this is that they could accidentally get the right answer(s) without actually knowing them, so there are always holes. (:

UbuWiki is stunning! A 4.5Meg WoaS, with embedded graphics. Amazing! I feel appropriately humbled. Of course, based on years of experience, the feeling will soon pass....

jmuelver wrote:

Handling accidental right answers is just part of the instructional technology package. No problem..

I figured as much. I suppose you guys have some sneaky way of knowing we were only guessing. (:

jmuelver wrote:

I think the variables thing can be done with an associative array. Tagging the value with the current page would be useful, too. That's something I've done with EXE-type instructional programming. I have to get deeper into WoaS, and wring it out a bit to keep from re-inventing what's already been done better than I could.

The source code is commented, so the more time you spend poking around in there, the more familiar you'll become with it. I tend to add comments of my own when I figure out something about the source. That way I can find that section again just by doing a search for Little Girl.

jmuelver wrote:

But, you know, a simplified authoring system would be a good teaching tool, especially for teaching teachers how to use it.

Probably the best approach is to put the absolute necessities (how to create and edit a page, and how to navigate in the wiki) in their face immediately by placing simple instructions on how to do those right in the introductory page. From there, or from the menu, you can have a link to additional, more detailed help for those who want to learn more.

If you're interested, I can put up a link to the idiot-proof wiki I created for my family members who resist reading instructions, but keep in mind that that version is severely crippled on purpose, so it wouldn't do for your purposes. (:

jmuelver wrote:

Next Big Thing (appropriate for a new post) to my mind is ability to import CreoleWiki (or simplified variant) files, perhaps created in a text editor or by processing existing files with SED or AWK-like parsers.

There's an extensive section on parsing in the source code. If you do a search for parse, you can find it and probably pretty easily add some regular expressions to it to parse additional types of text.

jmuelver wrote:

How are you converting images to Base64? I've got an ancient "export-as-64" set of subroutines in a flavor of BASIC around here somewhere that I could resurrect and cobble back together, I suppose....

Since I use Linux, I open a terminal window, go to the directory the image is in, and type base64 imagename to get the encoding. If you don't use Linux, your operating system might offer a similar command. If it doesn't, you could use an online service like this one.

When you run the command or use the service, you'll end up with the base64 code like this (but often far longer):

R0lGODlhBgAFAIABAAAAAP///yH5BAEAAAEALAAAAAAGAAUAAAIJDGJ4ic1qgAwFADs=

Then use this code on your page, replacing YOUR_CODE_HERE with your Base64 code, to embed the image on the page:

<img src="data:image/png;base64,YOUR_CODE_HERE">

You can name the page anything you like, and then use an include link ([[Include::MyImagePage]]) to put the image anywhere in the wiki.

As an example of what can be done, paste this code into a page in the wiki:

<img src="data:image/png;base64,R0lGODlhBgAFAIABAAAAAP///yH5BAEAAAEALAAAAAAGAAUAAAIJDGJ4ic1qgAwFADs=">

It will make a tiny smiley face. (:

jmuelver wrote:

Thanks! This can be a lot of fun, if we don't watch out...

I know. I can't seem to help myself. I keep a wiki on my desktop at all times so whenever I'm in the mood to tinker around with it, it's a click away.

legolas558 wrote:

why is it necessary to put direct raw base64 code? doesn't the upload feature work?

No. When trying to embed an image from the Desktop by using [[Image:: ]] as the link, I am offered the ability to browse to the image. Then when I click the Embed button, nothing happens, and this is what shows in the debug console:

Retrieving embedded source Image:: 
Transcluding Special::Embed(Special::Embed,image)
load_as_current("Image:: ") - 187 bytes
Exception while attempting to load

[Exception... "Component returned failure code: 0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH) [nsILocalFile.initWithPath]"  nsresult: "0x80520001 (NS_ERROR_FILE_UNRECOGNIZED_PATH)"  location: "JS frame :: file:///home/littlegirl/Desktop/woas-0.9.6b.htm :: mozillaLoadFile :: line 993"  data: no]
Exception while attempting to load

ReferenceError: ActiveXObject is not defined

It looks identical to this person's issue:

http://groups.google.com/group/stickwik … e2f9be1605

It also might be related to Can't embed images in FF3 - ID: 2049465 in the WoaS Bug Tracker, although that person doesn't offer the debug info for comparison.

I've tried seeing if I could figure out what's causing it, but I'm not a JavaScript guru, so it all looks good to me.

Last edited by Little Girl (14-10-2009 02:26:10)

so we have a rather big issue...perhaps it's a Windows only issue, i'll look further into it

Be free of any OS.  Use WoaS anywhere!

Last edited by Snaga (22-01-2010 07:45:43)