Register stuff (summary of Carol and my talk).
Rob Browning
rlb@cs.utexas.edu
24 Oct 2000 00:11:01 -0500
(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).
* 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