EAGLE Central Forums
Where the EAGLE community meets. Sponsored by Stratford Digital.

Home » CadSoft Support Forums » eagle.support.eng » Is anyone at AutoDesk listening?
Is anyone at AutoDesk listening? [message #167732] Fri, 11 November 2016 17:14 Go to next message
Paul Badger
Messages: 65
Registered: March 2014
Member
From an interview at Adafruit

*Adding board level design to the Autodesk portfolio is an interesting and sensible move  Given the significant differences between the UI and workflow in EAGLE and most Autodesk products, though, how do you plan to integrate EAGLE into the Autodesk ecosystem without isolating existing customers who have years of experience with EAGLE’s admittedly quirky UI?*
I think in some ways one of the things that makes EAGLE special to so many people is its UI. Speaking from experience, there is zero playbook when you build a UI for a tool that is so specific to a domain, especially when you began this long before there were UI standards out there (remember EAGLE is more than 25 years in the making). So I credit the EAGLE developers with managing to build a tool that isn’t surrounded by so much fluff! Can we make improvements? Of course we can, but it’s always a balance and we have to avoid compromising its simplicity for more menu options and workspace panel-creepage.
If you look at Fusion or even Inventor, you’ll notice that as our tools have gotten better, all of the interfaces have actually gotten simpler so I think it’s all trending in the same direction.

As I an educator and EagleCad user for the last five years (and author of some ULPs that add missing functionality to EagleCad) I would like to put in my vote for junking the "quirky" EagleCad interface for one that echoes the way the ENTIRETY OF OTHER GRAPHIC AND DESIGN SOFTWARE works. Old timers will quickly get used to using the mouse the way the rest of the world, and the rest of the their software does. New-comers will not have to read slightly ridiculous tutorials that explain how to work your way around a truly inadequate UI.

As an educator I always have to preface my comments to students with statements like "you have probably never used software this clunky before" and "Yes the mouse works differently than all your other software" and "Yes it does really take three or four clicks to do what you expect to be accomplished in one or two clicks" and "No there is no easy way to align objects, etc, etc"

I and many others have documented Eagle's UI inadequacies for years, many of the missing things should be easy to fix, and users have fixed them for years with ULPs of their own,
so implementing this functionality should be quick and easy. If you wish to see lists of bugs or missing functionality I'll gladly provide my own suggestions. if you search the internet, you can see this material going back years, things like "favorite Eagle bug contest"

As to the mouse question, while a few old-times may complain, using the mouse in a more standard way will quickly grow on them, as they realize that things are "just easier now" and they're  not missing the four extra mouse clicks.

Paul Badger

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209286
Re: Is anyone at AutoDesk listening? [message #167739 is a reply to message #167732] Sat, 12 November 2016 07:16 Go to previous messageGo to next message
Lorenz
Messages: 645
Registered: December 2006
Senior Member
Paul Badger wrote:

> From an interview at Adafruit
> [...]
> "Yes it does really take three or four clicks to do what you expect to
> be accomplished in one or two clicks" [...]

If you insist on doing everything with only the mouse you are right.

But set up some hotkeys for activating the commands you use most and
use the mouse only to select the object to apply it to and your work
flow gets even faster than the click optimized UI you seem to imagine.
--

Lorenz
Re: Is anyone at AutoDesk listening? [message #167741 is a reply to message #167739] Sat, 12 November 2016 12:14 Go to previous messageGo to next message
zoltan
Messages: 24
Registered: February 2006
Junior Member
On Sat, 12 Nov 2016 07:16:09 +0000
Lorenz <lorenznl@yahoo.com> wrote:

> If you insist on doing everything with only the mouse you are right.

I'm so glad you said that.

I for one would be happy to do things with the keyboard.

I loved the DOS OrCAD schematics editor back in the early '80s where
you could do everything with the keyboard. If you had a mouse, you could
use that but if you didn't, you could still do everything with ease.

When I say 'with ease' I mean 'usually with a small fraction of the
effort you need to do the same thing with Eagle'. Auto increment and
auto offset repeat. Record and replay. Hierarchical schematics (yes, I
know, Eagle 7 has that - but OrCAD had it 30 years ago).

I'd really be happy if Eagle would consider implementing some of those
features. Probably not overly complex, considering that at that time a
mainstream PC had 512K RAM, 5M HD and a 33MHz processor and it all fit
in that...
--
Zoltán Kócsi
Bendor Research Pty. Ltd.
Re: Is anyone at AutoDesk listening? [message #167744 is a reply to message #167739] Sat, 12 November 2016 15:58 Go to previous messageGo to next message
Paul Badger
Messages: 65
Registered: March 2014
Member
I'm all for hot keys, it still doesn't forgive the fact that to delete a group of objects I
1) Have to think about how to do it
2) Select the delete tool - maybe by hot key
3) Have to select the group tool
4) Have to hold the command key down
5) Have to click

Most other software
1) Lasso the objects
2) Hit delete key

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209342
Re: Is anyone at AutoDesk listening? [message #167745 is a reply to message #167744] Sat, 12 November 2016 16:31 Go to previous messageGo to next message
James Morrison
Messages: 1129
Registered: November 2004
Senior Member

Paul Badger wrote on Sat, 12 November 2016 15:58
I'm all for hot keys, it still doesn't forgive the fact that to delete a group of objects I
1) Have to think about how to do it
2) Select the delete tool - maybe by hot key
3) Have to select the group tool
4) Have to hold the command key down
5) Have to click

Most other software
1) Lasso the objects
2) Hit delete key

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209342


Hello Paul,

There is a reason that the EAGLE GUI acts the way it does. If you can understand the EAGLE philosophy then you can become quite efficient. I currently use Altium most right now and while it is a great tool and can do many, many things there are some fundamental things that are just more efficient in EAGLE.

EAGLE's primary modus operandi is to select the function and then apply that function to object after object. This is counter-intuitive to modern day OS's that primarily do the opposite: select and object (think right-click in file explore) and then select the function.

If you can understand that and start to think like that then EAGLE becomes very efficient. Like everything else, EAGLE's greatest strength is also its greatest weakness as this is not intuitive given modern day OS's generally behave in the opposite manner.

So thinking this way it becomes obvious that to move a group of objects one would:

- select the group function
- apply that to many object
- select the move function
- apply that to the group previously defined

But as you state, this is not the normal way to do things and causes new users especially great angst. I have suggested in the past that EAGLE institute an implicit group function when a user drags a rectangle or polygon around objects without a function selected. And an implicit move command when you left-click and drag an object or right-click and drag a group. Doing this doesn't have to break the current, efficient, way of doing things but at the same time makes it easier for newer users to at least not get frustrated and stick with EAGLE long enough to understand that there is an even better way to do things.

Cheers,

James.


James Morrison ~~~ Stratford Digital
http://www.stratforddigital.ca
Re: Is anyone at AutoDesk listening? [message #167748 is a reply to message #167744] Sat, 12 November 2016 17:46 Go to previous messageGo to next message
Olin
Messages: 903
Registered: December 2009
Location: Massachusetts
Senior Member
Paul Badger wrote on Sat, 12 November 2016 10:58

1) Have to think about how to do it

That's on you. As with any complicated tool, you have to learn to use it properly. Once you do, you don't have to think about it. I could say the same thing about your reverse way of doing it.

Quote:

Most other software
1) Lasso the objects
2) Hit delete key


In eagle:
1) group
2) Lasso the objects
3) Hit delete key

However, the real power of the modal interface becomes apparent when you want to perform the same operation on multiple things. To delete more objects in Eagle, you just click on the additional objects. This is very handy for actions like move, delete, setting values, etc.

No, we don't want Eagle to be different. Learn the tool before complaining about it.
Re: Is anyone at AutoDesk listening? [message #167750 is a reply to message #167732] Sun, 13 November 2016 00:25 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
Anybody complaining about the usability of EAGLE should think themselves lucky they don't have to put up with DxDesigner and be fleeced thousands of pounds annually for the privilege.

Just read the manual and follow a few tutorials and after a short while its really quite simple to use. That doesn't mean that there aren't improvements to be made in the usability of the UI, there are, but it certainly doesn't need completely changing.

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209348
Re: Is anyone at AutoDesk listening? [message #167760 is a reply to message #167732] Mon, 14 November 2016 14:35 Go to previous messageGo to next message
Chuck Huber
Messages: 599
Registered: October 2004
Senior Member
On 11/11/2016 12:14 PM, Paul Badger wrote:
> As I an educator and EagleCad user for the last five years (and author of some ULPs that add missing functionality to EagleCad) I would like to put in my vote for junking the "quirky" EagleCad interface for one that echoes the way the ENTIRETY OF OTHER GRAPHIC AND DESIGN SOFTWARE works. Old timers will quickly get used to using the mouse the way the rest of the world, and the rest of the their software does. New-comers will not have to read slightly ridiculous tutorials that explain how to work your way around a truly inadequate UI.

Wow... there's a couple of subjective observations. Quirky? ENTIRETY OF
OTHER GRAPHIC AND DESIGN SOFTWARE? Ridiculous tutorials? Truly
inadequate UI?

Certainly you have facts to back these claims?

> As an educator I always have to preface my comments to students with statements like "you have probably never used software this clunky before" and "Yes the mouse works differently than all your other software" and "Yes it does really take three or four clicks to do what you expect to be accomplished in one or two clicks" and "No there is no easy way to align objects, etc, etc"

I would think that an educator would be more interested in actually
teaching students the software rather than opining on it. Perhaps
taking a different approach to your preface would prove to have more
positive results. Such as... "Good morning students. I would like to
introduce to you some CAD software that features a slightly different
user interface. Once you learn this, it will make more sense to you and
you'll be more efficient with your work."

Of course, that would mean that you'd have to give up your
predisposition to the status quo. But it'd be worth an honest try.

> I and many others have documented Eagle's UI inadequacies for years, many of the missing things should be easy to fix, and users have fixed them for years with ULPs of their own,
> so implementing this functionality should be quick and easy. If you wish to see lists of bugs or missing functionality I'll gladly provide my own suggestions. if you search the internet, you can see this material going back years, things like "favorite Eagle bug contest"

Have you done the same for other software, oh, say... perhaps Windows?
Inventor? Pro/E? Altium?

> As to the mouse question, while a few old-times may complain, using the mouse in a more standard way will quickly grow on them, as they realize that things are "just easier now" and they're not missing the four extra mouse clicks.

There are several things wrong with this approach. First of all, the
concept of keeping up with the Jones's is not necessarily a good thing.
One of the key features of Eagle that makes it attractive as a tool is
the fact that it has a command line interface. The standard UI to which
you refer is drifting off into an area that's suitable only for the
casual desktop user whose biggest concern is how to make a sentence bold
in a word processor - i.e. for the masses. By sheer numbers they tend
to drive the UI development through market studies.

This is fine, as long as you're a casual desktop user. But as an
engineer, the "standard UI" is not necessarily the best approach. I
have found that Eagle's prefix notation (verb first, then object,
object, object... ) is far more efficient than a postfix notation where
one picks an object, then does something to it.

As for use of the term "old timers", you're discarding decades of
experience for no reason. Perhaps the testimony provided by this
experience doesn't promote your goal.

All in all, a user interface is certainly subjective, including my
perhaps heated observations above. All software can't be all things to
all users. Thus, when choosing software, one must consider the UI. One
of the reasons I chose Eagle for my company is precisely because of its
user interface. Its prefix notation and command line interface were
what brought it to the top of the short list of ECAD software. It's
availability on Linux sealed the deal. The license was icing on the cake!

I would no more ask Cadsoft to make Eagle behave more like Windoze or
Mac than I would ask Microsoft to make Windows behave more like Eagle.

Enjoy,
- Chuck
Re: Is anyone at AutoDesk listening? [message #167763 is a reply to message #167732] Mon, 14 November 2016 17:29 Go to previous messageGo to next message
Jorge Garcia
Messages: 1294
Registered: April 2010
Senior Member
Hello Paul,

Thank you for your comments. We are monitoring this situation very
closely and looking for the best way forward.

That's all I got for now.

Best Regards,
Jorge Garcia
Re: Is anyone at AutoDesk listening? [message #167769 is a reply to message #167732] Tue, 15 November 2016 07:34 Go to previous messageGo to next message
Joop_
Messages: 69
Registered: March 2007
Member
The fact that I can do almost everything with the keyboard is one of the reasons I like Eagle.
Re: Is anyone at AutoDesk listening? [message #167770 is a reply to message #167763] Tue, 15 November 2016 07:39 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 14.11.2016 18:29, Jorge Garcia wrote:
> Hello Paul,
>
> Thank you for your comments. We are monitoring this situation very
> closely and looking for the best way forward.
>
> That's all I got for now.

Just want to add my cents..
Being very familiar with both Eagle and Windows, I don't really think
the "modern" gui approach is impossible to do in Eagle. The gui would be
all about mapping your doings into a command line in the traditional
format, anything else would be too complex. I can't see any showstoppers
there.

I think may be there is a lack of understanding the advanced object
selection functions (key modifiers) in the windows (and Linux) GUI, like
how to add/remove cherry picked items to a selection group, how to
display and modify properties of multiple objects and so on. I see
people who cant even edit text the advanced way without using the mouse.
They don't know what shift,alt,ctrl used together with
arrow,home,end,page up,page down keys can do to help make things swift.
And the worst example is people who move their hand to the mouse when
they see an "OK/Cancel" requester. These are basic OS functionality that
are not hidden, but they are very useful functions that get hidden in
the shade, because there are more intuitive (but less effective) ways of
doing the same. I recognize very similar issues with new users in Eagle GUI.

Using standard GUI stuff, and add some initial voluntary tutorial at
first execution after the install (like games do) would probably help,
but there are us old dogs who prefer to use what we are used to.
Personally I could probably handle both types with the same efficiency.
Re: Is anyone at AutoDesk listening? [message #167773 is a reply to message #167770] Tue, 15 November 2016 15:00 Go to previous messageGo to next message
Joop_
Messages: 69
Registered: March 2007
Member
Morten Leikvoll wrote on Tue, 15 November 2016 08:39

..., but there are us old dogs who prefer to use what we are used to.


No, we prefer to use what gets the job done fastest, which is using the keyboard.



Re: Is anyone at AutoDesk listening? [message #167775 is a reply to message #167769] Tue, 15 November 2016 15:21 Go to previous messageGo to next message
Paul Badger
Messages: 65
Registered: March 2014
Member
> No, we prefer to use what gets the job done fastest, which is using the
> keyboard.

My point about selecting some things and hitting delete BTW.
Or do you type in Delete R1, R2 etc.

The keyboard interface needs a whole lot of work too, but I'm still glad it's there and use it some.
For example - why doesn’t ratsnest item toggle the fill back and forth - I have a ULP doing that.
My hat is off to anyone who has mastered moving a part with the keyboard.
Why that should be so hard is completely beyond me.

/**************************************  Eagle Challenge *******************************/

Goal - make ratsnest toggle the fills on polygons instead of the kludge it is now.

Put this ULP (hope I can attach it to this post ) in your ulp folder and call if from a hotkey - say command R or control R.

Challenge: Tell me you don't think this works better than the way it works now - (maybe you already have your own hack in place for similar functionality already). Question: Why are we talking about this after 30 years?

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209563
Re: Is anyone at AutoDesk listening? [message #167776 is a reply to message #167775] Tue, 15 November 2016 17:13 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> Paul Badger wrote:
>
> Goal - make ratsnest toggle the fills on polygons instead of the kludge it is now.
>
What do you mean? What is the kludge with the current system?

I have cmd+R set to do RATSNEST;
I have cmd+shift+R set to do RATSNEST; RIPUP @;

So I can do a ratsnest with all the polygons filled with the former and a ratsnest with none of the polygons filled with the latter. To me, toggling the fill state with successive clicks of the ratsnets would just be annoying.

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209568
Re: Is anyone at AutoDesk listening? [message #167778 is a reply to message #167775] Tue, 15 November 2016 17:16 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> Paul Badger wrote:
>
> Put this ULP (hope I can attach it to this post ) in your ulp folder and call if from a hotkey - say command R or control R.
>
> Challenge: Tell me you don't think this works better than the way it works now - (maybe you already have your own hack in place for similar functionality already). Question: Why are we talking about this after 30 years?
Your ULP didn't get attached so we can't look at what you are proposing.

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209569
Re: Is anyone at AutoDesk listening? [message #167782 is a reply to message #167732] Tue, 15 November 2016 17:33 Go to previous messageGo to next message
Paul Badger
Messages: 65
Registered: March 2014
Member
Seems like I can upload a video but nothing else? I know I've seen ULPs posted on this forum.
Here's the content - just paste it into a blank ulp and save it as toggleRats.ulp (I don't think the name will matter if you want to call it something else)
If someone has figured out how to post files please clue me in.




int fillings;
if(!board){ dlgMessageBox("Start this ULP in a Board"); exit(0);}
else {    
     board(B){
          B.signals(S){
               S.polygons(P){
                    P.fillings(F){
                         fillings++;
                    }
               }
          }
     }
if(fillings>0)exit("RIPUP @;\n");    //"Fillings exist"
else exit("RATSNEST;\n");
}

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209602
Re: Is anyone at AutoDesk listening? [message #167783 is a reply to message #167782] Tue, 15 November 2016 17:47 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> Seems like I can upload a video but nothing else? I know I've seen ULPs posted on this forum.
You just go into the advanced version of the editor (top right of the edit window) and then there is the option to attach it.

So I have tested your ULP and it works fine as I understood how you meant it to work. I'm not sure how it's improving on what can currently be done though? I'm not sure what you think is a kludge with how EAGLE currently works in this regard?

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209570
Re: Is anyone at AutoDesk listening? [message #167784 is a reply to message #167783] Tue, 15 November 2016 18:38 Go to previous messageGo to next message
hbridge99
Messages: 4
Registered: November 2016
Junior Member
>
>
> So I have tested your ULP and it works fine as I understood how you meant it to work. I'm not sure how it's improving on what can currently be done though? I'm not sure what you think is a kludge with how EAGLE currently works in this regard?
You hit ratsnest and polygons fill. Now how do I get them to “un-fill". You could be forgiven if you thought it might be in the menu just under ratsnest.
You could be forgiven if you thought it would toggle by hitting (or typing ) rats again. Instead it requires digging through the manual to find Ripup @; (and don’t forget the semicolon!)

So: Lets get this straight. Ratsnest is in the menu - and you can make a hot key for it.
But Ripup @; requires digging through the manual or the help section - I just took a quick look and there is not mention of Ripup @; in help ratsnest.
Maybe I missed it. Why dig through the manual when it should be intuitive, and easy.

Why would anyone imagine that the opposite of Ratsnest should be Ripup ? Do Eagle users enjoy learning this obscure stuff?
Why not “!rats” or “~rats"

OK - I’m not trying to be strident but I rest my case.

Anyway if anyone at AutoDesk is reading this - try it out for yourself and see what you think. It can’t be more than a little work to fix in quick order and you’ll be saving users a lot of grief.
I had to actually Google and or look through my ULP code (actually a kind reader in the forum wrote most of it). I wrote the ULP because I couldn’t remember the obscure command.

Paul

text from forum posted below

Re: How to unfill a polygon after ratsnet < https://www.element14.com/community/message/57138/l/re-how-to-unfill-a-poly gon-after-ratsnet#57138>

Richard Herman Jul 29, 2012 12:13 PM (in response to Gus Sabina < https://www.element14.com/community/thread/19268/l/how-to-unfill-a-polygon- after-ratsnet?displayFullThread=true#57135>)
Op Sun, 29 Jul 2012 18:34:51 +0200 schreef Gus Sabina

<noreply-116942@element14.com <mailto:noreply-116942@element14.com>>:


Hi:


Once you create a polygon for a ground plane, and after using Ratsnet,

the polygon fills. How to get rid of the fill again (other than closing

and opening the .brd again)?


Thanks;

Gus



Hi Gus,


Use RIPUP on an edge of the polygon. HELP RIPUP


Richard


Helpful Yes < https://www.element14.com/community/thread/19268/l/how-to-unfill-a-polygon- after-ratsnet?displayFullThread=true#> | No < https://www.element14.com/community/thread/19268/l/how-to-unfill-a-polygon- after-ratsnet?displayFullThread=true#>
Like < https://www.element14.com/community/thread/19268/l/how-to-unfill-a-polygon- after-ratsnet?displayFullThread=true#> Show 0 Likes(0) < https://www.element14.com/community/thread/19268/l/how-to-unfill-a-polygon- after-ratsnet?displayFullThread=true#>
Reply <>
Actions < https://www.element14.com/community/thread/19268/l/how-to-unfill-a-polygon- after-ratsnet?displayFullThread=true#>
Re: How to unfill a polygon after ratsnet < https://www.element14.com/community/message/57208/l/re-how-to-unfill-a-poly gon-after-ratsnet#57208>

Jorge Garcia Jul 30, 2012 1:37 PM (in response to Gus Sabina < https://www.element14.com/community/thread/19268/l/how-to-unfill-a-polygon- after-ratsnet?displayFullThread=true#57135>)

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209582
Re: Is anyone at AutoDesk listening? [message #167785 is a reply to message #167784] Tue, 15 November 2016 19:17 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> hbridge99 wrote:
>
> You could be forgiven if you thought it would toggle by hitting (or typing ) rats again. Instead it requires digging through the manual to find Ripup @; (and don’t forget the semicolon!)
>
> So: Lets get this straight. Ratsnest is in the menu - and you can make a hot key for it.
> But Ripup @; requires digging through the manual or the help section - I just took a quick look and there is not mention of Ripup @; in help ratsnest.
> Maybe I missed it. Why dig through the manual when it should be intuitive, and easy.
OK, I agree it could be made more obvious to new users by having a menu option or toolbar button to convert the polygon fills to outline.

Actually thinking about it some more, an alternative could be to have a view option which simply toggles the rendering mode of polygons rather than issuing a complete new ratsnest command. Sometimes I don't want to do a ratsnest because it then moves an airwire to somewhere inconvenient and I can't then route from the part of the net I want to.

Another way could be to have something like RATSNEST @; to tell it to process just the polygons and not do anything else.

> hbridge99 wrote:
>
> Why would anyone imagine that the opposite of Ratsnest should be Ripup ? Do Eagle users enjoy learning this obscure stuff?
> Why not “!rats” or “~rats"
>
> OK - I’m not trying to be strident but I rest my case.
I guess to me it's just not been that big of a deal to work it out and there are other things I would rather the devs be spending their time on like push and shove routing, decent net highlighting, assigning colours to groups of nets or net classes, bus routing with length matching, improvements to ULP, database connectors, etc, etc, etc.

I've used some very expensive PCB tools over the years and haven't found one then doesn't have some seriously frustrating issues. EAGLE is the only one that I can usually easily work around issues either by creating shortcuts or writing ULP to add new features. As an example of seriously frustrating in other packages, I had to add a whole new set of additional library files and write a netlist post-processor to allow me to connect a single symbol pin to multiple PCB pads when using DxDesigner because Mentor Graphics do not support this and believe firmly that there should be a 1-to-1 relationship between schematic symbol pins and PCB pads. I don't agree and I don't want to have to have and connect up 100+ GND pins on a large FPGA, or have multiple different symbols for an NPN transistor just so I can support transistors being in SOT23, SO8, etc.

> hbridge99 wrote:
>
> Anyway if anyone at AutoDesk is reading this - try it out for yourself and see what you think. It can’t be more than a little work to fix in quick order and you’ll be saving users a lot of grief.
> I had to actually Google and or look through my ULP code (actually a kind reader in the forum wrote most of it). I wrote the ULP because I couldn’t remember the obscure command.
I'm fairly sure Jorge and Richard from Autodesk will be reading this thread, I think Jorge commented on it a few posts back.

Best Regards,

Rachael

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209571
Re: Is anyone at AutoDesk listening? [message #167786 is a reply to message #167784] Tue, 15 November 2016 19:40 Go to previous messageGo to next message
Ed Robledo
Messages: 49
Registered: August 2005
Member
Hi Everyone,
EAGLE continues to progress thanks to the comments and suggestions from the community, some we can be implemented faster than others. But, be assured, that the CadSoft Team is closely monitoring the forums!!!
We are Listening!!!
Best Regards,
Ed

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209584
Re: Is anyone at AutoDesk listening? [message #167789 is a reply to message #167732] Wed, 16 November 2016 01:14 Go to previous messageGo to next message
Matt Berggren
Messages: 34
Registered: November 2016
Member
Hi Paul (et.Al) --

Direct answer <> direct question:  this sort of cleanup is on our roadmap and as someone both with a responsibility for the tools (EAGLE) and also as an eagle user (see https://hackaday.io/matt ( https://www.element14.com/community/external-link.jspa?url=https%3A%2F%2Fha ckaday.io%2Fmatt) for appropriate street cred) I'll add that this is super high on our priority list.  :)  We can do this without screwing up shortcuts and other command-line capabilities.  So to those others who may be concerned we'll screw this up, we're also super sensitive to this and we'll be sure we get this right. 

Selection is such a fundamental thing to get right and this is an area slated for some upgrades indeed!  What you're highlighting with both Selection, Delete and other processes, are a common area in which we've gotten feedback and I'll go on record as saying, we'll tidy this up soon!  Just hang in there and get ready for some pretty awesome stuff in the pipeline!

Best regards,

Matt Berggren
Director - Autodesk.

ps.  we're listening.  coming in loud and clear. 

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209622
Re: Is anyone at AutoDesk listening? [message #167791 is a reply to message #167785] Wed, 16 November 2016 07:04 Go to previous messageGo to next message
Lorenz
Messages: 645
Registered: December 2006
Senior Member
rachaelp wrote:
> [...]
> Sometimes I don't want to do a ratsnest because it then moves an
> airwire to somewhere inconvenient and I can't then route from the part
> of the net I want to.

do you know about the 'shift' and 'ctrl' modifiers of the route
command?
--

Lorenz
Re: Is anyone at AutoDesk listening? [message #167792 is a reply to message #167791] Wed, 16 November 2016 07:53 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> Lorenz wrote:
>
> do you know about the 'shift' and 'ctrl' modifiers of the route command?
>

No I did not.... :8} They'll come in handy! Thank you :)

I just wish I knew of a convenient alternative for the centre button for changing routing layers on a Mac (as it doesn't have the centre button).

Note: It's Cmd rather than Ctrl for Mac users (in case any other Mac users are reading this and don't know this),

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209624
Re: Is anyone at AutoDesk listening? [message #167793 is a reply to message #167745] Wed, 16 November 2016 07:59 Go to previous messageGo to next message
Rob Pearce
Messages: 480
Registered: September 2012
Senior Member
On 12/11/16 16:31, James Morrison wrote:
> So thinking this way it becomes obvious that to move a group of objects one
> would:
>
> - select the group function
> - apply that to many object
> - select the move function
> - apply that to the group previously defined
>
> But as you state, this is not the normal way to do things and causes new
> users especially great angst.

Not normal for word processors but it IS how GIMP works, almost.

I've tried using other CAD tools with different UI philosophies. Eagle's
one works.
Re: Is anyone at AutoDesk listening? [message #167794 is a reply to message #167770] Wed, 16 November 2016 08:04 Go to previous messageGo to next message
Rob Pearce
Messages: 480
Registered: September 2012
Senior Member
On 15/11/16 07:39, Morten Leikvoll wrote:
> These are basic OS functionality that are not hidden, but they are very
> useful functions that get hidden in the shade, because there are more
> intuitive (but less effective) ways of doing the same.

"More intuitive"? On the latest pieces of reinvented cr@p from
Microsoft? Rubbish!

Intuitive is a vastly over-abused word. People use it to mean "what I
learned first". This is NOT what it means. People use it to mean "what
I've always done". This is also NOT what it means.
Re: Is anyone at AutoDesk listening? [message #167795 is a reply to message #167773] Wed, 16 November 2016 08:04 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 15.11.2016 16:00, Joop wrote:
> Morten Leikvoll wrote on Tue, 15 November 2016 08:39
>> ..., but there are us old dogs who prefer to use what we are used to.
>
>
> No, we prefer to use what gets the job done fastest, which is using the
> keyboard.

Did anyone suggest to remove the command line bar? I would protest to
that too.

The discussion is purely how the GUI interface could/should work. The
GUI is orthogonal to the command line. As I mentioned, the GUI will
build a [traditional] command line and execute that.

Examples done with "modern" gui:
Task:Group some different width wires, add a few to the group and change
all to 0.2mm. Also change class to 0"

Howto:
- Lasso wires (same as click group + lasso)
- Similar to existing GUI, Ctrl+click on some more wires to toggle the
group selection (I've also seen some sw do ctrl+lasso up to remove
selected objects and ctrl+lasso down to add selected objects)
- Select properties from context menu or normal menu. A window of
properties is opened, and the width property will contain "<multiple>".
(All parameters containing "<multiple>" will not change). For
checkboxes, there are the "indeterminate" mode for "don't change".
- Now type 0.2mm in the width property field, and set class to 0 and
press apply/ok. The GUI will now process the parameter list and build
and execute the command "change width 0.2mm (>c0 0) change class 0 (>c 0
0)" and apply to the group.

For the old gui you would have to (note, commands left because this is a
pure GUI issue):
-select group under the change icon
-select bits with lasso or ctrl, much like the above
-select change width 0.2mm/(... and type 0.2mm) (note the number of
clicks and precision mouse movements you need to do to get there)
-ctrl+rightclick to apply
-select change class 0 (more precision mouse manouvers)
-ctrl+rightclick to apply

Even if the "modern" way contains more text, it's easier to handle and
more intuitive to new users.

Please challenge me with something you would find hard to do on a modern
GUI, cause I can't see anything that would not work.
Re: Is anyone at AutoDesk listening? [message #167796 is a reply to message #167794] Wed, 16 November 2016 08:39 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 16.11.2016 09:04, Rob Pearce wrote:
> On 15/11/16 07:39, Morten Leikvoll wrote:
>> These are basic OS functionality that are not hidden, but they are very
>> useful functions that get hidden in the shade, because there are more
>> intuitive (but less effective) ways of doing the same.
>
> "More intuitive"? On the latest pieces of reinvented cr@p from
> Microsoft? Rubbish!

*grin*

Ok, we can say a lot of bad things about microsoft, but they do have
years of wide experience with this, including ripping stuff from others.
But the result is pretty good when you know the few tricks of the trade.
(They did move focus over to touch now, but thats a different horror story)


> Intuitive is a vastly over-abused word. People use it to mean "what I
> learned first". This is NOT what it means. People use it to mean "what
> I've always done". This is also NOT what it means.
>

Yes, there is definitely a huge bias and misunderstanding to
"intuitiveness" from age and experience. One of my colleagues still
swear to emacs, and some others don't understand the problem with using
'vi' [for the younger ones:vi is an ascii text editor known for its non
intuitiveness]. I myself find the path of least resistance by using the
tools I know best, even if there may be more efficient tools around with
different hotkeys.

In the end, Autodesk needs to find their target audience. I suspect they
want to grab more customers, and they are often younger than us and have
some experience with different OS's. Autodesk also has a lot of
experience with markets and very good (but expensive) existing sw tools.
They may even have some standards for their developers to follow. I
suspect they don't want Eagle to stand out in the crowd, and they want
new customers to get going quickly (or they want to charge $$ for
training, I dont know)..
Re: Is anyone at AutoDesk listening? [message #167797 is a reply to message #167795] Wed, 16 November 2016 08:49 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> CadSoft Guest wrote:
>
> Even if the "modern" way contains more text, it's easier to handle and
> more intuitive to new users.
>
> Please challenge me with something you would find hard to do on a modern
> GUI, cause I can't see anything that would not work.
>
>
Personally I have no issues with improvements to the UI happening, there are areas that can be a little clunky and take more clickety clicking than should be necessary at the moment but I don't think solving these issues requires a complete overhaul of the UI. I do agree though that there wouldn't be anything that would be harder if the UI were to be modernised, I just don't think the UI is that bad that it warrants a huge development effort to overhaul it. Far more important to me is for new features to be introduced which start to bring EAGLE much closer in functionality and performance to the likes of Altium, Cadence and Mentor Graphics. This would likely lead to significantly increased revenues for Autodesk from EAGLE Ultimate sales to engineering professionals and companies.

However, what I do object to is rants about how bad the UI is and that it must be completely re-written to make it "modern". The goal of any UI changes should be to reduce the number of operations required to get any particular task done. At the end of the day EAGLE is a CAD tool and you would expect users of this type of tool to have the capability to learn and adapt to the UI of the tool. I personally expect to have to do an amount of learning with any new software application I pick up. None of the equivalents from the big three vendors I listed above are anywhere near as easy to just pick up and use as EAGLE currently is.

Best Regards,

Rachael

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209627
Re: Is anyone at AutoDesk listening? [message #167798 is a reply to message #167794] Wed, 16 November 2016 08:55 Go to previous messageGo to next message
warrenbrayshaw
Messages: 1759
Registered: January 2010
Location: New Zealand
Senior Member
On 16/11/2016 9:04 p.m., Rob Pearce wrote:
!
>
> Intuitive is a vastly over-abused word. People use it to mean "what I
> learned first". This is NOT what it means. People use it to mean "what
> I've always done". This is also NOT what it means.
>

Hear hear. I totally agree and I'm totally tired of people using the
word to justify their laziness for not learning how to operate the
product. Imagine if one learned to play guitar and upon picking up a
saxophone, complained that it did not work like a guitar so change it.
Hey, I only want to make music and you said the saxophone would make
music so stick some strings on it.

Warren
Re: Is anyone at AutoDesk listening? [message #167800 is a reply to message #167789] Wed, 16 November 2016 10:59 Go to previous messageGo to next message
geralds
Messages: 227
Registered: February 2014
Senior Member
Hi Matt,

Ok, direct answer <> direct question.
When will repaired Cadsoft website?
https://cadsoft.io/de/ressourcen/bibliotheken/
I come from PCAD (since 1985) then i worked with ORCAD, Altium, some others; but all of them  was very expensive.
Also with Autodesk CAD many years.
So, for development in electronics, i bought Eagle, 5.12 - 6.6.0 pro and a work until now with this tools
because very cheap, practical to use and many of my customers have Eagle.
With the 7.7.0 just in express version because i have the same function since version 6.0.
Why is no real progress in this? just naming the wires in the pcb, thats all?
This functions was implemented in PCAD in the 1990' and much more.
But now it's a little bit confuse what can i do for the future.
My favorite is PCAD, - today Altium Designer, but i don't like to give 10.000 Eur or more.
I have a small company and i fight every day in this market.
I'd like to upgrade my pro license jumping directly from 6.6.0 to 8.0.0 (if this version comes)  - is this possible?
Last year also few month i asked some questions about this.

https://www.element14.com/community/message/161484/l/eagle-lizenz-upgrade-v on-6-auf-8#161484 (/message/161484/l/eagle-lizenz-upgrade-von-6-auf-8#161484)

Best Regards
Gerald

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209559
Re: Is anyone at AutoDesk listening? [message #167802 is a reply to message #167732] Wed, 16 November 2016 13:15 Go to previous messageGo to next message
Joop_
Messages: 69
Registered: March 2007
Member
Imho not the gui needs to change but the manual.
What needs to be done is that new users need to be educated about how to use the keyboard.
Re: Is anyone at AutoDesk listening? [message #167806 is a reply to message #167802] Wed, 16 November 2016 19:03 Go to previous messageGo to next message
Ralf Stutzenberger
Messages: 1
Registered: November 2016
Junior Member
@joop14 - I would like to disagree.

Every user knows how to use the keyboard.
What you mean is: learn more and more shortcuts. Photoshop tells us: learn my shortcuts, Calamus tells us: learn my shortcuts, Windows tells us: learn my shortcut, MacOs tells us: learn my shortcuts ... and so on.

Software shoud support the user. A user should no be the slave of the software.
Here in Germany we have a nice slogan: "nowadays computer help us solve problems which we hadn´t when there were no computers.
I remember in early days I was creating PCB-Layous first with paper and coloured ink, then with Brady-Symbols. And at last with software. But the bigger software was, the more complicated it is.
Intuitive usable GUI, flexible Icons, intelligent support by the software is what I wish. Irfanview, Total-Commander....  examples for cool and tricky GUI and usability

Regards
Ralf

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209655
Re: Is anyone at AutoDesk listening? [message #167807 is a reply to message #167806] Wed, 16 November 2016 20:13 Go to previous messageGo to next message
Matt Berggren
Messages: 34
Registered: November 2016
Member
Thanks Ralf, I tend to agree.  Simply educating the user on shortcuts is no replacement for good, intuitive UI/UX.  So there needs to be a balance between what EAGLE does extremely well (and I have my list of favorite commands / processes / patterns in the SW) and what is no longer intuitive as our user behavior transforms and is influenced over time. 
I had worked pretty extensively on other EDA tools in addition to EAGLE in my 20 years in the ECAD industry and it's always essential that we (as developers) take a step back and ask "is that the best, fastest, most intuitive way to do <xyz>?".  If it's not, then you dont really have a defensible position when challenged by subsequent generations of engineers, makers, hackers, creatives, etc. who are coming online having adapted to contemporary UI/UX models.  Of course it's always amazing to have the love and the loyalty of the power users but we have to also acknowledge that paradigms change and we have to adapt to create the widest space possible for new users to come on board and be productive as possible, fast.   

Rest assured, we're making UI / UX decisions only after a serious look at how things operate and the reasons for certain features having been implemented certain ways (of course there was a reason that a developer took the approach they did, so we need to be mindful of that).  And I'd expect that we will have good reason for any changes before we commit them into the release version of the product. 

Best regards,

Matt Berggren
Director - Autodesk.

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209631
Re: Is anyone at AutoDesk listening? [message #167808 is a reply to message #167789] Wed, 16 November 2016 23:00 Go to previous messageGo to next message
Olin
Messages: 903
Registered: December 2009
Location: Massachusetts
Senior Member
Matt Berggren wrote on Tue, 15 November 2016 20:14

We can do this without screwing up shortcuts and other command-line capabilities.  So to those others who may be concerned we'll screw this up, we're also super sensitive to this and we'll be sure we get this right.


The only way to not screw it up is to leave it alone. Look carefully here at who is saying what. It's the new users that haven't taken the time to learn Eagle that come here and complain and want everything different. These also tend not to be the EE professionals that you need at the core of your customer base. Those that have used Eagle for years and use it often and professionally generally want you not to mess with the user interface, and want you to add some real substantive features instead.

I am one of those. I've used Eagle since version 4. I do remember it took some time to learn. I had to look things up and even call tech support on a few occasions. But after a while, I learned to use it well and wouldn't want it to work any other way. It's a breath of fresh air amongst the great mass of software out there that gets flashier and harder for power users each version.

Every other piece of large software I've used over the years has gotten harder to use. I wrote a whole book (yes, literally, The Way Computer Graphics Works, John Wiley and Sons) in the 1990s using MS Word. I took the trouble to actually read the manual, and got pretty good at it. Each version of Word after that became harder and harder to use, keyboard shortcuts broke, menu entries were moved around, and the interface generally dumbed down. I no longer use Word except when I really have to. Each version seemed to be more optimized for instant gratification at the expense of long term usability. Don't be like that!

The problem to address is not to make Eagle's UI "better". It's already quite good, well above most software. Don't strive to be like lesser software just because most of them are.

The problem to address is to make new users feel more comfortable with Eagle until they learn it well enough to appreciate its power the way it is. You seem to be falling into the trap of listening to the inexperienced but vocal users. They're new, don't get instant gratification, so of course they want everything the way they currently imagine is better. They've not learned the power of how things are done, don't have scripts, ULP, and a whole bunch of tricks and shortcuts and pet ways of doing things they've learned over the years to protect. Basically, they've got nothing to loose. Your established power user have a great deal to loose, and you can't afford to loose them. If you do, you'll be just another hobbyist product, and you'll always be compared to free offerings like KiCad instead of the real professional packages you need to be able to compete with.

So what to do? Good education. I'll admit, Eagle is hard to learn initially. The fix is to make the learning easier, not to dumb down the product itself. There are many things that can be done without hurting the product by a misguided "fix" of the UI.

Just fixing the awful help system alone would be a good start. I've used Eagle since around 2000 and have probably done over 100 boards with it, but I still have to look up details now and then. Even someone like me finds the help system frustrating. The good part about it is that you can look up details of a particular command reasonably well. However, it's difficult to use to ask about features. There is no overall index, at least that actually works (no, a global pattern search is not a index). Help windows pop up wherever they want, and never big enough to read.

Looking up the details of a command means entering "help name". Easy enough so far. Then a tiny help window pops up someplace. Now you have to move your hand from the keyboard to the mouse, interrupting workflow, and resize the help window. Now you have to read most of the help page to find what you are looking for. There is not string-find capability within a help page.

Here's a example. Go figure out how to set the spin flag on a existing text string. No, really, go actually try that. I dare you. This is something I do just infrequently enough to not remember between uses. The obvious place to start is with the TEXT command help page. It's easy enough to get that open. Now you want to look for "spin", but argh, Ctrl-F doesn't work, nor does there seem to be anything like it to search for "spin" on that help page. The only option is to skim, but not too quickly, looking for where the spin flag is mentioned. You see it near the top under "Orientation", but that only tells you that you can set the spin flag if you want text upside down. You came here already knowing that. The question is how to set the spin flag. More reading. You get to the end but don't find any other mention of the spin flag. Did you miss it because you skimmed the text, or is it really not there? You read the whole help page again, this time being more careful. No, it really isn't there. Now what? Back in the Orientation section it mentions that the "usual definitions" for orientation are used, which are listed in the ADD command help page. At least that's a link.

Now in the ADD help page, we have the same problem all over again. I just want to know how to set the spin flag, so want to find "spin", but there is no such mechanism. Skimming down, we find the "Orientation" section, and see that "S" to the orientation string sets the spin flag. Finally, just enter "S" in the right place.

But wait, where exactly do I put this "S"? Not in the TEXT command, since I'm trying to modify a existing text string. TEXT is for writing new strings. ADD makes no sense here, although that's where the spin syntax was finally found. I don't want to draw a new text string, I don't want to add something to my schematic or board or device. Now what? Seriously, think about it. Do you know? You've tried to RTFM and got to a dead end. Argh!

I'll cut this short and tell you that you need to use the ROTATE command. I know that at this point, but can you see how frustrating this is for a new user?

This kind of thing is why people bitch. Note the real problem here, though. It's not that Eagle has a spin flag, and that ROTATE needs to be used to change it in existing text strings, but that it's really hard to figure that out. And this is just one example of many.

The solution isn't yet another clickety-click interaction that is great the first two times you use it, but then becomes annoying baggage ever after. The solution is better education, introduction, and self-help. All the help text expanded out as a book in a PDF file, keeping the hyperlinks, would be big step forward. Getting a real tech writer to go over the help text would also be a good step. Yes, the information is there, eventually, but poorly indexed if at all, and too often not where you think to look for it. There is also very little topic-oriented help.

Documentation must serve several different purposes. There must be introduction for new users, topic-orientated help for when you don't know the specifics to ask about and to find out what's there, and reference help to look up details when you know what to ask. All are important, but you pretty much only do the latter.

The answer isn't just more links and more wordy descriptions in the existing reference text. That would make it worse because that dilutes the reference purpose. You need to recognize that it takes different sections, written with the different purposes in mind, to address each purpose properly. Lots of side information is clutter getting in the way of the facts in a reference section, and details increase the signal to noise ratio in the topic sections. A few good examples can be useful even in a reference section, but need to be liberally used in introduction sections. The topic sections should refer to the reference for the details, not try to duplicate them.

Writing good documentation is hard. But hard or not, this is where effort will yield the biggest return. You expect a new package to require new knowledge to learn. The frustrating part is when this learning is difficult. You then revert back to expecting it to work like other things you know. That's what causes the trouble.

Quote:

Selection is such a fundamental thing to get right and this is an area slated for some upgrades indeed!


No, noooo, nooooooooooooooooo! Don't break this. Selecting in Eagle works better than in other software. Changing this is short term gratification at the expense of klunkiness ever after. Don't fall for that. Don't just knee jerk and give the whiners what they want. Find the root cause of the whining, which is really the difficulty and frustrations of learning Eagle, not the actual details of Eagle.

Here's a good example from just a few days ago. I'm a electrical engineer with considerable experience using Eagle. I work with someone that does drafting and mechanical design, and uses AutoCad (I may have the name slighly wrong, but its one of your products). I only have AutoCad (or whatever it is exactly) viewer on my machine, not the full program.

I was trying to get some dimensions off a drawing, in part so that a circuit board I am designing with Eagle can mount to it properly. I asked the ME, and he showed me how to use the MEASURE "tool". Each time I wanted to find the X,Y offset between two points, I had to tediously click on the measure thingy (in a very tall bar at top using up a lot of pixels), click to make it drop down, then click on a ruler icon. I then click the two points I want to measure between. A little rectangle surrounds each. So far OK, maybe more clickety-clicking than it needed to be, but now what? Where is the measurement? After some futzing around, I find that I have to ask for some kind of "output" window, which gives me a lot of noise, but I can pick out the little bit I actually want. Now to the next X,Y offset, I have to do the whole tedius clickety-clicking again. There appeared to be no way to get into "measure mode", then take a bunch of measurements.

This really illustrates the power of the Eagle modal interface. You set the mode, then do stuff, as many stuffs as you want. Don't break it!.

Quote:

What you're highlighting with both Selection, Delete and other processes, are a common area in which we've gotten feedback


Yes, but again, consider the real root cause of the feedback. Also consider the silent majority, especially the power users, that prefer things the way they are because they are more efficient. Also don't underestimate how much you'll piss off existing users when you change something.

Quote:

I'll go on record as saying, we'll tidy this up soon!  Just hang in there and get ready for some pretty awesome stuff in the pipeline!


This is scary, truly scary. The last thing we need is new stuff the developers think is "awsome" <shudder>, especially when that relates to the UI.

Awsome would be some actual features, like multiple symbols per device, and allowing them to be "attached" to each 90 deg of rotation, for example. Right now I have to make separate devices for things like horizontal and vertical resistors, for example. Diodes need four devices since they have orientation.

As a great example of annoying fluff that may look cute to those that don't know what they're doing, but is actually useless to a real professional, is the god-awful new interface to the auto-router in version 7 (or was that 6?). The "top router" is someone's idea of a feature that I never heard anyone ask for. The UI got much less easy to use, and we still can't do the one thing that would actually be useful, which is to run the auto-router on multiple CPU cores simultaneously.

If you want to clean up the UI, start with fixing all the shortcut keys that broke over the last 15 years. Make every developer do some tasks in Eagle with the mouse 5 feet away. Make them try to use the keyboard for everything. You'll soon find plenty of things that will actually benefit real users that don't require breaking the great underlying UI paradigms in Eagle.
Re: Is anyone at AutoDesk listening? [message #167809 is a reply to message #167732] Thu, 17 November 2016 01:16 Go to previous messageGo to next message
eaglecandies
Messages: 186
Registered: September 2011
Location: Cincinnati
Senior Member
Hi Everyone,
EAGLE continues to progress thanks to the comments and suggestions from the community, some we can be implemented faster than others. But, be assured, that the CadSoft Team is closely monitoring the forums!!!
We are Listening!!!
Best Regards,
Ed
I find that either hard to believe or plain humorous...being able to show & interact with a true bottom view of the board has been requested for years...over and over and over and over...and where is it? When is it slated to be available? Where are the designator renumbering capabilities? Where is the highlighting of nets that actually works properly (rather than disappearing)? I'm talking about real validated functions, not some homebrew unofficial & completely undocumented ULP's. Eagle is certainly fine in many ways, but substantive progress has been lacking. I hope the long nap is over.
Re: Is anyone at AutoDesk listening? [message #167810 is a reply to message #167808] Thu, 17 November 2016 01:37 Go to previous messageGo to next message
rickb
Messages: 15
Registered: March 2016
Location: Junction City, OR USA
Junior Member
Many years ago I read about how a software company tested their pre-release software on new users. Video cameras were aimed at the users face to catch facial expressions, cameras at each side and behind the user recorded hand movement and video monitor images, and an audio recorder captured the voice. All of that was used to document just how good or bad the designers U/I decisions were. The users frustration or lack of made it very clear where improvements were needed. The developers were required to watch the video and use it as a guide for fixing the software.

Expensive but worthwhile.

One of the things I hate about software since the DOS/early windows days is the lack of a TECHNICAL REFERENCE MANUAL separate from any help system. The help system for most products sucks. It is written by people that know the software so well, they can't imagine anything else being needed.

Plus, everything Olin said x 1000.


Rick
Re: Is anyone at AutoDe sk listening? [message #167811 is a reply to message #167760] Thu, 17 November 2016 04:43 Go to previous messageGo to next message
hbridge99
Messages: 4
Registered: November 2016
Junior Member
> Wow... there's a couple of subjective observations.  Quirky? ENTIRETY OF
> OTHER GRAPHIC AND DESIGN SOFTWARE? Ridiculous tutorials? Truly
> inadequate UI?
>
> Certainly you have facts to back these claims?
Somewhere else in this thread is a brief discussion of the problems with selecting a tool first and then selecting the object.
Other's have written five page essays of missing items, inconsistencies, non-orthogonal design etc etc. It's not just me.

The reverse click paradigm of choosing an operation first and then selecting items to operate on it, are used NO WHERE else in the graphic design software I mostly use. Maybe it exists somewhere else in the CAD world which I know less about. I haven't seen it.

Here is my favorite and most irritating error message "Signal already exists. Use the Name tool to change the signal" WTF! The programmers were too lazy to just open the Name dialog for us - or open a smaller one that sets the options for the Name tool? They couldn't figure out how to have the Properties dialog change when a user chooses an existing signal.

You're routing a board, you decide something needs ripping up so you (mistakenly) grab the delete tool and click on the airwire. Up comes another silly error message about "can't back annotate this schematic" instead of just ripping up the trace, which is what the vast majority of users are going to expect should happen. Namely most users are expecting that "they are deleting the route - so the signal should go back to an airwire." not raise error messages. Probably the designers just didn't see how anyone could possibly want to use the delete tool to ripup a trace. After all, it's the wrong tool - but who cares?

> I would think that an educator would be more interested in actually
> teaching students the software rather than opining on it.  Perhaps
> taking a different approach to your preface would prove to have more
> positive results.  Such as...  "Good morning students.  I would like to
> introduce to you some CAD software that features a slightly different
> user interface.  Once you learn this, it will make more sense to you and
> you'll be more efficient with your work."
>
> Of course, that would mean that you'd have to give up your
> predisposition to the status quo.  But it'd be worth an honest try.
Again, if I hadn't read the same accounts written by others, I would think that is was just my outlook and opinion, but the accounts of Eagle's bizarre nature are easy to find on the internet. I don't tell students at all that Eagle is not usable, or that you can't make good boards with it. Only that it's some of the most clunky software that I use which I believe is true, although clearly there are worse EDA packages that others have mentioned.

I'm not at all against having the command line in the UI - it's often helpful - although some of the defaults suck. Why does the DRC dialog highlight problems in such a through way but "Show RI" on the command line merely highlights the part, which can be barely noticeable in a large schematic. There is an option to get a box around the part but it's buried in the manual somewhere.

Try moving a part over an inch (or a CM if you perfer) with the command line. This might be the Eagle power user test.

Why is the opposite of Ratsnest  Ripup @;  ??

Oh well lots of ideas here. I've used Eagle for five years to make maybe 150 boards. I have written and improved a few ULPs, and made custom menus to help get things done - but Eagle still irritates me every time I use it.  Since I can't afford Altium and KiCad still seems far behind Eagle, it's the devil I know now, so I'd like to see it be more fluid and have more features AND make more sense to my students.

best,

Paul

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209659
Re: Is anyone at AutoDe sk listening? [message #167814 is a reply to message #167808] Thu, 17 November 2016 05:30 Go to previous messageGo to next message
shabaz
Messages: 187
Registered: October 2012
Senior Member
I'd have to agree, the UI works, otherwise people would have migrated away from EAGLE to other software. I too have been using it since version 4.0.

I taught some newcomers EAGLE for two hours, and the first two that attempted a PCB went away, spent part of a day together creating a non-trivial board with a couple of modules, connectors, antenna and surface mount parts. It was very good for a first effort!

They'd never used EAGLE before. There were two or three brief e-mail exchanges for some clarification, but no verbal communication after the two hours training.

​ can attest to the fact that it is possible for beginners to be highly productive in EAGLE, and that the non-trivial board functioned.

I would also say I like the fact that EAGLE team is responsive to comments and queries, and I too would not want them to focus on non-important things. Usability has decreased slightly on high-res monitors but maybe that is resolved with recent releases (I'm still on an older release).

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209687
Re: Is anyone at AutoDesk listening? [message #167816 is a reply to message #167808] Thu, 17 November 2016 07:08 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
Olin Lathrop schrieb:

> [Many many correct statements]

Amen, except for:

> Awsome would be some actual features, like multiple symbols per device, and
> allowing them to be "attached" to each 90 deg of rotation, for example.
> Right now I have to make separate devices for things like horizontal and
> vertical resistors, for example. Diodes need four devices since they have
> orientation.

I can't see any reason for this - ROTATE exists.
Knowing that Olin is using EAGLE for years, I must miss some information
why he doesn't just rotate a diode...

Tilmann

(Using EAGLE since V1.2 in 1989, exactly *because* of its extremely
efficient modal UI.)
Re: Is anyone at AutoDesk listening? [message #167817 is a reply to message #167811] Thu, 17 November 2016 07:29 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
hbridge99 schrieb:

> The reverse click paradigm of choosing an operation first and then
> selecting items to operate on it, are used NO WHERE else in the
> graphic design software I mostly use. Maybe it exists somewhere else
> in the CAD world which I know less about. I haven't seen it.

And this is exactly the cause why working with EAGLE is that extremely
efficient.

> [Error messages instead of usere guidance]

I agree that in several situations, EAGLEs reactions to usage errors
can/should be improved. HELP and Manual can be improved even more, as
Olin has perfectly described (see the example of changing the spin flag...).

> Again, if I hadn't read the same accounts written by others, I would
> think that is was just my outlook and opinion, but the accounts of
> Eagle's bizarre nature are easy to find on the internet.

Naturally, these are not written by people that really work with EAGLE,
but by people who thought they could get a complex software (like a CAD
tool) and create complex designs in a few minutes without ever learning
how to use such a tool.

A fool with a tool is still a fool.

> I don't tell students at all that Eagle is not usable, or that you
> can't make good boards with it. Only that it's some of the most
> clunky software that I use which I believe is true, although clearly
> there are worse EDA packages that others have mentioned.

Maybe you'd better taught them how to use EAGLE correctly and
efficiently, and that the modal UI is the most powerful one in the CAD
world once you've got used to it - even if, or exactly because, it's
different from what you/they already know.

> I'm not at all against having the command line in the UI - it's often
> helpful - although some of the defaults suck. Why does the DRC dialog
> highlight problems in such a through way but "Show RI" on the command
> line merely highlights the part, which can be barely noticeable in a
> large schematic. There is an option to get a box around the part but
> it's buried in the manual somewhere.

Note that we're at the HELP and documentation level again (and the way a
function is implemented), not the UI.

> Try moving a part over an inch (or a CM if you perfer) with the
> command line. This might be the Eagle power user test.

Nonsense. No one ever will use a CAD completely using *only* the
keyboard. For several operations, using a pointing device is natural. So
you need to pick "the best of both" for efficient working. When working
with EAGLE, I always keep one hand on the trackball and the other at the
keyboard. The most often used commands are assigned to function keys,
and for the others I just type in abbreviated commands (for example, "r
<enter>" does a ratsnest).

You (or at least, I) really get fast with this method. Doing layouts
with EAGLE is a charm, this concept should *never* be changed.

> Oh well lots of ideas here. I've used Eagle for five years to make
> maybe 150 boards. I have written and improved a few ULPs, and made
> custom menus to help get things done - but Eagle still irritates me
> every time I use it.

This is really strange. Even after five years and so many designs, you
didn't recognize the advantages of that concept?

Tilmann
Re: Is anyone at AutoDesk listening? [message #167819 is a reply to message #167816] Thu, 17 November 2016 07:29 Go to previous messageGo to next message
Lorenz
Messages: 645
Registered: December 2006
Senior Member
Tilmann Reh wrote:

> Olin Lathrop schrieb:
>
>> [Many many correct statements]
>
> Amen, except for:
>
>> Awsome would be some actual features, like multiple symbols per device, and
>> allowing them to be "attached" to each 90 deg of rotation, for example.
>> Right now I have to make separate devices for things like horizontal and
>> vertical resistors, for example. Diodes need four devices since they have
>> orientation.
>
> I can't see any reason for this - ROTATE exists.
> Knowing that Olin is using EAGLE for years, I must miss some information
> why he doesn't just rotate a diode...

If I remember correctly it was about relative positioning of texts
--

Lorenz
Re: Is anyone at AutoDesk listening? [message #167820 is a reply to message #167806] Thu, 17 November 2016 07:38 Go to previous messageGo to next message
Joop_
Messages: 69
Registered: March 2007
Member
Ralf Stutzenberger wrote on Wed, 16 November 2016 20:03

@joop14 - I would like to disagree.


I prefer you don't Wink

Ralf Stutzenberger wrote on Wed, 16 November 2016 20:03

Every user knows how to use the keyboard.
What you mean is: learn more and more shortcuts.


Yes, that's what I meant.

Ralf Stutzenberger wrote on Wed, 16 November 2016 20:03

Photoshop tells us: learn my shortcuts, Calamus tells us: learn my shortcuts, Windows tells us: learn my shortcut, MacOs tells us: learn my shortcuts ... and so on.


You forgot the shortcuts for KDE and Gnome...

Why do they have different short-cuts? Because they have different tasks/goals or
different opinions about how to accomplish something.
Why do they have shortcuts? Because it will let an experienced user work much faster.
Is it annoying for starters? Yes it is.
What should we do to improve this? Help starters to learn the keyboard shortcuts.

Regards,
Joop

Re: Is anyone at AutoDesk listening? [message #167821 is a reply to message #167816] Thu, 17 November 2016 07:46 Go to previous messageGo to next message
shabaz
Messages: 187
Registered: October 2012
Senior Member
Maybe one reason could be to have text positioned differently based on orientation. It would be nice for the Rs and Cs to have text positioned differently (I like the text to always be left-to-right rather than sideways reading bottom-up, but that is a personal preference I guess! Currently I rotate the text separately, but then just copy-paste for subsequent Rs and Cs since that is quicker than adding new Rs and Cs and then rotating the text.

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209694
Re: Is anyone at AutoDesk listening? [message #167822 is a reply to message #167816] Thu, 17 November 2016 07:52 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> CadSoft Guest wrote:
>
> Olin Lathrop schrieb:
>
>> (https://www.element14.com/community/Many many correct statements)
>
> Amen, except for:
>
>> Awsome would be some actual features, like multiple symbols per device, and
>> allowing them to be "attached" to each 90 deg of rotation, for example.
>> Right now I have to make separate devices for things like horizontal and
>> vertical resistors, for example. Diodes need four devices since they have
>> orientation.
>
> I can't see any reason for this - ROTATE exists.
> Knowing that Olin is using EAGLE for years, I must miss some information
> why he doesn't just rotate a diode...
>
> Tilmann
>
> (Using EAGLE since V1.2 in 1989, exactly *because* of its extremely
> efficient modal UI.)
>
This was actually a topic which was discussed when I first joined this community.

I'm with Olin on this one. Yes you can rotate your resistors, diodes etc but then if you want schematics to look a particular way (I have had dealings with companies with very specific style guide requirements for schematics which mandated things down to relative text position, size etc for different component orientations as the schematics form part of their manual set for field service people!) you have to then go smash the symbols and reposition all the text.

There are other reasons for this, you might need versions of symbols which are drawn slightly differently to fit it with drawing different circuit topologies in easy to read ways for example. This would be an example of needing multiple symbols per device but it not being related to rotation.

There are of course other bigger features which would be great like push and shove routing and the ability to more easily length match a bus quickly (MEANDER helps but can be a bit of a faff), making a useful highlight (the way SHOW works is only marginally useful) and allowing airwires to be colour coded by net class. As per the above, there was a long thread on this not long after I joined the community. I think I actually started threads in the suggestions section for most of these things.

There are ways the UI could be improved without completely changing things. For example, if you go into properties you can see all the attributes of a device but you cant edit them from there. You have to go specifically to the attributes dialog. You could reduce the number of clicks required to get from properties to the attributes dialog if there was an edit button to take you directly to the attributes dialog, or even if you double clicking on a property took you to the edit dialog for that property.

Best Regards,

Rachael

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209635
Re: Is anyone at AutoDesk listening? [message #167823 is a reply to message #167822] Thu, 17 November 2016 08:14 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
rachaelp schrieb:

>> CadSoft Guest wrote:

Note that the element14 web interface still is so badly broken that it
can't even take the OPs name for the quote. :-( I'm not CadSoft Guest.
And there also was no need to replace the word "many" by a hyperlink to
the element14 website. :-\

>> I can't see any reason for this - ROTATE exists.
>> Knowing that Olin is using EAGLE for years, I must miss some information
>> why he doesn't just rotate a diode...
>
> I'm with Olin on this one. Yes you can rotate your resistors, diodes
> etc but then if you want schematics to look a particular way (I have
> had dealings with companies with very specific style guide
> requirements for schematics which mandated things down to relative
> text position, size etc for different component orientations as the
> schematics form part of their manual set for field service people!)
> you have to then go smash the symbols and reposition all the text.

That's exactly what I do. After all, since values often have very
different lengths, you need to move (some of) them around anyway...

> There are other reasons for this, you might need versions of symbols
> which are drawn slightly differently to fit it with drawing different
> circuit topologies in easy to read ways for example. This would be an
> example of needing multiple symbols per device but it not being
> related to rotation.

OK, understood.

Might be nice to have - but there are, IMHO, *much* more urgent issues
to solve first. Bottom view, gateswap in the board, just to mention two
(of a rather long list that's not being acknowledged for many years).

> There are ways the UI could be improved without completely changing
> things. For example, if you go into properties you can see all the
> attributes of a device but you cant edit them from there. You have to
> go specifically to the attributes dialog. You could reduce the number
> of clicks required to get from properties to the attributes dialog if
> there was an edit button to take you directly to the attributes
> dialog, or even if you double clicking on a property took you to the
> edit dialog for that property.

Fully agreed - this is basically the same that Paul complains about
regarding EAGLE's reactions on usage errors.

Tilmann
Re: Is anyone at AutoDesk listening? [message #167826 is a reply to message #167823] Thu, 17 November 2016 09:18 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> Tillman wrote:
>
> rachaelp schrieb:
>
>>> CadSoft Guest wrote:
>
> Note that the element14 web interface still is so badly broken that it
> can't even take the OPs name for the quote. I'm not CadSoft Guest.
> And there also was no need to replace the word "many" by a hyperlink to
> the element14 website. :-\
I'm guessing they don't get the user name information where they are getting the data feed from and are relying matching things up to an Element14 account. As you don't have one you are referred to as CadSoft Guest. CadSoft Guest is one of the busiest accounts on here :-D

For now I will manually change the name above :-)

> Tillman wrote:
>
>>> I can't see any reason for this - ROTATE exists.
>>> Knowing that Olin is using EAGLE for years, I must miss some information
>>> why he doesn't just rotate a diode...
>>
>> I'm with Olin on this one. Yes you can rotate your resistors, diodes
>> etc but then if you want schematics to look a particular way (I have
>> had dealings with companies with very specific style guide
>> requirements for schematics which mandated things down to relative
>> text position, size etc for different component orientations as the
>> schematics form part of their manual set for field service people!)
>> you have to then go smash the symbols and reposition all the text.
>
> That's exactly what I do. After all, since values often have very
> different lengths, you need to move (some of) them around anyway...
Actually the way I have things set up, if I didn't have to reposition because of rotation then everything would fit nicely and wouldn't need any editing at all in most cases. So for example, a lot of people use the value field of a capacitor to specify lots of information, say "10nF 50V X7R" or "100pF 250V C0G X1/Y2" whereas I have these broken out into separate and appropriately positioned properties of my capacitor symbol.

> Tillman wrote:
>
>> There are other reasons for this, you might need versions of symbols
>> which are drawn slightly differently to fit it with drawing different
>> circuit topologies in easy to read ways for example. This would be an
>> example of needing multiple symbols per device but it not being
>> related to rotation.
>
> OK, understood.
>
> Might be nice to have - but there are, IMHO, *much* more urgent issues
> to solve first. Bottom view, gateswap in the board, just to mention two
> (of a rather long list that's not being acknowledged for many years).
I agree, there are plenty of things I would put higher up the priority list than this but I wouldn't want this so far down the list that is never got dealt with.

Anything that makes it easier to do routing of complex boards takes priority over things which are of a more cosmetic nature so as I have said, push and shove, bus routing, bus length matching, visualisation aids like being able to apply different colours to the air wires of different net classes, have highlighting that persists so you can still see it while doing other things, etc, etc.

Also, how about making better use of net classes within the normal manual routing? Currently it seems it mostly affects the autorouter and DRC but could be used more intelligently to automatically set trace widths (and clearances if we've got push and shove) to those specified in the net class so you don't find out you made an error after the fact when you run DRC and find that your traces are too thin (but also for impedance matched traces too fat is an issue too which I don't think that's dealt with right now at all?).

How about having the ability to add constraints to nets within the schematic, so for example you could create a bus for DDR3 data, you might want to specify trace lengths (min and max), matching between traces within a group, matching between groups etc, target impedance, etc. For others you might want to specify voltage or current ratings and have trace widths, clearances, copper weight recommendations etc made based on those. There are a lot of other options for things like this too, I'll not list every idea I have here....

I'm also very much in favour of things that enable EAGLE to better integrate with other parts of the company systems, for example adding ODBC support (i.e. to allow access to databases) would allow EAGLE to integrate with a companies component management systems much more efficiently.

Best Regards,

Rachael

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209712
Re: Is anyone at AutoDesk listening? [message #167827 is a reply to message #167826] Thu, 17 November 2016 10:06 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
rachaelp schrieb:

> For now I will manually change the name above :-)
>
>> Tillman wrote:

Thanks - but then please take care of how it's /correctly/ written. :-)

> [...]
> I'm also very much in favour of things that enable EAGLE to better
> integrate with other parts of the company systems, for example adding
> ODBC support (i.e. to allow access to databases) would allow EAGLE to
> integrate with a companies component management systems much more
> efficiently.

Oh, while we're at this - restricting EAGLE projects to use all the same
filename (eagle.epf) and reside in a single "projects" folder is a pain
in the * that should urgently be corrected. We already have a project
hierarchy on our server and don't want to maintain (and synchronize) a
second one only for the EAGLE files.

As with any other IDE, project files should be individually named, and
allowed to be stored anyway - along with the related design files that
need to be addressed by relative URLs then. (Of course, libraries, ULPs,
DRC files and CAM jobs should be taken from a central repository.)

You see, there are *many* things that need improvement - however
definitely not the UI concept.

Tilmann
Re: Is anyone at AutoDesk listening? [message #167828 is a reply to message #167827] Thu, 17 November 2016 10:30 Go to previous messageGo to next message
rachaelp
Messages: 583
Registered: March 2015
Location: UK
Senior Member
> Tilmann wrote:
>
> rachaelp schrieb:
>
>> For now I will manually change the name above
>>
>>> Tillman wrote:
>
> Thanks - but then please take care of how it's /correctly/ written.
>
Yes of course, very sorry!

I don't know how I managed to not see the correct spelling as I usually pay attention to details like that as people often spell my same incorrectly and it can be irritating. I'll be more careful to get it right in future!

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209714
Re: Is anyone at AutoDesk listening? [message #167829 is a reply to message #167826] Thu, 17 November 2016 10:40 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
rachaelp schrieb:

> For now I will manually change the name above :-)
>
>> Tillman wrote:

Thanks - but then please take care of how it's /correctly/ written. :-)

> [...]
> I'm also very much in favour of things that enable EAGLE to better
> integrate with other parts of the company systems, for example adding
> ODBC support (i.e. to allow access to databases) would allow EAGLE to
> integrate with a companies component management systems much more
> efficiently.

Oh, while we're at this - restricting EAGLE projects to use all the same
filename (eagle.epf) and reside in a single "projects" folder is a pain
in the * that should urgently be corrected. We already have a project
hierarchy on our server and don't want to maintain (and synchronize) a
second one only for the EAGLE files.

As with any other IDE, project files should be individually named, and
allowed to be stored anywhere - along with the related design files that
need to be addressed by relative URLs then. (Of course, libraries, ULPs,
DRC files and CAM jobs should be taken from a central repository.)

You see, there are *many* things that need improvement - however
definitely not the UI concept.

Tilmann
Re: Is anyone at AutoDesk listening? [message #167830 is a reply to message #167827] Thu, 17 November 2016 10:44 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
I wrote:

> As with any other IDE, project files should be individually named, and
> allowed to be stored anyway - ...

of course I meant "anywhere".

(Don't know if the supersede worked with that crappy web interface,
supposedly not...)

Tilmann
Re: Is anyone at AutoDesk listening? [message #167831 is a reply to message #167808] Thu, 17 November 2016 11:21 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 17.11.2016 00:00, Olin Lathrop wrote:
> The only way to not screw it up is to leave it alone. Look carefully here
> at who is saying what. It's the new users that haven't taken the time to
> learn Eagle that come here and complain and want everything different.
> These also tend not to be the EE professionals that you need at the core of
> your customer base. Those that have used Eagle for years and use it often
> and professionally generally want you not to mess with the user interface,
> and want you to add some real substantive features instead.
>
> I am one of those. I've used Eagle since version 4. I do remember it took
> some time to learn. I had to look things up and even call tech support on
> a few occasions. But after a while, I learned to use it well and wouldn't
> want it to work any other way. It's a breath of fresh air amongst the
> great mass of software out there that gets flashier and harder for power
> users each version.

I have been using eagle since v3 but I also used other complex software
packages. You don't have to go further than using a basic feature of any
os; the file explorer. This has a basic way of working that most users
must learn. The ones who care to learn its shortcuts know how to drill
this quickly.

I do know that Eagle's GUI could approach common standards, and I find a
lot of common shortcuts that Eagle could have adapted to. Some was even
implemented some time ago. You don't any longer need to use F9 and F10
for undo and redo because they were moved to approach common OS practice
of using ctrl-z and ctrl-y. Even Linux started to use these keys long
time ago. I think they were originally windows keys.

Yes I agree with you that there exist totally flopped ui's around and
the one you mention, Word, is a good example of screwup not worth to
follow. But provided what I say about general sw is true, do you see the
need for Eagle to be different on shortcuts? I am not only thinking
about keyboard shortcuts, but also the way gui works, selecting first,
then action [and more action], provided selection is as or more flexible
as existing?

> Every other piece of large software I've used over the years has gotten
> harder to use. I wrote a whole book (yes, literally, The Way Computer
> Graphics Works, John Wiley and Sons) in the 1990s using MS Word. I took
> the trouble to actually read the manual, and got pretty good at it. Each
> version of Word after that became harder and harder to use, keyboard
> shortcuts broke, menu entries were moved around, and the interface
> generally dumbed down. I no longer use Word except when I really have to.
> Each version seemed to be more optimized for instant gratification at the
> expense of long term usability. Don't be like that!

For my age, I do seem to have a "modern" approach to this. If you have
to read a large book to be able to use some software, the software can
be improved and the manual made smaller. It's like using google, you
should not have to read a manual to use it, but rather look up topics as
you need them. Not to mention the "manual" you get with an iphone today.
It's simply old fashioned to have a tradition manual for software when
you got gigabytes of memory and disk available.

> The problem to address is not to make Eagle's UI "better". It's already
> quite good, well above most software. Don't strive to be like lesser
> software just because most of them are.

Yes it is good as it is. This is not about reducing functionality or
cluttering up usage. If they do that, they do it wrong.

> The problem to address is to make new users feel more comfortable with
> Eagle until they learn it well enough to appreciate its power the way it
> is. You seem to be falling into the trap of listening to the inexperienced
> but vocal users. They're new, don't get instant gratification, so of
> course they want everything the way they currently imagine is better.
> They've not learned the power of how things are done, don't have scripts,
> ULP, and a whole bunch of tricks and shortcuts and pet ways of doing things
> they've learned over the years to protect. Basically, they've got nothing
> to loose. Your established power user have a great deal to loose, and you
> can't afford to loose them. If you do, you'll be just another hobbyist
> product, and you'll always be compared to free offerings like KiCad instead
> of the real professional packages you need to be able to compete with.
>
> So what to do? Good education. I'll admit, Eagle is hard to learn
> initially. The fix is to make the learning easier, not to dumb down the
> product itself. There are many things that can be done without hurting the
> product by a misguided "fix" of the UI.

Don't underestimate the wall created by availability issues. For
example, I know Altium can do lot of things, and some time ago I was
setting aside a few days evaluating it, but after spending those days
playing with it, I gave up. I did not want to spend a week to read any
manual. The user interface was very complex for the things I needed to
do, and I could get an image of how it was put together. I simply didn't
have the time to get to a level where I could say "yes I can use this".
Instead I kept using the tool I know best; Eagle.
Also, when looking at the ridiculous price of the courses they arrange,
it just makes me shake my head and asking myself if they do this on
purpose to pimp the value of their product.

> Just fixing the awful help system alone would be a good start. I've used
> Eagle since around 2000 and have probably done over 100 boards with it, but
> I still have to look up details now and then. Even someone like me finds
> the help system frustrating. The good part about it is that you can look
> up details of a particular command reasonably well. However, it's
> difficult to use to ask about features. There is no overall index, at
> least that actually works (no, a global pattern search is not a index).
> Help windows pop up wherever they want, and never big enough to read.
>
> Looking up the details of a command means entering "help name". Easy
> enough so far. Then a tiny help window pops up someplace. Now you have to
> move your hand from the keyboard to the mouse, interrupting workflow, and
> resize the help window. Now you have to read most of the help page to find
> what you are looking for. There is not string-find capability within a
> help page.
>
> Here's a example. Go figure out how to set the spin flag on a existing
> text string. No, really, go actually try that. I dare you. This is
> something I do just infrequently enough to not remember between uses. The
> obvious place to start is with the TEXT command help page. It's easy
> enough to get that open. Now you want to look for "spin", but argh, Ctrl-F
> doesn't work, nor does there seem to be anything like it to search for
> "spin" on that help page. The only option is to skim, but not too quickly,
> looking for where the spin flag is mentioned. You see it near the top
> under "Orientation", but that only tells you that you can set the spin flag
> if you want text upside down. You came here already knowing that. The
> question is how to set the spin flag. More reading. You get to the end
> but don't find any other mention of the spin flag. Did you miss it because
> you skimmed the text, or is it really not there? You read the whole help
> page again, this time being more careful. No, it really isn't there. Now
> what? Back in the Orientation section it mentions that the "usual
> definitions" for orientation are used, which are listed in the ADD command
> help page. At least that's a link.
>
> Now in the ADD help page, we have the same problem all over again. I just
> want to know how to set the spin flag, so want to find "spin", but there is
> no such mechanism. Skimming down, we find the "Orientation" section, and
> see that "S" to the orientation string sets the spin flag. Finally, just
> enter "S" in the right place.
>
> But wait, where exactly do I put this "S"? Not in the TEXT command, since
> I'm trying to modify a existing text string. TEXT is for writing new
> strings. ADD makes no sense here, although that's where the spin syntax
> was finally found. I don't want to draw a new text string, I don't want to
> add something to my schematic or board or device. Now what? Seriously,
> think about it. Do you know? You've tried to RTFM and got to a dead end.
> Argh!
>
> I'll cut this short and tell you that you need to use the ROTATE command.
> I know that at this point, but can you see how frustrating this is for a
> new user?
>
> This kind of thing is why people bitch. Note the real problem here,
> though. It's not that Eagle has a spin flag, and that ROTATE needs to be
> used to change it in existing text strings, but that it's really hard to
> figure that out. And this is just one example of many.
>
> The solution isn't yet another clickety-click interaction that is great the
> first two times you use it, but then becomes annoying baggage ever after.
> The solution is better education, introduction, and self-help. All the
> help text expanded out as a book in a PDF file, keeping the hyperlinks,
> would be big step forward. Getting a real tech writer to go over the help
> text would also be a good step. Yes, the information is there, eventually,
> but poorly indexed if at all, and too often not where you think to look for
> it. There is also very little topic-oriented help.

Yes, a good interactive help would do great. This is in general a good
concept. Also something nice I have seen in some tools (like ultraedit)
is a search bar in the config menu. It has so many parameters to tweak
that it will help you search for a topic. This is worth embracing.

> Documentation must serve several different purposes. There must be
> introduction for new users, topic-orientated help for when you don't know
> the specifics to ask about and to find out what's there, and reference help
> to look up details when you know what to ask. All are important, but you
> pretty much only do the latter.

I have been referencing game tutorial earlier. Some of you probably
don't play computer games at all, but some may see the kids handle this
multi button gamepad like it was a spoon. Personally I cant stand them,
but its worth thinking how the kids are able to handle this pad this
efficient? I think the answer is in startup tutorials. The player gets
some easy tasks, and are asked to press this or that while they see the
result on the screen. When they pass, they move to the next task. I
think this will be/is the modern way of teaching also complex software.
You can say many things about spoiled kids, but they are here to take
over the world, and we made them like this. Look up the word
"gamification" on wikipedia.

> The answer isn't just more links and more wordy descriptions in the
> existing reference text. That would make it worse because that dilutes the
> reference purpose. You need to recognize that it takes different sections,
> written with the different purposes in mind, to address each purpose
> properly. Lots of side information is clutter getting in the way of the
> facts in a reference section, and details increase the signal to noise
> ratio in the topic sections. A few good examples can be useful even in a
> reference section, but need to be liberally used in introduction sections.
> The topic sections should refer to the reference for the details, not try
> to duplicate them.
>
> Writing good documentation is hard. But hard or not, this is where effort
> will yield the biggest return. You expect a new package to require new
> knowledge to learn. The frustrating part is when this learning is
> difficult. You then revert back to expecting it to work like other things
> you know. That's what causes the trouble.

There is a reason why all [maual geared] cars have a throttle and clutch
identically placed. Of course you need to follow some standards. The
more the better.

>
> Quote:
>> Selection is such a fundamental thing to get right and this is an area
>> slated for some upgrades indeed!
>
>
> No, noooo, nooooooooooooooooo! Don't break this. Selecting in Eagle works
> better than in other software. Changing this is short term gratification
> at the expense of klunkiness ever after. Don't fall for that. Don't just
> knee jerk and give the whiners what they want. Find the root cause of the
> whining, which is really the difficulty and frustrations of learning Eagle,
> not the actual details of Eagle.

No, selecting is not better in Eagle than other software.

> Here's a good example from just a few days ago. I'm a electrical engineer
> with considerable experience using Eagle. I work with someone that does
> drafting and mechanical design, and uses AutoCad (I may have the name
> slighly wrong, but its one of your products). I only have AutoCad (or
> whatever it is exactly) viewer on my machine, not the full program.
>
> I was trying to get some dimensions off a drawing, in part so that a
> circuit board I am designing with Eagle can mount to it properly. I asked
> the ME, and he showed me how to use the MEASURE "tool". Each time I wanted
> to find the X,Y offset between two points, I had to tediously click on the
> measure thingy (in a very tall bar at top using up a lot of pixels), click
> to make it drop down, then click on a ruler icon. I then click the two
> points I want to measure between. A little rectangle surrounds each. So
> far OK, maybe more clickety-clicking than it needed to be, but now what?
> Where is the measurement? After some futzing around, I find that I have to
> ask for some kind of "output" window, which gives me a lot of noise, but I
> can pick out the little bit I actually want. Now to the next X,Y offset, I
> have to do the whole tedius clickety-clicking again. There appeared to be
> no way to get into "measure mode", then take a bunch of measurements.
>
> This really illustrates the power of the Eagle modal interface. You set
> the mode, then do stuff, as many stuffs as you want. Don't break it!.

One bad piece of software can not be used to demonstrate this. You have
to compare it against the 10 best software packages out there. Anyway,
you are describing your experience with some software you obviously
don't know, so I won't care to comment.

> Quote:
>> What you're highlighting with both Selection, Delete and other
>> processes, are a common area in which we've gotten feedback
>
>
> Yes, but again, consider the real root cause of the feedback. Also
> consider the silent majority, especially the power users, that prefer
> things the way they are because they are more efficient. Also don't
> underestimate how much you'll piss off existing users when you change
> something.

Again, "more efficient" is your percived opinion. And your arguments
above are not valild.

> Quote:
>> I'll go on record as saying, we'll tidy this up soon! Just hang in
>> there and get ready for some pretty awesome stuff in the pipeline!
>
>
> This is scary, truly scary. The last thing we need is new stuff the
> developers think is "awsome" <shudder>, especially when that relates to the
> UI.
>
> Awsome would be some actual features, like multiple symbols per device, and
> allowing them to be "attached" to each 90 deg of rotation, for example.
> Right now I have to make separate devices for things like horizontal and
> vertical resistors, for example. Diodes need four devices since they have
> orientation.

This is a feature we have been arguing before. I think this may
introduce more issues than solving real problems, and the topic should
have priority way below full modular design. But yes, us experienced
users want new features. But then again Autodesk may want way more
customers too. They have a lot of potential in those paying for
overpriced tools.

> As a great example of annoying fluff that may look cute to those that don't
> know what they're doing, but is actually useless to a real professional, is
> the god-awful new interface to the auto-router in version 7 (or was that
> 6?). The "top router" is someone's idea of a feature that I never heard
> anyone ask for. The UI got much less easy to use, and we still can't do
> the one thing that would actually be useful, which is to run the
> auto-router on multiple CPU cores simultaneously.
>
> If you want to clean up the UI, start with fixing all the shortcut keys
> that broke over the last 15 years. Make every developer do some tasks in
> Eagle with the mouse 5 feet away. Make them try to use the keyboard for
> everything. You'll soon find plenty of things that will actually benefit
> real users that don't require breaking the great underlying UI paradigms in
> Eagle.
>
Again, very personal opinions and priorities. I don't agree.
Re: Is anyone at AutoDe sk listening? [message #167832 is a reply to message #167811] Thu, 17 November 2016 13:47 Go to previous messageGo to next message
Chuck Huber
Messages: 599
Registered: October 2004
Senior Member
On 11/16/2016 11:43 PM, hbridge99 wrote:
>
> The reverse click paradigm of choosing an operation first and then selecting items to operate on it, are used NO WHERE else in the graphic design software I mostly use. Maybe it exists somewhere else in the CAD world which I know less about. I haven't seen it.

That could be entirely true. But it's the prefix notation (verb first)
that makes Eagle more efficient than the others. It also makes Eagle
different. One must pose the question: is changing the UI to operate
more like other software worth the trade-off in efficiency.

> Here is my favorite and most irritating error message "Signal already exists. Use the Name tool to change the signal" WTF! The programmers were too lazy to just open the Name dialog for us - or open a smaller one that sets the options for the Name tool? They couldn't figure out how to have the Properties dialog change when a user chooses an existing signal.
....
> Why is the opposite of Ratsnest Ripup @; ??

Agreed. It took me a bit to get used to unrouting rather than
deleting. But it does make sense. One uses ROUTE to change an air wire
to a trace, and UNROUTE to change a trace back into an air wire. Yeah,
I know that it's listed as "ripup" on the menu and icon. But I have
come to think of it as "unroute" which works well since the keystrokes
to unroute are Alt-E, U (Edit menu, unroute).

When thought of as "unroute", it is clear that delete is an entirely
different operation. The only thing I have ever deleted off of board
are mounting holes, dimension lines, text, tplace lines, restrict lines
and polygons, polygon vertices. (wow... the list is longer than I thought.)

Perhaps the notation on the Icon and pull-down Edit menu should be
changed to unroute.

> Namely most users are expecting that "they are deleting the route - so the signal should go back to an airwire." not raise error messages. Probably the designers just didn't see how anyone could possibly want to use the delete tool to ripup a trace. After all, it's the wrong tool - but who cares?

It would be a bit more intuitive for those who haven't logged a hundred
hours or so in Eagle.

>
> I'm not at all against having the command line in the UI - it's often helpful - although some of the defaults suck. Why does the DRC dialog highlight problems in such a through way but "Show RI" on the command line merely highlights the part, which can be barely noticeable in a large schematic. There is an option to get a box around the part but it's buried in the manual somewhere.

Show @ RI;

> Try moving a part over an inch (or a CM if you perfer) with the command line. This might be the Eagle power user test.

Group the parts to move, then:
mov (C>0 0) (1 0);

moves the group exactly one inch to the right.

> Oh well lots of ideas here. I've used Eagle for five years to make maybe 150 boards. I have written and improved a few ULPs, and made custom menus to help get things done - but Eagle still irritates me every time I use it. Since I can't afford Altium and KiCad still seems far behind Eagle, it's the devil I know now, so I'd like to see it be more fluid and have more features AND make more sense to my students.

There really is no opposite of ratsnest. RATSNEST does two things.
First, it identifies the shortest distance between two same-signal
orphans. Secondly, it fills polygons. Clearly there is no good reason
to unRATSNEST with regard to airwires, but there is good reason to
remove the fill from polygons. Removing the fill could be loosely
thought of as unrouting the fill. This, I believe, led to the special
incantation of RIPUP of which all are now aware. (There I go again...
thinking "unroute" but typing "ripup".)

I can understand how this came to be so in the ongoing development of a
project.

Jorge, it seems like this thread spawned yet another enhancement to
consider: rename RIPUP to UNROUTE while maintaining backward
compatibility with existing scripts.

>
> best,
>
> Paul

All in all,

Paul, Thanks for the lively discussion. I would be seriously dismayed
if Eagle change to a more Windoze-like UI. Over the years, operating
Eagle has become second-nature. I even find myself typing eagle short
cuts in my MCAD package. The cost of doing a UI overhaul would be a
large fraction of developing a whole new product, once one includes
thorough regression testing. Maintaining the user's choice of UI's
(classic vs. new) would be equally burdensome.

But you're right... Some good ideas have spawned from this.

Best regards,
- Chuck
Re: Is anyone at AutoDesk listening? [message #167833 is a reply to message #167816] Thu, 17 November 2016 14:18 Go to previous messageGo to next message
Olin
Messages: 903
Registered: December 2009
Location: Massachusetts
Senior Member
Tilmann Reh wrote on Thu, 17 November 2016 02:08

I can't see any reason for this - ROTATE exists.
Knowing that Olin is using EAGLE for years, I must miss some information
why he doesn't just rotate a diode...


The problem is that text for things like the component designator and value don't rotate well. For vertical resistor, I have the designator and value to the right side. For horizontal resistors, I have the designator above and the value below.

You can only get from one to the other by smashing the part, then individually repositioning the text. That would be way too slow. My current solution is to have multiple devices that only differ in their symbol. For example, I have separate RESISTOR-H and RESISTOR-V devices. It's a little more work up front once, but saves significant time when creating schematics.

A better solution would be for Eagle to support multiple symbols per device. Since one purpose of this would be to allow customization for different orientations, this should allow for tying different symbols to different orientation angles. Right clicking the mouse when placing a part into a schematic would still "rotate" by switching to the symbol attached to that rotation angle, if one was. The default would be to rotate the first or default symbol of the device as it does now.
Re: Is anyone at AutoDe sk listening? [message #167834 is a reply to message #167832] Thu, 17 November 2016 14:32 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 17.11.2016 14:47, Chuck Huber wrote:
> But it's the prefix notation (verb first)
> that makes Eagle more efficient than the others.
(loads deleted)

I keep hearing this, and I have been asking myself why this makes Eagle
more efficient, and I can't find the anwer. Can you give some examples?
Re: Is anyone at AutoDe sk listening? [message #167835 is a reply to message #167834] Thu, 17 November 2016 15:05 Go to previous messageGo to next message
Olin
Messages: 903
Registered: December 2009
Location: Massachusetts
Senior Member
Morten Leikvoll wrote on Thu, 17 November 2016 09:32

> But it's the prefix notation (verb first)
> that makes Eagle more efficient than the others.

I keep hearing this, and I have been asking myself why this makes Eagle
more efficient, and I can't find the anwer. Can you give some examples?


I and others have already given several. A common one is deleting multiple object in a schematic. You do DEL once, then click away. It would be much slower to click each object, then separately indicate the delete operation.

Another example is setting the same value on a bunch of parts in a schematic. The way I have it set up, I do Ctrl-V, then the value in apostrophies. After that, anything you click on gets the value. Imagine how much more tedious it would be if you had to click on each part, then enter the value separately.

The example I mentioned using AutoCad to get a bunch of measurements was particularly relevant because that is software from the same company that now owns Eagle. Each measurement was a separate operation. There was no way (that I could easily find, I'm not a power user of AutoCad) to get into "measurement mode", then do a bunch of measurements in succession.

People don't like the modal interface because it's not what they are used to. That's not a good reason against it though. It's different for good reason, which one appreciates after getting used to it. The issue to spend effort on is to get new users over the hump more quickly and comfortably, not to dumb down the software to a lesser way of doing things just because everyone else does it that way.

This discussion reminds me of the RPN versus algebraic notation debate for calculators in the 1970s. Those that actually tried RPN pretty much universally liked it better. However, HP was terrible at marketing and user education, so the majority of calculator users never tried RPN. Some were even vehemently against it just because it was something they would have to learn.

I'm a bit embarrassed to admit I was for algebraic notation in college too. This was because my first calculator was algebraic, in large part because it was half the price of the cheapest HP calculator. Then I went to work for HP as my first job out of college. Naturally I was handed a RPN calculator for my use. Since it was part of my job, I sat down, read the manual, and learned to use it. It actually was very easy to learn to use RPN. It takes just a few minutes if you put your religious convictions aside and actually try. I found all those RPN evangelists were actually right. It really was better. Since that day, I've only bought RPN calculators, and have used them exclusively for professional engineering over the last 36 years.

Unfortunately, the dumb masses won out, and now the world uses largely algebraic calculators. This is all because it was "different" and appeared "difficult", even though it was actually quite easy to learn.

Again, the answer here is one of education and leading new users thru the better Eagle way confortably without making it seem difficult (because it's actually not), not by dumbing down the software to appease new users at the expense of long term usability.
Re: Is anyone at AutoDe sk listening? [message #167836 is a reply to message #167809] Thu, 17 November 2016 17:00 Go to previous messageGo to next message
Ed Robledo
Messages: 49
Registered: August 2005
Member
Hi Norm,
As part of the support team, we do our best to suggest to the developing team the concerns and ideas from the users that would most satisfy the EAGLE users.  All of them understand our interpretation because they themselves participate on many of the threads.  Once the information is gathered, it needs to be weighed based and what is mostly requested and which can actually be done.  Not all decisions might satisfy all users, but be assured they are reported and we are aware of them. It wouldn't be realistic to provide dates or tell you its coming out in the next version.  Now that we are part of the Autodesk Family, the possibilities of these becoming a reality is much closer. 
Regards,
Ed

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209730
Re: Is anyone at AutoDe sk listening? [message #167840 is a reply to message #167835] Thu, 17 November 2016 18:39 Go to previous messageGo to next message
Chuck Huber
Messages: 599
Registered: October 2004
Senior Member
On 11/17/2016 10:05 AM, Olin Lathrop wrote:
>
> This discussion reminds me of the RPN versus algebraic notation debate for
> calculators in the 1970s.

I, too, was there.

> I'm a bit embarrassed to admit I was for algebraic notation in college too.

I'm so sorry to hear this.

> This was because my first calculator was algebraic, in large part because
> it was half the price of the cheapest HP calculator. Then I went to work
> for HP as my first job out of college. Naturally I was handed a RPN
> calculator for my use. Since it was part of my job, I sat down, read the
> manual, and learned to use it. It actually was very easy to learn to use
> RPN. It takes just a few minutes if you put your religious convictions
> aside and actually try. I found all those RPN evangelists were actually
> right. It really was better. Since that day, I've only bought RPN
> calculators, and have used them exclusively for professional engineering
> over the last 36 years.

This is music to my ears. You truly are an enlightened one.

My intro to RPN was similar. My TI had gone dead and a friend was kind
enough to lend me his HP for a test. It took a mere 5 minutes to
understand the postfix notation and how much more sense it made. The
calculator itself caused a bit of a delay, just learning the location of
pi, square, square root, and trig functions. But once I sought and
found those buttons (some were 2nd-function), it was a breeze.

Once RPN, I never looked back. My iPhone and iPad have RPN calculators,
and I find "dc" on linux invaluable, even though it is text based.

> Again, the answer here is one of education and leading new users thru the
> better Eagle way confortably without making it seem difficult (because it's
> actually not), not by dumbing down the software to appease new users at the
> expense of long term usability.

Olin,
Your posts have been very well thought out, clear, and concise - exactly
what I have come to expect from you.

I concur with you regarding jumping to a new UI just because that's the
way the Jones's do it. The more prolific methods are often engineered
to suit the masses, even though a different way (like RPN) is much cleaner.

Later,
- Chuck
Re: Is anyone at AutoDesk listening? [message #167841 is a reply to message #167833] Thu, 17 November 2016 19:31 Go to previous messageGo to next message
Eric Stevens
Messages: 44
Registered: July 2008
Member
>
> The problem is that text for things like the component designator and value
> don't rotate well. For vertical resistor, I have the designator and value
> to the right side. For horizontal resistors, I have the designator above
> and the value below.
>
> You can only get from one to the other by smashing the part, then
> individually repositioning the text. That would be way too slow. My
> current solution is to have multiple devices that only differ in their
> symbol. For example, I have separate RESISTOR-H and RESISTOR-V devices.
> It's a little more work up front once, but saves significant time when
> creating schematics.
>
> A better solution would be for Eagle to support multiple symbols per
> device. Since one purpose of this would be to allow customization for
> different orientations, this should allow for tying different symbols to
> different orientation angles. Right clicking the mouse when placing a part
> into a schematic would still "rotate" by switching to the symbol attached
> to that rotation angle, if one was. The default would be to rotate the
> first or default symbol of the device as it does now.
>

I wrote a ULP that looks at part orientation for 1- and 2-pin parts, smashes the component, reformats the text (size,
font, etc), and repositions based on templates I set up in the script for resistors, caps, coils, etc. This way I don't
need different symbols. It works well for most of these parts but there are always some that you will have to adjust
after running.

If I get a chance to clean up some of the code mess and fix a few things I'll post it.

Eric
Re: Is anyone at AutoDesk listening? [message #167842 is a reply to message #167807] Thu, 17 November 2016 19:45 Go to previous messageGo to next message
Eric Stevens
Messages: 44
Registered: July 2008
Member
On 11/16/2016 03:13 PM, Matt Berggren wrote:
> Thanks Ralf, I tend to agree. Simply educating the user on shortcuts is no replacement for good, intuitive UI/UX. So there needs to be a balance between what EAGLE does extremely well (and I have my list of favorite commands / processes / patterns in the SW) and what is no longer intuitive as our user behavior transforms and is influenced over time.
> I had worked pretty extensively on other EDA tools in addition to EAGLE in my 20 years in the ECAD industry and it's always essential that we (as developers) take a step back and ask "is that the best, fastest, most intuitive way to do <xyz>?". If it's not, then you dont really have a defensible position when challenged by subsequent generations of engineers, makers, hackers, creatives, etc. who are coming online having adapted to contemporary UI/UX models. Of course it's always amazing to have the love and the loyalty of the power users but we have to also acknowledge that paradigms change and we have to adapt to create the widest space possible for new users to come on board and be productive as possible, fast.
>
> Rest assured, we're making UI / UX decisions only after a serious look at how things operate and the reasons for certain features having been implemented certain ways (of course there was a reason that a developer took the approach they did, so we need to be mindful of that). And I'd expect that we will have good reason for any changes before we commit them into the release version of the product.
>
> Best regards,
>
> Matt Berggren
> Director - Autodesk.

I'm hoping the UI considerations don't include a ribbon. I don't understand why this is even a thing. Monitors are
getting wider, not taller. I don't need a horrible UI design idea to take up a ridiculous amount of space on my 21:9
monitors. Think more XFCE than microsoft.

Eric
Re: Is anyone at AutoDe sk listening? [message #167843 is a reply to message #167835] Thu, 17 November 2016 19:51 Go to previous messageGo to next message
Eric Stevens
Messages: 44
Registered: July 2008
Member
> I found all those RPN evangelists were actually
> right. It really was better. Since that day, I've only bought RPN
> calculators, and have used them exclusively for professional engineering
> over the last 36 years.
>

You'd have to rip my HP15C from my cold dead hands. I can barely use a calculator with an equals button and parenthesis.

Eric
Re: Is anyone at AutoDesk listening? [message #167844 is a reply to message #167843] Thu, 17 November 2016 20:01 Go to previous messageGo to next message
Jan Cumps
Messages: 8
Registered: November 2016
Junior Member
First time I heard this discussion was in 1979 in the Sint-Jan-Berchmanscollege in Diest, Belgium. i guess I will not witness the day that this one gets resolved...

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209752
Re: Is anyone at AutoDe sk listening? [message #167848 is a reply to message #167835] Fri, 18 November 2016 10:13 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 17.11.2016 16:05, Olin Lathrop wrote:
> Morten Leikvoll wrote on Thu, 17 November 2016 09:32
>>> But it's the prefix notation (verb first)
>>> that makes Eagle more efficient than the others.
>>
>> I keep hearing this, and I have been asking myself why this makes Eagle
>>
>> more efficient, and I can't find the anwer. Can you give some examples?
>
>
> I and others have already given several. A common one is deleting multiple
> object in a schematic. You do DEL once, then click away. It would be much
> slower to click each object, then separately indicate the delete
> operation.

You really need to get updated on latest GUI. Of course you can
multiselect and delete.


> Another example is setting the same value on a bunch of parts in a
> schematic. The way I have it set up, I do Ctrl-V, then the value in
> apostrophies. After that, anything you click on gets the value. Imagine
> how much more tedious it would be if you had to click on each part, then
> enter the value separately.

Not a problem. Example the modern way: Multi select and open properties
for the multiple objects, change the value attibute (from
'indeterminate' to the value you want).

> The example I mentioned using AutoCad to get a bunch of measurements was
> particularly relevant because that is software from the same company that
> now owns Eagle. Each measurement was a separate operation. There was no
> way (that I could easily find, I'm not a power user of AutoCad) to get into
> "measurement mode", then do a bunch of measurements in succession.

Autocad is not a good reference to good modern gui.

> People don't like the modal interface because it's not what they are used
> to. That's not a good reason against it though. It's different for good
> reason, which one appreciates after getting used to it. The issue to spend
> effort on is to get new users over the hump more quickly and comfortably,
> not to dumb down the software to a lesser way of doing things just because
> everyone else does it that way.
>
> This discussion reminds me of the RPN versus algebraic notation debate for
> calculators in the 1970s. Those that actually tried RPN pretty much
> universally liked it better. However, HP was terrible at marketing and
> user education, so the majority of calculator users never tried RPN. Some
> were even vehemently against it just because it was something they would
> have to learn.

RPN is not the most popular. With modern computers you just write the
formula as you see it and get the answer. This is not a good argument
either.

> I'm a bit embarrassed to admit I was for algebraic notation in college too.
> This was because my first calculator was algebraic, in large part because
> it was half the price of the cheapest HP calculator. Then I went to work
> for HP as my first job out of college. Naturally I was handed a RPN
> calculator for my use. Since it was part of my job, I sat down, read the
> manual, and learned to use it. It actually was very easy to learn to use
> RPN. It takes just a few minutes if you put your religious convictions
> aside and actually try. I found all those RPN evangelists were actually
> right. It really was better. Since that day, I've only bought RPN
> calculators, and have used them exclusively for professional engineering
> over the last 36 years.

This discussion belongs to the 80's. Its not an issue anymore.

> Unfortunately, the dumb masses won out, and now the world uses largely
> algebraic calculators. This is all because it was "different" and appeared
> "difficult", even though it was actually quite easy to learn.

Personal opinions, I won't comment other than saying other ppl disagree,
and its not because they are lazy. It may very well bebecause they are
more efficient.

> Again, the answer here is one of education and leading new users thru the
> better Eagle way confortably without making it seem difficult (because it's
> actually not), not by dumbing down the software to appease new users at the
> expense of long term usability.
>

You show all the signs of avoiding to learn anything new. I tell you it
can be efficient, maybe more than current. I am still looking for that
"great example" that actually works with Eagle's gui.
Re: Is anyone at AutoDesk listening? [message #167849 is a reply to message #167842] Fri, 18 November 2016 10:18 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 17.11.2016 20:45, Eric Stevens wrote:
> I'm hoping the UI considerations don't include a ribbon. I don't
> understand why this is even a thing. Monitors are getting wider, not
> taller. I don't need a horrible UI design idea to take up a ridiculous
> amount of space on my 21:9 monitors. Think more XFCE than microsoft.

Hoho, couldnt agree more :) The ribbon is the worst disaster invented in
modern GUI times. If it's added, please make every function available
elsewhere, and put an option in to get rid of it.
Re: Is anyone at AutoDesk listening? [message #167850 is a reply to message #167849] Fri, 18 November 2016 14:41 Go to previous messageGo to next message
Olin
Messages: 903
Registered: December 2009
Location: Massachusetts
Senior Member
Morten Leikvoll wrote on Fri, 18 November 2016 05:18

The ribbon is the worst disaster invented in
modern GUI times. If it's added, please make every function available
elsewhere, and put an option in to get rid of it.


Absolutely!

Unfortunately the AutoCad viewer I had to get measurements from had one of those ribbons taking up a ridiculous number of pixels vertically. Yucc. The reason I point this out is because it comes from the same company that now owns Eagle. I seriously hope they don't try to make Eagle like AutoCad.

The first thing I do with software I plan to use for real is shut off all those space-wasting ribbons, tool bars, babbling paper clips, and whatever else. Good software lets you access everything from menus that can be activated by a single ALT-key combination, then single keys to select menu entries from there. That's so much faster than clickety-clicking your way thru menus, toolbars, or ribbons.

The latest versions of MS products have gotten really annoying. There are now double-letter abbreviations for things, they only show up after you hold down ALT, and then are big and obtrusive. The old way of underlining a single letter to show the ALT-key was simple, unobtrusive, and worked both ways. If you wanted to clickety-click, you could just harmlessly ignore the little underlines.

There was no problem. Then somebody "fixed" the UI, and now we have a problem.
Re: Is anyone at AutoDe sk listening? [message #167851 is a reply to message #167848] Fri, 18 November 2016 15:00 Go to previous messageGo to next message
Olin
Messages: 903
Registered: December 2009
Location: Massachusetts
Senior Member
Morten Leikvoll wrote on Fri, 18 November 2016 05:13

Autocad is not a good reference to good modern gui.


But it's very relevant here since it comes from the same company that now owns Eagle.

Quote:

> It actually was very easy to learn to use
> RPN. It takes just a few minutes if you put your religious convictions
> aside and actually try. I found all those RPN evangelists were actually
> right. It really was better. Since that day, I've only bought RPN
> calculators, and have used them exclusively for professional engineering
> over the last 36 years.

This discussion belongs to the 80's. Its not an issue anymore.


It is exactly the issue we face with Eagle today. It illustrates how most popular doesn't mean better. The masses can be wrong, and often are. It also illustrates the real problem, which is people being uncomfortable with something they don't know. They then argue against it any way they can to make it go away.

The software developers need to understand this is what's happening, and to not address the problem by appeasing the masses and dumbing things down for them. Instead, help them get over the initial aversion with easily accessible tutorials, examples, good help system, and the like. Once they get comfortable with it, they'll become evangelists for you, just like the overwhelming fraction of Eagle power users are today.
Re: Is anyone at AutoDe sk listening? [message #167852 is a reply to message #167848] Fri, 18 November 2016 15:13 Go to previous messageGo to next message
Olin
Messages: 903
Registered: December 2009
Location: Massachusetts
Senior Member
Morten Leikvoll wrote on Fri, 18 November 2016 05:13

> I and others have already given several. A common one is deleting multiple
> object in a schematic. You do DEL once, then click away. It would be much
> slower to click each object, then separately indicate the delete
> operation.

You really need to get updated on latest GUI. Of course you can
multiselect and delete.


Multi-selecting is not the same as setting a mode and then doing any number of those operations incrementally. With multi-selecting, you have to decide up front what items you want to apply the operation to. It can be easy to miss something, then you're back to doing it over again. You also don't get the same incremental visual feedback. Multi-selecting generally highlights or otherwise shows you what's selected, but that's different from it being completely gone, for example, if the function is delete. It's mentally easier to simply delete each item until everything you want gone is gone.

Of course there are times when selecting a group of objects is the natural way to do things. Eagle has that too. The arguments for the common way all come down to that it's more common. Unfortunately, common doesn't mean better.
Re: Is anyone at AutoDesk listening? [message #167860 is a reply to message #167732] Sat, 19 November 2016 03:42 Go to previous messageGo to next message
eaglecandies
Messages: 186
Registered: September 2011
Location: Cincinnati
Senior Member
How tough would it be to just program in a choice for the interface style?
The current method "merely" selects a mode (modal), then the object(s) [such as mode=delete..thereafter start picking objects]..it seems like this could be made reversible: A selection, followed by today's inherent modes becoming actions instead. So then pick object(s) (Windows-way), followed by the action button (delete, rotate, etc, or hot key, or right click selection). The group button would disappear in "windows mode", since groups would be selected windows-way. But the overall menus might be largely kept as-is.
A few things, such as drawing a polygon require a preceding mode setting whether in windows or traditional mode (in windows apps you typically need to set a polygon drawing mode before starting).
What would it take to implement something like this? Autodesk has the resources to make it happen--and quickly.
Re: Is anyone at AutoDe sk listening? [message #167863 is a reply to message #167745] Sat, 19 November 2016 05:43 Go to previous messageGo to next message
Matt Berggren
Messages: 34
Registered: November 2016
Member
Hi James, et. Al --

What I think is missing from this thread is "what's the default mode when no other mode is selected?" and that opens up some interesting discussion.  Firstly, Altium has things like modal delete.  From the menu it's Edit+Delete and then you're in the mode until you Esc out of it.  The value of this capability has meant that it continues to be in the software 15+ years after that use-model has all but disappeared.  There was value there so we never removed it (full disclosure, I worked there for before Autodesk / Cadsoft, having hung around this industry long enough to remember when Masstek was OrCAD and Tango was Protel in America :) ...Ok, now that we know I'm old...Back to the matter at hand). 

The modern UI paradigm is that there is never a mode where +no+ command is selected.  There is always a "state".  And this is where I think selection can be improved to be more intuitive.  So when no mode is enabled, why wouldn't you want to be able to select an object?  Why wouldn't you want to be able to use Ctrl / Cmd + Click to cumulatively select?  Why wouldn't you want to be able to simply hit Delete when objects are selected +and no other command is in process+ and the command line is empty, to delete objects?  And why can't this peacefully coexist with the other modal commands?  The notion that I somehow +accidentally+ hit Delete is a pretty remote one, dont you think?

Likewise, hooking the LeftMouseDown + Drag event, couldnt that same "command-less" mode detect that you have things selected and just preempt your need to pick the Move command and revert to Move mode? 

The essence of what I'm saying is, we dont want to make unnecessary, overwhelming changes to the SW that leave you all scratching your heads and trying to re-learn the tools.  However the notion that the behavior most common in every other package - specifically +what happens when you're not in a command+ - is somehow bound to break the paradigm seems like a pretty weak argument.  Of course "strong opinions loosely held"...so if someone can demonstrate a case where the default state shouldn't be to select things *when no other command is selected* *and the command line is empty*, I'm totally open to considering it.

Likewise, there is the model of hitting Esc when you want to exit a command, rather than having to hit the stop sign or selecting another command.  This is a little more fidgety in the event that Esc is bound to some other operation belonging to a command, but again, can someone highlight a case where hitting Esc to terminate a command would cause a major issue?  We have looked high and low and there doesn't appear to be a situation where we couldn't make this work intuitively.

The sorts of changes we're talking about have to work in harmony with the general workflow however there are mouse clicks to be saved by - in some cases - not having the pick a command when the command state should simply be obvious and something we can intuit from the context.  These are the things we are most interested in improving. 

As I've mentioned in a previous post, the only 100% defensible arguments in my view are ones that point to improved productivity, usually measured in reduced mouse clicks.  Collision detection in routing is a clear case where there are virtually zero cases in which a track should violate another track's clearance rule.  If nothing else, this should be the corner-case and we can enable a mode to support this. 

Learning curve is something we have to ignore where the productivity gains are clearly there.  Sadly, in many cases, we have two great approaches varying largely on preference and there's a judgement call to be made.  Here, learning curve plays a role there but not the only role.  We'd hope to make changes in a way that's in the best interest of everyone but rest assured, we cant / wont just make random decisions based on our personal preferences and if you see something that looks that way, I want you to call us out on it! (I promise I'm got my fair share of gripes with all tools and have as recently as the last 2 years built production products on at least 3 different platforms, so the wounds are pretty raw!)

Thank you all for the spirited, well-reasoned dialog.  Please keep your suggestions / concerns coming, it truly helps us build a better tool!

Best regards,

Matt Berggren
Director - Autodesk

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209834
Re: Is anyone at AutoDesk listening? [message #167864 is a reply to message #167860] Sat, 19 November 2016 08:52 Go to previous messageGo to next message
Rob Pearce
Messages: 480
Registered: September 2012
Senior Member
On 19/11/16 03:42, Hoyt wrote:
> How tough would it be to just program in a choice for the interface style?
> The current method "merely" selects a mode (modal), then the object(s)
> [such as mode=delete..thereafter start picking objects]..it seems like this
> could be made reversible: A selection, followed by today's inherent modes
> becoming actions instead. So then pick object(s) (Windows-way), followed
> by the action button (delete, rotate, etc, or hot key, or right click
> selection).

First, I don't think the "Windows way" works well for CAD. All the
examples I can think of require you to "activate" that selection process
by picking (one of) the select tool(s). Eagle already has a select tool,
called "group". So your suggestion boils down to:

- if the user defines a "group" and then immediately clicks a new
function, assume an immediate right-click.

I don't see that as a big improvement, to be honest.
Re: Is anyone at AutoDesk listening? [message #167866 is a reply to message #167860] Sat, 19 November 2016 08:58 Go to previous messageGo to next message
Joern Paschedag
Messages: 1436
Registered: August 2008
Senior Member
Am 19.11.2016 um 04:42 schrieb Hoyt:
> How tough would it be to just program in a choice for the interface style?
> The current method "merely" selects a mode (modal), then the object(s)
> [such as mode=delete..thereafter start picking objects]..it seems like this
> could be made reversible: A selection, followed by today's inherent modes
> becoming actions instead. So then pick object(s) (Windows-way), followed
> by the action button (delete, rotate, etc, or hot key, or right click
> selection). The group button would disappear in "windows mode", since
> groups would be selected windows-way. But the overall menus might be
> largely kept as-is.
> A few things, such as drawing a polygon require a preceding mode setting
> whether in windows or traditional mode (in windows apps you typically need
> to set a polygon drawing mode before starting).
> What would it take to implement something like this? Autodesk has the
> resources to make it happen--and quickly.
>

THEN you can FORGET eagle.

--
Mit freundlichen Grüßen / With best regards

Joern Paschedag
Re: Is anyone at AutoDesk listening? [message #167867 is a reply to message #167732] Sat, 19 November 2016 09:09 Go to previous messageGo to next message
eaglecandies
Messages: 186
Registered: September 2011
Location: Cincinnati
Senior Member
THEN you can FORGET eagle.

What's to forget?..simply give the preference to pick the object(s) first or the action first, based on the user preference. So the hardcore eagle user will still have it to their liking.
Re: Is anyone at AutoDesk listening? [message #167868 is a reply to message #167807] Sat, 19 November 2016 13:12 Go to previous messageGo to next message
rk
Messages: 386
Registered: February 2005
Senior Member
Andreas made many good suggestions regarding the UI years ago, maybe
it's worth reading it again:

http://www.eaglecentral.ca/index.php/mv/msg/45784/142573/3ad621ab557e961e03 3b23199a05b569

http://www.eaglecentral.ca/index.php/mv/msg/45785/142576/3ad621ab557e961e03 3b23199a05b569

http://www.eaglecentral.ca/index.php/m/142577/3ad621ab557e961e033b23199a05b 569

http://www.eaglecentral.ca/index.php/m/142579/3ad621ab557e961e033b23199a05b 569

http://www.eaglecentral.ca/index.php/m/142761/3ad621ab557e961e033b23199a05b 569

and so on, goes up to:

http://www.eaglecentral.ca/index.php/m/156819/3ad621ab557e961e033b23199a05b 569

Rene
Re: Is anyone at AutoDesk listening? [message #167870 is a reply to message #167867] Sat, 19 November 2016 15:04 Go to previous messageGo to next message
hbridge99
Messages: 4
Registered: November 2016
Junior Member
> The essence of what I'm saying is, we dont want to make unnecessary, overwhelming changes to the SW that leave you all scratching your heads and trying to re-learn the tools.  However the notion that the behavior most common in every other package - specifically what happens when you're not in a command - is somehow bound to break the paradigm seems like a pretty weak argument.  Of course "strong opinions loosely held"...so if someone can demonstrate a case where the default state shouldn't be to select things when no other command is selected and the command line is empty, I'm totally open to considering it.
>
> Likewise, there is the model of hitting Esc when you want to exit a command, rather than having to hit the stop sign or selecting another command.  This is a little more fidgety in the event that Esc is bound to some other operation belonging to a command, but again, can someone highlight a case where hitting Esc to terminate a command would cause a major issue?  We have looked high and low and there doesn't appear to be a situation where we couldn't make this work intuitively.
>
> The sorts of changes we're talking about have to work in harmony with the general workflow however there are mouse clicks to be saved by - in some cases - not having the pick a command when the command state should simply be obvious and something we can intuit from the context.  These are the things we are most interested in improving.
There are times in which Eagle just "loses focus" and I wonder why it's so dumb that it can't go back to the move tool, so kudos on making this work right.

I wrote up the analysis below, with which I expect many long-time users will disagree. I should point out that after using Eagle for five years, making dozens of boards and hundreds of revisions - I'm not a new user. I think I started on Eagle 4.

I myself am agnostic about the Verb-Noun way of doing things, although I would be glad to see it go away. I do hope that some of the rest of the aggravations of the UI will be fixed, along the lines of the five essays linked to above, and also some new functionality such as making the router more intelligent. I'll also put in my vote for being able to view a board from the bottom side - it doesn't sound like rocket science, although a simple set of tools to align objects on a board seems even less like rocket science, and I've watched five or six revisions come and go without that functionality.

I would also urge AutoDesk to look at the "Database view" in Ultiboard/Multisim. If that program had a mac version I might be using it, even though it's more expensive than Eagle. It would seem that low-level / low-cost software should make progress by cribbing advanced features / good ideas from more capable software, as has been pointed out, which is the real competition.

Pros and Cons of the "Verb before Noun" Paradigm   AKA Eagle's mouse UI

Pros
* It allows single-click manipulation of single objects. Saving some clicks.
* This requires choosing a tool first however so the total clicks may not be as great as imagined.

Cons
* It necessitates the use of a "Group" tool - otherwise the arrow tool just lassos the objects, or shift clicks etc. The tools Delete, and Copy are also not found in lots of software toolboxes, relying instead on the Edit menu plus well-known hot keys.
* It is not orthogonal, meaning that single objects and groups are treated differently. This creates confusion, as well as leading to learning difficulties.
* When working with groups, It increases the number and variety of clicks (left, CMD-right-click) increasing confusion, leading to a harder to learn paradigm, and is slower.
* Perhaps more controversially, it is cognitively harder to grasp.
** Ask yourself, do I open the refrigerator door, then go and pick up food to put in the refrigerator?
** I submit that object - verb is much congruent with the way our minds work.
* The Verb before Noun paradigm may be found nowhere else in modern software, so tends to work against users pervious knowledge about computer interfaces.


Noun before Verb interface benefits
* Is more orthogonal implying ease of learning, ease of use, as:
* Single objects and groups are treated in exactly the same manner.
* Is congruent with modern standards, and perhaps more controversially:
* Is more congruent with the way our minds work.
* A noun-verb interface also allows such shortcuts as "dragging off a copy" with the option key, by using the modifier key as a verb.
* Incidentally this could also be used to provide a simulated "one click" access to to the move tool also, with a modifier key, or as suggested above just the software contextually intuiting what the user wants.
* The arrow tool becomes a more universal tool, perhaps eliminating up to three tools in the toolbox. Group, Copy, Delete and perhaps the Change tool although this depends on enhanced functionality of the UI

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209867
Re: Is anyone at AutoDesk listening? [message #167872 is a reply to message #167732] Sat, 19 November 2016 17:20 Go to previous messageGo to next message
eaglecandies
Messages: 186
Registered: September 2011
Location: Cincinnati
Senior Member
Please fix the decades-long issue with the wire button, maybe rename it "lines" & change its icon. Far far far too many users attempt to use this to "wire up" their schematics, causing extreme aggravation (and endless comments like: "No, this is really not the correct button to use, though it looks like you should") Rename the net button as wires/nets. Why does this simple change take more than 10 years of endless problems?
Re: Is anyone at AutoDesk listening? [message #167875 is a reply to message #167870] Sat, 19 November 2016 20:16 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
hbridge99 schrieb:

> I wrote up the analysis below, with which I expect many long-time
> users will disagree. I should point out that after using Eagle for
> five years, making dozens of boards and hundreds of revisions - I'm
> not a new user. I think I started on Eagle 4.
>
> I myself am agnostic about the Verb-Noun way of doing things,
> although I would be glad to see it go away.

Don't you see the contradiction in just this one sentence? It appears
pretty obvious that you are strongly biased against verb-noun...

I already mentioned before that there surely are many details where the
UI can be improved, particularly with respect to its reactions on
"unexpected" user actions. EAGLE could be much more intelligent here and
perform what the user "wanted" to do instead of raising an error
message. But that's not related to the modal concept of the UI.

I won't comment your "analysis" (which interestingly contains only "pro"
for the noun-verb concept) since it simply ignores the way a PCB CAD
tool like EAGLE is used. (Even if there are good and strong arguments
against your claims...)

At least when *I* am working with EAGLE, the main work is *not*
selecting objects.

First, I enter the schematics. For that, I ADD the components. Then I
MOVE them to form a good arrangement. After that, I draw the NETs. *All*
of these operations benefit *much* from the modal UI since it's always
the same operation I do, many times in sequence. And since MOVE and NET
are assigned to function keys, it's very easy and comfortable to change
the mode inbetween when finding out that some device should be placed
differently. Always with left hand at the keyboard and right hand on the
trackball, this makes drawing a schematic very fast, convenient and
efficient.

After the schematic is finished, I switch to the board. Again, at first
I need to arrange the components with MOVE - very many components in
sequence. Later I ROUTE (for quality reasons, I don't use the
autorouter) - again, this applies to many tracks in sequence. If I need
to push something inbetween - no problem: MOVE, SPLIT and ROUTE are on
function keys. As with drawing the schematic, the workflow consists of a
long sequence of always the same command(s), which *perfectly* fits the
modal concept and result in *much* less mouse action. (You already guess
it - the same applies to the cleanup of routing layers and silkscreen
later.)

I shudder when thinking I'd need to do such work with a non-modal UI.
When selecting objects really is needed, I don't even mind using GROUP
(which, BTW, also is assigned to a function key).

I don't mind if selecting and/or dragging might be made possible when
there's no "active" command (as Matt mentioned) - as long as the
commands that represent >95% of the work still are modal.

I don't say EAGLEs modal UI is easy to learn for beginners that just
want to start doing complex designs without even looking at a manual or
tutorial. But I'm sure that if you'd teach those beginners this
efficient way to use EAGLE, they'd adopt it quickly and also see the
benefits.

Claiming that you did dozens of designs in several years with EAGLE,
apparently without realizing such basics, that work must be horrible and
very time consuming for you. Opposed to that, *I* like working with
EAGLE. I also did (and occasionally do) look at other CAD tools, but
EAGLE appears to be the most efficient one for me - explicitly because
of its modal UI.

0.02$
Tilmann
Re: Is anyone at AutoDesk listening? [message #167876 is a reply to message #167732] Sat, 19 November 2016 23:36 Go to previous messageGo to next message
hbridge99
Messages: 4
Registered: November 2016
Junior Member
> @Tilmann
>
> First, I enter the schematics. For that, I ADD the components. Then I
> MOVE them to form a good arrangement. After that, I draw the NETs. All
> of these operations benefit much from the modal UI since it's always
> the same operation I do, many times in sequence. And since MOVE and NET
> are assigned to function keys, it's very easy and comfortable to change
> the mode inbetween when finding out that some device should be placed
> differently. Always with left hand at the keyboard and right hand on the
> trackball, this makes drawing a schematic very fast, convenient and
> efficient.
>
> After the schematic is finished, I switch to the board. Again, at first
> I need to arrange the components with MOVE - very many components in
> sequence. Later I ROUTE (for quality reasons, I don't use the
> autorouter) - again, this applies to many tracks in sequence. If I need
> to push something inbetween - no problem: MOVE, SPLIT and ROUTE are on
> function keys. As with drawing the schematic, the workflow consists of a
> long sequence of always the same command(s), which perfectly fits the
> modal concept and result in much less mouse action. (You already guess
> it - the same applies to the cleanup of routing layers and silkscreen
> later.)
I don't think my workflow is that much different than yours, except I use the group tool a lot more. Once things are in approximately the correct order, things need to move in modules, and as groups of components. This is where Eagle feels the most awkward to me.

And I also don't think you'd see that much difference between the way it works now vs a smart non-modal interface. As stated above it is possible (and common) to make the move tool work with one click. Every one of the graphic design programs I use does this without fuss. The route tool would probably work in exactly the way it does now as routing on a group of objects doesn't make sense. The Add tool would work the same. Some things could just away. The group tool, the copy tool, the delete tool (look for those in some of the other software you use). A lot of right clicks could be replaced by left clicks with right clicks contextually offering your top three or four choices instead of scrolling have way down a menu.

Given a well tuned UI I happen to think that number of clicks would be much reduced - but again this depends on a lot of things.

Do I think that part of Eagle (the clicking) will make that much difference if the rest of the awkwardness isn't changed? Absolutely not. Features such as aligning and distributing objects and lots of automation (such as push and shove routing) that is currently lacking will make the difference. Parsing out user intentions (and the most logical possibilities) instead of throwing up absurd error messages will make the difference. Providing missing menus. Providing navigation in Libraries while making a part. Making the Control Panel go away. (not its functions). (My bet is that the control panel was written as a separate effort and just never integrated into the package well. Why searching should be so much faster in Add than in the control panel has always been a divine mystery to me.) Why not right click on a part in the Add dialog and add the part to the open library?

Paul

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209878
Re: Is anyone at AutoDe sk listening? [message #167877 is a reply to message #167800] Sun, 20 November 2016 05:43 Go to previous messageGo to next message
Matt Berggren
Messages: 34
Registered: November 2016
Member
Hi Gerald --

What's wrong with the webpage?  It was working for me.  Let me know what the issue is and I'll fix it. 

I personally love that you came from PCAD!  In fact, I'd spent a good deal of time @ Accel (makers of PCAD for the folks too young to remember) before joining Altium and later Autodesk...And I have to confess, I still have a fondness for MANY of it's features that we didnt chose to carry into the Protel-universe.  (Nice thing about being both a SW and HW engineer is I've had the good fortune to be able to recreate what I felt was always missing via scripting tools or SW APIs!) 

If you have a list of favorite PCAD features, I'd love to hear about them!  It was genuinely ahead of its time and when the old accel gang gets together we frequently joke about "new" features in even the very high priced tools which we had in 2002, 2004, 2006, etc.  :)

Regarding the pace of feature development for EAGLE, I can only say that we are really making progress in development today and the development team - myself included - are both excited and enthusiastic about the future of the tools.  We have grown the team but also brought on board the best and brightest from this space.  Great thing about being in this biz for SO many years is you develop some great relationships and I can honestly say that the people we've got working on EAGLE today are some of the best I've ever known.  So stay tuned!  The future of EAGLE is *very* bright!  (ok, no more hand-wavy)

Best regards,

Matt

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209842
Re: Is anyone at AutoDe sk listening? [message #167878 is a reply to message #167870] Sun, 20 November 2016 06:14 Go to previous messageGo to next message
Matt Berggren
Messages: 34
Registered: November 2016
Member
Thanks Tilmann! 

As Ive said, I think we can strike this balance quite well and not have to leave folks behind.  Modal behavior has it's benefits (I really believe this and if you look at most ecad tools, they have this approach all over the place because it *does* make sense for heaps of operations...some modal commands are more hidden than others - usually in menus - but I promise, they're in there).  And as I've said, if the feature is truly faster or more efficient, then that's the only truly defensible position long term.  Where it's a judgement call (ie. both options are equally good) then EAGLE's history will have a BIG influence on what we do. 

To be sure though, we dont want to change the use-model unless we feel we've got good reason to do this!  Extend it?  Yes.  But willy-nilly change it?  Nope.  So legacy users shouldn't be seriously impacted by the things we do.  Will some things change?  Sure, but we'll do things cautiously and work with the amazing support and product teams (you no doubt know them all -- Ed, Jorge, Richard, Andre, etc) to be sure we don't drop the ball. 

What I mentioned earlier about the "what to do when there is no state selected?," the good thing is that modern UIs / event processing gives us multiple options for how we both detect your intent and then bind commands to specific mouse operations (Left Click, Left Click + Drag, Right Click, Right Click + Drag, middle mouse, etc).  So we have plenty of options which enable a more friendly (noun-verb friendly -ish) workflow without having to abandon the verb<>noun model. Take as a simple example:  if you left click and drag with no other command selected, you would expect to be able to draw a selection rectangle.  This can occur without changing *anything* about the verb<>noun model. 

What we *will* avoid is creating two command models.  A hybrid approach is not just possible but is actually the only approach any piece of software you use today supports.  When you place a line in photoshop for example, you select a mode and then place it.  When you delete it, you can select it and hit delete.  One is modal, the other mode is derived from the context.  Neither of these prevents the other.  Neither requires we delete a command from a menu or a toolbar, or change anyone's workflow. 

Have a play with just about any software and feel around for when something is modal, and when something is derived from the context or by interpreting user behavior.  The fact is that we dont actually use one model at all.  In fact, we use both models frequently and if there's anything "weird" or anything which stands out in EAGLE's current UI, it's that one mode tends to prevail without the other mode that is familiar to non-EAGLE users. 

Hope this helps give a bit more detail on our thinking / approach.  Please keep the suggestions coming!

Best regards,

Matt

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209843
Re: Is anyone at AutoDe sk listening? [message #167879 is a reply to message #167872] Sun, 20 November 2016 06:16 Go to previous messageGo to next message
Matt Berggren
Messages: 34
Registered: November 2016
Member
> Norm Novotney wrote:
>
> Please fix the decades-long issue with the wire button, maybe rename it
> "lines" & change its icon. Far far far too many users attempt to use this
> to "wire up" their schematics, causing extreme aggravation (and endless
> comments like: "No, this is really not the correct button to use, though it
> looks like you should") Rename the net button as wires/nets. Why does this
> simple change take more than 10 years of endless problems?
> --
> http://www.eaglecentral.ca ( https://www.element14.com/community/external-link.jspa?url=http%3A%2F%2Fwww .eaglecentral.ca) :: The original and best browser access to CadSoft EAGLE support forums. Supported by EAGLE licenses purchased through us :: http://www.eaglelicenses.com ( https://www.element14.com/community/external-link.jspa?url=http%3A%2F%2Fwww .eaglelicenses.com)
>

Yep.  List item #1 = stop calling the line drawing tool "Wire".  Because scripts are bound to this, probably not worth us breaking the command-line syntax.  But this is silly and will be changed.  Sorry this took so long.  :)

Best regards,

Matt

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209844
Re: Is anyone at AutoDe sk listening? [message #167880 is a reply to message #167878] Sun, 20 November 2016 07:55 Go to previous messageGo to next message
warrenbrayshaw
Messages: 1759
Registered: January 2010
Location: New Zealand
Senior Member
Matt Berggren wrote on Sun, 20 November 2016 19:14
Thanks Tilmann! 


....... Take as a simple example:  if you left click and drag with no other command selected, you would expect to be able to draw a selection rectangle.  This can occur without changing *anything* about the verb<>noun model................. 


Best regards,

Matt

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209843



Hi Matt
First let me say I was encouraged by the number of words you were typing. Things looked promising.

I'm responding using Eagle Central and not the newsgroup because the formatting Element14 uses makes quoting untenable.
I'm surprised and disappointed you use Element14 to respond. I was living in hope that Autodesk would instruct its lawyers to send a cease and desist to Element14 and get that badly implemented portal, that split the community, shut down.

Your response to Tilmann appears to contradict you previous words.
I understood earlier that you were considering, with no command selected, if you click and drag on an object it would trigger a move. Once you release the left mouse button you would be in the 'no command' state again. This seems to be a useful thing to me. But above you said you would expect to generate a selection rectangle. Something you would not want unless you were grouping objects.

Anyway, all the best, you have a big task ahead of you.

Warren





Re: Is anyone at AutoDe sk listening? [message #167881 is a reply to message #167880] Sun, 20 November 2016 08:43 Go to previous messageGo to next message
Matt Berggren
Messages: 34
Registered: November 2016
Member
Thanks Warren!  The newsgroups are cool however I was concerned about whether I needed to quote folks, etc. so having something a little more graphical was a nice insurance policy.  :)  We'll get this all ported to +something+ at some stage but let's not start that discussion from within this thread as I suspect it'll set a few folks off and we want to avoid either rousing people for something that hasn't been decided or getting too far off-topic! 

Regarding the drag to "group select" ...that was really just a way of saying that if there isn't an object under the cursor, then we can detect this and have some options for other stuff we can do +*if there is no currently active command*+.  (...And that last bit is the essential thing that really makes much of this possible.)  So if there wasnt anything active and you started to hold the left mouse button and drag in the workspace, one would expect that you would switch to a selection mode and be using the selection-rectangle.  If you did that over a component, you would expect to be able to Move it.  We can detect this and modify the command to serve the context.  Once the stuff is selected, you could revert to either 'no active command' or stay in that mode.  It's really something I'd love to hear feedback on.

Point being, I don't think this +awareness of context+ inhibits anything that a user might otherwise want to do, as the left mouse button isn't bound to anything when there's no active command and nothing hanging from the cursor (correct me if I'm wrong but this is what the code shows).  Because pan is all done using the middle mouse button or multiple fingers on the trackpad, and this actually stretches the paradigm a bit (because you are invoking a command without selecting it first); it seems obvious to me that the default behavior when there is nothing but "+whitespace+" under the cursor and you click and hold the left mouse button, +should+ be to allow you to select objects within a rectangle.  But of course feedback would be handy to make sure this is what most folks expect.

This is pretty standard behavior - and again from what I've seen - doesn't appear to break the verb<>noun paradigm in any other way but "this is how it's always been done," which is a pretty hollow argument, no?  The verb noun gets to persist but the commands become more intuitive.  This is what I was trying to communicate in that last post.

Happy to hear feedback on this, but it's pretty obvious that there are ways that verb<>noun can persist whilst addressing some of the less-than-intuitive behaviors.  Thoughts on this are totally welcome and I look forward to feedback!

Best regards,

Matt
p.s. the text editor window keeps resizing on me in firefox as I type...this really is a feisty forum system ;)  ...I take your point!

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/209845
Re: Is anyone at AutoDe sk listening? [message #167882 is a reply to message #167881] Sun, 20 November 2016 14:33 Go to previous messageGo to next message
Olin
Messages: 903
Registered: December 2009
Location: Massachusetts
Senior Member
Matt Berggren wrote on Sun, 20 November 2016 03:43

So if there wasnt anything active and you started to hold the left mouse button and drag in the workspace, one would expect that you would switch to a selection mode and be using the selection-rectangle.  If you did that over a component, you would expect to be able to Move it.


This may get tricky because now you have to decide how close close is. For large components, like a microcontroller symbol in a schematic, you can still visually appear to be "in" the microcontroller, but far from its origin and much closer to the origin of some other component, like a cap connected closely to one of the pins. What do you want to do? Move the micro, move the cap, or start a selection?

It might be better to have a leftclick-drag always do one thing consistantly, which should probably be a move. Grouping is far less common than moving. Grouping is also more complicated. You can drag a rectangle or click a sequence of points to define a polygon. This latter gets used a lot when moving clumps of components in a schematic. By the time a sheet is filled with components, there is rarely a simple rectangle that delineates exactly what you want to group. If you can only do rectangle-drag grouping, you're loosing 1/2 to 2/3 the power of group anyway.

Some of the worst experiences with other software is when it tries to be clever and think it knows what I want to do. Getting it wrong a few times is way more annoying than the benefit of getting it right more often. Being able to count on it to be completely predictable is worth a lot. If that means you can't do a group automatically, OK. It's not like doing a group now is hard. Its not one of the things about Eagle I ever considered frustrating.

Also, whatever you do, don't break things for existing users that have taken the trouble to learn Eagle and can use it well. I think that doing something like a move automatically from leftclick-drag is "free" in that it does't break anything, but I'd have to play with it a while to be sure. So many interactions in Eagle have become automatic by now, that looking back I'm not always sure what my fingers were doing. As long as all that continues to work, I don't really object. I am worried about unintended consequences, though.

Quote:

We can detect this and modify the command to serve the context.  Once the stuff is selected, you could revert to either 'no active command' or stay in that mode.  It's really something I'd love to hear feedback on.


I'm not totally sure what you are asking about. Let's say you are not in a command, and do a leftclick-drag that moves a object. Now the question is what to do if the next action is leftclick-drag? First, that's only a question if there was more than one choice what the system might do on leftclick-drag in the first place with no command active. As I said above, I'm worried that trying to infer too much from context will create more frustration than it will streamline usage. However, let's say you chose between move and group depending on nearness to a origin point.

My gut feel is that predictability is the most important here. Whatever algorithm you use to decide what to do should be the same each time, regardless of the previous decision. Let's say someone just did a implied move by click-drag. Now there are two possible intentions, they want to do another move or they want to do a group. There are also two actions to consider, which are click-drag near a origin and not. This results in four possibilities:

Click-drag near origin, wants to do move. No problem, causes move.

Click-drag near origin, wants to do group. Going to do move either way. User error.

Click-drag far from origin, wants to do group. Inheriting the previous mode is obviously bad here. The user did the usual thing to do a group, and is going get pissed if this causes a move instead. They are going to think "Argh! Just because I did a move, now it thinks that's all I ever want to do. Give me software that doesn't think it's smarter than I am!?"

Click-drag far from origin, wants to do move. This is really the only case where inheriting the mode does anything useful. If you do move, things proceed as intended. If you do group, the user doesn't get what they intended, but who are they going to blame? Most likely the user will think "oops, I missed", let up on the button, position the pointer more accurately, and try again. The worst case is they think "I just did a move, why can't this stupid software remember that!?". That just doesn't sound as likely, nor cause the same frustration level as the previous case.

However, these things are hard to imagine up front. You really have to play with it a while to find what is more comfortable.
Re: Is anyone at AutoDe sk listening? [message #167883 is a reply to message #167880] Sun, 20 November 2016 21:21 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
Warren Brayshaw schrieb:

> I'm responding using Eagle Central and not the newsgroup because the
> formatting Element14 uses makes quoting untenable.

Please don't confuse "Element14" with the newsgroups where the original
message repository resides.

Both Eagle Central and Element14 are web interfaces to the newsgroups -
with one big difference: Element14 is absolute crap, while Eagle Central
works.

Still, accessing the newsgroups directly via NNTP newsreader (like
Thunderbird, Forte Agent or the like) is the best (and IMHO most
efficient) method. But if someone prefers a web interface for whatever
reason, Eagle Central is the *very much* better choice.

> I'm surprised and disappointed you use Element14 to respond. I was
> living in hope that Autodesk would instruct its lawyers to send a
> cease and desist to Element14 and get that badly implemented portal,
> that split the community, shut down.

In fact, I am hoping that too.

Tilmann
Re: Is anyone at AutoDe sk listening? [message #167884 is a reply to message #167881] Sun, 20 November 2016 21:34 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
Matt Berggren schrieb:

> Thanks Warren! The newsgroups are cool however I was concerned
> about whether I needed to quote folks, etc. so having something a
> little more graphical was a nice insurance policy. :)

If you want to use a "more graphical", web based interface to the
newsgroups, *please* use Eagle Central instead of Element14.

Element14 ist the worst newsgroup to web forum interface one can ever
think of, and obviously noone is interested in fixing the numerous bugs.
So it should better be shut down.

> We'll get this all ported to +something+ at some stage but let's not
> start that discussion from within this thread as I suspect it'll set
> a few folks off and we want to avoid either rousing people for
> something that hasn't been decided or getting too far off-topic!

No problem, I can start a new thread about that if you like...

But just take care: If you are thinking about "porting this all" to
something else, please *never* shut down these NNTP newsgroups. As soon
as you'd do this, you'd surely loose many of the regulars here. Using
direct NNTP access is the by far most efficient way for this kind of
communication, maybe comparable to the modal UI of EAGLE. :-)

To not waste ressources here, I'd recommend to not build up something
new "of your own", but simply use what's already there. There are
perfectly working NNTP newsgroups, with a fairly good working web
interface at Eagle Central. You might consider to just leave it that way
and use your ressources for more urgent issues.

Many thanks for listening (and participating) anyway,
Tilmann
Re: Is anyone at AutoDesk listening? [message #167885 is a reply to message #167876] Sun, 20 November 2016 21:59 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
hbridge99 schrieb:
>> @Tilmann

Using the crappy Element14 web interface, you completely broke up
threading. :-(

> I don't think my workflow is that much different than yours, except I
> use the group tool a lot more. Once things are in approximately the
> correct order, things need to move in modules, and as groups of
> components. This is where Eagle feels the most awkward to me.

In fact, it doesn't appear awkward to me. Since I assigned GROUP to a
function key (which is not in the default configuration for whatever
reason), it is perfectly convenient to do such work. And of course I
also use the group tool a lot.

> And I also don't think you'd see that much difference between the way
> it works now vs a smart non-modal interface. As stated above it is
> possible (and common) to make the move tool work with one click.
> Every one of the graphic design programs I use does this without
> fuss. The route tool would probably work in exactly the way it does
> now as routing on a group of objects doesn't make sense. The Add tool
> would work the same. Some things could just away. The group tool, the
> copy tool, the delete tool (look for those in some of the other
> software you use).

OK, so you're not argueing against a modal UI at all? Your previous
posts sound different...

> A lot of right clicks could be replaced by left clicks with right
> clicks contextually offering your top three or four choices instead
> of scrolling have way down a menu.

I never needed or used the context menu in EAGLE. For sake of
efficiency, I configured EAGLE to use the right mouse button for group
operations and the CTL key for panning, just as it was earlier. These
"more modern" UI changes are examples for how proposed "more common"
enhancements to the UI can seriously cut down efficiency. At least
CadSoft provided options to revert to the older, better behaviour.

Having said that, I can't see any benefit from your proposal.

> Given a well tuned UI I happen to think that number of clicks would
> be much reduced - but again this depends on a lot of things.
> ....

I think we definitely agree that there are several details at which the
UI and functionality of EAGLE can (and should) be improved, and I have
mentioned that before. But that still is not related to the discussion
about the modal concept. You're argueing at the wrong items.

Tilmann
Re: Is anyone at AutoDe sk listening? [message #167886 is a reply to message #167879] Sun, 20 November 2016 22:04 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
Matt Berggren schrieb:
>> Norm Novotney wrote:
>>
>> Please fix the decades-long issue with the wire button, maybe
>> rename it "lines" & change its icon. Far far far too many users
>> attempt to use this to "wire up" their schematics, causing extreme
>> aggravation (and endless comments like: "No, this is really not the
>> correct button to use, though it looks like you should") Rename the
>> net button as wires/nets. Why does this simple change take more
>> than 10 years of endless problems?
>
> Yep. List item #1 = stop calling the line drawing tool "Wire".
> Because scripts are bound to this, probably not worth us breaking the
> command-line syntax. But this is silly and will be changed. Sorry
> this took so long. :)

The solution to this is very simple (and has been proposed so many
times): Just rename icon and "official" command to LINE, while at the
command line (and so in scripts) still accept WIRE as well (additionally
to LINE). Just add a remark in the manual that for compatibility
reasons, WIRE is still accepted.

That's all.

Tilmann
Re: Is anyone at AutoDesk listening? [message #167887 is a reply to message #167732] Sun, 20 November 2016 22:33 Go to previous messageGo to next message
eaglecandies
Messages: 186
Registered: September 2011
Location: Cincinnati
Senior Member
The solution to this is very simple (and has been proposed so many
times): Just rename icon and "official" command to LINE, while at the
command line (and so in scripts) still accept WIRE as well (additionally
to LINE). Just add a remark in the manual that for compatibility
reasons, WIRE is still accepted.

Its strange, even in the latest V7 training video:
https://youtu.be/6MF6VNIyNAE
at 2:30 they make special mention that you might be confused & must use "net" rather than "wire". If so, what was stopping this fix all these years?

Re: Is anyone at AutoDesk listening? [message #167888 is a reply to message #167887] Mon, 21 November 2016 06:57 Go to previous messageGo to next message
Tilmann Reh
Messages: 2068
Registered: October 2004
Senior Member
Hoyt schrieb:
> The solution to this is very simple (and has been proposed so many
> times): Just rename icon and "official" command to LINE, while at the
> command line (and so in scripts) still accept WIRE as well (additionally
> to LINE). Just add a remark in the manual that for compatibility
> reasons, WIRE is still accepted.

*PLEASE* use the "reply" function and do not constantly break threading.
Also stop copying someone elses text into your messages without marking
it as quote. ("Reply" does exactly that for you, BTW.)

> Its strange, even in the latest V7 training video:
> https://youtu.be/6MF6VNIyNAE
> at 2:30 they make special mention that you might be confused & must use
> "net" rather than "wire". If so, what was stopping this fix all these
> years?

Questions, questions...

It took a about a decade until the current annotation state was made
visible. It took much more than a decade, and still we're waiting, for a
bottom view and for gateswap in the board - just to mention two. All of
these sould be rather simple to implement.

Let's hope that things really get better now. At least the messages of
Matt sound promising...

Tilmann
Re: Is anyone at AutoDe sk listening? [message #167890 is a reply to message #167863] Mon, 21 November 2016 09:25 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 19.11.2016 06:43, Matt Berggren wrote:
> Hi James, et. Al --
>
> What I think is missing from this thread is "what's the default mode when no other mode is selected?" and that opens up some interesting discussion. Firstly, Altium has things like modal delete. From the menu it's Edit+Delete and then you're in the mode until you Esc out of it. The value of this capability has meant that it continues to be in the software 15+ years after that use-model has all but disappeared. There was value there so we never removed it (full disclosure, I worked there for before Autodesk / Cadsoft, having hung around this industry long enough to remember when Masstek was OrCAD and Tango was Protel in America :) ...Ok, now that we know I'm old...Back to the matter at hand).
>
> The modern UI paradigm is that there is never a mode where +no+ command is selected. There is always a "state". And this is where I think selection can be improved to be more intuitive. So when no mode is enabled, why wouldn't you want to be able to select an object? Why wouldn't you want to be able to use Ctrl / Cmd + Click to cumulatively select? Why wouldn't you want to be able to simply hit Delete when objects are selected +and no other command is in process+ and the command line is empty, to delete objects? And why can't this peacefully coexist with the other modal commands? The notion that I somehow +accidentally+ hit Delete is a pretty remote one, dont you think?
>
> Likewise, hooking the LeftMouseDown + Drag event, couldnt that same "command-less" mode detect that you have things selected and just preempt your need to pick the Move command and revert to Move mode?
>
> The essence of what I'm saying is, we dont want to make unnecessary, overwhelming changes to the SW that leave you all scratching your heads and trying to re-learn the tools. However the notion that the behavior most common in every other package - specifically +what happens when you're not in a command+ - is somehow bound to break the paradigm seems like a pretty weak argument. Of course "strong opinions loosely held"...so if someone can demonstrate a case where the default state shouldn't be to select things *when no other command is selected* *and the command line is empty*, I'm totally open to considering it.
>
> Likewise, there is the model of hitting Esc when you want to exit a command, rather than having to hit the stop sign or selecting another command. This is a little more fidgety in the event that Esc is bound to some other operation belonging to a command, but again, can someone highlight a case where hitting Esc to terminate a command would cause a major issue? We have looked high and low and there doesn't appear to be a situation where we couldn't make this work intuitively.
>
> The sorts of changes we're talking about have to work in harmony with the general workflow however there are mouse clicks to be saved by - in some cases - not having the pick a command when the command state should simply be obvious and something we can intuit from the context. These are the things we are most interested in improving.
>
> As I've mentioned in a previous post, the only 100% defensible arguments in my view are ones that point to improved productivity, usually measured in reduced mouse clicks. Collision detection in routing is a clear case where there are virtually zero cases in which a track should violate another track's clearance rule. If nothing else, this should be the corner-case and we can enable a mode to support this.
>
> Learning curve is something we have to ignore where the productivity gains are clearly there. Sadly, in many cases, we have two great approaches varying largely on preference and there's a judgement call to be made. Here, learning curve plays a role there but not the only role. We'd hope to make changes in a way that's in the best interest of everyone but rest assured, we cant / wont just make random decisions based on our personal preferences and if you see something that looks that way, I want you to call us out on it! (I promise I'm got my fair share of gripes with all tools and have as recently as the last 2 years built production products on at least 3 different platforms, so the wounds are pretty raw!)
>
> Thank you all for the spirited, well-reasoned dialog. Please keep your suggestions / concerns coming, it truly helps us build a better tool!
>
> Best regards,
>
> Matt Berggren
> Director - Autodesk
>

Thanks Matt. It sounds to me like Eagle is in good hands :) Now I hope
you can keep the cost down. Someone in my office mentioned Autodesk had
a reputation to buy software and make it expensive ;)
Re: Is anyone at AutoDe sk listening? [message #167891 is a reply to message #167852] Mon, 21 November 2016 09:29 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 18.11.2016 16:13, Olin Lathrop wrote:
> Morten Leikvoll wrote on Fri, 18 November 2016 05:13
>>> I and others have already given several. A common one is deleting
>>> multiple
>>> object in a schematic. You do DEL once, then click away. It
>>> would be much
>>> slower to click each object, then separately indicate the delete
>>> operation.
>>
>> You really need to get updated on latest GUI. Of course you can
>> multiselect and delete.
>
>
> Multi-selecting is not the same as setting a mode and then doing any number
> of those operations incrementally. With multi-selecting, you have to
> decide up front what items you want to apply the operation to.

No, you can multiselect, do an operation, do another operation, deselect
some, or add some, and do another operation. Why do you think you have
to select over again? This is up to the gui programmers.

> It can be
> easy to miss something, then you're back to doing it over again. You also
> don't get the same incremental visual feedback. Multi-selecting generally
> highlights or otherwise shows you what's selected, but that's different
> from it being completely gone, for example, if the function is delete.
> It's mentally easier to simply delete each item until everything you want
> gone is gone.

> Of course there are times when selecting a group of objects is the natural
> way to do things. Eagle has that too. The arguments for the common way
> all come down to that it's more common. Unfortunately, common doesn't mean
> better.

I don't get you here. I simply don't see the difference between
modern/eagle way.
Re: Is anyone at AutoDe sk listening? [message #167892 is a reply to message #167884] Mon, 21 November 2016 09:39 Go to previous messageGo to next message
Friedrich Bleikamp
Messages: 79
Registered: August 2005
Member
Am 20.11.2016 um 22:34 schrieb Tilmann Reh:

> But just take care: If you are thinking about "porting this all" to
> something else, please *never* shut down these NNTP newsgroups. As soon
> as you'd do this, you'd surely loose many of the regulars here. Using
> direct NNTP access is the by far most efficient way for this kind of
> communication, maybe comparable to the modal UI of EAGLE. :-)
>
> To not waste ressources here, I'd recommend to not build up something
> new "of your own", but simply use what's already there. There are
> perfectly working NNTP newsgroups, with a fairly good working web
> interface at Eagle Central. You might consider to just leave it that way
> and use your ressources for more urgent issues.
>
> Many thanks for listening (and participating) anyway,
> Tilmann
>

I agree with Tilmann. My footer has been saying it for a long time.

Freundliche Grüße / Kind regards
Friedrich
-----------------------------------------------
.... benutzen Sie nntp://news.cadsoft.de und einen
funktionierenden News-Reader wie Thunderbird!
.... use NNTP://news.cadsoft.de and a
functional news reader like Thunderbird!
Re: Is anyone at AutoDesk listening? [message #167893 is a reply to message #167870] Mon, 21 November 2016 09:39 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 19.11.2016 16:04, hbridge99 wrote:
> Pros
> * It allows single-click manipulation of single objects. Saving some clicks.

We don't have to loose this pro. The interaction with command line + gui
should still work, so if you type a command, it should stay in this
command until the command is deselected, replaced by some other command
or escaped. Maybe you can make the gui "lock" tools from the toolbar
too, to make them act on clicked objects. But this is a job for
Autodesk, wich I think they will do well.
Re: Is anyone at AutoDe sk listening? [message #167894 is a reply to message #167886] Mon, 21 November 2016 09:54 Go to previous messageGo to next message
Morten Leikvoll
Messages: 1347
Registered: November 2007
Senior Member
On 20.11.2016 23:04, Tilmann Reh wrote:
> Matt Berggren schrieb:
>>> Norm Novotney wrote:
>>>
>>> Please fix the decades-long issue with the wire button, maybe
>>> rename it "lines" & change its icon. Far far far too many users
>>> attempt to use this to "wire up" their schematics, causing extreme
>>> aggravation (and endless comments like: "No, this is really not the
>>> correct button to use, though it looks like you should") Rename the
>>> net button as wires/nets. Why does this simple change take more
>>> than 10 years of endless problems?
>>
>> Yep. List item #1 = stop calling the line drawing tool "Wire".
>> Because scripts are bound to this, probably not worth us breaking the
>> command-line syntax. But this is silly and will be changed. Sorry
>> this took so long. :)
>
> The solution to this is very simple (and has been proposed so many
> times): Just rename icon and "official" command to LINE, while at the
> command line (and so in scripts) still accept WIRE as well (additionally
> to LINE). Just add a remark in the manual that for compatibility
> reasons, WIRE is still accepted.

Oh.. there is more to it.. All the data structures contain wire loop
members and so on..

To me Wire works fine. And a wire is really a net not in use. In both
schematic and board you can rename them to become signals/nets, as long
as they are on signal/net layers.

I'd rather see they worked on displaying them differently: Show a X over
unconnected pins, so users dont think they are connected when not. Maybe
even displaying an [live ERC] error (red exclamation mark?) when wires
are close or unconnected (not on grid) when they now appear to be.

In schematic, maybe wire and net can be merged to one tool if a live
snapping tool would display where the wire/net really would start/end
from/to at click.
Re: Is anyone at AutoDe sk listening? [message #167900 is a reply to message #167894] Mon, 21 November 2016 15:44 Go to previous messageGo to next message
eaglecandies
Messages: 186
Registered: September 2011
Location: Cincinnati
Senior Member
It needs to be named "lines" or people will still use wire for wiring up their parts & then the question will be why do they get 'X' when they try to wire up their circuit. Displaying X at unconnected pins, is a nice feature, however.
Re: Is anyone at AutoDe sk listening? [message #167904 is a reply to message #167887] Tue, 22 November 2016 06:39 Go to previous messageGo to next message
Matt Berggren
Messages: 34
Registered: November 2016
Member
Done.  :)  Sorry that took so long. 

Best regards,

Matt - Autodesk.

--
To view any images and attachments in this post, visit:
https://www.element14.com/community/message/210022
Re: Is anyone at AutoDesk listening? [message #169472 is a reply to message #167732] Sun, 19 February 2017 01:50 Go to previous message
eaglecandies
Messages: 186
Registered: September 2011
Location: Cincinnati
Senior Member
Now is the time to perform an progress check---has the Bottom View function promised last year been implemented during this new subscription conversion..or are these features all talk and no action?

Hi Everyone,
EAGLE continues to progress thanks to the comments and suggestions from the community, some we can be implemented faster than others. But, be assured, that the CadSoft Team is closely monitoring the forums!!!
We are Listening!!!
Best Regards,
Ed I find that either hard to believe or plain humorous...being able to show & interact with a true bottom view of the board has been requested for years...over and over and over and over...and where is it? When is it slated to be available? Where are the designator renumbering capabilities? Where is the highlighting of nets that actually works properly (rather than disappearing)? .... I hope the long nap is over.
Previous Topic: Revert net name back to default
Next Topic: ARDUINO MEGA2560 NOT AUTOROUTING ON EAGLE
Goto Forum:
  


Current Time: Sat Jul 22 18:51:28 GMT 2017