Since Last Run dialog concerns

Josh Sled jsled at asynchronous.org
Thu Jun 14 17:49:12 EDT 2007


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.

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.



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


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


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


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

> 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?


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


> 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'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'm curious what you think of the SX List page and the new (tabbed) SX
Editor, as well.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 188 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20070614/0d9126bb/attachment.bin 


More information about the gnucash-devel mailing list