kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 9/10/2014 1:54 PM, Tim Hutt wrote:
> On 10 September 2014 10:25, Javier Serrano
> <javier.serrano.pareja@xxxxxxxxx
> <mailto:javier.serrano.pareja@xxxxxxxxx>> wrote:
> 
>      There is a big difference between commercial proprietary
>     applications and FOSS applications with no paid labor
> 
> 
> Definitely true. I think part of the problem is that FOSS developers
> generally develop for themselves, and once someone becomes a developer
> they are hardly a new user! So features for new users don't get much
> attention.

How are you defining a new user?  Are you talking about someone who has
no idea how to design and lay out a printed circuit board or are you
talking about someone who is coming from another electronic design
application?  Judging by some of you comments, it seems like the former.
 I agree that KiCad usability could be improved but I am opposed to
adding nagware to the point where all of these things you have proposed
start getting in the way of me getting work done.

> 
>     Watching 15 minutes of your video has been a very painful experience.
> 
> 
> Sorry! Though imagine how painful it would have been with Eagle!
>  
> 
>     if one accepts the premise that KiCad should be very usable by a new
>     user
> 
> 
> I think this is critical. It already looks like some people disagree!
> But I think they are just making excuses for Kicad. Even complex
> software can be usable for new users. I basically 100% agree with what
> you said so I won't repeat it all.
> 
> In particular though, I strongly believe:
> 
> 1. Good software has a manual. Great software doesn't need one.

I disagree with you on this.  The first thing I look for with any new
piece of software with a GUI is the list of keyboard short cuts.  If the
I cannot get to the primary functionality of an application without
clicking and pointing, that application will have a short life span on
my computer.  Pointing and clicking are only user friendly to users who
are stuck in that paradigm.

> 
> 2. Even complex software like CAD and EDA can be made so usable it
> rarely requires a manual. Solidworks is a great example. They have
> clearly put a lot of effort into making it user friendly.
> 
> 3. You *can* learn well-designed programs by clicking around in the
> interface. It's what most people do (obligatory: https://xkcd.com/627/ )

Every object in the schematic or board editor has a context menu
(assuming you know what the right mouse button is used for) that
contains all of the actions that can be performed on that object.
Embedded in the context menu for an object are the hot keys so you don't
have to keep using the context menu which is always slower because it
requires more steps.

> 
> One of the best ways to make a program more newbie-friendly without
> really changing it is to add something like one of the following:
> 
>     a) Rich tooltips.
> 
>     b) Qt "WhatsThis?" buttons. They are better than tooltips IMO
> because they are obviously there, and they more strongly suggest that
> the developer has actually written something useful (not something like
> "The mangler button. If clicked it activates the mangler. See help for
> more.").
> 
>      c) "Signpost" tooltips.
> 
> Here are some (horribly photoshopped) examples:
> 
> Current tooltip:
> 
> Inline images 2
> 
> Rich tooltip (if the manual is great, why not link to it more from the UI?)
> 
> Inline images 3
> 
> Currently, the help info below is shown in an (actually helpful!)
> tooltip which I honestly only noticed when making this screenshot. If
> you check my video, I didn't notice it when I actually wanted help!
> 
> Inline images 4
> 
> It would be better if the presence of good help is made more explicit
> like this (sorry for my bad art skills):
> Inline images 5
> 
> Signpost, when you first run Kicad. There could be periodic different
> hints (and an option to disable them altogether of course).
> 
> Inline images 6
> 
> Anyway, I'm glad everyone has found this interesting and hopefully
> useful! I may make a "Usability Project" page on the wiki with links to
> particularly glaring usability bugs.
> 
> Cheers,
> 
> Tim
>