Mail Archives: geda-user/2012/12/14/14:31:11
On Dec 14, 2012, at 11:20 AM, DJ Delorie wrote:
>
>> Consider that manual tagging is the simplest, least confusing, and
>> most predictable option. It should therefore be the model for the
>> primitive operation.
>
> It's also the most expensive for the user, so goes against "the tool
> should help you".
Even more important is "the tool should not hinder you": if the problem is simple, it should not force complexity on you. Also "the conceptual foundation for the tool should be as clean and simple as possible".
> Consider a user who cuts and copies a subcircuit 15
> times (I've done this, even scripted it). Asking the user to re-tag
> every single object in those pastes is a non-starter.
As I said, manual tagging should be the model for the primitive operation. That should not preclude automation (ideally, every primitive operation should be available as a function to the scripting language). But if you don't build on simple primitives, automation becomes more difficult. It also tends to be perverse to the user, insisting on unwanted complexity in simple situations.
>
> An ideal solution is something that can diagnose and locate shorts
> most (or nearly all) of the time, without requiring the user to do
> more overall work.
>
>> Especially when learning the tool, the user needs manual control
>> over what's going on.
>
> I disagree. IMHO the user should not have to do many extra steps
> before they've learned what they're for.
But the alternative is what you have in pcb. I have tried to learn it, but it's a hall of mirrors. There's no solid ground on which to stand, conceptually. "Elements" aren't elementary, "polygons" would be more honestly called "amoebas" (they are complex, living things), ...
> Each step in the learning
> process should have immediate feedback and reward.
Uh, oh, emotional words ;-)
In my experience with pcb, it's all punishment and confusion. It's impossible to get the program to do anything *simple*. Instead, it tries to read the user's mind, frequently getting it wrong. And it isn't just me: a couple of years ago I had an experienced professional engineer working for me. One of his tasks was learning pcb (I was thinking, OK, maybe it's just one of those things a simple-minded physicist can't get). He failed.
When learning C, you don't start with the autotools and work your way down to "Hello world". It's the other way around. Understanding the primitive operations is the key to understanding the higher level stuff. Of course, you must actually have primitive operations to understand.
John Doty Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd AT noqsi DOT com
- Raw text -