Since Last Run dialog concerns

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Since Last Run dialog concerns

Tim Wunder (Lists)
I understand the desire for a simpler SLR dialog. The one in 2.0.x required
navigating multiple pages of a druid in order to create transactions. But
I've grown accustomed to its quirkiness, and find it far more usable than the
new, simplified version currently in head.

First, I'll describe and comment on the SLR as it stands in 2.0.x:
The first page of the SLR druid in 2.0.x would be of "Transaction Reminders".
It has a nice bold heading indicating that these are just reminders, with a
good textual clarification, "The listed Scheduled Transaction are to-be
created soon. Select any which you would like to create now, and
click "Forward" to create them."
Listed would be the SX name, date, frequency, and days away.

The next page showed all the transation that would be Automatically created.
It is boldly labeled "Auto-Created Transaction Notification" and displays as
a register containing automatically created SX transactions. Marginally
useful, but clear to the user.

The next page shows "To-Create Transaction Preparation." .
Granted there's a bit too much techno speak going on there, it might be better
titled "Pending Transactions." It contains a list of transactions that will
be created, but may require additional user interaction. It is also the point
at which the user can change the "State" (perhaps "Status" would be a better
term to use in that dialog, but I digress). I can change the State (or
status) of the SX from "Ready to create" to "Ignore" or "Postpone." I've used
this page frequently when I want to just process those transactions I do via
on line bill pay and to postpone those transactions that require me to write
an actual check. Change the status on a couple of SXs and click Forward to
process the remaining.

The next page depends on whether there are any SXs with variables or not. If
there are variables that require input, then the user is presented with a
variable entry dialog.

After all the variables are entered, and all the SXs are ready to create, the
next page provides the user with a final review of the transactions to be
created. That dialog is clearly labeled "Created Transaction Review."

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.

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

Well, I don't want to see the reminders interspersed in with the SXs that are
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
default, hide the reminders. If the user clicks  the "Show Reminders" button,
then display the transaction reminders and change the button to "Hide
Reminders"

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.

Additionally, I don't like it displaying SXs that are neither reminders nor
ready to be created. It clutters the dialog and causes confusion.

The headings of the dialog are too techno-speak. Instead of "SX, Instance,
Variable" something like "Transaction" would be better. Instead of "Instance
State" I'd prefer "Status."  Instead of "Variable Value" use "Value"
or "Amount." And if it is a variable, show it as (need value), if not,
display an amount. 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

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.

Regardless, the display of the SXs in the SLR could be made so much more user
friendly, 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.

Regards,
Tim

--
Fedora Core release 6 (Zod), Linux 2.6.20-1.2952.fc6
KDE: 3.5.6-4.fc6
 21:40:01 up 13 days, 13:47,  1 user,  load average: 0.25, 0.17, 0.12
"It's what you learn after you know it all that counts" John Wooden

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Since Last Run dialog concerns

Josh Sled

Tim Wunder <[hidden email]> 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}

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Since Last Run dialog concerns

Tim Wunder (Lists)
On Thursday 14 June 2007 5:49:12 pm Josh Sled wrote:

> Tim Wunder <[hidden email]> 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


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Since Last Run dialog concerns

Josh Sled
Tim Wunder <[hidden email]> writes:
> 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.

I don't agree; I don't think it's piled ... in the regular case, I have maybe
one reminder and two to-create SXes ... so three things to see.  I guess it
could be 2 pages with 1 or 2 things each, but it seems like one "unit" of
interaction is better than two, here.  I'm not so sure about the need to
separate the reminders out from the others ...

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

That's a good point ... they don't really deserve a line-item at all.  I've
noted this in <src/doc/sx.rst>.


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

No, I don't.

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

Another really good idea, noted.

--
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo ${a}@${b}

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

attachment0 (194 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Since Last Run dialog concerns

Tim Wunder (Lists)
On Monday 18 June 2007 9:49:42 pm Josh Sled wrote:

> Tim Wunder <[hidden email]> writes:
> > 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.
>
> I don't agree; I don't think it's piled ... in the regular case, I have
> maybe one reminder and two to-create SXes ... so three things to see.  I
> guess it could be 2 pages with 1 or 2 things each, but it seems like one
> "unit" of interaction is better than two, here.  I'm not so sure about the
> need to separate the reminders out from the others ...
>
<snip>

That's where our use cases differ. I have 30-40 SXs, often with more than 10
reminders plus another 5 or 10 to-creates at a given time. With <10 SXs, I
can see the desire to have everything there. With the number of SXs I
typically have to look at, throwing reminders in with the to-creates is too
much stuff to look at (for me, anyway).
Perhaps a sorted view, then? List Reminders under a heading of "Upcoming
Transactions" or "Transaction Reminders" and the to-be-created under a
heading of "Ready to Process Transactions" or "Transactions Ready for
Processing."

Regards,
Tim


_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

signature.asc (196 bytes) Download Attachment