[GNC] survey: unifying the appearance in different options dialogs

[Geert Janssens]

On Thursday, July 26, 2018 9:41:53 AM CEST Adrien Monteleone wrote:
> Di Mang,
> 
> Looking at the Gnome HIG (since we’re dealing with gtk) their recommendation
> is to NOT scroll tabs but rather use a Side Bar List instead or re-arrange
> the content:
> 
> "Do not use too many tabs. If you cannot see all the tabs without scrolling
> or splitting them into multiple rows, you are probably using too many and
> should use a list control instead.”
> (https://developer.gnome.org/hig/stable/tabs.html.en)
> 
> I see the main window being an exception because those are dynamic tabs that
> are part of the primary window, similar to a web browser. (though I’ve been
> using left-side tabs for registers/reports and I tend to prefer this) The
> HIG also specify to avoid using dynamic tabs for other purposes like
> controls.
> 
> So rather than set a limit where most preference dialogs will use top tabs
> and then switch to a Side Bar List, rather, the guidelines would suggest to
> either leave them split as-is. So if unified presentation is the goal,
> you’d rather have to change all dialogs to Side Bar Lists instead of Tabs.
> This would satisfy even the 800x600 or large fonts users as vertical
> scrolling is more natural and horizontal scrolling is generally discouraged
> in both interface and web design.
> 

I'm late to this discussion due to my absence. I'm glad you brought up the 
Gnome HIG, Adrien, because I'm having exactly the same thoughts as you do.

I think tabs are only useful if there's two or three at most. Anything more 
will cause difficulties for small dialog windows (they don't always span 800px), 
with larger fonts or in translated form.

So in my mind 6 is equally arbitrary as the original 4 or the proposed 8.

I do appreciate the effort to create consistency in the interface. In that 
regard I agree moving away completely from tabs for our option dialogs would 
be a better solution. There is plenty of prior art: libreoffice options use a 
list instead of tabs to group options. So do most kde applications for their 
options. Same for Firefox preferences.

I equally agree tabs can still be used to stack different pages on the main 
window (account hierarchy plus several of register pages and report pages). 
The number tabs in this case is undefined beforehand.


> Looking over *some* of the report options dialogs, it seems there is room
> for consolidation.
> 
> Certainly, in almost any report, the contents of ‘General’ can be
> incorporated into ‘Display’. At worst, the date range/setting can be left
> out, and in that case, perhaps the better UI element would be for the
> report to have a toolbar/header bar with date selectors as Action/View
> buttons. (it *can* be it’s own primary window. It doesn’t have to open in a
> tab, and can still have a parent>child relation, but even stay open if
> desired after closing the parent - probably useful in many cases as this
> would allow placement on other workspaces, monitors, etc.) I can currently
> choose to open reports in a new window, but their toolbar is identical to
> the parent, which isn’t necessarily useful as-is. I would suspect the date
> selectors something to be commonly changed when running a report, and this
> would make them very prominent. (and de-clutter the now consolidated
> ‘Display/General’ tab)
> 
> To be sure, not all ‘General’ tabs are the same, and it seems some of them
> have become a catch-all. Then some reports have special tabs for only a few
> controls but those separate tabs are generally related. For example, the
> P&L report has a tab for Commodities (as do many reports) and another for
> Entries (dealing with closing entries). It seems in both cases, the
> controls deal with calculation controls. Rather than two tabs here, there
> should be one ‘generic’ tab called ‘Calculations’ or something better. The
> content of the tab can use divider lines to separate the controls into
> groups if needed. I’m now going to do for the individual controls, what you
> did for the tabs and map them all out and where they presently are
> organized and perhaps instead should be.
> 
> It seems so far (research pending) that at the least report options are
> needed for three things:
> 
> What data will be included (the accounts tab)
> How that data will be manipulated/calculated (the new ‘calculations’ tab,
> but perhaps even non-existent for some basic reports) How the results will
> be displayed (the display tab)
> 
> On that note, date selectors determine the data to be included, so perhaps
> they instead belong on the Accounts tab (renamed to ‘data’ or ‘info’
> perhaps?) or just put them on a toolbar for the report.
> 
> Perhaps there are more classes of controls, but if not, that means each
> report needs only three tabs.
> 
> Some options, like commodity calculations perhaps should be in general
> GnuCash preferences under reports. (which is pretty sparse currently) And
> really, there are some options (like much of the Display tab) which are
> common to all reports. Those might be better moved there as well. (so you
> get a general unified presentation style, but you can manipulate within
> each report display options specific to *that* specific report or instance
> of report) I could be wrong, but my guess would be if someone doesn’t want
> zero values in one report, they don’t want them in any report, and the same
> for accounts with no balance, or where parent accounts are placeholders
> only. (another spot that shouldn’t even be a preference, if it’s a
> placeholder, it will never have a balance other than zero and the balance
> should always be suppressed visually)
> 
> I’ve always thought the report options to be a kitchen-sink type approach
> and some reports I honestly can’t make heads or tails of what changing some
> particular setting is going to accomplish. (the visual hierarchy on some
> tabs is atrocious if just non-existent) To be clear, non of this is a knock
> on the hard work the devs have put in. But from a user perspective, this
> has always been a sore spot for me and judging by questions on the list
> related to ‘how do I accomplish this or that in a report’ or ‘is there a
> report to show me X’ I’d say there is room for improvement here. Once this
> is all mapped out, decisions can be made on how to re-organize or
> re-design. I think most info can be gleaned from the current crop of
> reports, but rather how to accomplish this is slightly obtuse and not very
> discoverable.
> 
> I know I just went all over the map, sorry.
> 
> I’ll start categorizing each setting/option by how it affects the report and
> then we’ll all have a clearer picture of what settings are common and which
> seem misplaced and then what to do with them.
> 
I'm looking forward to this analysis :)

Agreed some attention to design would help a lot for the current reports.

Geert