On Sun, 2012-10-28 at 12:20 +0100, Éloi Rivard wrote:
> An efficient way to discover and find commands could simply to sort
> them in categories. I made a mockup of a "command manager" with a
> simpler interface than the current one.
>
> Images intégrées 1This sounds generally on the right lines. Three general comments:
>
> You can see command groups on the left. Let's imagine a command can
> appear in several group, with a tag mechanism for instance. The "Lorem
> Ipsum" is the selected command description.
>
> The top toolbar contains several items. The command set list shows all
> the sets reachable by the program (users and system ones) plus a
> special entry "Create a new command set". The first button allows you
> to save the set, the second one to load the default set. The third
> button is the current "find" one: user type a shortcut and the
> corresponding command is found. The search bar allows you to search in
> the commands (let's say name and description) instantly.
>
> With such a system, beginners will be able to find a command as they
> are sorted and have explicit names, and experienced users will be able
> to find a command by typing its name directly or with its shortcut.
>
> What do you think ?
1. It would be important to generate the data to populate this
command manager automatically, otherwise it will get out-of-date
as Denemo progresses and will not be trusted by users (like the
manual). This is slightly messy because, for historical reasons,
we have built-in and scripted commands. However they are all
seen at one point during start-up, and so the generation of the
data could be done there (either at runtime or done by the
developers before making a release). Some work would need to be
done to classify scripted commands (eg tag them by the groups
they belong to).
Scripted commands are stored in XML files that already have some meta data fields (author etc.). An XML field "tag" for instance should be OK for this ?
2. "Command Groups" - there are several ways of grouping commands -
earlier in Denemo's history we had two complete menu systems,
one by action (create, delete, move, edit, show_properties, ...)
and the other by object (score, movement, staff ...), with
commands appearing in both. Using tags instead the user could
select one or more tags and the command list would change
accordingly.
A tabbed group list should solve this. You choose some tags/groups to be displayed in an "action" tab (create, delete etc.) and put the rest in a "categories" tab.
3. "Command Sets" - currently these correspond to files
with .shortcuts suffix. These determine whether a command is
hidden from the menu system and what shortcuts if any it has. As
long as your new command manager was very conspicuously
available I think it would be ok to have both shortcuts and
"hidden" set on one command. Which is where the discussion
started - why have a menu item for "move cursor right". This is
missing from your mock-up I think - a check-button for whether
the item should be in the menus or not.
An issue in Denemo currently is that menus have an informative purpose more than a action purpose. Some entries are just here to let the user know that they exist (like indeed "move cursor to the right"). Now if the "informative" function is carried by this command manager, some menus entry should be disabled by default, making some menus a bit clearer.
Here is an updated mockup:
I think these ideas will benefit from comments from others too if they
can spare the time. This would be a great improvement in usability.
Richard
Éloi
>
> 2012/10/27 Richard Shann <address@hidden>
> On Thu, 2012-10-25 at 19:10 +0200, Éloi Rivard wrote:
>
> > And maybe you can consider a fourth way to use denemo. Users
> doesn't
> > write music at all, but just want to read existing
> partitions. That's
> > the case for my brass band : musicians just play the
> partitions with
> > Noteworthy, and play music over it. They are helped with
> what plays
> > the software, and the moving cursor on the partition.
>
>
> Denemo would need more work on the MIDI generation to make
> this
> attractive - the MIDI playback is there just to check (by ear)
> that the
> notes are correct. Even this is incomplete - it does not play
> grace
> notes.
> There will be other possible uses for Denemo - particularly
> music
> analysis (we have a routine that checks a composition for
> consecutives
> already), and I hope people will develop these. I was thinking
> about
> things that Denemo could be recommended for right now. Right
> now it is
> strongest at entering music quickly, accurately, and
> musically, and
> delivering a high quality printed score without manual tweaks
> to the
> appearance (thanks to LilyPond). I don't know how it compares
> with other
> programs for playing along with the playback...
>
> Richard
>
>
>
>
>
>
>
> --
> Éloi Rivard - address@hidden
>
> « On perd plus à être indécis qu'à se tromper. »
>