Register stuff (summary of Carol and my talk).

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

    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

  * 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

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

Rob Browning <> PGP=E80E0D04F521A094 532B97F5D64E3930