Re: [Audacity-devel] Deleting selection at the beginning

[Markus M. <me...@me...>]

Shane,

thanks for the very interesting info concerning the UI research. I'd
like to add that one should _always_ try not to mix up implementation
and interface. If "silence" takes up to much space, _that_ should be
fixed, not the command "silence" replaced by another command. What
should be the default behaviour is another question, of course -- but I
think that Audacity can already be customized enough (keybaord shortcuts
etc.) so that this shouldn't matter too much.


Markus

Am Mon, den 05.07.2004 schrieb Shane Mueller um 14:10:
> On Mon, 2004-07-05 at 10:31 +0100, Daniel James wrote:
> > > > 1. Deleting a selection at the beginning of a track moves the
> > > > rest of the audio back up the timeline. This is a problem with a
> > > > multitrack project of course, because the tracks are then out of
> > > > sync. Could this behaviour be made a preference?
> > >
> > > Why not use "Silence" instead of "Delete" in this case?
> > 
> > I figure if you've got a load of blocks that you don't need, it's 
> > better to delete them (rather than silence them) to save disc space.
> > 
> > To give an example - you've got a five minute track played by a live 
> > band with a fifteen-second violin solo near the end. During the first 
> > four minutes on this track, the violin player is shuffling around, 
> > making background noise.
> 
> Although I don't think the silence function uses the amount of space you
> might think it does (it may actually be close to nothing, and probably
> no larger than a single blockfile no matter how long the silence is),
> another way to get the behavior you want is to use the trim function, as
> long as the part of the track you want to get rid of is at the
> beginning; yet another way is to select the region you want to keep and
> "Duplicate" in onto a new track.
> 
> I'm sure we've all run into situations with software we use where the
> developer takes an "I-Know-Best" attitude to feature suggestions (at
> least people like me who use Gnome), offering excuses and workarounds
> but not expressing interest in just fixing it.  I hope this doesn't seem
> like that type of situation, but the costs are not only in the extra
> time it takes to add such features---they also can add complexity for
> the regular user.  A friend of mine has done research using an eye-
> tracker to examine selection of items from pulldown menus--he showed
> that menu search is a bizarre mixture between linear search (scanning
> down the menu item-by-item) and random jumping around. Essentially, each
> additional item you add to a menu adds roughly a constant amount of
> search time for the novice user; items toward the bottom take a little
> longer, but people compensate by jumping down to the bottom just in case
> its down there, which might actually hurt them in the long run except
> that they are probably eventually able to guess where items are in the
> list; and so then it helps them.
> 
> A useful question to ask when considering adding a new menu item is
> whether the time it saves is worth the extra cost incurred every time an
> item from the menu is chosen.  Adding something to the edit menu could
> increase selection time of things from that menu by a couple hundred ms;
> if a function you introduce replaces a sequence of tasks that normally
> takes more than a few seconds, that might be worthwhile, depending on
> how often it is used relative to other entries in the menu. A 250 ms
> cost could swamp a 5 sec savings for a user who uses that menu item less
> than 5% of the times that menu is selected. I suggest that, for now,
> adding a delete-in-place is not worth the cost as it can already be
> accomplished a few other ways (add silence, duplicate, trim, or delete-
> and-manually-align). As Dominic suggested, be on the lookout for ways to
> incorporate such a function that would give us a lot of bang for the
> buck.
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Audacity-devel mailing list
> Aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel