tracking investment-related transactions

Bill Gribble grib@gnumatic.com
Tue, 5 Dec 2000 08:22:16 -0600


On Tue, Dec 05, 2000 at 05:12:10PM +1100, Robert Graham Merkel wrote:
> I propose to add turn the "account add/edit dialog" into a tabbed
> dialog.  The first page would stay pretty much as is, with the removal
> of the "security" and "source for price quotes" field.  The next tab,
> entitled "investment settings" (or something more appropriate if
> anyone can think of something better), would have the "security" and 
> "price quotes" field, as well as a new account-tree field "related
> accounts" where you would specify which account(s) are to be used to
> record expenses and incomes for that stock/mutual fund account.  

I think it's a fine idea to separate investment-specific settings from
'normal' settings, but I don't think it's time to do this yet.  I am
still strongly in favor of removing the account currency and putting
it into the Transaction structure, which would make it necessary to
put the "security" field on the first page, because EVERY account has
one.  

> I thought about using druids for this, but there doesn't seem to need
> to be a fixed sequence.  Thoughts?

You asked for it :) 

For tax purposes, and to match the behavior of other finance programs,
we need to have several different income and expense accounts with
different specific roles.  For each of as many as 5 income/expense
account "roles" (Dividend, Interest, Short-term CG, Long-term CG,
Commissions, plus possibly Misc income, Misc expense) you need to have
an associated gnucash account.  However, some of them you only need
for specific types of accounts (Short/Long CG are only for mutual
funds), and if course the whole "investment" tab is irrelevant for at
least half of most people's accounts.

To me, that screams 'druid', because for each possible role you need
to go through the 'pick an existing account, or create a new one, and
assign it a role' routine which is fairly nasty from the UI
perspective if you are trying to put each "role" in a sort of one-line
hbox arrangement.  Also, you really have a sort of "flow chart" which
depends on what type of account you select to determine what data
needs to be entered; that's another big flashing 'druid' sign :)

Druids are easy to make (we can talk about it on IRC) and address a
LOT of people's problems about the complexity of big data entry UI
issues.  If you consider how often you will be running the new account
dialog (hardly ever) and what a pain it is to go back and fix mistakes
if you didn't understand what was going on in the dialog (a big pain),
it makes sense to have a druid structure that has the relevant
documentation visible on screen and focuses user attention on a
sequence of small, comprehensible subproblems.

For me, it's not so much that druids are good for problems that have
an innate sequential nature.  Practically, every problem is solved
sequentially because the user can only be sending input to one widget
at a time.  Druids just help the developer guide a user through the
best or least confusing order of selecting widgets to type in, and can
eliminate trouble by only asking the relevant questions.

In short :) I think you might reconsider using a druid for the new 
account creation dialog.  

b.g.