Hey all, the mockup image in this post worked under the idea of users drag’n’dropping pieces from the toolbar on the side to the middle. Having recently worked on another app that had DnD for the interface I can safely say it was not fun to work with. Lots of extra movement that quickly became extremely tedious.
Instead, there should be cells containing “+” buttons in all the areas where new pieces can be added. When clicked on they bring up a sortable and searchable dialog of components that can be placed there. When the dialog is brought up, the search box is automatically highlighted so you can immediately begin typing the piece name you want. It will also have a short list of recently/most used pieces.
I think there will still be drag’n’drop for reordering components in the list. The distances will be less, and the mechanics familiar from other apps. Also, reordering happens less often than adding new pieces.
UI Changes
I plan on getting rid of all the tab views in favor of a single view that can easily be navigated.
It will have a small preview in the top left that brings the node view back up to the represented item. By preview I am thinking something similar to a minimap as seen in most games. It will be small until hovered over whereupon it will expand slightly for a clearer image.
When in the node view it will show a mini version of the flowchart with the current node highlighted.
When in the scene view it will show the list of scenes with the current scene highlighted.
When in the list of scenes it will show the title image and be a link back to the dashboard.
I’d like to make a really cool animation for it so that when it’s clicked on it expands to fill the screen, or slides up to the other view, or zooms out of the current view to see the bigger one. I’ll decide on that later when I’ve got a better grasp of how animations work in HTML.
Variables
Variables will still be in the toolbar to either the left or right. It will slide in and out as needed. Variables will be much better laid out and divided into sections for scenes and global. Again the + buttons in relevant locations will be the way to add variables.
When selected they will have a trash icon on the left. Clicking it will delete the variable immediately if it has no usages, else the sidebar will change to become a list of links to all the locations it is used in the game and you must fix each of these before you can confirm the delete.
Dashboards
There will be two layers of dashboards. One containing an overview of all the projects you are working on or are a member of. They will be in private, public, and protected sections. This is related to the collaboration tools I will get into in a minute. There will also be access to the Community view where you can search public projects.
Then there will be the dashboard for each specific project.
This will contain options to change your project from private to public and vice-versa. There will also be an “invite collaborators” button.
All projects will have the settings for title text and image, as well as the summary. New projects will be filled in with some boilerplate text that seems to be common to all the CS games I’ve played. From there will be a link to the scenes view.
If it is a public project, there will also be a list of submitted changesets from other users. They will be roughly grouped by which parts of the project they modify.* (see “Regarding collaboration tools”)
Protected projects will only have collaborators and changesets will work slightly differently for them.
Online/Offline
Hopefully this section will address all nagging concerns about Chronicler’s online features.
All project data will be stored offline locally on your individual computers. This data will then be synced with the server.
This means Chronicler is not bound to the internet in order to run, but when it is connected you can rest assured that your project will be backed up, and can be used across multiple devices.
To facilitate this functionality there will be an icon to the left of the user profile in the header bar. This icon will show a green check-mark when pending changes are synced to the server, a loading spinner when changes are being sent or received, and a “no connection” symbol when no connection can be established.
Clicking on the “no connection” icon will show the options: “retry now (5s)” and "switch to offline mode.
The “(5s)” shows how many seconds remain until the next automatic attempt to reconnect occurs.
When in offline mode, Chronicler will not attempt to automatically connect.
I’m not certain how to handle user accounts in offline mode. The best way I can think of would simply be to encrypt user data with a password similar to what 7zip allows you to do with zip files. Note that local encryption will be optional in the settings.
Regarding collaboration tools
This is probably the most complex part of the entire project. As such, it will be put on hold until the core features are complete.
(nodes are the new name for bubbles, and components are the pieces that go in them like text, actions, and choices.)
Public projects will be featured on the homepage and searchable by anyone including anonymous users without an account. Collaborators can be invited to public projects.
Private projects are exactly what you would expect. Only you can see and modify them.
Protected projects are simply private projects that have collaborators associated with them.
I will use the term “user” to refer to non-collaborators.
Users
When a user wishes to modify a public project they will have full access to change whatever they wish with the project. This includes adding new nodes/scenes, and modifying text. Any changes they make will be put into a “changeset” and submitted to the server. When submitting a changeset the user will be able to include a message explaining why they felt the change was necessary.
Collaborators
When a collaborator modifies a project, their changes are immediately committed. If they make modifications to another’s work, then a changeset is added to the project. This changeset does not need to be confirmed by the owner, however a notification will appear. All collaborators can view the changesets, but only the owner of the project can revert to a previous changeset.
Regarding ownership, collaborators can own components and can own or co-own parts of components.
For example, a text component in a node was created and partially written by Sally. Bob comes in and completes the other half of the story in that box. He also fixes a couple of typos Sally made while she was in a hurry.
The question here is: who owns what?
Sally and Bob now co-own the whole component. Any changes to it by other users will result in a changeset.
Bob now owns the half of the component that he wrote and co-owns the typos he fixed. Even though Sally owns the whole component, any changes she makes to Bob’s text will result in a changeset.
If Bob makes further changes to the half he owns, there will be no changeset.
However, if either Bob or Sally modifies the typos that they co-own then a changeset will be committed.
Changesets will be grouped under the component they are in.
Owners
When the owner logs in they will notice the “messages” icon in the header bar shows that activity on their projects has occurred. Clicking on it will take them to the changesets view for the relevant project. From there they can view the changesets either grouped by user, or grouped by change.
When grouped by change they will be presented with lists of changesets that modify the same places, and ending in a list of changesets that are distinct from each other. This way they can quickly switch between changes to the same location and accept or reject them as they see fit. Of course the owner can modify the location manually and accept that as the final change.
When a changeset is accepted or rejected, a message informing the submitter will be sent so they can see what the final verdict on that section was.
Besides modifying the project directly, users and collaborators can leave comments on scenes, nodes, and components.
Closing thoughts
Personally, I’m super excited about the collaboration tools, as that could result in some truly epic community games. However, I needs must stave off my excitement for now. I’m working on this for my Senior Project at Uni, and we are only given a short amount of time to complete it. As such I have to focus on the core features that I specified in my proposal to the professor.
I plan on drawing up some new mockup designs for these features. Stay tuned for them in the coming weeks.
I have already started converting my project from JS to Elm and am quite pleased with how that is going. Not only does the Elm code take significantly less lines, but is safer and easier to maintain. Another benefit is that it is pure functional. This means that any functions when given the same input always return the same output with no side-effects. This allows for the Elm backend to cache function calls so that when they are given the same arguments a second time, it can simply map them to the result without performing the calculation again. In this way the program will get faster the longer it is run!
I could honestly sing Elm’s praises for another hour, but I better sign off here. 
Thanks!
-BenSeawalker