Posted by: Peter Quirk | May 28, 2008

More thoughts on notecards, and collaborating on PowerPoint presentations

In an earlier post I lamented the lack of printing support for notecards in Second Life. Bob Wellman commented that he submitted the original JIRA bug report requesting supporting for printing over a year ago. There followed some fruitful conversations and a suggestion that I contact Jani Pirkola at realXtend to see if he could squeeze the printing functionality into the next release.

I met Jani at the last meeting of the Gronstedt Group and followed up with an email. Jani hasn’t had a chance to reply yet (he’s got a new release of realXtend to get out the door!) but the conversations with Bob have continued to spawn ideas.

Bob is rightly frustrated about the use of notecards to define all manner of parameters to scripted objects. In a personal email to me this morning, he suggested that a new structured notecard – he calls it a datacard – is needed for specifying configuration data. He envisages datacards being maintained with your favorite spreadsheet program. Datacards would have two columns, one for names (or keys) and the other for values. He also envisages some new API calls in LSL (Linden Scripting Language) or the OpenSim API.

I responded that the meta issue is that LSL should have support for reading name/value pairs from all sort of data structures – CSV, XML, JSON, XLS, and ODF & OOXML spreadsheets. In concert with this, LSL should be able to deal with formats in some generalized document container (Bob’s datacard?), or external files (like the opensim.exe.config file) or delivered via RSS, ATOM or other web services.

Access to these formats will be much easier when the new implementation of LSL on Mono is completed. All of these data formats can be accessed more or less easily with C#. The OpenSim scripting implementation allowed C# to be mixed with (the fairly incomplete) LSL implementation many months ago. realXtend includes all the OpenSim scripting goodness, and adds IronPython scripting on the server side. As a .NET language, IronPython should provide easy reading of the abovementioned data formats as well.

So the next step in the thought process was to do with PowerPoint. Everyone is familiar with the dismal user experience of watching slides in Second Life progressively emerge from the primordial graphic ooze, taking advantage(?) of the progressive streaming features of their underlying JPEG2000 representation. It’s worse than lag on a busy island! Given that the Mono-based scripting engine will deliver 1-2 orders of magnitude better performance, and hence could support a much higher prim count, it makes sense to deliver PowerPoint slides as they were composed – as a series of graphic primitives delivered in a time sequence on a canvas.

I can envisage a projector object which accesses an external PowerPoint file (on Slideshare.net perhaps), and transforms the primitives on the current slide into their corresponding prims and composite prims on some whiteboard object. I’m assuming that text boxes would be converted to HTML on the fly and rendered as such on dynamically created prims of the right size. What’s interesting about this approach is the possibility of animating objects in the third dimension. For example, one might specify that a PowerPoint “fly out (up)” operation be mapped to a “fly one foot towards the viewer then follow an upwards arc before disappearing (de-rezzing)”.

This approach of returning to the graphical roots of PowerPoint slides also enables the projector object to process audio attachments, and to handle “hot spots” (clickable areas) on graphical primitives. Who knows, if this is done right, it could become the preferred mechanism for viewing AND interacting with PowerPoint slides in a distributed team setting. Just add a “tear-off” feature to clone a slide and you have real possibilities for team members to annotate or rearrange elements in a slide in a way that has not previously been demonstrated.

Advertisements

Responses

  1. Hi all

    Just to clarify I actually see a Datacard has having more than 2 columns like in a spreadsheet or a database table.

    for instance datacard1 contains the following 4 rows of 6 columns:
    key Name colour Sizex Sizey Sizez
    1 Tom Blue 10 10 10
    2 Dick Red 20 10 30
    3 Harry Yellow 15 6 16

    New scripting commands could be written to access it as follows:
    OsGetDataElement (datacardname, key, element)
    – Uses the key and element name to return the appropriate cell value from the Datacard named.
    e.g. OsGetDataElement (datacard1, 2, colour) returns the value “Red”

    OsSetDataElement (datacardname, key, element, newvalue)
    – Updates the appriate cell in the Datacard.
    e.g. OsSetDataElement (datacard1, 2, colour, “Purple”) alters line 2 colour to Purple

    But apart form that what Peter said is correct I see the inability to store data in an organised way in a prim as a big ommision in LSL. This way of storing configuration data as a table of rows and columns would be fairly intuative for people I believe.

    I believe the big objection to updatable notecards by LL in the past has been that every change creates a new asset. Maybe a way round that would be to have a script read the whole Datacard into script memory on rezzing the object and updating the Datacard in script memory only until such time as the script issues a commit datacard command. This would reduce the number of new assets created and would be more efficient in script terms too I believe.

  2. The Opensim team is working hard on forking Second Life-like worlds by adding its own set of scripting functions prefixed by the letters “OS”. Amongst the proposed new functions for notecards, primarily for configuration data (all of which should be added to LSL), are the following:
    * osMakeNotecard(string name, [ line1, line2, line3, …])
    * integer handler=osReadNotecardKey(string notecard, string key)
    * osWriteNotecardKey(string notecard, string key,string value)
    * integer handle=osXMLParser(string xml)

    There’s a lot of heat and not much light about future directions for notecards from the Second Life JIRA database in bugs SVC-402, MISC-760, SVC-1528, MISC-825, SVC-1561, SVC-966, VWR-2921, et al.

    It’s hard to find any requests for functionality related to taking notes or doing word processing except these:
    * VWR-112 (correctlty representing RTL languages like Arabic on a notecard)
    * VWR-1927 (adjusting font sizes for people with vision disabilities. Torley Linden replies that they’re working on a dynamic UI to address this and internationalization issues.)
    * VWR-7467 (adding limited rich text features)

  3. […] wrote recently about an idea for PowerPoint slides in Second Life to project themselves into the third dimension. I talked about animating bulleted […]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Categories

%d bloggers like this: