The articy:draft client
In a nutshell
The articy:draft client is the core component for creative working. It contains all the editors for story flows, entities, locations and assets and uses a server connection to synchronize data with the server. You can also consider it the "front-end" through which you can view and edit your projects.articy:draft client - For administrators
You can use the articy:draft client to administrate your server and projects. Details can be found on Server administrationarticy:draft client - For designers
After a successful connection and log-in, the articy:server sends a list of available projects to your articy:draft client, which will be displayed in the project selector. "Available projects" are those where you are assigned as a resource. The project administrators can pick users known to the server and add them to their project's "staff", either as regular team members, administrators or guests. Guests can open projects, but their access is limited to read-only. They can view everything in the exact same way as team members, but they cannot make any changes.After you have opened a project, you can explore it via the various means that articy:draft offers. Yet, you cannot start working before you have claimed a portion of the project for editing. This helps avoiding conflicts where two team members have modified the same pieces of data. These kinds of conflicts can hardly be resolved when it comes to storytelling, thus articy:draft's approach won't allow two users to change the same data fragments at the same time.
Following this idea, the project is split into so-called partitions. Partitioning (which is the process of splitting the project into partitions) is done by the project administrator and can only be done in exclusive mode. In order to change the project's partitions, a project administrator needs to have access to the entire project, since partitioning involves heavy moving, restructuring and shuffling of data. If you need a finer granularity of data (for example if you want to be able to claim a chapter of the story for editing while other authors can continue writing on theirs), you can unclaim all partitions and ask the project manager to create new partitions for each chapter.
Even though you don't really need to worry about that, the following helps understanding the functionality of the multi-user mode: Each partition is represented by a single file in your local project folder. This file contains the partition's content, including the sub-structure and all topological information necessary to reconstruct the branch of the project structure "below" the partition. The same partition file is also stored in the server repository, safely guarded by either Perforce or Subversion. articy:draft synchronizes these two file versions, to upload your changes to the server on the one hand, and to download the newest data to your local project folder on the other. Now that you know that each partition is a file, it's easy to understand why repartitioning can only be done in exclusive mode: On file has to be split into two files, both on the server and across all clients, which requires all clients to perform the exact same set of operations on their local data. To make this failure-proof, articy:draft enforces a workflow that guarantees writing permissions on all files involved.
As soon as you have claimed one or more partitions for you, you're ready to start working. If you have claimed a chapter within the flow, you can break it down into flow fragments, enter the synopsis text, attach concept arts, and so on. While doing so, nobody in the team can see your changes, they're only stored locally on your machine. This means that during your editing, two different file versions exist: the "official" version stored in the repository (and thus synced to all other clients' machines), and your personal local version with your changes. You can now decide to either publish your changes to the server and make them the "official" newest version (your changes will then be broadcasted to all other clients), or to discard your changes and roll back to the server version. In the latter case, your local version will be overwritten with the original version like it was before you started editing.
While you're working, you will notice other partitions to be highlighted with an "update available" symbol. This indicates that other users have published changes and your local versions of those partitions are outdated. articy:draft doesn't automatically keep your data up-to-date, because this would result in a rather chaotic appearance with things popping up and vanishing all around you. You can focus on your work, and when you've reached the point where you want to view changes of your team mates in context, you can perform the "update all" command to synchronize your local data with the "head revision", which is the most recent server data. Of course, partitions claimed by you will not be overwritten during a project update.
To facilitate your orientation, each articy:draft object clearly visualizes it's "claiming state" via a signal-light icon:
- The object is a partition and available (read-only for you, but can be claimed).
- The object is a partition and claimed by someone else (read-only for you).
- The object is a partition and claimed by you (can be edited).
- Your local copy of the object is outdated, you don't have the latest changes somebody else has made. Update required!.
- The object is a child of a partition that is available (read-only for you, but can be claimed).
- The object is a child of a partition that is claimed by someone else (read-only for you).
- The object is a child of a partition that is claimed by you (can be edited).If the user interface won't allow you to perform a certain action, for example drop an object somewhere, enter text or move something around, it'll probably be because the action involves a partition that isn't claimed by you, either directly or indirectly. You don't have the right to access parts of the project while they're claimed by other people in your team, which results in some of your operations being suppressed. We're striving to make this transparent for you, but we understand that this can be irritating at first.
Here's an under-the-hood detail that'll help you looking behind things and understand what is going on:
Imagine you're working on a dialogue between two characters. This means that you have a partition within the "flow" section claimed by you. Someone else is working on "entities". The idea behind partitions aims at avoiding conflicts that occur when two people are working on the same data. Yet, there is also some conflict potential in references across partition boundaries. What happens if the other user deletes the character that you've used in your dialogue? There's a certain period where the data becomes inconsistent: The character still exists in your local project folder and is referenced in your dialogue, but it has been deleted and the deletion has been broadcasted to everybody but you. For situations like this, articy:draft utilizes a powerful "referencing system". This was just one example, but since articy:draft heavily uses cross-referencing, situations like this will occur often in the course of your development project. Yet, it won't result in a loss of data integrity or corrupt database states. articy:draft handles your references safely and bears such conflict states with grace. In the example above, you'll see that the dialogue's entity changes to "unassigned" after you've updated your project. But here's the good news: The character reference in the dialogue will automatically become valid again if your colleague undoes the deletion or creates a new character with the same name. The additional information stored to enable this kind of smart referencing is lightweight and won't have any significant impact on the database size, but it helps avoiding data loss- and thus frustration.
Imagine you're working on a dialogue between two characters. This means that you have a partition within the "flow" section claimed by you. Someone else is working on "entities". The idea behind partitions aims at avoiding conflicts that occur when two people are working on the same data. Yet, there is also some conflict potential in references across partition boundaries. What happens if the other user deletes the character that you've used in your dialogue? There's a certain period where the data becomes inconsistent: The character still exists in your local project folder and is referenced in your dialogue, but it has been deleted and the deletion has been broadcasted to everybody but you. For situations like this, articy:draft utilizes a powerful "referencing system". This was just one example, but since articy:draft heavily uses cross-referencing, situations like this will occur often in the course of your development project. Yet, it won't result in a loss of data integrity or corrupt database states. articy:draft handles your references safely and bears such conflict states with grace. In the example above, you'll see that the dialogue's entity changes to "unassigned" after you've updated your project. But here's the good news: The character reference in the dialogue will automatically become valid again if your colleague undoes the deletion or creates a new character with the same name. The additional information stored to enable this kind of smart referencing is lightweight and won't have any significant impact on the database size, but it helps avoiding data loss- and thus frustration.