Since Last Run dialog concerns

[Tim Wunder]

On Thursday 14 June 2007 5:49:12 pm Josh Sled wrote:
> Tim Wunder <tim at thewunders.org> writes:
> > I understand the desire for a simpler SLR dialog. The one in 2.0.x
> > required
>
> [...]
>
> > And finally the user is presented with a "Press Apply to  create these
> > transactions" page, where the user could cancel out of everything, or
> > press Apply to commit the entrries.
> >
> > Now you might say that's a lot of dialogs to force a user through just to
> > create some SXs, but the dialogs are clear, well labeled, and logical.
>
> There was one more page that probably no one ever saw, which was the
> "obsolete SX deletion" page.
>

Yep, I have seen that page, just forgot about it.

> As well, there was a lot of logic behind the scenes to maintain each page
> in response to changes in the others.
>
> And (even still), the only way to get the real transactions displayed for
> review was to actually create them, which meant that: 1/ they were created
> before 'Apply' was pressed, which is not ideal, and 2/ they needed to be
> deleted if you hit Back or Cancel, dirtying the book along the way.
>

Right. I dodn't say that the old SLR was good, or that there weren't good 
reasons to re-write it. I'm saying that from this end user's perspective, the 
old way is more appealing than the current state of the new way.

> > Now I'll describe the new diaog, and why I don't particularly care for it
> > (and maybe some ways to improve it):
> > When starting the SLR, the user is presented with a single window
> > titled "Since Last Run". There's no bold name of the window, there's no
> > description of what the window is for. It's just a window containing what
> > appears to be every transaction reminder and every transaction ready to
> > be created.
>
> Yes.  This was part of the goal: instead of splitting these related
> transactions across 3-4 separate pages of the druid, to bring them into a
> single dialog where the user can both see and act on them in one go.
>

It's not always a good thing to pile everything into a single view. Some 
things need to be separated. Particularly reminders, or upcoming SXs, from 
current SXs that require immediate action. Additionally, it seemed 
that /every/ SX was listed, regardless of its state, even those that were 
neither reminders nor ready to be created. There is no reason that the SLR 
should display SXs that are neither in a reminder state, nor in a to be 
created state.

>
> [reminders vs. to-create...]
>
> > ready to be created. I liked how the 2.0.x SLR separates the two. Maybe a
> > compromise would be to provide a button to hide or show the reminders. By
>
> The view could be filtered, yes.  I don't have plans to do this right now,
> but I've noted it in <src/doc/sx.rst>.
>

A reasonable compromise.

> > I also don't like how I have to click and hold the Instance State in
> > order to select another Instance State for an SX. Let me click, let go
> > and then select a new state.
>
> Yes, this is an artifact of how the GtkTreeView works with the editable
> cells.  Similar to the register, the first click activates the cell, where
> the widget changes from a label to the combobox.  It would be nice if there
> was an affordance in the GtkTreeView that the cells were activate-able.
>

Well, I /strenuously/ object ;) 
I'll get used to, I suppose. 

> > The headings of the dialog are too techno-speak.
>
> These are all great suggestions.  I've added them to <src/doc/sx.rst>.
>
> > Instead of "SX, Instance, Variable" something like "Transaction" would be
> > better.
>
> The "problem" with that column is that it does contain all three values:
> the SX name, the instance date and the variable name, as well as being the
> hierarchy-control widget column.  But it's probably better to just say
> "Transaction" than try to combine all that.
>

Yeah. That's my thoughts in suggesting "Transaction" as the column label. You 
and I know that all three elements are listed there, but brevity and 
readability should win out over exactness in this case.

> > Instead of "Instance
> > State" I'd prefer "Status."  Instead of "Variable Value" use "Value"
> > or "Amount."
>
> Agreed.
>
> > And if it is a variable, show it as (need value), if not,
> > display an amount.
>
> That is what happens now.  Are you seeing something else?
>

Yes. While I do see "(need value)" for variables, there is no amount displayed 
for SXs that do not have variables.

> > Perhaps the amount on the first line of the SX. Maybe even
> > add an account name to the dialog. Perhaps the account displayed could be
> > specified in the SX itself, in the template transaction dialog by adding
> > a display tag. Each line item on the template transaction could have a
> > checkbox for displaying in the SLR. But I'd prefer to see something like
> >
> > Transaction		Status			Amount	Account
> > Payday
> > 	6/20/07		To be created	$1000	Income:Salary
>
> Yeah, we have this general problem with the SXes and the template
> transactions ... the variables can affect more than one account, and
> there's not a single account or value that's reasonable to display (without
> user prompting), though in most cases there probably will be...  letting
> the user decide what account/amount to be displayed would be good.
>

I understand the problem. For instance, My gas and electric bill has 4 
variables: GasDelivery, GasComm (commodity), Electric, and Stab (an electric 
rate stabilization amount). My checking account gets credited by 
(GasDelivery+GasComm+Electric-Stab). In that case, what should get displayed? 
You have to display the variables, but should the checking account amount be 
displayed as well? 

Another example would be my paycheck. There are 8 accounts that get touched by 
that transaction. Which one should be displayed? Income:Salary? Assets:Liquid 
Assets: Checking? All of them? Definitely a case where the user needs to be 
able to select what, if any, amount gets displayed in the SLR.

> > Instead of the arrow thingy that lets the user expand the SX instances,
> > why not just show the SX names in Bold and list the instances below, in a
> > semi-outline kind of fashion? The usefulness of being able to expand or
> > contract the instances of an SX escapes me, but I think there would be an
> > appearance and readability benefit from making the SX names bold.
>
> If there are a lot of SXes, the expand/contract widgets are very useful. 
> The GtkTreeView naturally provides them.  I agree that bolding the SX names
> would make it more appealing.
>

I have lots of SXs, yet I fail to see the usefulness of the expand/contract 
widgets. It strikes me as clutter. Do you actually use that? I think the need 
to expand and contract the SXs in the display would go away if there were an 
ability to filter transactions.

Here's another thought I just had while looking at the SLR. Much of the 
clutter I see are Reminder SXs with variables that are expanded by default in 
the tree view. Would it be possible to only expand the variables if the SX is 
in a to be created state and not a reminder? That would go a long way towards 
de-cluttering the view, IMO.

> > I'll admit that as I looked at the new SLR in a bit more detail tonight,
> > I see where it could be an improvement over the old SLR. But as it stands
> > now, I certainly prefer the old SLR to the new.
>
> Thanks for the feedback.  :)
>

I should have given it sooner, but I didn't want to comment on something that 
wasn't finished yet. 

> I'm curious what you think of the SX List page and the new (tabbed) SX
> Editor, as well.

I like them both. Although I found myself more than one time cliking the "X" 
to close gnucash thinking I was closing the SX List window. But I do like the 
tabbed SX Editor much better than the current editor in 2.0.x.


Regards, 
Tim

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070614/432856ec/attachment.bin