John Pruitt - Thinking about the customer in design

I Quite agree with john, as i created some software that way, a few years back, on windows, and targets.
Thanks for the info, quite usefull in reality.
Its there and always will be there, the design logic.

That a product does not end up looking like Frankenstein's monster makes sense from many points view:  end users, marketers, developers.  Still, Microsoft customers receive products that present an inscrutable public face, with many controls whose purpose and rationale and existence is not at all clear from their appearance in the product let alone in-product "help" and published literature, if any.  I am reminded of the repetitive experience of relearning the IDE as each release is published.  If I perform a certain task using a certain idiom in release X then that task is performed using a different idiom in release X+1 without so much as a how-do-you-do.  There are tons of widgets that I don't care about and won't ever use.  There are some that I should know exist and should be able to learn in under an hour through some well-defined teaching aids integrated with the product.  Differences between releases should be better explained.  What is available should be made explicit.  A good presentation of the design philosophy of a release would help users be better users of that release and willing buyers of the next release.  Back in the early 1970s I looked forward to receiving weekly updates (natural language summaries on the purpose of a feature set and how to use it) on a locally developed text editor.  It was a pleasure to vicariously experience the product as it was being built and to learn each feature as it was added.  In the 2000 aughts, things have devolved so that I see only the end product with no systematic approach provided to learn what it offers and how to use it.  This goes for everything from the IDE to the operating system.  Some of the Knowledge Base articles may as well be written in Martian for all the insight they provide.  There must be a tacit rule that all such writing be overly concise, rigorously accurate, commit to nothing, and, in the end, explain nothing unless you came to the article already more or less understanding the solution to the problem that you were trying to solve.  What must be obvious to people who work with products on a daily basis, because they create them, need not be and usually isn't obvious once the product is bought, paid for and sitting on someone's desk.  Crossing the gap has no single or obvious solution, but the gap should be recognized.