Dev Blog #15: Threads revisited
After much experimentation, I concluded yesterday that the timeline-interpolation feature of Threads wasn't working out.
It worked - perfectly - but it had no practical use. A note visually midway between an event on Monday and an event on Friday would probably be given a time on Wednesday - but when? Who would want to fiddle around moving notes by single pixels to change the time from 11:30 to 11:45? Not to mention that moving just one note in a series would affect all the rest.
So: fun feature, but utterly bonkers. Which is why I've re-imagined it!
What happens now is that notes adopt the time of the closest connected note that has an explicit time. That sounds complicated but it's actually much simpler and very useful - an example might help:
Suppose a scene occurs at 10am Monday in which Bill and Ben have a fight. As a note, that would look like this:
Now I can connect two other notes to that scene:
These tag definitions of Bill and Ben automatically pick up the @10am timecode from the scene to which they're connected, and become part of those characters' timelines. If I change when the fight happens, the timelines will automatically rearrange themselves to match.
Time still propagates out across multiple thread connections, but now each note picks a winner rather than attempting to calculate an average - and this is made obvious by a visual highlight on threads that are 'carrying' time information.
UPDATE:
Yay! Got it working last night. Really liking the highlighting of connections; it's very clear what's going on. I also ran a stress test with 1000 randomly time-coded and interconnected notes, and propagating time-codes takes about half a ten-thousandth of a second.
One thing that did turn out to be necessary, which I hadn't planned upon, was introducing the concept of a 'home' location for notes that live in multiple drawers and places.
For example, those #Bill and #Ben notes above: suppose you push them into Bill and Ben drawers to become part of a connected character arc as well. Now there are multiple connections to differently time-coded notes - which should the app use?
By making one of the locations of a note 'special' - a home location - the app knows that is where the time-code should be calculated.
All of this will probably make a lot more sense when I manage to get a demo video together. I started at the weekend, before realising this feature change needed to be a part of it.
It worked - perfectly - but it had no practical use. A note visually midway between an event on Monday and an event on Friday would probably be given a time on Wednesday - but when? Who would want to fiddle around moving notes by single pixels to change the time from 11:30 to 11:45? Not to mention that moving just one note in a series would affect all the rest.
So: fun feature, but utterly bonkers. Which is why I've re-imagined it!
What happens now is that notes adopt the time of the closest connected note that has an explicit time. That sounds complicated but it's actually much simpler and very useful - an example might help:
Suppose a scene occurs at 10am Monday in which Bill and Ben have a fight. As a note, that would look like this:
@10am Bill and Ben have a fight!
Now I can connect two other notes to that scene:
#Bill: Angry at Ben and has a black eye.
#Ben: Angry at Bill and has a broken nose.
These tag definitions of Bill and Ben automatically pick up the @10am timecode from the scene to which they're connected, and become part of those characters' timelines. If I change when the fight happens, the timelines will automatically rearrange themselves to match.
Time still propagates out across multiple thread connections, but now each note picks a winner rather than attempting to calculate an average - and this is made obvious by a visual highlight on threads that are 'carrying' time information.
UPDATE:
Yay! Got it working last night. Really liking the highlighting of connections; it's very clear what's going on. I also ran a stress test with 1000 randomly time-coded and interconnected notes, and propagating time-codes takes about half a ten-thousandth of a second.
One thing that did turn out to be necessary, which I hadn't planned upon, was introducing the concept of a 'home' location for notes that live in multiple drawers and places.
For example, those #Bill and #Ben notes above: suppose you push them into Bill and Ben drawers to become part of a connected character arc as well. Now there are multiple connections to differently time-coded notes - which should the app use?
By making one of the locations of a note 'special' - a home location - the app knows that is where the time-code should be calculated.
All of this will probably make a lot more sense when I manage to get a demo video together. I started at the weekend, before realising this feature change needed to be a part of it.
Comments
Post a Comment