I was planning on mulling over this question then spouting something deeply insightful. I mulled too long, and I think the general points have been addressed, though for the sake of getting everyone on the same page, I'll rehash them here.
Commonly having users express a *need* to lock tracks to protect them is symptomatic of: 1) Insufficiently obvious (or an absence of) ways to protect 'finished' parts. 2) Very flat access coupled dangerously subtle effects of edits and too little protection from accidental operations. The Lumiera 'protect' model can be served effectively and without added complexity through the steps select tracks -> create containing 'meta' track -> lock this new track. A simple, consistent, and logical selection model would be a selection on a per-track basis when tracks ends are clicked; alternatively when clicking/dragging across clips in the timeline those clips are selected, along with---this is important---all filters/media that interacts with them. This will very visibly and gently tell the user that if they want to protect those clips, then they will either need to also protect this related media further out or slice the related media to ensure consistency. Not explicitly having the user select slice points leads to scores of scenarios where subtle interactions either break our lock or they frustrate the user with invisible, unexplained restrictions. If this operation turns out to be common, we can always offer a selection context menu option to do it automatically and a keybinding. Of course, creating a meta-track from a selection described above is fairly trivial (one context menu entry/keybind/button) and obviously should be highly accessible. Locking the track should be closely related to disarming it (in the interface, that is), but it has the obvious difference that it's still used in renders/previews/etc. The problem of easy accidental edits is more subtle, and I don't think lucidly discussable outside a much more complete interface. However, a visible by default undo/redo stack with a little animation to indicate new edits could catch the eye of many (most?) users and let them know they changed something by accident. Other thoughts: I agree that locking should be really solid. I also think that a good 'collapsed' tree design (including that in collapsed view the track can only be moved/etc. as a single block) would allow a simple way to do things like re-arrange finished sections adjust times and so on without 'ruining' our lock's purpose. I think that anchoring the locked clips to their start time is the most understandable paradigm for users---I know there are some ideas about pure relative positioning that have been discussed before, but in the GUI this should probably not apply to locked entities. On 13:54 Fri 18 Jul , Ichthyostega wrote: > Christian Thaeter schrieb: > > [01:01] * cehteh talked with his wife earlier what features she misses > > in cin and would like for lumiera > ... > > [01:03] <cehteh> very high on the list is 'grouping' .. that is you can > > have a 'armed' selection of tracks and then do a vertical selection on > > the timeline > > [01:03] <cehteh> and define this things to become a group > > [01:04] <cehteh> this group shall be protected (thats very important) > > from editing by default > > [01:04] <cehteh> and is only moveable as a whole > > Wow! I count this as an indirect support for my placement proposal.. ;-) > > ... > > [01:07] <cehteh> with cin i often hear that beginners destroy hours of > > work with one wrong click .. so thats reasonable to protect things which > > are supposed to be finshed (for now) > > This is a real problem and not limited to beginners. The more complex > the Sessions you create are, the more you are prone to destroying > already finished things inadvertently. > > > [01:11] <rcbarnes> I'm stil confused about what problem this solves. > > [01:11] <rcbarnes> Is it just protecting from accidental edits, or is > > there something more? > ... > > [03:42] <rcbarnes> cehteh: I still have to figure out if adding a > > different feature can't be obviated by cleaver use of what's already > > planned, so as to reduce complexity. > > I am fully in support of rcbarnes' argument here. I don't think we need > a "feature" especially for this. > It is OK and reasonable for a user to request a "feature". Because the > user thinks in usage stories, and (s)he wants to "have" a solution for > each "issue" (s)he is aware of. But as developers/designers we should > always -- at least initially -- try to withstand the temptation to use > these feature requests immediately as recipes to direct our work, for > sake of the sanity of the interface and application. Most "features" > out there can be decomposed into a small number of primitives, which > are often already there or only need to be augmented a little. Even > if such an approach is a bit more demanding for the user (because > he has to learn how to achieve things by using the standard set of > primitive actions provided by the application instead of just > using some pre-configured macro operation), on the long run > it even helps reduce the mental burden for the user, > and increases "discoverability". > > > Thus, considering the problem at hand > > * it is clear we need a "locked" state. And this locked state should be > /really/ airtight. Quite a lot applications provide such a locking, > which more often than not isn't of much real use because it does > leave some loophole for messing things up without notice. > So, locked objects should be completely intangible. > * we have meta-clips for complete sub-EDLs which can be used as > building blocks. We could consider to provide a function for > converting a selection into a meta-clip and another function > to expand/import/extract a metaclip immediately into the current EDL. > * again my Placement proposal. There are a lot of things which aren't > "properties" of the object as such, but are rather due to the fact of > being located at some point in configuration space. This is how the > real world works, but it may seem strange in the context of computer > software interfaces, where we all got used to the obvious workaround > of sticking a pseudo-property to the object to simulate such > relation-tied behaviour. > In my proposed/planned/drafted implementation of Placement, I wanted > to have relative time positions (besides absolute positions), and > further I wanted to have a "stick-to" placement which would tie > objects together and derive any unspecified properties-of-placement > by querying the group. The most important use case for this stick-to > placement would be effects attached to a clip, but it would work as > well for a cluster of clips. > * then only missing part now is a elaborate selection feature in the > GUI, which would allow to create range selections, area selections, > arbitrary selections, track tree based selections, maybe even > selections by some tag or wildcard. > Then you would be able to apply operations to all selected objects, > "for example" you could add a stick-to placement property to them, > thus creating a group, and then apply the locking (which will be > propagated to all sticked-together objects, of course) > > > Cheers, > Hermann V. -- Clay Barnes Website: http://www.hci-matters.com GPG Public Key (Fingerprint 0xBEF1 E1B8 3CC8 4F9E 65E): http://www.hci-matters.com/keys/robertclaytonbarnes_public_key_until20130101.gpg https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0xE1B83CC84F9E65E8
signature.asc
Description: Digital signature
