Every user likes programs that are easy to use, so they can be learned
quickly, and even after some off-time, they can even faster be
re-learned. Programs that are LOGICAL and strictly follow certain
conventions help in this respect.
Many years ago, before starting to use EAGLE, I checked out several
layout programs and found one that I immediately disliked. The reason
was that it was definitely NOT logical: There were at least ten
different menu entries for moving things, because one entry could only
move symbols, the next one only nets, the third only... And those
entries were hidden somewhere in the third menu hierarchy, and no
shortcuts were possible. And schematics and board needed COMPLETELY
different thinking to be able to use them. What a mess.
At that time, EAGLE's GUI seemed VERY good to me: Same look-and-feel for
schematics, board and libraries, same commands, etc. Wonderful.
Unfortunately, there were and still are things that are NOT logical or
consistent (at least not from a user's point of view), and which make it
a bit hard for the user to understand what's going on. Most of these
things (perhaps all of them?) have already been mentioned before, but
anyway:
1. GROUPS can be moved across sheets, but not single objects. The
COPY command doesn't work across sheets, neither do INVOKE, ADD
etc. I had complaints about EAGLE not being able to move things
across sheets AT ALL, because people ALWAYS first try that with
single objects, and, after this fails, simply cannot believe
that it should work for groups.
2. If the COPY command is used with a single object, the object is
duplicated and NOT put onto the clipboard. If COPY is used with
a GROUP, this is duplicated AND put onto the clipboard.
3. There's no internal SNAP command available. Too bad. But wait,
isn't there some ULP that does that? Let's look into the ULP
folder. Gosh, there's a whole bunch of things! Weeeeelllllll,
there it is: 'snap-on-grid-sch.ulp'. But it doesn't work on my
board. 'snap-pin-in-symbol.ulp' doesn't work, either. Hmmm, is
snapping board elements not possible, then? Looking for half an
hour longer, one additionally finds 'cmd-snap-board.ulp' and
'cmd-snappads.ulp'. Why are they called differently, so that
one cannot find them easily? And, even better: Why are there
FOUR of them at all? It would be MUCH better if there was only
ONE program called 'snap.ulp' that did it all. Unfortunately,
even the (very spartan) user interfaces of these four programs
differ. Why? They all do the same thing: They snap objects.
A CONSISTENT user interface would be much more logical.
(As a matter of fact, I myself DID write a SNAP program that
CAN do all of that and HAS a consistent UI. Additionally,
groups are not supported, and object types to snap can be
selected. If anybody is interested, please reply)
4. The VALUE command supports only SINGLE objects. Why is it
not possible to bulk-revalue GROUPS? If there are objects
with VALUE=OFF in this group, one could just change the
warning message: "There are 4 components(s) with no user-
definable value. Do you still want to change those?"
5. VERY DANGEROUS BEHAVIOUR: Moving a GATE pin onto an existing
NET ending, the net is connected to the pin. Moving a NET
ending onto an existing GATE pin does NOT create any
electrical connection. Fortunately, this is an error found by
the ERC, but why let it happen in the first place? Of course,
NO electrical connections should be created automatically when
a net only TOUCHES a pin, but doesn't END there.
6. A select few commands (e.g., paste, add, replace, text) are
COMPLETELY cancelled when pressing ESC, meaning that there
is NO command active after pressing ESC. All other commands
can NOT be completely cancelled with ESC, but, strangely,
it's possible with the STOP button. It would be more logical
if the ESC key had ALWAYS the same functionality as clicking
on STOP.
(But I agree that there might be points in keeping the
current behaviour, even though it's not logical)
7. The CAM processor has a command line option for selecting
the desired variant, but there's no GUI option for this.
8. In order to let EAGLE display the REAL pad/via dimensions
for each layer, the user will have ENORMOUS problems finding
this function under DISPLAY, and then having to manually
set pad and via colours to zero. Who the heck knows this?
And hands up, please, of those who find this logical!
(Of course this IS logical, from a programmer's point of
view. But the user cannot and should not think in terms of
programmer's implementation details)
9. VERY NAUGHTY: The WIRE command doesn't do any proper wiring.
One has to use NET for this. It is NO problem that the
correct command is called NET, but it is a SERIOUS problem
that the WRONG command is called WIRE. That is VERY illogical.
I'm sure there's LOTS of other stuff like that, which simply doesn't
come into my mind immediately (and which I tend to forget, because I can
live a long time without these things being corrected, but a NEWBIE's
user experience might be crippled by inconsistencies such as these).
Andreas Weidner