[Lumiera] GUI comments and suggestions

[Joel Holdsworth]

> That is a good idea too, although I would probably make this an option
> enabled rather than disabled by default.  Users acquainted with other
> editing applications will be very confused if they see the usual
> buttons are missing.  Also, many people simply are not keyboard savvy
> and will still use the buttons for editing.
> 
> This also brings up the question of whether button assignment should
> be a feature (if it's not planned already).  In Avid you can assign
> buttons to certain locations in the viewer windows and timeline.  I
> personally like this feature as it allows me to add features I use a
> lot and remove those I don't, as well as design specific interface
> configurations for if I'm working on, say, effects, and then switch to
> working on audio mixing.  Different editing scenarios call for
> different buttons, so it would be useful to have the ability to
> reassign buttons.  I did not see anything about this in the GUI
> brainstorming page, so I thought I'd mention it.
> 
> As far as the gui is concerned, the editor should have control over as
> much of the interface as possible.  Being able to rearrange and resize
> windows at will, open/close panels and controls, except for what is
> needed for the task at hand, and button reassignment are all
> invaluable because although we as the designers can create default
> layouts which seem intuitive to us, they will inevitably be
> unintuitive to others.

The current planned approach to solving this problem is through
"perspectives" - which are a series of stored panel layouts, where the
GUI is configured for specific tasks. Eclipse has similar functionality,
it works well, and so I'm planning to include it.

> The task of editing is a work of art, and every single editor I know
> has a different editing style.  Some use just keyboards, others use
> mouse/keyboard, or even just the mouse, and you will almost ALWAYS
> find that they another editor prefers their panels laid out is
> different than your own.  Editors are like painters, and rarely will
> one set of tools or working environment be ideal from one person to
> the next.

> Some things must be hard coded, of course, but the bottom line is that
> any on screen element that can be relinquished to the editor to
> control in one way or another should be.

Customization is only good in a few limited and carefully selected ways.
It easily becomes an excuse to avoid tough design decisions which lead
to simplicity - we aim to produce a GUI that is comfortable for everyone
with no customisation, and then where it helps add small amounts back
in.

> That's not a bad idea, although if the video has a burn-in window
> itself, the two could conflict with one another.  I think a small
> amount of screen real estate for the TC window is not unreasonable,
> and it is standard in every editing app I know of, but doing it as an
> OSD layer that could be toggled on/off would also work for me.  We
> should probably discuss this more to come to a consensus on how to
> implement the TC window.

I don't want to rely on overlays for the TC, because people mostly want
to see all of the video. This means that we will need to put the TC
readout elsewhere. There's no sense in having a double TC readout, and
it seems that the readout belongs with the transport control set.

> Most features should be designed to conform to the
> 'norm' which all editing applications abide by.

Yes I agree, there's no shame in the 'norm' - the norm is good. Lumiera
should be normal to use not weird, but with the addition of unique
features that give the user new power - but all set on the backdrop of
the 'norm'