Too much stuff is hidden under context sensitive RMB?

Community Feature Request Chat
1

I would like community opinions on the discoverability user interface. But first try to not think of this as it works for me. Obviously it does since your using the software. But try to think how a new users sees this.

So seems to me that the case sensitive RMB button menu has become over time a bit overloaded. While at the same time the main menu has become a bit underwhelming. The problem with this is:

  • discoverability of features suffer since the RMB menu is case sensitive. So it makes it hard to have a overview of what one can do
  • And the RMB menu is starting to be a bit on the heavy side. For example nightly fom fewweeks ago has more than 50 entries in the rmb menu. Some that can only be found there

Personally i also find that using things like rmb → shape modification → fillet or the rmb → positioning tools → move with reference is a bit cumbersome for this exact reason. So for example positioning tools should possibly be duplicated in the edit menu.

Also while we are at it some of the tools are modal unnecessarily for example:

  • Move item window could easily be non modal
  • Same for create polygon form selection
  • Fillet lines
  • Tuning pattern properties
  • …

Okay so i know now your saying that this isnt really high priority* and shouldn’t stop people form developing new tools. Sure, its not a either or thing. This is a good opportunity to enlist new devs to do just this.

Anyway, i will just leave you with a thought that one of the the most successful open source tool with user interface tool is currently Blender. And they really suffered until the made the changes to make the program less quirky (it still is but at least they made the effort to remove the quirks) and their user base skyrocketed. And they now have a lot more Dev power as a result.

* that’s the way the forum hangs i suppose.

2

I’m not sure I agree here, but maybe I have been using Kicad for too long. I also have not used recent nightlies, so I don’t know how “bad” it has become, but functions have to be put somewhere, and the context menus (“case sensitive” is something else), generally require less mouse movements then going to the main menu. KiCad is also loosing it’s simplicity and becoming a powerful but also more complicated program. Less often used functions such as the positioning tools have to be tugged away somewhere.

A part of the “problem” is also the way KiCad is being developed as an Open source program. Improvements for the menu structure, such as configurable button bars have been in the pipeline for a long time, but there are many more functions and ideas waiting on github for someone to implement them, then the developers have time available to implement them. And working on new features is also more exciting and fun then re-implementing a menu system (although for some people that may be just what they like to do). I am guessing that new implemented functions are developing faster then the menu system and they are piling up in the menu’s to be moved later to a more permanent place.

Edit: I’m also just a user and craftyjon (below) knows much more about KiCad development then I do. Mabye it was not clear from what I wrote above, but I do like the modal menu system.

I also fully support the Idea of making KiCad fit to be used by “professionals” (and also being usable by hobbyists) instead of aiming for hobbyists, and never reach the level of capabilities required by the “professionals”.

3

Yeah obviously they have to be somewhere. And yes i agree that devs might not want to deal with this. Tahts why there needs t be a better strategy perhaps.

4

The number of RMB functions on 8.0.5 PCB editor, under the cursor, is 24. For 8.99, the current number is 22.
23 on each for Schematic.

Reading comments on Gitlab for quite some time I get the impression that effort is made to place functions suitably within the current system.

A new system?
I don’t know about that. I do know that a cooling unit will need to be installed in the forum if a new menu system was introduced, remembering the reaction to the Icon changes in Kicad 6. :wink:

1 Like
5

Making any of these non-modal would be quite complex. They are modal because they capture the current state of the design and then push their modifications back to the board when accepted. Non-modal dialogs need to have real-time back and forth. Non-modal dialogs are also typically only used for actions that tend to be done over and over again. I’m not sure the examples you give fit this paradigm.

3 Likes
6

I don’t think this actually reflects what happens.

  • As JMK mentioned, we do actually put a bit of thought into where things go in the menus, to try to keep them manageable
  • But, KiCad is a complex CAD tool that can do many things and has many functions. Many of these functions are also contextual: they only work in certain situations or when certain things are selected. This is why they appear in context menus.
  • While it probably does happen sometimes that people prioritize things that are “fun”, this only actually happens when the fun things also align with our overall development goals. We tend to prioritize working on things that will help KiCad be adopted by more professional users and be useful for more different types of PCB design – things that are impossible or inefficient in KiCad today. KiCad is still playing catch-up in some areas to paid PCB design software, and we want to address those gaps first. We do put a lot of thought and effort into making KiCad as easy to use as possible given the goals of being a full-featured professional tool, and we already have removed a lot of the “quirks” of older KiCad versions that made it different from other software that accomplishes the same tasks. I think we will continue to prioritize that kind of UX work, but context menus that have actions that apply to the currently-selected kinds of objects is not a quirk in my opinion – it is a well-used concept across many different kinds of software.
10 Likes
7

Nice, I was really talking about where next not about a justification of what exists. Clearly what is currently there, is what is currently there.

Thank you for explaining how modal dialogs should work. Its just that this isn’t true none of:

  • move item,
  • create polygon form selection,
  • fillet lines,

have complex state! Lets do some proof on this by looking at kicads own dialogs. The Position Relative To Reference is non-modal while Move Item is modal, the former arguably having more complex state so as per your logic should be modal!

dialogs
dialogs783Ă—223 8.89 KB

Image 1: Position relative to reference dialog is non-modal while move item is modal

From a user interface point of view that is inconsistent. In reality the Move Item and Position Relative To Reference should probably be one dialog that is non-modal.

Similarity KiCAD makes things selection sensitive even in cases where it does not make sense. For example the Position Relative To Reference is not available when nothing is selected, but does not require a selection. Now it should probably live also in the edit menu. It can be in the RMB menu off course but it should also live elsewhere for discovery reasons. Also no selection is just a special case of something selected.

Again example form the GUI, the place menu neatly nearly duplicates the toolbar (see image 2). As per your logic should that be removed? Consistency states that the tools that are only in the RMB menu should also find themselves in the menu system.

dialogs2
dialogs2347Ă—661 19.5 KB

Image 2: Tools and actions should both live in the menu system as well as other part of the GUI.

And:

As JMK mentioned, we do actually put a bit of thought into where things go in the menus, to try to keep them manageable

If so, where is KiCAD’s user interface style manual? So that I can start fixing your UX issues as per your style guide. I am not asking any of you to do it. I can do this kind of stuff, just point me on the way so that i can get it done as per you master plan.

@jmk

The number of RMB functions on 8.0.5 PCB editor, under the cursor, is 24. For 8.99, the current number is 22.

Maybe on main level. But new users need to read all sub-menus at some point, for each selection type separately for discovering what tools they have. So in KiCAD 8.0.5 there are more than 50 menu items under a line selection for example (see image 3). Situation is getting worse in KiCAD 8.99

dialogs4
dialogs41076Ă—765 61 KB

Image 3: Situation for shapes in KiCAD 8.0.5

Fixing these kinds of things will makes things way better on the long run.

8

Sorry, my only comment is “That’s what happens with a complicated program with a lot of features”.

To me, personally, this does not look too bad.
All the precision movements are grouped.
All the line edits are grouped.
Creating from selections are grouped.
etc.

To me, this is much more manageable than several rows of icons over the top of the screen and more at the bottom that I forget to notice.
I find lists far easier to negotiate than icons.

JMHO

9

I dont disagree entirely with you. Icon toolbars are probably not the way to go. I’m just trying to come up with a strategy that does:

  • provide discoverability irrespective of users selection
  • that provides a way to deal with beyond doubling of complexity, imagine same menu with 100-200 items
  • that is as self consistent as possible
  • remove redundancies where duplication of effort is not strictly justified
  • provide a framework for actions to coexist with tool initiated actions
  • removing sub menus with 2 items

I don’t think KiCAD is really a complex software. Nearly all tools that i use daily are as complex or a magnitude or two more complex than KiCAD. Well, except notepad.

10

We don’t have a written style guide that answers all your questions. We do this by discussion and consensus. If you want to change things here, open a GitLab issue describing your proposal in detail, and the team can discuss it there. Coming at it with the attitude that things are broken and need to be fixed isn’t the best idea, though. Even if you disagree with the choices that have been made, you should treat them respectfully as choices someone else made for a reason, not “bugs” to be fixed.

I don’t think the team agrees with this. Our past discussions have generally held that highly contextual actions (ones that only can work when certain things are selected, for example) are best placed in context menus, and not in toolbars or system menus which show them all the time.

This is just a bug – neither of them can work in non-modal mode. If you try using Position Relative as a “non-modal” dialog you will find that it probably doesn’t work the way you expect.

This dialog does actually require something to be selected.

Both the main menu (of which the Place menu is a part) and the toolbar are non-contextual. There is intentionally duplication between these two at the moment. Space on the toolbar is much more limited, though, so less common actions are located only in the main menu and not in the toolbars. We have no such consistency rules about RMB menu actions – many of those actions are contextual, and therefore they should not show up in the toolbar or main menu.

There are already ways people can discover actions that are contextual other than selecting and right-clicking items:

  • Reading the manual
  • Looking at the list of hotkeys
  • Taking classes, watching video tutorials, etc.

I don’t think we will agree that this is insufficient and so all contextual actions that are in a context menu today should also be added to the main menu or toolbars.

11

Coming at it with the attitude that things are broken and need to be fixed isn’t the best idea, though

I didn’t say it was broken, i asked if it was broken. To me it feels like broken long term strategy.

This dialog does actually require something to be selected.

Well, theres no need for that, not really. None of the dialogs require the state to be correct up front just as long as the selection state is okay or empty when you execute the ok button (which is always). It is very easy to do (might not be easy in your code base but is objectively easy nonetheless,.its like converting a loop to tail recursion).

I have already prototype the move item dialog that does this im currently thinking of ways to combine the dialogs, maybe even the . It doesn’t look correct at the moment because in not well versed in styling wxpython*. So its not terribly good looking like the real deal (mainly the close button looks wrong). I will start doing user A-B testing in few weeks on students.

We have no such consistency rules about RMB menu actions – many of those actions are contextual, and therefore they should not show up in the toolbar or main menu.

I does there need to be a strategy? Your increasing capabilities considerably, you don’t have much more room to grow.

Anyway UI design and UI ergonomics is not about what it feels like its about actually getting feedback from measured actions of users. Right now students (not conclusive i only have a sample of 80 potential new users) are reporting to me not really wanting to use KiCAD. instead opting for other tools.

* reason for doing it with wxPython is i can prototype without compiling. Only i have no acces to top level menus. But i guess its possible.

12

OK. If you would like to propose a change here, the right place is on GitLab. If it is very easy to do, it should also be very easy to open a discussion about why you want to do it and talk it through with the team.

Maybe. Do you have a specific proposal? If so, again, opening a GitLab issue is the right next step. We have discussed removing some of the non-contextual actions from the context menu (such as the Zoom sub-menu) but it hasn’t happened yet.

13

OK. If you would like to propose a change here, the right place is on GitLab. If it is very easy to do, it should also be very easy to open a discussion about why you want to do it and talk it through with the team.

No its not really easy. You can open a ticket but its almost always shot down immediately as a copy of something, thats probably is not a copy.

(such as the Zoom sub-menu)

Yes please. it does not really make all that much sense. But is also really far away in the menu at all times.

14

If you link to some examples of issues that were closed as duplicates but that you think are not actually duplicates, we can certainly review. We try to consolidate issues that are similar where possible, but sometimes we get it wrong.

Issues that are closed can always be re-opened. You can also comment directly on closed issues that you think were closed incorrectly.

15

This interests me.

What other tools and why other tools?

1 Like
16

I edited away an unnecessary part of the discussion. @joojala, I have felt that you have been quite aggressive in your posts. Filter them beforehand.

17

why other tools?

I don’t know, really. But i have a hunch:

The current student meta seems to be related to the way KiCAD does the footprint database. There is this built in assumption in many students that everything has been done. There seems to a a quite pervasive idea that one can avoid responsibility if one uses a download. Now if something is not in the standard library they automatically gravitate to download which causes them lots of problems.

Ive seen at least 4 students rage quit kicad this year. I’m not always exactly present so if i see 4 there is bound to be lot more of where that came

18

Good question. That’s quite sweeping claim and requires some details – have the students found something specific to be too difficult or clumsy? Or have you (joojala) just interpreted their generic frustration and/or difficulties in the learning curve and located them to your own opinions/frustrations?

Personally I find KiCad usability quite good. Not perfect, not necessarily top grade in every respect, but still quite good. Yet I see merit in this specific viewpoint about overloaded menus/toolbars etc. although I don’t see anything being out of control. The discussion is welcome.

Unfortunately I haven’t been able to spend time with KiCad as much as some years ago and have partly lost touch with the details, otherwise I could give more thought to these details. I have worked with v8 in recent months and the menus haven’t popped up (no pun intended) as a hindrance or even a slight frustration. Sometimes over the years I have felt the main context menu is too crowded, and now when I look at it I can see at least some room for enhancement. For example in the PCB editor:

  • Select All and Unselect All are unnecessary in the context menu. Universally, across different kinds of software, these are found in the main menu bar → Edit menu and can be easily accessed there.
  • Zoom and Grid are unnecessary there, too. They are good and logical when nothing is selected and the menu is opened on the canvas, but how much they are really needed in the context menu when something has been selected? Even when something is selected, they are directly accessible under the main toolbar.
2 Likes
19

I think i would need to measure this. But i have no idea on how to statistically approach the measurement. What i do know is tat the same time the learning curve of kicad isn’t all that big as most students know how to use: Illustrator, Rhino, Solidworks on a reasonable level.

Though the problem can also be that they don’t design mostly pcb’s. Although that’s mostly all they do in my area.

On the menu. I feel like sub menus with less than 2 or maybe 3 items are pointless. Locking menu probably could all be in the main level. Especially if the last 4 items are dropped.

20

Ahhh, the old “Creating Personal Libraries and needing to edit badly drawn 3rd. party symbols/footprints problem”. :grinning:

I can understand the student’s problems: Not only do they have to learn the Schematic & PCB programs, but there are those other two extra learning curves; the Footprint & Symbol Editors. And none have quick fixes!!! :frowning_face:

Sorry, I shouldn’t write in such a mean fashion towards your students.

I also find it amazing the huge number of comments on this forum by people who will go out of their way to spend; maybe, hours, looking for 3rd party symbols and footprints to download and use on a project.

I’m not sure what the solution is to this problem.

Perhaps there is confusion in the creation of Personal Libraries. That shouldn’t be so if the new Kicad documents are read. I also wrote a guide in real beginners terms in the FAQs. Maybe you could copy these and distribute them to your students?

Learning to draw symbols and footprints needs a little ingenuity and imagination to get good results with the available tools. I do think Kicad could benefit from some sort of guide on what and how to use the given tools: another “tips & tricks” guide. A good way to start is to place a Kicad library item into its Editor and deconstruct it to see how that item is made.