Two more observations:

Transit (as in Miscellaneous:Transit) is preferred by autocomplete to
Transfer, at least in M04. This is counter-intuitive to the alphabet and
hoses up the analysis which assumed that Transfer was a 2 character cost and
Transit was 6. That alone, weighted against my data, would have a huge cost
in keystrokes for single list entry--again, assuming I couldn't adapt my
thought processes to think of a transfer as the target account name instead
of a transfer.

Aside from the other subcategory conflict cited, I have
Miscellaneous:Supplies and Computer:Supplies. I use Miscellaneous:Supplies A
LOT. Typing merely supplies won't work.

I stand by the analysis and belief that Single List costs me extra typing
even if it doesn't cost anybody else extra.

Thus, I change M04 back to Dual List. Enough trying to convince myself I can
learn to live with it. I'll cross the bridge permanently if M06 is worthy
and, like M05, attempts to eliminate the choice.

It occured to me that Just A Little Bit More Analysis might reveal some
interesting tidbits, so I built a few more queries.

Determining unique top level categories from the joint Category:Subcategory
namespace costs an average of 3.96 characters vs. 2.71 for the top level
from just the Category set. (As before, this is for categories used in my
file without regard to frequency.) Add the seperator and that's more than
two extra characters.

What are the hitters here? 17 of the 28 top level categories incur a cost
when trying to autocomplete them from the merged namespace. 10 incur one
character. One incurs two characters. Five incur three characters. One
incurs five and the last one incurs six.

Examples: Interest Expense must be uniqued from Interest (as in Investment
Income. That's 6. (Not that I type that one but almost never.) Taxes takes
a three character hit to be uniqued from Tax Preparation (as in
Miscellaneous. I don't type that one often, either, but it's in my
transaction data A BUNCH. Automobile (one that does get typed fairly
frequently) incurs a three character hit to get uniqued from Auto Loan
Interest (as in Interest Expense and Auto Allowance (as in Wages &
Salary. There was already another Category before au but beginning with a,
so the minimum in dual list is au.

I conclude my analytic technique is valid and my analysis is correct and the
only way to avoid single list entry costing keystrokes is to use the
subcategory exclusively where applicable and not ambiguous in the
namespace--i.e., the Automobile:Maintenance vs. Housing:Maintenance problem
which my analysis didn't try to account for. That's quite a re-training
hurdle and is not uniformly applicable, unlike dual category entry.

Now I will file this database away in the archives.

Good feedback, though I'd like to address how we think of users.

Though we do tend to build up user models that obviously don't reflect exact
people, I don't think that they are exactly mythical. They are abstract, but
based on reasonably deep and credible data. We use the results of focus
groups, surveys, customer surveys, PSS roll-ups, email requests, beta
feedback and even ad hoc review of newsgroup posts.

We've built out two detailed user profiles, one that would like to use the
Advanced register and one that would like to use the Essential register. I'm
not surprised if many readers and posters in this newsgroup identify with
the Advanced register user; I probably do myself. It's possible, though,
that some users will want to use both registers (on different accounts), and
we may find simple, direct, and complete ways to accomplish tasks that
satisfy both users.

It is incorrect to state that the development team doesn't use the product.
Many of us were users before we were on the Money team. We don't, however,
design the product merely to suit ourselves. In some cases I use the
features in ways that I don't prefer, in part to make sure that I understand
how they work. We have learned that no small group of users can be the sole
model for our feature design.

-Russ Paul-Jones

"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:exqVPwp1EHA.304[at]TK2MSFTNGP11.phx.gbl...
- quote -

Good feedback, though I'd like to address how we think of users.

Though we do tend to build up user models that obviously don't reflect exact
people, I don't think that they are exactly mythical. They are abstract, but
based on reasonably deep and credible data. We use the results of focus
groups, surveys, customer surveys, PSS roll-ups, email requests, beta
feedback and even ad hoc review of newsgroup posts.

We've built out two detailed user profiles, one that would like to use the
Advanced register and one that would like to use the Essential register. I'm
not surprised if many readers and posters in this newsgroup identify with
the Advanced register user; I probably do myself. It's possible, though,
that some users will want to use both registers (on different accounts), and
we may find simple, direct, and complete ways to accomplish tasks that
satisfy both users.

It is incorrect to state that the development team doesn't use the product.
Many of us were users before we were on the Money team. We don't, however,
design the product merely to suit ourselves. In some cases I use the
features in ways that I don't prefer, in part to make sure that I understand
how they work. We have learned that no small group of users can be the sole
model for our feature design.

-Russ Paul-Jones

"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:exqVPwp1EHA.304[at]TK2MSFTNGP11.phx.gbl...
- quote -

I really don't know about most users. I suspect that those who are
reasonably comfortable with the keyboard and know that a drop-down control
can be typed into recognize pretty quickly that typing is LOTS faster than
all of the mouse movement and mouse clicking. This is especially true since
you can't avoid the keyboard--unless you use the calculator control to enter
the amount--but can avoid the mouse.

"Cal Learner-- MVP" <via_newsgroup[at]please.tnx> wrote in message
news:2s1oq0d46vek3c94kstl05avk6pg60a57u[at]4ax.com...
- quote -

This user, Cal, NEVER used drop-down category assignment in 8 years
until forced to by the pre-registry tweak version of Money 2005.

--
Brent Neville


"Cal Learner-- MVP" <via_newsgroup[at]please.tnx> wrote in message
news:2s1oq0d46vek3c94kstl05avk6pg60a57u[at]4ax.com...
- quote -

In microsoft.public.money, Dick Watson wrote:

- quote -

Don't you think most users use drop-down lists to assign categories?

If that list user has dual list enabled, but click or type first
into the sub-category, it behaves as a single category list anyway.

Of course I understand that this keystroke analysis was not done for
a typical user. ;-)

Attracting new Money users is understandable, Russ, but I hope you would
also be concerned about your existing user base. Oddly enough, new
users eventually become old users who have transformed themselves from
"newbies" into experts who might perform tasks in different ways.

Who beta-tested this version of Money? Certainly not experienced,
long-time users. Most of the problems and usability concerns are
strikingly obvious, but either went unnoticed or ignored. I personally
filed multiple SRX's (for problems which have since been corrected) and
considered filing many more.

Many of us long-term users (in my case, all 8 versions since 1998),
seriously considered either not upgrading to 2005 (like Dick) or
switching to a competitor's product.

--
Brent Neville


"Russ Paul-Jones" <russpj[at]microsoft.com> wrote in message
news:OSdpMVo1EHA.208[at]TK2MSFTNGP12.phx.gbl...
- quote -

revise "Bbb found in Aaa:Baa without regard to Ddd:Ba" to "Bbb found in
Aaa:Bbb without regard to
Ddd:Bb"

Ooops.

"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:e9sm8ap1EHA.1292[at]TK2MSFTNGP10.phx.gbl...
- quote -

Thank you for commenting on the decision and the process. More than many
others, I do understand how trades like this get made and lifecycle costs
get assessed in these trades. I've been there. And I've had to swallow my
share of design decisions that proved stupid or unpopular or both.

The one data point you provided that was missing from view was that the
visible register, largely unchanged for single category list users, was put
on top of fundamentally reworked register code. I will assume that the new
register code provides some benefits or better growth path for the future,
though these benefits in M05 were not apparent to me. Perhaps this was
because, for my three weeks, I was an Advanced * M05 user, not an Essential
* one.

Sadly, you also indirectly reinforce several of my unhappy conclusions. 1)
Features are being added (or subtracted) based heavily on a mythic
"perceived user"--the ones you "thought would use it"--or on testing with
people who aren't yet users and may never be, no matter what the product is
changed to be. The mythic user is a lowest-common-denominator one and the
goal is to continue to drive this level down rather than to empower all
users, including the curmudgeon power users, which may be a class of 1. 2)
Few of the Money developers actually use the thing to crank in serious
amounts of data and do serious analysis and financial management using it. I
conclude the latter because I find it inconceivable that serious users who
actually enter some data would not appreciate the impact that this change
would have on very longtime fellow users who actually crank lots of data
into this thing. I recognize this may be unfair. You may all just download
all your transaction data and never actually touch the keyboard when using
the product. More power to you if this is the case. But it does not
represent the way all users use it or at least not the way this one user
uses it.

Thanks again for listening and joining the discussion. It may not seem like
it, but many of us really are Money fans, myself included. (In my case,
that's excepting M05.) Hopefully the dialog contributes to a better product
in the future for all of us users and for Microsoft.

Note also my other entry tonight in this thread that recounts some
model-based analysis I did of the keystroke cost of this design choice.

"Russ Paul-Jones" <russpj[at]microsoft.com> wrote in message
news:OSdpMVo1EHA.208[at]TK2MSFTNGP12.phx.gbl...
- quote -

This post sent me to thinking and to do a little bit of real-world analysis.
Actually, the little bit of analysis turned into somewhat of a science
project. There were some interesting results.

I set out to test categories from my existing data to determine what effect
single category list had vs. dual category list on the amount of typing to
enter autocompleted categories.

First, I retrieved all of my Money transactions into Excel using MoneyLink.
I retrieved all transactions for all accounts for all dates. This yielded
33,993 transactions (as of a few moments ago). I used Excel to reduce this
to unique lists of category:subcategory to reflect my real-world data. In
order to make the data-grinding easier, I put this data in Access tables.
The first listed categories, the second subcategories with a key link to the
parent categories (this to deal with Housing:Maintenance vs., say,
Automobile:Maintenance), and the third listed the merged set of category and
subcategory names. These tables, respectively, had 28, 269, and 261 rows.
One interesting side effect observable at this phase was that many
subcategories were actually investment names that were the object of Buy
activity. The investment names tend to be long and repetitive from one to
the next, many beginning with, say, "Fidelity " or "US $100 EE Bond - ".
Unfortunately, MoneyLink can't extract classification. I would have done a
parallel exercise.

With a little bit of VBA, I developed queries to count the character cost to
render these unique. I did make allowance for the "one key" alphabet-order
hits. ("Aaa" found before "Abc" just by typing the "a".) I also made sure to
recognize that subcategories will autocomplete in a subset only of
subcategories with the same parent. (Bbb found in Aaa:Baa without regard to
Ddd:Ba.) I then queried out the average of these unique character costs.
Categories from the categories only list took an average of 2.71 characters,
from the subcategories list (within their categories) 4.68 characters, and
to pick a unique name from the merged list 5.74 characters. This suggests a
character cost for dual list entry on the order of almost two characters,
allowing for the separator (":"). (2.71+1+5.74)

I didn't like this answer since it didn't match my preconceived notion that
dual list saves me typing.

Considering why I got this answer, I decided that perhaps the large number
of characters associated with making the investments unique (among other
similar rare but long and rare and duplicative things) might be skewing
results since they are a VERY small player in the total list of
transactions.

So I did some more Access hacking. I linked to the Excel table of MoneyLink
retrieved transaction data and went off and create a rather surprising large
set of queries to weigh these character costs against the total set of data
at hand. (Even in this, certain concessions must be made. I didn't have any
easy way to weigh this cost vs. actual typing and weed out autocompletes
based on Payee or categorization long-since entered only once in a scheduled
item and not retyped for many or most of the transactions in the data set.)

I applied the character costs to each of 33,927 transactions. (The
difference between the 33,927 and the total of 33,993 retrieved represents
uncategorized transactions.) Averaging the results indicated that dual list
entry represented an average of 5.67 keystrokes, including the one character
separator. (This ignores my preference for Tab vs. Shift+;.) Entering the
single list unique category represented an average of 4.31 characters.

Again, I didn't like this answer since it didn't match my preconceived
notion that dual list saves me typing. (At least this vindicated my theory
that weighting against frequency in the dataset would reduce the cost of
dual list entry.)

I had to spend a lot longer pondering this one. I don't enter data by only
the unique subcategory. I don't because I don't think of Food:Groceries as
Groceries (or G) whilst thinking of Automobile:maintenance as
Automobile:Maintenance (I can't think of this as just M since that collides
with Housing:Maintenance.) For this reason, even after several months of
trying to "get with the program" I still generally enter the category, the
separator, and the subcategory.

A little bit more query hacking and I determined the average keystroke cost
of entering the dataset, using the combined category and subcategory
namespace for the category and the individual parent category specific
namespaces for the subcategories and one character for the separator, to be
8.72 characters. This is more than three more keystrokes than dual list
entry from the separate namespaces.

Finally, I got a result I liked.

From this we can conclude that I have too much time on my hands or too much
of a sense of adventure for tackling questions like this. One can also
conclude that there may be some real effect here. The cost of this effect
depends heavily on two things: a) your category set and, particularly, the
extent of your usage of subcategories, and b) whether you actually enter
categorization using the optimal name every time. (The former is notable
since the M05 default categories all but eliminate subcategories. Why they
retained them for Taxes but not for other things where they are at least as
useful is a subject for another thread. The latter is notable since it
suggests that you have to remember, among 269 other possibilities, that g is
good enough for food:groceries but m is not good enough for
automobile:maintenance.) Of course, if you download transaction data and let
Money figure it out from the merchant name, the whole subject is moot.

As always, YMMV.

"Chris Cowles" <NoSpam[at]For.me> wrote in message
news:en6gZ%23A1EHA.2824[at]TK2MSFTNGP09.phx.gbl...
- quote -

I saw Dick's earlier request in this same thread. I'm sorry for not
answering sooner, but it's really not that interesting an answer, and it's
much too long for its worth. But you have asked nicely twice now.

Assuming a team with finite resources, every feature created or maintained
has an opportunity cost in things that the team will not do, whether in new
features, better quality, or earlier shipping of the release. That is
obvious, but it is useful to point out that in order to manage the product
we make many decisions where these tradeoffs are important, and even the
maintenance of existing features can have non-trivial costs.

So, all I can really do is explain the costs, and perhaps the train of
thought. The new register is essentially new code. As functionality was
brought over, it gave us a chance to examine it once again. Very early on,
we decided to settle on one version of the category combos for the new
register, and a single combo was deemed better for the customers we thought
would use it. It has been our default for new users for a few versions now,
and it tests better with potential customers.

We also did some reworking of the older register code (to base it on some of
the same foundations that the new register would be using). At this time,
the same thinking sort of leaked over in this form: "Is it worth the cost of
reworking and retesting this code, given that we have a more popular version
of the control set that we know we'll continue to develop in future
versions?"

I think that it was a mistake to let the thinking leak over, or at least to
let it answer the question. The team did look into the question of backwards
compatability, but convinced themselves that users didn't need both ways to
accomplish the same task. This evaluation didn't take into account the
attachment you naturally have to certain keystroke patterns or the seeming
arbitrariness of the decision.

I think that this thread has supported the thinking that both ways can be
considered better by different users, but I'm glad that we were able to
restore your choice in this matter.

-Russ Paul-Jones

"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:e4ctEi%230EHA.3368[at]TK2MSFTNGP10.phx.gbl...
- quote -

I saw Dick's earlier request in this same thread. I'm sorry for not
answering sooner, but it's really not that interesting an answer, and it's
much too long for its worth. But you have asked nicely twice now.

Assuming a team with finite resources, every feature created or maintained
has an opportunity cost in things that the team will not do, whether in new
features, better quality, or earlier shipping of the release. That is
obvious, but it is useful to point out that in order to manage the product
we make many decisions where these tradeoffs are important, and even the
maintenance of existing features can have non-trivial costs.

So, all I can really do is explain the costs, and perhaps the train of
thought. The new register is essentially new code. As functionality was
brought over, it gave us a chance to examine it once again. Very early on,
we decided to settle on one version of the category combos for the new
register, and a single combo was deemed better for the customers we thought
would use it. It has been our default for new users for a few versions now,
and it tests better with potential customers.

We also did some reworking of the older register code (to base it on some of
the same foundations that the new register would be using). At this time,
the same thinking sort of leaked over in this form: "Is it worth the cost of
reworking and retesting this code, given that we have a more popular version
of the control set that we know we'll continue to develop in future
versions?"

I think that it was a mistake to let the thinking leak over, or at least to
let it answer the question. The team did look into the question of backwards
compatability, but convinced themselves that users didn't need both ways to
accomplish the same task. This evaluation didn't take into account the
attachment you naturally have to certain keystroke patterns or the seeming
arbitrariness of the decision.

I think that this thread has supported the thinking that both ways can be
considered better by different users, but I'm glad that we were able to
restore your choice in this matter.

-Russ Paul-Jones

"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:e4ctEi%230EHA.3368[at]TK2MSFTNGP10.phx.gbl...
- quote -

I consider a combination keystroke the same as a single key, as long as it's
a natural hand movement. Therein lies the difference in our perceptions, I
believe.

I agree that it should remain an option. Disabling it was short-sighted by
MS. It only irritated some customers and did not provide any advantage to
those already using single categories.
--
Chris Cowles,
Gainesville, FL

"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:e4ctEi%230EHA.3368[at]TK2MSFTNGP10.phx.gbl...
- quote -

If the : were a ;, I might agree for the case of duplicates subs within
categories, which is not a common one for me.

But here's an example of where this doesn't work. I have
Miscellaneous:Transit and Transfer:[many]. Old way took keystrokes: "tr TAB
Shift+(" (for account named "(pocket change)") since tr disambiguated
Transfer. New way takes keystrokes: "transf Shift+; Shift+(" to avoid
Transit. Now it's possible that some of the transfer targets would be easier
to just type and enable skipping typing the "transf". But I don't think of
it as anything but a Transfer:[name of acct]. So mentally, this is a hurdle
I still haven't overcome.

I've been running this way since I heard M05 was forcing it. I still prefer
the other. I could probably be retrained with enough time and practice. But,
I ask again, why must I be? What was the gain to the product of eliminating
the option? Did it make it a better tool? Did it make life any easier for
new users for whom it was already the default? I asked Russ this in a
posting in one of his threads. He didn't answer.

"Chris Cowles" <NoSpam[at]For.me> wrote in message
news:urQKJG%230EHA.2292[at]TK2MSFTNGP15.phx.gbl...
- quote -

It takes exactly the same number of key strokes when there duplicate
subcategories. Just replace the tab in dual-categories with a colon in
single-categories, once the first few characters uniquely identify the top
category.

It takes less keystrokes using single categories when you have unique
subcategories. Just skip the category (which you can't do in dual-category
display) and start typing the subcategory.

I used to prefer dual-categories as you do, Dick. I switched when '05 came
out, to make a comparison. In my opinion, it's better, but it's just that:
an opinion.
--
Chris Cowles,
Gainesville, FL

"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:eFlKF0i0EHA.2568[at]TK2MSFTNGP10.phx.gbl...
- quote -

point taken

Jim

"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:eFlKF0i0EHA.2568[at]TK2MSFTNGP10.phx.gbl...
- quote -

It takes more typing for the very reason Ian cites:

- quote -

These duplicates are not necessarily complete duplicates. But if I'm trying
to enter one or two or three characters, it has to disambiguate against more
than twice as many possibilities.

Likewise, it forces overcoming ten years of muscle memory for no good
purpose that I can see. Leaving the option for dual list cost nothing and
harmed no one. (Actually, it was an option for NOT dual list.)

This was not my top reason for disliking M05. See
http://umpmfaq.info/Money2005.htm for more information.

"Jim Johnson" <dogman56[at]msn.com> wrote in message
news:10q8tnk863f8b62[at]corp.supernews.com...
- quote -

That's how I do it to. I've never understood Dick's reasoning that more
typing is involved - seem less to me. I think if you know what lower level
one you want you can just type the first few letters of that and it will
pull up. There are a lot of gripes about 2005, but I never quite understood
why that one is such a big deal to people.

Jim

"Ian Waddington" <irwmlistlist[at]tiscali.co.uk> wrote in message
news:uHJ42ca0EHA.632[at]TK2MSFTNGP10.phx.gbl...
- quote -

No i dont like single category. I use the tab key for navigation.
"Dick Watson" <littlegreengecko[at]mind-enufalready-spring.com> wrote in
message news:eR1mDYW0EHA.2688[at]TK2MSFTNGP09.phx.gbl...
- quote -