Causality Wishlist

Hi,

Great! Quick notes:

I think that anchoring a tag to text will be doable. This will be how comments will work in collaboration as well. The comment is in actual reality attached to the beat, but it'll refer to specific text. The trouble is the life cycle, because text is fluid, and it's very difficult to maintain identity for specific text as it's copy/pasted/edited/replaced/duplicated. So things will anchor to text in a best-effort kind of way, but if the text deteriorates too much, we'll stop attempting to refer to specific text.

We may look into a toolbar, but we're very conservative about real estate, because once we crowd the real estate, lots of UI will stop working as a concept and then need new solutions. Truth be told, the primary reason we're looking at it is simply familiarity. We know that we're "weird" in terms of being a very different way to manage a story, and the presence of things that people already know allows them to get past the perceived unusualness. This is the kind of problem that goes away when everybody knows Causality. In the beginning, people had all kinds of questions about Shot Designer. All of that has gone away. Now we only answer two kinds of emails, activation, or a specific crash we're unable to make go away in the current iteration. Few people wonder how to use it.

On tag colors, there has been some talk of multi-colored beats, i.e. a primary and a secondary color. Having drawn lots of prototypes for this, I don't believe in this idea. Basically, you can't highlight everything. Color must have immediate meaning, and everything else should be colorless or neutral. If everything is colored, then none of the coloring provides any meaning, you tune it out. Every prototype that tries to do multi-colored beats looks like confetti. It barely works in a still image, which guarantees that it won't work at real-use speed. But if we went in this direction, you could have an option that the first and second tags/characters color the beat. We're just driving dangerously close to the edge where color loses all meaning.

On Undo, we don't do anything deliberately to flatten the undo stack, except when we really have to, which is rare, only a couple of special operations. I think you're seeing actions that break into two undo-steps. Try to press undo one more time. This is a regression we're tolerating until we can rewrite the functions that need this.

On image support, this will all come with the distributed data model for sync. We can't direct-link to files, because that won't work if the document is cloud-connected, which you also need for just working on several of your own devices.

A feature you'll also want is a feature planned for a long time where you can have multiple expressions side by side, i.e. a screenplay version and a book version. Or a comic book version and a plaintext scratchpad version, or write multiple language editions as the same time.

Hi Per,

Thanks for taking a closer look at the points I raised and for your detailed feedback. Animated Graphic Novel

To give a little bit of background I am using Causality for a long format animated graphic novel and normally work in Onenote to write my scripts, because I haven't found any screen writing format that fits my way of writing a story, until I discovered Causality that is.

Onenote

The thing I like about Onenote is the free flowy way it allows you to work, building or writing starter ideas and beats, outline them in chronological or thematic order and then build from there. However it is not so good at the later stages of writing a screenplay and that's why I'm looking into other solutions.

I have to say that causality really fits my way of working without feeling "boxed in", except for the beat editor maybe. As for your immediate feedback here's my thoughts Tags I would be quite happy to have the tags still sitting on the top of the beat and being linked to the beat object, but it would be nice to "anchor" it to a specific sentence or paragraph, so I don't have to search for it which can get repetitive if you have longer beats. I understand that you've made high level decisions for v3 of the software and wouldn't want to go "against" that flow. Timeline Navigation / Script Sync I have the timeline in a separate window, the script window to fullscreen and the sync button on. When I now click a beat in the timeline, it will take me out of full screen mode, but when I also have the whiteboard as a separate window, then it behaves as you would expect Visual Cues I agree on the inspector which is definitely helpful in most scenarios. I understand about the touch aspect as well and would be curious to know how many people use causality on a touch device. Text Formatting

Spelling, text formatting and paragraph style are all in the right click menu, which is good but it's definitely not a visual way of editing text, but maybe that's personal. A hovering toolbar feature, like the one I used in writing this post would be great. Tag Color For the tag color I can follow your thinking for keeping it as it is, which is fine, unless you have more than three or four tags on a beat and there is no "winning" tag.

Side by Side / Nesting

I use the side by side work method all the time in Onenote and it's great for messyheads like me that want to write in a visual way, with bits and pieces (notes, version etc…) floating around the same beat until it gels together and I can copy/paste/rewrite it into it's "final" shape Crashes As for the crashes, I have to say I've been having hard disk problems and have replace dwhat I think is the faulty drive yesterday, so that probably explains a lot of the crashes. Undo Undo is so important to not feel like you're bound by what you've done, so any improvements there would be great. As for the last two points, I will have another go to see if it's not me still being a causality newbie. Images/Storyboard And finally, as this is for a long format animated graphic novel, being able to import images would be great, but I'm sure there's other items on the priority list. Thanks again for the feedback, Iwan

Hi,

On tags on text, this isn't technically possible, and I'm also not sold that it's good. But technically, it's a massive and deep rewrite of the app that fundamentally changes hundreds of assumptions. It would also need a whole new kind of UI that shows tags inside the text, and the confusion would be endless about where a tag is, because now you can't know whether a tag is on a beat or somewhere inside of it. We need to stick to things happening at the object level. Getting rid of a lot of this kind of ambiguity for 3.0 is a huge success, and it re-teaches the lesson that ambiguity causes a lack of intuition about the state of the app, which slows you down overall and forces the app into countless contortions in order to display and react to ambiguous information. I'm happy to air the idea for the team, but this is with 99.99% probability not going to happen.

On selecting beats in the timeline, that's strange that that doesn't already work. The intention is as much as possible that these are just different views on the same thing and it shouldn't matter where you make the selection. Does your app not scroll to the beat and highlight it? Is the running man icon in the bottom right disabled?

Visual cues, yes, and we used to have more of that. The reality is that even with the inspector on the screen, your eye simply doesn't go over there. And it wouldn't be very disruptive to have icons with a popup menu to show additional information directly on a beat. The only real downside is that the hover you'd use to do this on desktop doesn't exist on mobile, so it's not a complete solution, i.e. only solving a problem by introducing a hover is not a true solution. So we'd need to answer how this works on a touch interface.

On bullet lists, this was something we postponed for later. It's actually something that's native to the text editor, and we disabled it, because we need to answer how to encode it in our text format. But agree, for non-fiction, it's a very missing feature. I've moved it higher on the list. Truth be told, we're soon going into the cave to work on collaboration for a while, and we're ruthless about which features are allowed to get in front.

I don't understand the text format being too clunky suggestion. Which dropdown? If this is about not having buttons for bold/italic/underline, consider that these are on the keyboard, and we're keen on not plastering the app with ribbons and panels. Where a word processor doesn't need the real estate, we desperately do, and the app as a whole is hurt by having too many panels that are rarely used. Our contention is that nobody is dying from not having panels, and power-users want to use the keyboard anyway.

On tag color, we'd rather that if the tag is so important that it should color the beat, it's also not wrong to have it first. It's just that these kinds of suggestions are just adding new dimensions and micro-configuration, which turns around and becomes ambiguity. I don't agree that this needs a separate a new configuration dimension. Move the tag first. If it's important enough to color the beat, it's also important enough to be first.

Interesting idea to have multiple versions side by side. I see the utility. Technically, it's quite a curveball, but I'll put it on the list. It was actually always intended that you could have two versions side by side in a Diff view to see what was changed. This would also be necessary for some conflict resolution in collaboration. So this problem will have to be solved. The dialogs are just hard-coded right now to make it difficult. It will need some thought.

Are you submitting the crashes? Our crash volume is quite low. Please email the email address you've used on reports to support@hollywoodcamerawork.com. Are the crashes tied to anything, a specific action? Sometimes one single user has 80% of the crashes on a given version, because their intuition of the app or their specific document makes them take a specific route that crashes, and nobody else takes the exact same route. So it's quite possible we don't know about whatever issue you're having. And no crash has the dozens of crashes you seem the allude at (all our crashes are little corner cases with 1-2 incidents). So we'll need some help to understand this.

Undo is back to the beginning of the session. There are some actions that have to flatten the undo stack because they cannot be undone. We have also allowed some actions to require two undo steps, which is an anomaly we're tolerating because we're getting rid of some code that was merging commits. Once the sync data model is operational, we can let multi-step actions be a single undo step again. This is in an area of some code that we're throwing out shortly, so we'd rather not invest weeks in it and then throw it out immediately after.

Which auto-complete is that you can't get working? Character names? Scene headings? Specific fields? We don't have any awareness of any problems here, so we'll need some help to understand it.

When you mention having to click parenthetical twice, where are you clicking? System menu? Toolbar? Right-click? Keyboard? On that note, most people simply use the automation, and typing "(", which switches them to a parenthetical line. It sounds like you're selecting styles a lot by clicking, which is quite unusual. Could you describe this workflow and why you're doing it this way?