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

[Adrien Monteleone]

After reading John Ralls’ reply on the wizards (example 4) I agree with him, the sidebar list needs to go. Adding numbered steps would help, but the better option is to not even list the steps, just walk the user through the steps with next <> back buttons. I think this would also adhere better to the Gnome HIG concerning removing confusing information presented to the user. The user cannot click a later tab and jump there, so don’t present them as tabs at all, use a different presentation and guide the user through the options in the order you need to guide them.

Regards,
Adrien

> On Aug 2, 2018, at 3:21 PM, Di Mang <di.mang.freetime at gmail.com> wrote:
> 
> 
> 
> 2018-08-01 13:58 GMT+02:00 Adrien Monteleone <adrien.monteleone at lusfiber.net>:
> 
> 
> > On Aug 1, 2018, at 4:57 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> > 
> > Op dinsdag 31 juli 2018 00:51:54 CEST schreef 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.
> > 
> > This doesn't make sense to me. If we move to "tabs" on the left for at least 
> > one option window, we need to dimension the window anyway that it will fit on 
> > the smallest screen we wish to support. How would this minimal dimension be 
> > affected by the number of "tabs" in that area ? (I'm quoting "tabs" because 
> > it's not the exact term for the exact widget I had in mind, more on that 
> > below).
> > 
> > Having a consistent way to represent options throughout the application is 
> > more important to me.
> 
> I agree. Options shouldn’t switch to one or the other based on their quantity. All of these dialogs should be consistent. And if it can work once...
> 
> > 
> >> 
> >> 
> >> 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)
> > 
> > Indeed, although a scroll bar for tabs is a bit awkward.
> > 
> >> 
> >> *
> >> windows with main preferences: currently with tabs on the left side (like
> >> in Geany)
> > 
> > I suppose you mean “many" preferences.
> > 
> 
> Perhaps the ‘main’ app preferences, which does use the sidebar list. The Gnome desktop does the same.
> 
> 
> Yes, I meant here the "main" app preferences: like "Edit" > "Preferences" in GnuCash.
> For more clarity find examples of different dialogs in the appendix. 
> 
> >> 
> >> An alternative solution may be
> >> the Side Bar List instead of Tabs on the left side (like in LibreOffice,
> >> Gimp, Firefox)
> > 
> > I surely agree a Side Bar List is better and that (or something similar) is 
> > what I had in mind. In fact I thought that's what you meant as well as the 
> > option dialogs for several reports were showing a list of groups instead as a 
> >> list of tabs on my system already before your change.
> >
> > Yes Side Bar List is the proper widget from what I can glean from the Gnome HIG.
> > I thought that was what Di Mang was referring to as well.
>  
> Yes, I think the Side Bar List is a good solution for a list of many different settings.
> 
> > 
> >> * option dialogs with only few tabs: tabs at the top position (like in
> >> Geany, Gedit, Gimp, LibreOffice)
> > 
> > As said that would then break consistency again. Wasn't that your initial 
> > argument (which I like) ?
> > 
> > My ideal solution would be a dynamic side bar list. That is if there's enough 
> > horizontal screen space (and the dialog is wide enough) show the list 
> > permanently. If the dialog gets narrowed (either due to user action or due to 
> > limited screen space), make the list hidden by default (with a button to show 
> > it) and when that button is clicked make it hover the actual content.
> > 
> > Here's a video of another application implementing this behavior (though from 
> > the KDE world):
> > https://www.youtube.com/watch?v=H24jdjE5Q6E
> > 
> > Clearly this is for gnucash 4.x at best...
> > 
> > Regards,
> > 
> > Geert
> 
> Interesting. I don’t suppose Gtk+4 has this in the works?
> 
> Regards,
> Adrien
> _______________________________________________
> 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 - Examples of different dialogues.png>