KiCad user manual refresh - what topics do you most want to know about?

It wouldn’t be quite such a challenge if there was more help available, but a real problem is, as hinted by @eelik : who knows enough besides the developers?
I, for one, feel guilty that I just don’t know enough about 6.0 to raise my hand to assist with the manual, instead, just leaving the work to those very few developers.

I didn’t saw current documentation. I didn’t installed 5.99 yet (I don’t have Windows 10). So may be there is already done what I write here.
I think that for someone learning to use KiCad the most helpful will be well organised cheat sheet containing hot-keys. May be it should be separate 4-page pdf to be printed to have it at hand.
Under well organised I understand that it should help to find keys to be used in the state of work I am currently in and not to find what specified key does - so certainly not in alphabetic order.
I suggest to divide them into as many as can be logically justified groups (may be 2…3 level tree) and keys in each group ordered by expected frequency of use.
For example (using hotkeys from V5.1 (I don’t know changes to V6)):
in ‘Schematic - element placement’ group I see the hotkeys ‘A’, ‘P’, ‘M’, ‘C’ at the beginning,
in ‘Schematic - making connections’ I see ‘W’, ‘B’, ‘Z’, ‘L’ at the beginning,
in ‘PCB - routing’ I see ‘X’, ‘V’, ‘W/Shift+W’ at the beginning,
I think ‘routing-modifying’ should be separate group (D,G,U,I,…) and ‘modifying length’ also separate, may be as subgroup of modifying.
I think that what someone really needs (after reading the documentation) is such cheat-sheet. May be there should be separate cheat-sheet with only most frequently used keys (so that the beginner does not get lost in the mass of information he don’t needs at the beginning).

3 Likes

I think it would be possible for someone who has the time to spare and is otherwise comfortable with technical writing. I think someone who can take the time to “poke at” a certain KiCad feature in depth can probably write at least an 80% correct manual section about that feature, and then the developers only have to be asked about 20%. Non-developers could also help by flagging which sections from the existing manual are now obsolete in 5.99, which are unclear / in need of polish, etc.

It definitely would be some work, and I don’t necessarily expect to find that many people from the community are up for helping with it, but I wanted to mention anyway in case someone sees the post who does feel like they could assist with part of the process and wants to discuss with me the details and see if it could work.

By the way, while I don’t dispute this, I want to clarify that the user manual is intended to be reference material, and explicitly not a tutorial. We will look to the community (including this forum, and those people who create YouTube videos and blog posts about KiCad, etc) to create step-by-step tutorials and other content that goes beyond the reference manual.

Based on the recent traffic that I’ve seen here, detailed instructions for installing on the latest MacOS (or even various different MacOS versions) seems like it would be important. I don’t have a Mac so many of the instructions are obtuse to me, but it does seem to be a fairly frequent question. (And from what little I’ve been to understand, MacOS doesn’t go out of its way to make it easy either…)

This is true; one of the ways we are addressing it is to make some changes to how you install on MacOS, so once those are done, if it still is an issue we’ll definitely cover it.

1 Like

Some form of “whats new, whats changes” section.
A good thing to add would be where plugins/settings are stored (especially linux) since I am sure this will bite some people

4 Likes

I’d like to see an up to date KiCad cheatsheet. One page, how to layout. Most important commands, important: Keyboard shortcuts!

I found a video on how to combine pcb´s into one for manufacture, which doesn´t work for my install fedora33 kicad 5.1.10. I´d like a chapter on making panels to reduce pcb-setup-costs.

1 Like

KiCad doesn’t support panelization, so there’s no reason to describe it in the manual. There are workflows which help with that but hardly material for the manual. BTW, this is a recurring topic, the latest thread is How to replicate the same board in the panel PCB. It’s also in the FAQ.

1 Like

Thanks, Janek

I feel pretty much the same. I am not a “power user”. But perhaps I could do some review of the manual. When you want to find issues, you ought not let experts do all of your testing. The experts are less likely to be stymied by issues. You want to get some review/testing done by users with a lower skill level as they are more likely to get stuck somewhere. But in my case there are many features/aspects that I do not use. These include busses, impedance control & track length matching.

No matter what info is in the manual, it is of little use to anyone if you can’t find it. Above all, the manual needs an INDEX!

Thanks
bdh

I suggest more about importing, exporting and working with CAD files. That is where I get hung up every time. I don’t use these things often enough to become proficient or to get the processes burnt into neurons.

Another area is cross platform use. More details about what is different on Mac vs Windows vs Linux! If there are files that need to be accessed outside of KiCad, where are they?

Thanks for your effort
Jim Wagner
Oregon Research Electronics

1 Like

Is an index better than keyword search? (I am not sure). But I far prefer digesting technical information in a searchable electronic format rather than hard copy. Makes it much easier to find information. I think that indexes often seem to omit (just what I am looking for) that is contained in the text.

But to get back to the core question; mainly for schematic capture; I am trying to remember how to de-select symbols or wires from a window selected group. I saw that posted somewhere but cannot find it…

IMHO index is better. Keywords are good if you know the technical terms used in a program, but if you are not sure of a term used, indexes are an easier way to eliminate what you are not looking for.

Bus naming, bus entries and hierarchical bus connections documentation seems to need some love.

1 Like

I think an explanation of the custom DRC rules is completely missing.

I have a vague memory of gitlab of a promise by one of the people who implemented the rules to at least write a short section about it.

The custom design rules are already fairly well documented at https://docs.kicad.org/master/en/pcbnew/pcbnew.html - please note anything that you find missing.

1 Like

As we are moving to the primary format of the documentation being a website, I’m not sure how much an index makes sense (vs. search). An index to me is most useful in a printed manual where you can refer to page numbers. Open to ideas here (either on how an index could be useful on a website, or on how we can make search better)

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.