[mythtv-users] cutlist editor feedback (was Re: cutlist editing hangs frontend)

Tue Nov 16 01:33:40 UTC 2010

On Sun, Nov 14, 2010 at 05:43:21PM -0500, Michael T. Dean wrote:
>  On 11/14/2010 05:29 PM, Craig Sanders wrote:
> >actually, it doesn't. having to hunt and peck for the M key rather than
> >the Enter key sucks. that change might be justifiable if there were
> >actually a good reason for it, but there isn't - it's just an arbitrary
> >change with no benefit.
> 
> FWIW, there is exactly one situation for which you need to use the
> MENU key.  Every other action can be done with only SELECT and the
> directional keys.***  

that statement directly contradicts the documentation you pointed me at,
in http://www.mythtv.org/wiki/Editing_Recordings, which says that (as
well as the obvious menu-appropriate functions) the MENU key is used for

 - cut to beginning or end of recording (2 operations, but i'll count it as 1)
 - deleting an individual cut (but see below)
 - moving the start/end of a cut

since it IS possible to delete a cut with just the enter key,
that leaves two situations where you need to use the MENU key:
cut-to-beginning/end AND moving the start/end of a cut.

some specific detailed comments:

DELETE:

deleting a cut is also avail via DELETE(D) key which is, admittedly,
different from the MENU key but still requires a hunt and peck to find
it on a keyboard in a darkened room. it's also close to the E key, so
it's possible to accidentally save-and-exit before you're ready.

with the old editor, SELECT/Enter provided this function.   IMO, it still
should - hitting SELECT/Enter should:

 1. inside a cut, popup a menu allowing user to delete, move start, or
    move end of cut. (this already happens - nice. should be documented,
    though).

 2. outside of a cut, popup a menu to add a new cut, move the start of
    the subsequent cut (if any) or move the end of the prior cut (if
    any).  cut-to-start and cut-to-end options should also be on this
    menu.

    the default could simply be "Add" or it could be context-dependent
    - if "close to" a prior/subsequent cut then default to moving that,
    otherwise default to add.

that would make *ALL* adding/moving/deleting operations controllable
entirely by SELECT and the arrow keys, same as the v0.23 editor.

which would leave the MENU key for quit, save & exit, undo all changes,
clear, invert, LOADCOMMSKIP etc.

CUT TO START/END:

the cut to start/end functions *seem* unavailable much of the time. it
seems to be available ONLY if there are no other cuts before/after the
cursor. to make matters worse, often there is an "invisible" (too small
to see on the edit bar) cut at the very start or end of the recording
which prevents the cut-to-start/end functions from being available.

it would be useful if they were always available, merging all
prior/subsequent cuts into one big cut to start/end - some channels
routinely screw up their schedules making it necessary requirement to
record 10 or 20 minutes or more before and after each recording, and
these extra minutes often have commflagged cuts in them.

being able to move the cursor to a cut and just press SELECT and then
cut-to-start/end at that point without having to manually delete each
cut before/after the cursor (losing your cursor pos in the process)
would eliminate much of the feeling of clumsiness i reported.

in the old editor you could just insert a new cut pointing either
forward or back and then move to each cut before (or after) that,
hitting Enter twice on each one to delete them. this was extremely quick
and easy to do.

e.g. if there were 3 cuts remaining after the cursor then something like
<right><Enter><Enter><right><Enter><Enter><right><Enter><Enter> would
delete them all, taking a fraction of a second to type that. minimal
keystrokes, minimal hand movement, no hunt-and-peck.

the new editor's cut-to-start/end function has the potential to be even
quicker and easier by eliminating the need to delete the extraneous
cuts, but it isn't. one small change (making the menu option available
regardless of any prior/subsequent cuts) would fix that.

MODAL EDITING:

the SELECT/Enter key often seems like it is completely unresponsive, but
after some experimentation i've realised that the major problem with it
is that the editor provides no feedback to the user what "mode" they're
in - there are three modes: normal cursor movement, add start of cut,
and add end of cut. there's no indicator to tell you what mode you're
currently in. 

this is probably the root cause of my previous comment that the Enter
key works inconsistently (and why it took me until this morning to
notice that pressing SELECT inside a cut actually does pop up a menu to
delete/move start/move end - *IFF* you're not in the "add end of cut"
mode)

I've got no problem with modal editors (i'm a vi user so i'm used to it
and like it), but there really needs to be some kind of indicator to
tell the user what the current mode is, so they'll know what the SELECT
key will do next time they press it. 

this would, no doubt, require support from the theme (i only use
MythCenter & MythCenter-Wide so i have no idea if a mode indicator is
already available in other themes)

Just having a menu for SELECT as mentioned in point 2 in the "DELETE"
comments above would partially solve this - it would alert you that you
were about to enter insert-cut mode, but you'd still have no way of
telling what mode you are currently in.

INSERTING CUTS:

I haven't quite figured out what exact circumstances trigger it, but
i've noticed a few times that if i insert a new cut that intersects an
existing cut then the editor doesn't merge them into one cut. i *think*
it might be partially merging them as moving the cursor by cut-point
takes 1 or 2 extra pushes of the arrow/pgup/pgdn key.

this seems to happen when one of the cuts is "small".

WISHLIST:

1. it would be very useful to be able to bind cut-to-start and cut-to-end
to keys.

2. ditto for move-start-of-cut and move-end-of-cut.

3. an "undo last change" feature would be great. even better would be a
multi-level undo/redo feature. this undo & redo should be on the SELECT
popup menu, not the MENU menu(*). and, again, binding undo/redo to keys
would also be useful.

(*) the MENU popup would keep the "undo all changes" option. the
difference is that SELECT is for individual edits, while MENU is for
stuff to do with the entire editing session.

4. a 'save and exit and queue a transcoding job' option would be useful.
and would be even nicer if you could choose the kind of transcoding
(incl. lossless aka honor-cutlist only) from a submenu.

5. summarising this wishlist and the other comments in this post, here's
what i think the SELECT and MENU popup menus should have:

SELECT popup:

 - add cut
 - delete cut
 - move start of next (or current) cut
 - move end of previous (or current) cut
 - cut to start from here
 - cut to end from here
 - undo
 - redo

MENU popup:

 - quit
 - save & exit
 - save & exit & transcode (w/ submenu)
 - undo all changes
 - clear all cuts
 - invert cuts
 - LOADCOMMSKIP

ODDITIES WITH RETURNING FROM THE EDITOR TO THE PLAYER:

This is (probably) a bug in the player, not the editor.

i've also noticed that if i exit the editor while the cursor is in the
final cut-to-end cut, then the player sometimes (usually) is confused
and gets stuck repeating/stuttering on the current frame - seems like
it doesn't realise it's at the end of playable content and should just
exit. pressing ESC to exit the recording works.

> And, truth be told, if you really wanted to, you could perform that
> one action in that one situation that requires the MENU key using only
> SELECT (though half of the time it would require one more button press
> than just using MENU and the other half it would require exactly the
> same number of button presses).
> 
> Determining exactly what that situation is--and how to use the
> editor such that MENU is unnecessary or mostly unnecessary--is left
> as an exercise to the interested reader.

being arrogantly mysterious does nobody any favours - do you want users
to actually understand your work on the editor or just be condescending
towards them?

> Also, note that when you're complaining that the developers didn't
> consider usability and made things more awkward, it's obvious you're
> assuming everyone edits recordings the way you do.  

funny, i think that's exactly what you're doing.

you're the developer, so if It Works For Me is one of your design
goals, then that's your right - but don't be surprised if others say It
Doesn't Work For Me, especially if you've changed or removed existing
functionality that they'd got used to and come to depend upon.

one of my programs that i released had a feature which worked *exactly*
the way i wanted it to - but many (most? all?) users assumed that it
worked or should work differently and i got numerous duplicate bug
reports about the same thing.

some would say that feature was Broken-By-Design.  I say It Worked For
Me. both were true.

I eventually got tired of explaining why it worked the way it did, gave
in, and made it work the way most users expected it to work. the bug
reports stopped (hooray!).  I still think that it wasn't actually a bug
but a) the constant bug reports were annoying and b) when i wasn't being
stubbornly annoyed about it, it was obvious that it made more sense to
make it work the way that most people expected it to work.

> Remember that not everyone in this whole wide world gets good results
> from MythTV's commercial detection.

i get anywhere from poor to reasonable results from ad detection,
depending mostly on the channel but also on the show. good enough to use
it as the base for editing (mostly i just have to adjust the start & end
points of the commflagged cuts, and do big cuts at the begining and end
of the recording. and maybe add or delete a cut here or there).

> Note, also, that you may find that if you were to change the way you
> used the commercial detection when editing recordings, you may be able
> to edit recordings even more efficiently than you could with the old
> UI (and using fewer button presses--and no need for MENU or hitting
> keys that are close together, other than the arrow keys).

it would be nice if that was the case, but it isn't. see detailed
comments above.

hopefully some of my feedback will help to make it possible.

craig

-- 
craig sanders <cas at taz.net.au>