Re: some usability review

[Tim Janik <timj gtk org>]

On Thu, 16 Dec 2004, Stefan Westerfeld wrote:

> I've just made an informal usability review, in which a first-time BEAST
> User, who knows enough about music to know what he wanted to accomplish
> try the GUI. The task he wanted to perform was to enter a drum beat and
> create an ogg file from it.
>
> We used Debians beast-0.6.2 package for the test, and I gave some help
> over the phone.

hm, i'd not call that a "usability review" yet ;)

> 2. it may be useful to allow click & drag note setting, that is
>   (a) you click on the start of a note
>   (b) you move the mouse while still holding the left mouse button, to
>   adjust the length

that works already.

> 3. when editing drums, the default behaviour of the piano roll, to round the
>   note value to the next/previous quantization value is not intuitive -
>   since drums are virtually zero length, truncating down to the note
>   start would be more intuitive

i'm sorry you don't make sense here. first, you talk about the default
quantization setting of a piano roll which is obviously tuned to be
suitable for notes, not drums. then you talk about "rounding" notes.
do you mean quantization based alignment of the note start or the
default note length which is 1/4th?
finally, what do you mean by "truncating down to the note start"?
at what point should truncation occour, what's it's purpose and
when do you envision that to occour?

>   implementing a drum editor with zero-length notes, which are set on
>   grid crossings would solve the problem:
>
>   Snare  -----|--------|--------X--------|----
>               |        |        |        |
>   HiHat  -----|--------X--------|--------X----
>               |        |        |        |
>   Bass  ------X--------|--------|--------|---
>               |        |        |        |
>   Tom1  ------|--------|--------|--------|---
>
>
>   for drum multisamples such a drum editor could provide intuitive labels

implementing a drum editor will obviously suit the user better than a 
piano roll, when editing drums.


> 5. the user wanted to edit a 2/4 beat, for which the grid lines in the
>   piano roll editor are misleading - configuration would be useful

implementing different piano roll grid settings is currently blocking on you.

>   => other items:
>
> 6. the beast.gtk.org site does send Text/Plain as mimetype for .bse
>   files - this makes downloading the files with browsers such as
>   firefox harder than it should be, because firefox's default is to
>   show the text file, rather than to save it, which in our test made
>   the browser crash (during trying to download 808-kit.bse, a 4.7 Mb
>   multiwave drum sample)

file a bug against firefox for the crash, and send an email off
to yosh <yosh gimp org> for any issues you have with the apache
setup at gtk.org.

> 7. 196.73282883 bpm in the song doesn't look too nice; maybe it would be
>   better if adjusting the slider would only set the bpm value to
>   integer values

it definitely wouldn't be better, because that would allow much
coarser settings only. you attempt to trade aesthetics for
usability here which is basically always wrong.
to improve the display of the bpm setting, reduction of the amount
of displayed fractional values seems like a better idea to me (say
(2 ior 3).

>   BEAST should do one of the following:
>    * show parameter tabs in separate windows
>    * show a dialog "file has been modified, save?"
>    * autosave, so that the file could be recovered

these are all items mentioned in the TODO already.

> 10. a file filter, to see only those files that are relevant for the
>    current save operation would be beneficial, i.e.
>
>    [ *.bse   BSE files ]
>    [ *       all files ]
>
>    or, likewise *.wav for export audio, or *.mp3, *.ogg, ... for load
>    wave

Gtk+ has traditionally not employed file filters. well see whether that
changes if beast is ported to the Gtk+-2.6 file chooser.

> 11. the export audio function isn't easy to understand
>    * it is not clear how to start audio export
>    * it is not clear how to make no audio export happen
>    * the file save dialog can't be used for unactivating audio export,
>      the only way to accomplish this is to delete the text entry AND
>      press return, which doesn't lead to confidence that nothing will
>      be overwritten, once this was done

i do not understand why or how the file save dialog should stop
beast from recording sound.

>   suggestion: replace the whole functioniality by "File -> Export Song as
>   Audio" and "File -> Export Loop as Audio"

i don't see how this would be an equivalent feature. the Export Audio
feature records everything that is produced by the current interactive (!!)
session to a WAV file. offline rendering of the sound file is not a
suitable replacement for that.

---
ciaoTJ