--------------BC3FECB55B492B628E5857FB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Rob Browning wrote:
> (This is mostly part of an ongoing conversation Dave and I have been
> having, so bear with me as I bring it onto the list. Also, with
> respect to some of these changes, please try and make sure you've
> tried to think about the most complicated case(s), one of which I
> illustrate below (the furniture case), before offering a "better"
> alternative. If possible, I'd like to try and limit the number of
> circles we run around in here.)
>
> I hope this will be interesting, and I don't know what you're
> currently thinking WRT to register updates, so maybe I'm preaching to
> the converted, but Carol and I talked about the register for a while
> the other day (because she was really having some trouble
> understanding it), and here's a summary of things we discussed/thought
> of, in no particular order.
>
> * Carol really seemed to want some more obvious separation between
> transactions in the register. It wasn't clear whether this was a
> problem with the coloring scheme (to me it seems like maybe the
> dark color should be the transaction color...), or could be solved
> with the usage of heavier/lighter lines - maybe grey lines within
> a transaction and it's splits and black lines separating one
> transaction from another, or required something else. (I've also
> got some suggestions related to this I'll discuss below).
I have changed the default coloring scheme to make this less confusing. I use
the Auto Single mode. The non selected transactions have alternating bright
and dim colors. All of the lines of the selected transaction are the same,
different color, except that the selected split is a fourth color and
surrounded by double lines.
> * As we all know, the current multi-line register is confusing. We
> talked about a variety of ways to fix this, but settled on
> something mostly like what I think we were already planning, but
> with a minor twist I thought of the other day, but I can't recall
> if you and I discussed. The idea is that the multi-line register
> be changed to be something like a general ledger, but rendered
> from the perspective of a "current account", and having one more
> column than we have now, a "diff" column.
>
> As an example, imagine you go to a store and you buy three pieces
> of furniture and you pay with checks from two accounts (check 1001
> from Checking and check 321 from Savings). (Actually, this case
> is *more* complicated than we've talked about before, and we
> couldn't handle it right now without changing both splits and
> transactions, but some of the ideas are still useful, including
> the extra column, and I'd like to present it as an extremely
> complex case. Then work our way back to what we'd actually like
> to support ATM.)
>
> Here's how the transaction would look like this from the Furniture
> account (presume a previous Furniture balance of 1000):
>
> Date | Num | Desc | Account | deb | cr | diff | bal
> --------------------------------------------------------------------------
> 2000-10-01| | Shopping spree. | | | | 700 | 1700
> | | Louis XIV chair | Furniture | 200 | | |
> | | Louis XIV sofa | Furniture | 400 | | |
> | | Art Deco ottoman | Furniture | 100 | | |
> | 1001 | Olga's Antiques | Checking | | 400 | |
> | 321 | Olga's Antiques | Savings | | 300 | |
>
> Note how the diff shows you the affect of this transaction on the
> balance which (as usual) is the balance with respect to the
> current account.
>
> Note too that this setup allows you to have two checks, and two
> check numbers in the same transaction without confusion. This is
> something we can't do right now, and possibly something we don't
> want to do soon, but I figured it was worth mentioning as a
> possibility.
>
> When we look at this transaction from one of the other accounts,
> *everything* stays the same except for the diff and the balance.
> Here's what it would look like from Checking if we presume a
> previous balance of 1200:
>
> Date | Num | Desc | Account | deb | cr | diff | bal
> --------------------------------------------------------------------------
> 2000-10-01| | Shopping spree. | | | | -700 | 1500
> | | Louis XIV chair | Furniture | 200 | | |
> | | Louis XIV sofa | Furniture | 400 | | |
> | | Art Deco ottoman | Furniture | 100 | | |
> | 1001 | Olga's Antiques | Checking | | 400 | |
> | 321 | Olga's Antiques | Savings | | 300 | |
>
> * Note in the above examples how the date field has no horizontal
> lines for any of the split lines. Even though I just did that
> here to make things look cleaner and save space, I wonder if we
> might want to consider trying this, if it wouldn't be an
> implementation nightmare across the board. I think it might
> really help to make transactions stand out from one another.
> Perhaps something like this:
>
> -----------------------------------------------------
> |2000-10-01| | Some description | |
> | |-----------------------------------------
> | | | split1 memo | |
> | |-----------------------------------------
> | | | split2 memo | |
> | |-----------------------------------------
> | | | split3 memo | |
> -----------------------------------------------------
> |2000-10-04| | Some description | |
> | |-----------------------------------------
> | | | split1 memo | |
> | |-----------------------------------------
> | | | split2 memo | |
>
> * Carol mentioned, and I think she's right, that being able to edit
> the "current account" in the first line of a transaction can be
> very confusing (i.e in all the non-single-line modes). While I've
> had good cause to use that trick to relocate transactions to other
> places (when you're cleaning up a scrub account for example), it
> might be a good idea not to make it seem like the obvious thing to
> do. Perhaps the default tab traversal should just skip it. I
> suspect it's rare that you'd really want to edit that field, and
> skipping it would speed up normal data entry. If we think that's
> a good idea, we should consider skipping the credit/debit field on
> the transaction line as well.
>
> * I'm wondering if, given the furniture example above, we should
> consider whether or not the num field should belong to the
> transaction or to the split. Of course if we decided that it
> belonged to the split, we'll have to address a set of related UI
> issues.
>
> * Carol suggested that it would be really convenient to be able to
> click on the "Split" field when in single line mode and have just
> that transaction expand to show all the splits. Thinking about
> it, this is how one of the other big apps used to handle this
> situation.
>
> * On a similar note, I've been thinking that if I had a
> general-ledgeresque view, like the one in the furniture example
> above, and I had a *smart* single line mode, which included a
> transaction memo on the line (hey, I've got a wide display and
> small fonts :>), and had the ability to, with a keypress, expand
> the current transaction into multi-line mode (without affecting
> any of the others), and with another keypress collapse that node,
> that might be the only two modes I'd need. Actually, perhaps what
> I'd *really* like is this:
>
> * I'd still like an option that would let me turn off all those
> blank split lines that every transaction has when you're not in
> single-line mode. To me, they're distracting, and they really
> limit the amount of information you can get on one screen. In
> exchange, I'd like to be able to add a new split line with a
> keypress or via a menu item. I can then imagine a mode that looks
> like single-line mode, unless you hit that key, and when you hit
> that key, only expands the current transaction to have N+1
> splits. I think I might also want this mode to always show all
> the existing splits for transactions that have splits, but without
> seeing it, it's hard to say for sure.
>
> Whew...
> --
> Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel@lists.gnumatic.com
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
I've been using gnucash for a few months and one thing that really confused me
was the way amount in the second or third line of a split always changes to
maintain a zero total balance. When I enter a transaction to pay a credit
card, it typically has about a dozen splits. Entering Discover Card on the
Memo line recalls the previous months bill. So, I change the total amount,
and the first category, say gasoline, changes. Then I enter the gasoline
amount and the second category, say groceries changes. Then I enter the
grocery amount and the gasoline line changes again! When I first saw this,
thought gnucash was seriously broke. I entered a few more category amounts
and I figured out what was gong on. I added an account for Unallocated
Expense and put it in the second line, and now every thing works OK. This is
bad behavior. Changing an amount the user just entered, with no explanation
whatever, is not good. The previous money program I used, Managing Your
Money, automatically added an unallocated expense line at the end of a
transaction to maintain the balance. We need to work on a different way to
handle this.
--
Gilligan | __o .oooO
/| _ \<,_ ( )
/p|\ (_)/ (_) \ ( Oooo.
/ | \ ------------ \_) ( )
======== ) /
======== gilligan@mpinet.net (_/
~~~~~~~~~~~~~~~~ uschold@cs.ucf.edu
--------------BC3FECB55B492B628E5857FB
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
Rob Browning wrote:
(This is mostly part of an ongoing conversation Dave
and I have been
having, so bear with me as I bring it onto the list. Also,
with
respect to some of these changes, please try and make sure you've
tried to think about the most complicated case(s), one of which
I
illustrate below (the furniture case), before offering a "better"
alternative. If possible, I'd like to try and limit the
number of
circles we run around in here.)
I hope this will be interesting, and I don't know what you're
currently thinking WRT to register updates, so maybe I'm preaching
to
the converted, but Carol and I talked about the register for a while
the other day (because she was really having some trouble
understanding it), and here's a summary of things we discussed/thought
of, in no particular order.
* Carol really seemed to want some more obvious separation between
transactions in the register. It wasn't clear
whether this was a
problem with the coloring scheme (to me it seems
like maybe the
dark color should be the transaction color...),
or could be solved
with the usage of heavier/lighter lines - maybe
grey lines within
a transaction and it's splits and black lines separating
one
transaction from another, or required something
else. (I've also
got some suggestions related to this I'll discuss
below).
I have changed the default coloring scheme to make this less confusing.
I use the Auto Single mode. The non selected transactions have alternating
bright and dim colors. All of the lines of the selected transaction
are the same, different color, except that the selected split is a fourth
color and surrounded by double lines.
* As we all know, the current multi-line register
is confusing. We
talked about a variety of ways to fix this, but
settled on
something mostly like what I think we were already
planning, but
with a minor twist I thought of the other day, but
I can't recall
if you and I discussed. The idea is that the
multi-line register
be changed to be something like a general ledger,
but rendered
from the perspective of a "current account", and
having one more
column than we have now, a "diff" column.
As an example, imagine you go to a store and you
buy three pieces
of furniture and you pay with checks from two accounts
(check 1001
from Checking and check 321 from Savings).
(Actually, this case
is *more* complicated than we've talked about before,
and we
couldn't handle it right now without changing both
splits and
transactions, but some of the ideas are still useful,
including
the extra column, and I'd like to present it as
an extremely
complex case. Then work our way back to what
we'd actually like
to support ATM.)
Here's how the transaction would look like this from
the Furniture
account (presume a previous Furniture balance of
1000):
Date | Num | Desc
| Account | deb | cr | diff | bal
--------------------------------------------------------------------------
2000-10-01| | Shopping spree.
| |
| | 700 | 1700
|
| Louis XIV chair | Furniture | 200 | |
|
|
| Louis XIV sofa | Furniture | 400 |
| |
|
| Art Deco ottoman | Furniture | 100 | |
|
| 1001
| Olga's Antiques | Checking | | 400
| |
|
321 | Olga's Antiques | Savings |
| 300 | |
Note how the diff shows you the affect of this transaction
on the
balance which (as usual) is the balance with respect
to the
current account.
Note too that this setup allows you to have two checks,
and two
check numbers in the same transaction without confusion.
This is
something we can't do right now, and possibly something
we don't
want to do soon, but I figured it was worth mentioning
as a
possibility.
When we look at this transaction from one of the
other accounts,
*everything* stays the same except for the diff
and the balance.
Here's what it would look like from Checking if
we presume a
previous balance of 1200:
Date | Num | Desc
| Account | deb | cr | diff | bal
--------------------------------------------------------------------------
2000-10-01| | Shopping spree.
| |
| | -700 | 1500
|
| Louis XIV chair | Furniture | 200 | |
|
|
| Louis XIV sofa | Furniture | 400 |
| |
|
| Art Deco ottoman | Furniture | 100 | |
|
| 1001
| Olga's Antiques | Checking | | 400
| |
|
321 | Olga's Antiques | Savings |
| 300 | |
* Note in the above examples how the date field has no horizontal
lines for any of the split lines. Even though
I just did that
here to make things look cleaner and save space,
I wonder if we
might want to consider trying this, if it wouldn't
be an
implementation nightmare across the board.
I think it might
really help to make transactions stand out from
one another.
Perhaps something like this:
-----------------------------------------------------
|2000-10-01|
| Some description |
|
|
|-----------------------------------------
|
| | split1 memo
| |
|
|-----------------------------------------
|
| | split2 memo
| |
|
|-----------------------------------------
|
| | split3 memo
| |
-----------------------------------------------------
|2000-10-04|
| Some description |
|
|
|-----------------------------------------
|
| | split1 memo
| |
|
|-----------------------------------------
|
| | split2 memo
| |
* Carol mentioned, and I think she's right, that being able to
edit
the "current account" in the first line of a transaction
can be
very confusing (i.e in all the non-single-line modes).
While I've
had good cause to use that trick to relocate transactions
to other
places (when you're cleaning up a scrub account
for example), it
might be a good idea not to make it seem like the
obvious thing to
do. Perhaps the default tab traversal should
just skip it. I
suspect it's rare that you'd really want to edit
that field, and
skipping it would speed up normal data entry.
If we think that's
a good idea, we should consider skipping the credit/debit
field on
the transaction line as well.
* I'm wondering if, given the furniture example above, we should
consider whether or not the num field should belong
to the
transaction or to the split. Of course if
we decided that it
belonged to the split, we'll have to address a set
of related UI
issues.
* Carol suggested that it would be really convenient to be able
to
click on the "Split" field when in single line mode
and have just
that transaction expand to show all the splits.
Thinking about
it, this is how one of the other big apps used to
handle this
situation.
* On a similar note, I've been thinking that if I had a
general-ledgeresque view, like the one in the furniture
example
above, and I had a *smart* single line mode, which
included a
transaction memo on the line (hey, I've got a wide
display and
small fonts :>), and had the ability to, with a
keypress, expand
the current transaction into multi-line mode (without
affecting
any of the others), and with another keypress collapse
that node,
that might be the only two modes I'd need.
Actually, perhaps what
I'd *really* like is this:
* I'd still like an option that would let me turn off all those
blank split lines that every transaction has when
you're not in
single-line mode. To me, they're distracting,
and they really
limit the amount of information you can get on one
screen. In
exchange, I'd like to be able to add a new split
line with a
keypress or via a menu item. I can then imagine
a mode that looks
like single-line mode, unless you hit that key,
and when you hit
that key, only expands the current transaction to
have N+1
splits. I think I might also want this mode
to always show all
the existing splits for transactions that have splits,
but without
seeing it, it's hard to say for sure.
Whew...
--
Rob Browning <rlb@cs.utexas.edu> PGP=E80E0D04F521A094 532B97F5D64E3930
_______________________________________________
gnucash-devel mailing list
gnucash-devel@lists.gnumatic.com
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
I've been using gnucash for a few months and one thing that really confused
me was the way amount in the second or third line of a split always changes
to maintain a zero total balance. When I enter a transaction to pay
a credit card, it typically has about a dozen splits. Entering Discover
Card on the Memo line recalls the previous months bill. So, I change
the total amount, and the first category, say gasoline, changes.
Then I enter the gasoline amount and the second category, say groceries
changes. Then I enter the grocery amount and the gasoline line changes
again! When I first saw this, thought gnucash was seriously broke.
I entered a few more category amounts and I figured out what was gong on.
I added an account for Unallocated Expense and put it in the second line,
and now every thing works OK. This is bad behavior. Changing
an amount the user just entered, with no explanation whatever, is not good.
The previous money program I used, Managing Your Money, automatically added
an unallocated expense line at the end of a transaction to maintain the
balance. We need to work on a different way to handle this.
--
Gilligan | __o .oooO
/| _ \<,_ ( )
/p|\ (_)/ (_) \ ( Oooo.
/ | \ ------------ \_) ( )
======== ) /
======== gilligan@mpinet.net (_/
~~~~~~~~~~~~~~~~ uschold@cs.ucf.edu