AOSL 1.1 - Features Discussion

[Klaim - Joël Lamotte]

Hi,

I'd like to expose here my plan for AOSL 1.1. I will not work on it in immediate times, so I think it's a good idea to potentially get some input before working on it.

At the moment, AOSL 1.0 draft-3 is almost totally fixed (some minor fix are needed) but it lacks some features that should be added once it is stabilized.

Here are the features:

1. text objects

Currently to display text you have to display an image.

I didn't put any text object in AOSL 1.0 because it was not clear yet how to describe text information in a general enough way to be used

in non-web implementations of players. 

2. effects (animations - position & color)

Currently there is no standard effects provided. With the web player starting to show results, and following the example of several

(game) libraries that implements animated values through ease and other fades, it is possible to define a basic set of such animations

that should be available in any player.

3. mark stages that can be jumped to (chapters?) to allow players to provide a way to jump there

When a sequence have branches and/or loops, it is very hard to provide a way for the reader to jump directly at a specific stage in the sequence.

On the algorithmic side it is not hard (using default moves and/or Djikstra graph search).

The problem is more to find a way to represent the full sequence for the reader to point where to go. A graph is not intuitive and show too  much to the reader.

A timeline would be possible but maybe not a good idea if the story have several branches that don't merge later.

The solution I think would work best would be to allow the author to mark specific stages as being points where the reader can directly jump.

It would be like chapters in a DVD/BlueRay, but it would allow to mark stages in branches too.

4. script API

There is not yet a script standard API, so currently the scripts are not very useful or portable.

The script API have to be described in a language-agnostic way, and would provide ways to manipulate the objects and communicate with the player implementation.

5. jump to another sequence

It would be useful for the author to be able to say to play another sequence from inside one sequence.

One of the reasons to use this would be to write "series" of sequences, but allow the reader to jump from an episode to another without any cut.

The other reason is to allow a very big sequence to be loaded in separate chuncks of resources.

A player can load resources the way it prefer, but if some resources are very heavy, it can be useful to make sure all pllayers unload these resources once not needed anymore.

To be sure it is done, having these heavy resources part of sequences and then jumping to another sequence when not needed is useful.

Any comments are welcome.

Joel Lamotte / Klaim

[Klaim - Joël Lamotte]

Another feature I was thinking about, concerning navigation:

6. Random Navigation

Allow the author to let the player choose the next move in a random way (instead of in a deterministic way).

That would allow authors to have minor variations in the experiences of the user for cheap.

I have a motivating example that I'll try to extend from one if the AOSWP demos that I'm preparing.

Joel Lamotte / Klaim

[Klaim - Joël Lamotte]

Here is another feature I felt the need while experimenting with the coming AOS Web Player demo:

 7. Multiple Lecture Threads

The general idea is to allow several, maybe unrelated, parts of the story graph to be read in parallel.

For example:

-> X -> Y ->Z    (this one is looping from Z to X)

      ^____/

-> A -> B -> C -> D -> E -> F -> G -> H -> I -> J

Here the story starts with two beginning stages: A and X. Each "next" move will move both threads in parallel, resuling in this sequence of stages:

 A , X => B , Y => C , Z => D , X => E, Y => F, Z => G, X => etc.

The typical usage of such feature would be to have a background loop sequence and front non-loop action.
For example, imagine X Y and Y being stages showing the same background but with some changes like rain drops.

Allowing this feature would help telling a story with recurring parts of sequences in parallel.
The need came when trying to write such a sequence: with AOSL 1.1 we have to copy the X->Y->Z moves "by hand" in the main A->...->J sequence.
This is very problematic, in particular when you want to make modifications to the number of stages in the main sequence.

This feature would be cut in several parts:

 a. allow the "begin" attribute of a <story> to start with several stages.

 b. allow a move to target several stages (the "to" attribute is currently limited to only one target).
 c. add a way to express a "end of story" stage for the player to end any other thread when this expression is met.

The need for c is apparent in the example I gave: here we have the X->Y->Z part that is looping with no end condition,

so a player would not end the sequence when J is met but would continue to allow a "next" move with no limit. 

This can be good for some interesting storytelling experiments, but in the same time most use would end at J.

To fix this the immediate thinking would be to have some scripted condition in J and X/Y/Z to make these last stages move to another "end" stage that would have no other move.

But that is a bit boilerplate to express a simple thing: "stop reading here".

As always, any feedback on these ideas is welcome.

Joel Lamotte

[Klaim - Joël Lamotte]

I'm coming back to this list of features for some comments months later:

On Thursday, July 5, 2012 8:19:50 AM UTC+2, Klaim - Joël Lamotte wrote:

1. text objects

Currently to display text you have to display an image.

I didn't put any text object in AOSL 1.0 because it was not clear yet how to describe text information in a general enough way to be used

in non-web implementations of players. 

Basically the text objects would need to feature two things:

 a. localization

 b. formatting

Layers are supposed to be a way to setup localization, by putting all texts instance of the same lang in the same layer, activating only the layer of the reader's lang.
However, this solution will be unefficient if a lot of languages are provided. For example in europe we have French, English, German, Spanish, Portuguese, Danish, Swedish...

If we keep the count of these 7 lang only, it means each text would have 7 text objects in the AOSL file. 

A way to fix this is to add a localized text database resource type wich would provide a set of texts in different languages.

Then a text instance would only use a text id, which would point to the right text depending on the player's configuration.

This could be optional, making using only one language simpler too.

 

2. effects (animations - position & color)

Currently there is no standard effects provided. With the web player starting to show results, and following the example of several

(game) libraries that implements animated values through ease and other fades, it is possible to define a basic set of such animations

that should be available in any player.

A first implementation would provide just what some common libraries provide and are common between these libraries. 

JQuery and Cocos2D(-X) provide almost the same set of easing functions, which would be a good starting point.

 

3. mark stages that can be jumped to (chapters?) to allow players to provide a way to jump there

When a sequence have branches and/or loops, it is very hard to provide a way for the reader to jump directly at a specific stage in the sequence.

On the algorithmic side it is not hard (using default moves and/or Djikstra graph search).

The problem is more to find a way to represent the full sequence for the reader to point where to go. A graph is not intuitive and show too  much to the reader.

A timeline would be possible but maybe not a good idea if the story have several branches that don't merge later.

The solution I think would work best would be to allow the author to mark specific stages as being points where the reader can directly jump.

It would be like chapters in a DVD/BlueRay, but it would allow to mark stages in branches too.

This is a feature a lot of people pointed to me. Great care have to be taken to design this.

 

4. script API

There is not yet a script standard API, so currently the scripts are not very useful or portable.

The script API have to be described in a language-agnostic way, and would provide ways to manipulate the objects and communicate with the player implementation.

I think this should be postponed to AOSL 1.2 or 2.0

 

5. jump to another sequence

It would be useful for the author to be able to say to play another sequence from inside one sequence.

One of the reasons to use this would be to write "series" of sequences, but allow the reader to jump from an episode to another without any cut.

The other reason is to allow a very big sequence to be loaded in separate chuncks of resources.

A player can load resources the way it prefer, but if some resources are very heavy, it can be useful to make sure all pllayers unload these resources once not needed anymore.

To be sure it is done, having these heavy resources part of sequences and then jumping to another sequence when not needed is useful.

This need thinking too. Depending on the player implementation and context, widely different possibilities could be offered.

Joel Lamotte / Klaim

 

[Klaim - Joël Lamotte]

On Friday, July 6, 2012 7:50:01 AM UTC+2, Klaim - Joël Lamotte wrote:

6. Random Navigation

Allow the author to let the player choose the next move in a random way (instead of in a deterministic way).

That would allow authors to have minor variations in the experiences of the user for cheap.

I have a motivating example that I'll try to extend from one if the AOSWP demos that I'm preparing.

I believe this isn't a priority but could be easily integrated as a Navigation property.

As said I have a motivating example that makes a nice story that have variations, which is part of the point of telling stories through digital platforms.

Joel Lamotte / Klaim
 

[Klaim - Joël Lamotte]

On Sunday, August 12, 2012 8:52:52 PM UTC+2, Klaim - Joël Lamotte wrote:

Here is another feature I felt the need while experimenting with the coming AOS Web Player demo:

Actually, through months I've got clues that this is a very important feature to have as it simplify designing sequences quite a bit.

Basically, the point is to allow multiple path of reading going on in parallel. It allows to exploit in more significant manner the simultaneity of digital display.
Mixed with random navigation, it could allow quite positively surprising reader's experiences. 

I have reasons to think this is important to add as soon as possible. I think I'll try to update the AOSL xsd specification before writing the full human-readable documentation.

Joel Lamotte / Klaim

[Leo Ki]

2012/12/20 Klaim - Joël Lamotte <mjk...@gmail.com>

A way to fix this is to add a localized text database resource type wich would provide a set of texts in different languages.

Then a text instance would only use a text id, which would point to the right text depending on the player's configuration.

Just a quick note: Localization can affect more than just text. In some cases it might require changing the size of a bubble or its orientation, depending on how thoroughly the localization is done. The case of the overlaid graphical onomatopoeia or street signs or store names is even trickier. So I think there should be a way for a given localization to override any attribute of a particular screen, including the whole screen itself when necessary. I guess AOS is supple enough to allow such a knack.

[Klaim - Joël Lamotte]

Thanks for your feedback!

On Sun, Dec 23, 2012 at 9:37 PM, Leo Ki <leoki...@gmail.com> wrote:

I guess AOS is supple enough to allow such a knack.

The Layer system should allow this. However, it is totally separate from a potential localized text system... 

I guess this needs more thinking...

Joel Lamotte

[Klaim - Joël Lamotte]

A few weeks ago, someone suggested a change:

Move all Meta data outside the AOSL file.

I'm not sure about this, maybe some Meta data still need to be in the AOSL file.

I still wanted to record this here.

Joel Lamotte / Klaim