More "descriptions"! Why does nobody care?

Interesting topic. My answer to “why does nobody care” is basically as mf_ibfeew put it.

Many moons ago I was primarily a software developer. I lived and breathed comments and docs. I always explained myself and left notes documenting the design intent and considerations for future users.

When I was introduced to schematic capture I was shocked at how bare the artefacts were. You had to determine Zener voltages from their part numbers, figure out the truth table of a discrete logic circuit from the simulation, work out the difference between the SOIC14P127_865X600X175L83X41N and SOIC14P127_865X600X175L83X41M footprints based on their name.

I accepted it as “the way” for a while, then eventually started my own business and got to define conventions from scratch. Now my staff create schematics with comments, notes, tables and design details, and my work is a little richer and more rewarding.

But I still look at description fields and think “this will not support much”. Much of my experience is with Altium and KiCad, and so I’ve always looked at those fields and thought of them as very lightweight. I don’t expect much of them and they don’t give me much. They squeeze into tables and BOMs and picker dialogs and show up here and there without too much fuss or bother. Your post has made me realise I’ve internalised them as “not the place for documentation”.

Now I’m using a database library, I casually added a “Notes” field and oh boy have I found it useful! DB libraries are not an answer to your question, I know, but the revelation is that if I can link from an artefact (a symbol, a library, whatever) to a dedicated documentation tool, then I can have the richness that documentation deserves.

So I suppose the reason I don’t care, is that I think there ought to be a better place for documentation. You’ve made me care a bit more though.

2 Likes

it’s important to differentiate between the description of a library element like a footprint and the description of a component in the design.

A footprint has two “descriptions”:

  • The “footprint description property” resembling the footprint itself,
  • The “Description” footprint field describing the component in the design.

The description in the design is not the weakness I’m targeting with this thread. This is often set or refined after adding the component from a library.

My intention is a better documentation of libraries.

BTW: A symbol has no description property at all, just the description field. But symbols do normally not require so much explanation so this acceptable.

Really inconvenient and error-prone is that the description of a whole library is not bound to the library but hidden in a “per computer” configuration file.

It’s actually per user.

I get alarmed when too many fields are available, embedding malware has to be guarded against and there might be copyright violations.

I have a checklist for footprints.
There it is explained what to check and how to check it.
Any deviations or additional information is captured there.
Then you can link that checklist file to the footprints