Generic Import, Usual Usage Scenario

[Christian Stimming]

I feel that we are still quite far from actually having the same 
objective with the generic importer. Therefore I thought I should 
describe more clearly what "the usual case" for the generic importer 
would be -- what is "the usual scenario" for when users are going to use it?

 From my point of view, "The Usual Usage Scenario" is

* The user regularly (every 1-30 days) imports a number of transactions 
(some number between 1 and 100).
* 90% of these transactions are *new* transactions i.e. are *not* a 
duplicate of an already entered transaction.
* For 50% of these transactions, payee/description/text is uniform 
enough so that the destination account can automatically be correctly 
guessed.

If we now argue about a GUI for the importer, please keep in mind what 
our Usual Scenario is. If you think my above description doesn't quite 
fit your situation, please send your comments.

For the HBCI protocol, additional assumptions will hold that narrow down 
the usage scenario even more, giving "The Usual HBCI Scenario":

* *All* transactions have one known originating account.
* The bank account belongs to a German bank (HBCI simply exists only 
here), which implies the following two points:
* If an imported transaction is a duplicate of an existing (probably 
manually entered) transaction, the amounts will match *exactly* in 99% 
of the cases.
* If an imported transaction is a duplicate of an existing (probably 
manually entered) transaction, the date will be off by 1-2 days for 50% 
of these transactions.

In the ongoing discussion, I want to achieve a GUI that serves the 
user's needs in "The Usual Scenario" as good as possible. Additionally, 
I would love it if there is enough configurability to take into account 
"The HBCI Scenario" as well, which is currently the case e.g. through 
the fact that the hbci-protocol can call the 
Transaction-duplicate-matcher without having to call the account-matcher 
first.

Now what kind of GUI matches "The Usual Usage Scenario"?

As you can see above, I believe that the action of "duplicate detection" 
is the *exception* and *not* the rule. Therefore ultimately I would like 
to arrive at a GUI where the *exceptions* are marked in a way that they 
signal "Here further checking is necessary", and for the 90% rest it 
automatically should be obvious that the *don't* require any further 
manual checking for duplicates. One example of applying that point of 
view is that I strongly oppose any GUI that would require "clicking on 
every transaction" just to confirm the fact that they are new ones.

Also, since I just argued that only a small minority of imported 
transactions will turn out to be duplicates, I actually want to arrive 
at a GUI that does *not* require the user to ask himself "Is this 
transaction a duplicate" for *every* transaction. Again, this question 
is only relevant for a small minority of the transactions. That's why I 
oppose the integration of the destination-account-choosing into the 
existing duplicate-detection GUI: If these two actions appear in the 
same window, it means that the user is in fact asked both questions for 
each transaction. This IMHO will result unnecessary distraction from the 
real task. Therefore I am voting for a seperate window/druid page for 
the destination-account-choosing.

I believe that this is actually a point where the application of the 
Inductive UI Guidelines from 
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwui/html/iuiguidelines.asp
would make perfectly sense. To quote their four steps in designing IUI 
software:

    1. Focus each screen on a single task.
    2. State the task.
    3. Make the screen's contents suit the task.
    4. Offer links to secondary tasks.

In that sense, one single task is "Find the [10%] duplicates in the 
imported transactions". A different task is "Choose destination accounts 
for imported transactions".

Uh well. Maybe people should first comment on what I've already written.

Christian