Re: Best idea of the week, make that year. Yeah, yeah, I know the year just started

["Chuck Martin" <cm -at- writeforyou -dot- com>]

"k k" <turnleftatnowhere -at- yahoo -dot- com> wrote in message news:229662 -at- techwr-l -dot-  -dot-  -dot- 
>
>
>
> >
> > P.S. To tie this to another thread, this is why a UI
> > seminar is in the long
> > term more useful than an XML class: done right, the
> > good system design would
> > alleviate the need for programming a follow-up
> > message.
> >
>
> I currently work for a company that does financial
> transfer software.
>
> The above statement isn't really applicable. The fact
> "Michaelangelo 5.5" isn't printed on the statement has
> nothing to do with UI design. The question of what is
> printed on the statement is a business decision made
> by the company that actually printed and sent the
> statement.

And the business can decide to print that information

>
> Credit card transactions are almost never handled by
> the company that sells you the product. That company
> hands off the information to a processor, a company
> that has the databases to handle routing ACH files
> between banks and the Federal Reserve. They do the leg
> work of notifying the FR and the credit card company
> of where money needs to be shifted between accounts.
> (In fact, ALL bank transfers in this country are
> actually done by the Federal Reserve. When someone
> speaks of banks transferring funds, what really
> happens is Bank 1 sends a messge to the Federal
> Reserve that they owe X dollars to Bank 2, and the
> Federal Reserve is the entity that actually sends the
> money.) The credit card company prints the statement
> and sends it to you. They are the ones that decide
> what to put on the statement.

Databases contain information. What information is contained--and what
information is transferred, is a decision made by the companies involved.

>
> The name of the product or the name of the company
> that sold it is not necessarily included in the data
> that goes through the processor to the credit card
> company. Most likely that file has only an account
> number to identify the source of the data. Obviously
> the credit card company doesn't want to bother doing
> the programming needed to extract the name of the
> product or its manufacturer from its database and
> include them on the printed statement. The people who
> sell you "Michaelangelo 5.5" or whatever it is are
> putting themselves out and doing the customer a great
> favor to correct a flaw in the system caused by the
> credit card companies increasing their profit margin
> by reducing their code creation load.

And therein lies the design issue. It's not uncommon for companies to take
the easy way out and then "fix it in the docs." It almost always takes more
design and programming resources to make a good UI, yet even in the 21st
century no one seems to remember the old saw about never enough time (or
resources) to do it right but always anough time (or resources) to do it
over (or patch it).

"That file" can have *any* information; that it doesn't have information
that would create a better user experience can be attributed to a number of
things, including laziness, stinginess, or an unwillingness to revisit
legacy bad design.

>
> UI design has nothing to do with this. The UI designer
> can't affect the business rules that cause the
> situation.
>
>
But that's exactly part of the UI designer's job: to make sure users get the
information they need, when they need it. If the business rules don't
currently accommmodate that, then change the business rules.

The thing is, it's so easy to defend bad practices. "The file doens't have
that information." Well why the heck not? Far too many people simply accept
limitations such as these because they are told it "can't" be done--but more
often than not, it *can.* It's just that someone, somewhere, decided they
*won't.* There's a huge gulf between "can't" and "won't."

Meanwhile, I believe things *can* be done, that things *can* be made better.
If you eliminate the word "can't" from your everyday vocabulary, you'd be
surprised at what you can do.

Chuck Martin