On Thu, 2001-11-22 at 15:14, Josh Sled wrote: My comments on this are purely from an end user point of view. As someone who is spending a lot of time looking at portions of the GnuCash interface (while doing docs) this seems like a good time to comment on some aspects of the UI. I would encourage you also to look at the GNOME 2.0 HIG http://developer.gnome.org/projects/gup/hig/draft_hig/ and http://geocities.com/mpt_nz/ig2h.html
>
>
> RFC:
> Refactoring window-register into a composite widget and containing window.
>
>
> Proposal
> --------
>
> Each of the widget-register's contained UI sub-elts is exposed to the caller
> for modification; for instance, the window-register itself adds the following
> toolbar actions:
>
> . close
>
> . transfer
> . find
> . report
> . print
I feel that even in the main window-register we have to much space being
used. This results in a menubar that stretches across the screen. It
would be nice if we could either cut the size of the toolbar space used
down and/or have a toolbar that only showed text for items where it's
not clear what purpose they have. I have attached a file showing an
example of the sort of icon/text combination I'm thinking of.
(toolbar.png) In this example obviously the print icon itself is clear
enough to not need a text description (I used that as it was the easiest
icon to attach text too). This shows how we could use a text description
beside the icon to minimise screen use and leave other icons whose
purpose is clear without text descriptions. Tooltips can also make the
icon's purpose clearer.
>
> The popup menu, as well, will perhaps want to be modified by the caller; in
> the SX Editor, there is no menubar on the dialog... thus there is no menu bar
> for the actions which are currently in the window-register's Register, Edit
> and Transaction menus. A subset of the menu options provided by the
> window-register [such as modifying the display style, exposing cut/paste
> functionality] should be provided by the context/popup menu, or perhaps in
> the toolbar... but in any case, the caller will want to modify the existing
> menus where necessary to provide all appropriate functionality.
>
In general I think it a good thing to have only the menu items necessary
to use that piece of the register available.
>
> . Creation, by passing in the display_ledger to use, already configured
> for/with the appropriate type/Query.
>
> [ These are the common actions between the toolbar and popup menu... more
> importantly, they seem "common" to both uses of the register. ]
> . Enter
> . Cancel
> . Delete
> . Duplicate
> . Schedule
> . Split
> . Blank
> . Jump
> . Transfer
>
> . Style options
> . Basic, Auto, Journal
> . Double-line
>
> . Copy [split | txn]
> . Cut [split | txn]
> . Paste [split | txn]
>
> Unsupported
> -----------
>
> The following functionality will be supported by the caller, if necessary
> [read: the window-register will support these, as the SX-based callers won't
> use it]
>
> . Sorting
> . Date-range selection
> . Account editing/creation
> . Check/repair
> . Find
> . Report
> . Print
> . Invoice
> . Stock splitting
> . Reconciliation
>
I find it confusing that in the Register windows the menu that I would
expect to be the first one (Transaction) is the 4th. The menu's in
general in GnuCash are fairly confusingly laid out, for example if I'm
going to edit an account's details I would expect to find this action on
an Edit menu, not the Account menu. The current layout means users have
to spend more time searching for a task.
How about a menu layout like this;
Chart of Accounts:
File:
New: -> SubMenu:
File
Account
Account Tree
Report
Scheduled Transaction
Open:-> SubMenu:
File
Account
SubAccount
Report
Scheduled Transaction
Save:
Save As:
I could go into a lot more detail here, but I do think we need to
rearrange the way we have the menu's laid out to make things easier to
find from a users perspective.
> Functionality Vector
> --------------------
>
> A goal of this effort is consistency: the user has experience with the
> window-register, and has created a mental map of actions and effects [and if
> they haven't, it will retard that map creation by having multiple different
> registers in different parts of the program]. Thus, the set of functionality
> that the widget-register supports should be configurable in such a way that
> not-available items ["Schedule..." while editing a Scheduled Transaction's
> template-transaction] are not removed, but only grayed out.
>
> This shall be done with a bitmask to be passed into the widget-register,
> specifying which functionality to turn off. Functionality which is turned
> off is left visually in place, but set to be insensitive, and thus the
> callbacks are not able to be invoked. Probably the right thing, then, to do
> is not attach the callbacks at all.
>
This is good, having greyed out menu's indicates to the user they need
to do something in order to make it work.
The find dialog:
WE were talking on IRC about this, it seems like its interface could use
a bit of cleanup. The second url I mentioned above suggest's about 6
tabs max. We could probably reduce the number of tabs and have multiple
options in one tab rather than a whole tab for just date.
We also talked a bit about the menu's on IRC. The suggestion was made to
have a 'File' menu in the registers which would give the user access to
things like import (a transaction), save (what I'm currently doing),
print and close.
Chris
toolbar.png
Description: PNG image
