Tabloid Update: Part 2

Good news and bad news.

Good news first: the tabloid (my cheap Android 2.2 tablet) still works!

I've started using Graffiti for input. This is a replacement for the onscreen keyboard and basically involves your drawing shapes on an area at the base of the screen. The majority of the shapes correspond to upper-case letters so are not hard to learn. There's a separate area for numbers and you can easily popup a list of shapes by drawing upwards off the top of the input area. Swapping back to the app can sometimes be problematic though. I first used this app on my HandSpring Visor PDA back in, erm, 1999 so it feels both familiar and retro. It also does word-prediction but some of the guesses are weird and/or earlier typos. Given that input is entirely silent, with not even the tiny pattering of virtual keyboards, it is also potentially seminar-friendly. Retro affection notwithstanding, I am purchasing a (similarly cheap) case with in-built (if somewhat cramped) keyboard.

One thing I didn't expect was the possibility of being able to program on these machines but I note that not only is there potential scripting support for the likes of Python via SL4A (not tried it) but also more generally via IDEdroid which sends your code off for remote compilation. OK, you can't do anything fancy but it's still a neat idea. Again, haven't tried it but goes on my to-do list, admittedly somewhere near the bottom. Proper cross-OS support is always going to be a challenge. I've only spotted LiveCode and PhoneGap as platforms thus far. I'm sure more will emerge but it's not a priority for me. The platform-specific Scratch-inspired App Inventor seemed off the agenda with the imminent closure of Google Labs but MIT stepped in at the last moment.

I'm still hoping to use TiddlyWiki/Space, i.e. the web, for mobile but the interface design issues are somewhat hard to get to grapple with if you don't have access to the hardware. I'm presently playing with a plugin that lets you change the stylesheet and hence tailor the layout to the platform. There's a couple of useful summaries of testing tools/strategies for mobile phone browser (iPad included as link in the second). Of course, you necessarily lose something in the transition so I hope Mozilla come up with something in this era of HTML5. At present, however, Firefox is one of the few browsers that doesn't run on the M009s so that is all for the future.

I am trialling Do It Tomorrow as a simple to-do list app. I suspect I may want something a little more fine-grained though, possibly a TiddlyWiki-based GTD tool. Workflowy also looks nice but does not run well on my system or offline as yet. I suspect it needs to be an app rather than a web tool.

I'm still using and liking Thinking Space. It does play very nicely with Freemind (and the related Freeplane).

In an effort to get out more now the weather has improved, I've used the tabloid both on the train and in a shaded outdoor area of a cafe. Not much good in bright sunlight, of course. Another indoor cafe has free wifi and it worked fine there too. Probably need to find out more about Firesheep and sidejacking issues though.

Bad news: the 30-pin connector was always a disaster waiting to happen and as I wandered round looking for a better signal for my 3G dongle, the USB adaptor and attached dongle detached, fell to ground and the dongle is now an ex-dongle. More generally, picking up wifi can also be a tedious process and I am still getting occasional freezes that require a hard reset. No progress with EduRoam (actually, I suspect it is a dead duck so have not pursued further) so I've bought into mifi instead (basically a mobile wifi hotspot for up to 5 devices). I've dropped this once but it survived OK. It works well on the train except when in tunnels (of course).

Someone alerted me to problems entering text in fields in Blackboard wikis using the default web browser. HTML source mode works though and apparently this is a problem for iOS as well.

I continue to use Google Reader for RSS feeds. I've added a few Google Groups and Twitter feeds as well. While I eventually got the hang of scrolling without firing up the record I was touching, the text display sometimes gets lightly corrupted. How to get stuff out of Reader isn't immediately obvious though there is a "send to" option under Settings for the likes of Delicious. JoliPrint can create a very nicely formatted PDF of a list.

I also have a corrupted icon.

I have learned to live with the battery life. It helps that you can use the tabloid while recharging.

Other news:
In terms of reference management, there's a third-party app for Mendeley called Referey though I haven't tried it and don't know whether it will be compatible. Doubtless an official app will be along in due course (there is one already for iOS).

Surprised to see even a basic Android PDB molecular viewer called PDBs.

ReactionGrid have an early version of Jibe running on Android.

The little company I bought the tabloid from has apparently sold 6000 to date! They now have a slightly more expensive version (£140) with a larger (still resistive) screen with GPS and HDMI output so you can project (on the iPad this is also a function of the app, not sure here). It also has built-in USB sockets (yay). As I'm not convinced that peering at the 7" screen is good for my eyes (though it's a good size for busy commuter trains), this sounds all good although it presently only runs Android 2.1 so I probably will not rush. No feedback either (feedback on the M009s tends to be mixed depending on whether you expected iPad quality for the price). Nice to see manufacturers exploring the low-end given that Android has not thus far been a huge success at the other end.

Indeed, the withdrawal of HP from WebOS tablet development and the large discounts now available on stock have driven the tablet to the top of the Amazon US charts and spurred initiatives to port Android to it. There are also new low-cost Android tablets on the immediate horizon such as the AndyPad and AndyPad Pro, the latter with capacitive screen and HDMI output. Meanwhile Seton Hall University in the US is trialling the new Lenovo ThinkPad. Many are expecting Amazon to enter the fray as well.

The other big surprise was that Google bought Motorola Mobile, in large part for its patent portfolio. Google, Apple and Microsoft look set for litigation wars. Quite how that will impact the various platforms and cost of low-end tablets remains to be seen.

Using Twine to make a path through an OpenSim build

I haven't been blogging as regularly as I ought. I have, however, been reading blogs and a couple of articles caught my eye this past week.

First Robin Heyden has some excellent tips for running virtual training sessions. One important point she makes is the need to train students only for the task at hand to avoid overwhelming them with detail.

The second article was by Cathy Moore who describes use of the TiddlyWiki-based Twine to generate e-learning scenarios. Twine itself is a visual editor for interactive fiction stories with passages (aka as tiddlers/chunks) linked to show pathways through the story (see lefthand side of picture above for really crude example).

Underpinning Twine is a specialist language called twee that provides useful macros to manage the reader experience. I looked at twee in the very early days of this blog with the intention of using a third-party information manager called Treeline to generate twee code for processing into standalone TiddlyWikis. However, being purpose-designed, Twine helps a lot in implementing paths through a scenario, visualizing them and outputting versions in special TiddlyWiki formats (Jonah or SugarCane) or as plain twee-formatted text for proof-reading. See Cathy's blog for a better explanation together with the videos by Twine's creator, Chris Klimas.

Putting these two ideas together, I wondered about the possibility of using the client web browser to display a story or backstory to a class, including branches for optional just-in-time help in the client browser. Bear in mind that not all of the following has been developed or tested.

The Twine and twee documentation give the background though some of it, text-formatting for example, is standard TiddlyWiki markup. As with any TiddlyWiki, you can include embed images and html in the document using the appropriate tags.

More interesting, however, is the notion that you could use OpenSim http-in functions to provide links from the backstory to inworld and thereby deliver objects, notecards, etc as avatars click links in the backstory. The problem here though is that the relevant function, llGiveInventory, requires the avatar's key while Twine by default appears to have no macro to set user-specified variables such as the avatar's name or key.

The simplest way round this for my small class (20 maximum) would be to give students a list of numbers as backstory links so that choosing one takes the student to a page that sets the twee variable $avatar_id to a string between 1 and 20 (the maximum number in my first semester class) and a link that returns them to the main pathway. (I've only included two options as branches in the lefthand side of the image above). I'm using a string in this instance because I want to concatenate it to other strings to generate twee code that will represent the URL.

When students login, they touch a prim that allocates a unique number in the aforementioned range while at the same time recording their name and key against that number and opening the backstory in the in-client browser using llLoadURL. You might use OSSL to store this data in a notecard. The connection between the browser is made when they follow the number-specific branch I described above.

Subsequently any backstory URLs that generate http-in links are generated on-the-fly. For example, the code shown on the righthandside window in the picture would create a hyperlink that tells the receiving prim inworld to give a notecard to the avatar who clicked the link. Of course, that requires some complementary inworld scripting in LSL. The prim might just as easily give a landmark for a teleport step, an object for them to rez or, indeed, temp-rez an object automatically.

This strategy doesn't as things stand prevent one student from pretending to be another but I'm trusting the them not to play games with the system!

One of the avatars on NWG has written a much more sophisticated inworld quest system but it depends in part on an external database. Here the "database" resides in the TiddlyWiki JavaScript and I am hopeful that the same system should be usable from sim-on-a-stick without internet connection. We shall see.

Of course, there are downsides, notably coping with sim and viewer issues (crashes, restarts) and communicating back from the sim (not crucial unless you are making the TiddlyWiki the focus or attempting to create VLE/LMS-type functionality). Reloading the TiddlyWiki in the event of accidentally closing it may also be an issue. Bugs in twee macros are also problematic, not least with the continued evolution of TiddlyWiki and web browsers generally and the fact that Twine/twee and the version of TiddlyWiki used are no longer under development.

How would you use it? Clearly you could be very prosaic and just employ it to step students through some inworld activities (as per the example above). Alternatively, you could develop some more or less fanciful role-play scenario ("there's an outbreak of a previously unknown disease -- go at once to the virtual situation room" or "you are gene id xyz: what is your sequence, what's nearby on the genome, what do you interact with and how is your activity regulated?"). You could also have different stories for the same space and have students compose stories to explain a space and then try each others out.

If you read Cathy Moore's blog, she suggests interspersing text scenarios with activities rather than integrating the two as here. Clearly, that's an option as well. As the TiddlyWiki will run fine in the browser on my Android tablet, you also potentially have a means of generating content that can be read out-of-class without access to the sim. As Twine can import and export twee code, you can also author from a simple text editor.

Linden Lab are becoming increasingly interested in using Second Life for games so it would not surprise me if we see more of this kind of activity. For me it is yet another way to integrate the complementary strengths of text and 3D immersive environments.

Mesh viewers and accessing OpenSim grids

Mesh was rolled out on the Second Life grid yesterday and a new viewer, SL Viewer 3, was deployed so you could actually see it. Despite concerns voiced by others over the future of the prim-based economy, I'm hopeful that this will be good news once the dust has settled. Linden Lab has evolved a costing mechanism based on prim equivalence that is not implemented in OpenSim where it is left to the good sense of the builder as to what to use (in terms of sim performance) and where to source it (in terms of intellectual property issues).

In OpenSim 0.7.1.1, the version New World Grid will be using from Monday, mesh is very experimental, being an early version of the one the Lindens have deployed. The experimental version in the developmental 0.7.2 code is closer to the current SL experience but still experimental. That said, I've used mesh on 0.7.1.1 running on a USB stick and it worked OK for single avatars. That required Kirstens viewer S21r7, a series 2 viewer, albeit an old one now. According to Daniel Voyager, the latest iteration of Kirstens remains the only third-party viewer supporting the current version of mesh at rollout.

I mention this as I've had problems lately with the series 2 viewers on OpenSim 0.6.9. Avatars fail to rez, some regions fail to load or freeze shortly after entry (sometimes a relog clears this, other times not) and some aspects of the hypergrid are borked, most particularly chatted secondlife:// protocols, a means to execute jumps in the absence of scripted gizmos such as hypergates.

Hopefully some of these issues will be resolved as the version of OpenSim I'm using catches up with the viewers. One shouldn't, however, underestimate the recent rate of churn in viewer development. One feature missing from many of the current viewers is a grid selector that can incorporate OpenSim grids. Indeed, one of the Firestorm viewer team commented on a blog lamenting this absent feature:

We are planning OpenSim compatibility for a future release. For now, we're concentrating on making the best viewer in Second Life. Just getting to where we are now has been a monumental undertaking.

Hitherto, the only viewer with a grid manager and selector that I could find which also support shared media was Dolphin 2. The developer is also committed to incorporating mesh when it stabilizes. I have yet to test it extensively under 0.7.1.1 but will do so early next week.

One unexpected development, however, arrived alongside mesh in SL Viewer 3. Viewer 2 had previously had a grid selector but it basically listed the main (Agni) and beta (Aditi) grids and then a number of (presumably) fictitious ones. As of yesterday, however, the list was mysteriously augmented by New World Grid (thanks @voidpipe on Twitter for the tip who had the same experience with OSGrid). The image above shows the login screen with the part of the Preferences dialog and the grid selector.

Quite how the grid came to be included is obscure to say the least as there is no grid manager that allows grids to be added and configured. The (to me) critical question, however, is whether this (presumably security-inspired) behaviour is replicated on our networks and on home installs. If not, I shall look to Dolphin 2 (and the other viewers if they catch up) or, failing that, the standard kludge of editing shortcut properties to include the command-line loginuri. This is fine for me but less than user-friendly for students wanting to install a client on their home PC.

Obviously the fact that many viewers have had to replicate SL viewer functionality as a first stage of development means that other oddities are likely to occur. Search and profiles, for example, default to SL in SL Viewer 3 on New World Grid which can be doubly confusing if the same avatar name is used on both grids. Telling students that their friends list is OK but the profiles and search are borked adds to cognitive load when Robin Heyden underlines the importance of not overwhelming students during first contact. Of course, these things will resolve given time...

In an ideal world I would probably have been using the Viewer 2 (or 3) version of Imprudence, namely Kokua. With the imminent retirement of lead developer Jacek Antonelli, however, development has necessarily slowed. This highlights two issues: firstly, that it is good to have choice and, secondly, that any choice at all depends on the extraordinary commitment of viewer and server devs, past and present. For that, the rest of us, I am sure, are truly grateful.