Any Help Is Welcome
Art Of Sequence (or AOS) is a volunteer driven project, powered only by love of art, love of authors and the will to help them. Still, it’s a very big project, made of several sub-projects that are different tools working together. It’s designed to be open to extension. The purpose is to provide a base on which companies and authors could build their own tools. It requires a very wide variety of skills, knowledge and a lot of time to develop all these tools.
Any help is welcome. Below we describe how you can help on the technical side. If you’re an author but don’t have technical skills, you can still help by providing feedback and suggestions (on the forum http://forum.artofsequence.org ).
For developers, instructions to setup the developpement environnement are available there. A coding convention is also available : we’ll accept only code following this convention. It’s a constant work-in-progress so feel free to ask details or propose enhancements to it.
If you want to participate on the technical side of the project, here is a list of war fronts to fight on.
You should first look at the issues lists for each sub-project:
If the issues are bugs or not-working-as-it-should features, feel free to fix them and create pull-requests. (If you’re not familiar with Git, our source-control tool, here is a good starting point : http://git-scm.com/book )
However if the issues imply design decisions, please first discuss the issue in the comments or in the related discussion on the forum if necessary.
Improve The Build-System Scripts
AOS provide tools and players implementations that are meant to work at least on Windows, MacOSX and Linux (at least Ubuntu & Fedora). To achieve this goal for C++ code, we use CMake as meta-build system to generate the project files necessary for each platform and tools sets. We also have some Python scripts for post-build actions.
However, we don’t have CMake specialists in the team at the moment and the current CMake files might be very naive implementations.
Any help to enhance CMake files documentation and implementation (flexibility, correctness) are very welcome!
Improve Cross-Platform Support
The tools provided by A.O.S. are meant to work at least on Windows, MacOS and Linux (Ubuntu and Fedora).
At the moment, while keeping this objective in mind, we develop and check the application only on Windows. Deep checks of correct behavior of the tools on those platforms are welcome.
Also, the players implementations are meant to be working on more different platforms, specific to the player application nature. Deep checks of provided players implementations behavior on those platforms are welcome too!
AOSL is the format that allows the tools and interpreters to work together. It’s xml-based and totally defined and documented in an xsd file at the moment. As it’s a format specification, originally written by one person only, it needs a lot of reviews and enhancement for the future versions:
Enhancement, fixes and new features propositions are obviously welcome and encouraged. Just provide changesets to check in with a full explanation of your proposition for review.
At the moment, AOSL is really poorly documented. If you start to grasp the point of AOSL, you’re encouraged to help on it’s documentation, either in the xsd definition documentation tags or by providing tutorials and articles for example.
There is a specification document being written for AOSL 2.0 and other related documentation that are all work-in-progress. You can also discuss these documents on the forum.
AOS Designer is the main visual edition tool of the project. We need to add helpful and powerful features to let the author be free to story-board and mount their sequences as they wish and with almost not limits.
Skills wanted :
Programming : C++, Boost, Qt
UX and usability designs
Graphics : icons and other graphic stuffs
Improve User Experience
The project being in it’s infancy, the current objective is to make it just work.
Having said that, it’s still a visual montage tool that needs to be really simple and clear to use. We try to implement the UI in a useful way as much as possible while we implement the basic features of this tool.
We need to have some resources focused purely on usability.
You can suggest improvements on the forum or even implement some and propose them to be pulled in the codebase, with a provided rational for the feature.
One thing that might help a lot would be to add usage statistics to the code, to make the tool send use data about how the users behave. That would complete observation of real-world usage that I’m doing with some people around me.
AOS Designer really need tutorials and extensive documentation.
A wiki might be a good solution for such documentation (TODO?).
Another type of documentation is everything that is inside the tool itself. For example, tooltips and contextual information pages might help the users to figure what they should or can do at any moment.
Tutorials could be implemented in several ways :
Tutorial sequences : sequences explaining how to use the tool and providing their own sources/project files, to help the user understand how to do something. I think it should be the preferred form because it would help "eating our own dog food" and it’s a perfect case of explanation by desmonstration.
Textual tutorials : classic tutorial texts.
Write Unit Tests
There is always missing unit tests in our C++ projects at the moment. Any help on this front would be awesome.
Exporters are tools that convert a story (an AOSL file) and it’s resources (images, sounds, etc.) into another format.
However, this will not be enough. One of the purposes of AOS is to allow defining a Sequence, maybe making some variants, and exporting to several different targets.
There are several kinds of targets/output :
Interpreters : see the next section. Some exporters will just allow players to read specific optimized formats.
There are two kind of interpreters :
Players reading AOSL files directly : those are the most flexible players. However they might suffer from performance problems on some platforms like embedded hardware (smartphones for example) because they need to parse XML, then interpret it, then gather associated media files before starting to show the story.
Players reading specific format : mostly for performance reasons, a binary format for some players might be necessary.
For binary formats, there is no official AOSL binary at the moment because it’s meant to be extended: players can implement additional features to the language. When such a player-specific extension is used in a Sequence that is played in a player that don’t know this extension, it’s just ignored, like with HTML tags.
Ideas of players that might be interesting to provide :
Flash player (implemented in AS3)
Improve The Web Player
You can see an work-in-progress example there: http://demo.artofsequence.org