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

[Di Mang]

Hello Geert and Adrien,

I agree it is a good idea to revise the report options and possibly
summarize to reduce the number of tabs.
There are currently
some reports that have tabs with only a few settings.


But in my opinion it would not be a good solution to move away completely
from tabs for *all* option dialogs.
For option dialogs with only a few reports it will take up too much space
on the window.


I think we
have to
distinguish between different
option
dialogs / windows:

* main window: an exception, because of dynamic tabs (with a scroll bar if
necessary)

*
windows with main preferences: currently with tabs on the left side (like
in Geany)

An alternative solution may be
the Side Bar List instead of Tabs on the left side (like in LibreOffice,
Gimp, Firefox)
* option dialogs with only few tabs: tabs at the top position (like in
Geany, Gedit, Gimp, LibreOffice)

I'm looking forward to analysis from Adrien too.

Regards,
Di Mang




2018-07-30 20:52 GMT+02:00 Geert Janssens <geert.gnucash at kobaltwit.be>:

> 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
>
>
> _______________________________________________
> 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.
>