Documentation organisation on docs.kicad.org

IMO, the documentation could benefit from reorganisation.

When one lands on the starting page the top 3 items are Introduction, Getting Started in KiCad, and KiCad. That’s roughtly the order they should be read in.

IMO Introduction is a short document and could be merged into KiCad, and maybe it should be clearer Getting Started in KiCad is a tutorial, maybe call it Start Here to make it more imperative.

I think the Symbol Editor and Footprint Editors deserve documents of their own now. They have top level icons in the project manager. They should be inserted after the Schematic Editor and Layout Editor respectively.

3 Likes

Some vague thoughts as the main person working on docs…

I sort of agree about the intro section, in that I don’t love that it’s a separate document and I don’t think it currently really includes enough information at present to justify being its own thing or to justify advertising it and getting anyone to read it, but I also don’t think it fully belongs in the KiCad section as that’s mostly about the project manager itself. Some of its content could go into KiCad (the overview of each application, for example), while other parts could be moved/repeated in each application manual (overview of KiCad’s UI model, for example), while other parts don’t really belong in any existing location other than where they are now (new feature list, for example). So I don’t have a neat plan for improving that, other than potentially splitting it up.

For what it’s worth we have an issue tracking this, but truthfully it’s fairly low priority for me to sort out compared to other documentation updates I’m working on.

As for symbol/footprint editors, I hear you and I’ve considered separating them as well, but I go back and forth on it. Those sections are fairly tightly tied into the respective “main” editor documentation and we rely on those sections to explain some schematic/pcb editor concepts, particularly with regard to symbol/footprint properties. The reverse is also true, as the symbol/footprint editor sections point to the main editor docs for explaining drawing tools, array tools, etc. I do intend to at least “promote” the symbol/footprint editor sections up a level in the hierarchy, so they’re easier to find and you can take better advantage of the table of contents, so that should help even if they don’t get their own full chapter.

I know those are some wishy-washy responses but you’ve hit on a few things I’ve thought about a decent amount without arriving at many conclusions. I do appreciate the feedback. I’m happy to chat more if you have thoughts.

1 Like

How about this:

Move the installation directions in Introduction to Start Here, as installing KiCad is often the first barrier. The glossary could also go here to help newbies use the standard terminology. Essentially Start Here becomes the intro.

New feature list could go into a new document What’s New in KiCad N, for those who want a quick summary of changes. It could be a cumulative document containing What’s New in KiCad N-1, and further back.

Rename KiCad to Project Manager.

Good to see the Symbol and Footprint Editors get more prominence.

Also, is there a way to get the HTML to make Discourse show the section name in the preview instead of a generic preview of the whole document. Would make it easier to see the relevance of a link to a section.

I was reading KiCad documentation only once and it was in theory V4 documentation and practically it was about V3. My knowledge about what is in documentation now is close to 0.
In my opinion you can think of symbol edition as a kind of preparation to do schematics and footprint edition as a kind of preparation to PCB edition.
Thinking that way they can be positioned at the beginning of relevant documentations. I think that you need not to know a lot about schematic edition (except need to position pins in raster) to describe how symbols are done and need not to know a lot about PCB design to describe footprint design.
My approach may be a bit distorted because when I started my adventure with KiCad, I first created my libraries and only then drew the schematic and PCB.

I needed to look at the 5.1 documentation index and noticed that the Introduction first appeared in 6.0. So that’s a point for moving its contents to other documents.