After discussing what will change in AOS project communication starting next year, here are some more technical shift of focus that are on the work.
Development Effort Priority: AOS Designer
I need to use AOS Designer (AOSD). I say this as an author not as a developer. What I mean is that I want to make some stories that I know are hard to do with current tools but should be easier with AOSD. I am not the only one and a lot of people have been waiting years for me to provide a first usable versions of it, even if it’s broken, just to help with the development effort.
Unfortunately, in the middle of developing the first AOSD version, I discovered several code architecture problems that made me rewrite everything once – which was to be expected as I never did write this kind of editor before. Then I hit a point where I really needed to have AOSL stabilized to be able to exploit it correctly. At this time, the development effort shifted back at stabilizing AOSL. Once done, I had to make sure AOSL was interpretable by tools, some kind of working proof-of-concept, which meant I had to write a player implementation, resulting in the work done on AOS Web Player version 0.1.
Now that these basics constructs are finally ready, I can focus on AOS Designer. It really needs tons of love so it will be my priority and I already started working on it.
AOS Designer relies on Qt for the GUI parts -the other parts are supposed to be totally independent, even if it’s not yet totally the case in the current code. Qt had a major release this month, Qt5, which I already began to migrate AOSD code to, as you can see in this repository. One of the reasons to use Qt5 is that it solves some problems I have been hitting in developing AOSD. I also will consider making all the interfaces in QML / QtQuick to help UI designer contribute to the project. I’m not sure yet if it is the right approach for this project but I’ll have to play with it enough to get enough experience to know, or rely on a contributor’s Qt experience in the future if someone feels like helping.
In the beginning of this year I started a discussion in the developer forum to review the features that I feel are needed to make AOSL more useful, as an inter-operable format to represent digital story-telling . Among the important features, text object support, localization (which can currently be done with the “layer” system, but is not perfect for the job yet) and standardized effects would be the most important ones.
As the effort will focus on AOSD as a priority, enhancing AOSL will take some time but can be done in a parallel effort. The first step is to decide which features will get in, how it will be represented and update documentation (more on that in the following section). However, once this is done, an updated version of AOS WebPlayer should be implemented as a proof of concept OR an updated version of AOS Designer OR both if we want to be complete. Any way, this work is necessary to make all the tools very useful but as I can’t clone myself (yet) to work on several projects at the same time, it will go slowly. Fortunately, the first AOSD and AOSWP versions can still rely on AOSL 1.0 while we figure out what AOSL 1.1 will be.
There are several reasons, other than the lack of exposition and clarity, which makes programmers interested in AOS don’t feel like they can help. One is that AOS projects mix a wide range of technologies that can be intimidating for some; another, more important, is that there is a big lack of documentation necessary to jump in the wagon of the slowly rolling train that is this project. It’s not like I totally neglected technical documentation. It’s just not enough yet.
Here is a list of documents that I made so far to help clarify how to work on AOS:
- How to contribute: expose the different work fronts of the different projects.
- Development Setup: for programmers, how to setup a development environment to work on AOS projects.
- Coding Standard: for programmers, some (unfinished but usable) coding rules.
- AOSL Design: an explanation of the goals and guidelines to use in designing AOSL
- AOS Designer : Vision : a description of objectives and design guidelines used in designing and developing AOS Designer.
And here is a list of documents that are missing to help contribution:
- AOSL Specification: currently, AOSL is described in an XSD file, which is very helpful for programming works, but only if you already understand how the AOSL format is supposed to work. The missing document is a human-readable description of how a AOSL file is composed. I started working on this long time ago but stopped because it needed first to have a proof-of-concept showing that the format is readable (to software, not to humans) and usable the way it was designed.
- AOSD Use Cases: this would be to clarify development goals for future developers. However, I think this might not be necessary. First because it will be more obvious what have to be improved in AOSD once a first version is released. Second because such documentation takes a time that I don’t really have. So for now I will put this in stand-by and only reconsider it once AOSD 0.1 is available.
- AOSD Code Architecture: a description of how the AOSD code is organized. It would just be helpful to have a quick overview for new developers before diving into the actual code. Some time ago I began making a diagram that would make things easier and will be accompanied by some short description of what you see there. I think it is not necessary to complete this document yet because AOSD needs to be stabilized first, but part of the work is done and once AOSD 0.1 is released, I will finish this document.
If you think other documents would be helpful, please describe them in the comments.
New AOSL-based Format
I had some discussions with some people interested in the AOSL format. One of them suggested to provide a specification for another format that would contain the resources used by the AOSL format.
Currently, AOSL don’t specify what format of resources (images, sounds, etc.) are required, it is up to the interpreter implementation to set limitations. This design decision was taken to make sure AOSL can describe any kind of digital story-telling regardless of the kind of resources that it is composed with. However, this means that different interpreters will read the resource infos differently, maybe look for the resource files in different ways depending on the context. This allow nice features, like having an interpreter inside a video game to make “cinematics” using AOS technologies, but it is not really practical for more general cases like when you just want to have a file that contain your whole story and don’t care what player will be used in the end.
This generic case require that some kind of format is specified over AOSL to make possible to just throw a sequence file to any player that accept generic sequence file. This format would be something similar to the epub format: a zip file with an AOSL file to drive the story and resources in sub-directories. It might also specify which generic formats of resources are accepted, certainly something close to HTML specifications.
I will take the time to specify such format as it will help other developers tools exploit AOSL power. It will be used by AOS Designer too.
Development Website Migration
I notified some months ago that the development resources, code & documentation, will migrate from Google Code to BitBucket.org. Nothing special here. The new repository is already in place and what’s missing is the migration of the current documentation. Hopefully it will be done in no time very soon.
The reasons for the migrations are multiple. One is that Google Code forces the user to have and use a GMail account. Another is that it don’t allow easy pull-request manipulations. I would have used GitHub if the project was using git, but it uses Mercurial and I don’t have any reason to change this at the moment.
Once the migration of the development resources is done, I will also split the code repository in the following way:
- aosl : the repository containing the AOSL specification and documentation, including the XSD file.
- aoslcpp: the repository containing a C++ library that can read and interpret an AOSL file.
- aoswebplayer: the repository containing the code of the web player. I’m not sure yet if I will put the demo in this one. It’s likely but not sure.
- aosdesigner: the repository containing the code of the AOS Designer project.
Until now, all this code was contained in only one repository to simplify things. However, this is not very helpful for developers wanting to develop with specific version of one of these projects, while using specific version of another of these projects. Also, it is currently not really easy to just get AOSLCPP project to build another tool over it, like a (iOS or Android or Windows or Mac or Linux) native player for example.
These are separate projects, even if they are interdependent, so they should have separate code. I will use build system scripts (CMake) to make sure each project that needs some dependencies will check that these dependencies are available. This separation will also help me keep track of issues separate for each project.
It will also allow me to specify different licences to different projects. (The current code will stay MIT though).
As I stated in the introduction article, I will need to live from both Art Of Sequence and other projects. To achieve this, once AOSD 0.1 is out, I will also start work on other sub-projects that will have more or less commercial licenses.
More on that in the next and last article about my plans for AOS in 2013. Stay tuned!