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

Thu Jul 26 03:41:53 EDT 2018

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.

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 suspect after that work is done, your tab question will no longer need an answer.

Regards,
Adrien

> On Jul 19, 2018, at 2:02 PM, Di Mang <di.mang.freetime at gmail.com> wrote:
> 
> Hello John,
> 
> 
> 2018-07-19 2:56 GMT+02:00 John Ralls <jralls at ceridwen.us>:
> 
>> 
>> 
>>> On Jul 18, 2018, at 7:24 AM, Adrien Monteleone <
>> adrien.monteleone at lusfiber.net> wrote:
>>> 
>>> I didn’t realize there were so many such dialogs!
>>> 
>>> Looking them over now, I’d think setting the value to “8” would leave
>> some room for future flexibility and this appears to be doable based on the
>> size of most tabs. (this would vary with very long strings, perhaps
>> considering German, it might be better to leave the max at “6”)
>>> 
>>> It looks like the Import/Export and Online Banking setup dialogs are
>> different in that they force the user to step through each tab in order.
>> Normally, tabs should not depend on or affect settings in other tabs. (or
>> the dialog should be re-arranged) Since this is the case with those
>> dialogs, it seems either they’ve been specially designed, or they are using
>> a different gtk element to force the progression through tabs rather than
>> let the user jump around.
>>> 
>>> I see some room for improvement here as well. Adding numerals before the
>> label of each tab in these ‘ordered-tab-dialogs’ would make the fact that
>> you have to go in order a bit more obvious. (I tried to jump around, and
>> only when I couldn’t did I notice the ’Next’ button which clued me in)
>>> 
>>> Additionally, it seems the Import Bills/Invoice and the
>> Customers/Vendors dialogs are intended to operate the same way, but simply
>> haven’t been transitioned to the other format. (which I personally think is
>> the better design as it forces the user to enter required information in
>> order.)
>>> 
>>> If those last two changes aren’t something you’ll be dealing with, I’ll
>> just file bug reports/RFE’s on them.
>>> 
>>> Thanks for your work!
>> 
>> Assistants (Online Banking, Imports, Stock Split, Mortgage/Loan, New File,
>> maybe more) are special dialogs that walk the user through a process.
>> Microsoft calls them “Wizards”, Gtk calls them assistants (long ago they
>> called them “Gurus”). They do indeed have a separate class, GtkAssistant
>> [1] and the tab setting shouldn’t affect them.
>> 
>> Wizards have been around since Windows 3 at least and the “Back” and
>> “Next” buttons are a dead giveaway that that’s what your in. I don’t think
>> that numbering the list of pages is going to make it more intuitive. IMO
>> the list of pages itself is distracting and gives the impression that you
>> can skip around in it so I’d get rid of it entirely.
>> 
>> Before we go overboard with the number of tabs across the top of dialogs
>> remember that if dialogs--or any other window’s default size--get bigger
>> than 800x600 we get complaints from people with small screens. Remember as
>> well that some users may have large fonts set because of poor eyesight and
>> that can have an effect on dialog width even if the tab labels are short.
>> 
>> 
> I've just tested the look of dialogs with several tabs. The size of the
> dialogs depends directly on the selected design and the number of tabs (and
> tab's names).
> The dialogs with 7 tabs are smaller as 800x600 px in common design and only
> slightly larger in design for people with poor eyesight.
> A possible solution for dialogs with more than 7 tabs would be the
> activation of scroll buttons like in main window. See examples in
> attachment.
> 
> 
> 
>> Regards,
>> John Ralls
>> 
>> [1] https://developer.gnome.org/gtk3/stable/GtkAssistant.html <
>> https://developer.gnome.org/gtk3/stable/GtkAssistant.html>
>> _______________________________________________
>> gnucash-user mailing list
>> gnucash-user at gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> If you are using Nabble or Gmane, please see
>> https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
>> -----
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
>> 
> <GnuCash - Tabs Appearance.png><GnuCash - Design for poor eyesight.png>_______________________________________________
> gnucash-user mailing list
> gnucash-user at gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information.
> -----
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.