Register stuff (summary of Carol and my talk).

[Dave Peticolas]

Rob Browning writes:
> 
> (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 was considering using grey lines inside the transaction, but eliminating
the lines for the blank date field might be good as well. When I get the
infrastructure for this working, we can test it out.


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

Why not put the 'diff' number in the unused 'deb' and 'cred' column?
Since the diff column is only present in multi-line mode, the shift
to multi-line mode and back would be rather awkward visually.


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

Don't you mean diff = -400 and bal = 800?


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

With the general ledger approach (show all splits), there is no need to
have the 'current account' field, because the splits in the open account
are visible as well, and presumably editable.


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

Conceivably, there is both a transaction number and a split number. 


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

I think this is a good idea, but again, how would the 'diff' field
be displayed in that case? Just stick it in that one line? It would
be visually hard to parse, I think.


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

I checked in some work today that removes the blank split lines in
multi-line mode except for the current transaction. Thus, multi-line
mode is now an 'auto' mode.

dave