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

_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel