My apologies for the length of this post. I’m thinking out loud here… But, in all reality, by now you, dear reader, should be expecting posts this long from me.
As far as differentiating local labels from text elements, the color should be a good indicator. (Of course, that does mean that the reader needs to know the color coding used in KiCAD), I’m not sure how consistent KiCAD’s default coloring of features is to other programs, and at least for local viewing (and screen shots) those colors are user customizable.
Hey, those who have customized your colors in EESchema, are those color customizations honored when printing/plotting in color? Or, are the default colors used on prints/plots?
I was recently thinking something similar, but for a different reason. Both sheet and global labels have an option for indicating signal direction. Local labels don’t. We all have recently been seeing newbies posting projects for advice and they seem to prefer global labels. I don’t know for sure, but my assumption is because they can add to the label directional information to help think about the logic of the circuit.
I’m not sure, but I don’t think that the label type is evaluated at ERC so the differently shaped glyphs are informational only. For reference here are the label types: (Yes, what I’m calling “Sheet” labels are really “Hierarchical” labels. I’m just being lazy by only having to try to spell that word once…)
My not quite fully formed idea is to suggest keeping everything about the local label the same except adding directional glyphs where the connection point is.
Like the other label types, the glyph should be the same color as the label to visually link them (at least on color screens and color printouts.) To differentiate the local label glyphs from the sheet glyps, I’m thinking open glyphs. For example (in the above orientation) for an input use two greater-than symbols “>>” with the connection point on the furthest part of the glyph from the text (to help indicate the intent to drop this label along a wire, but still look good on the end of a wire segment). For bidirectional and tri-state use both a greater-than and less-than symbol with normal typographic kerning between the two: “<>”. For passive, two vertical bars (to differentiate it from what might look like a small cross) “||”, or have no glyph for passive type to give an option to not use a glyph for people who don’t want them.
Or maybe the local labels shouldn’t use “input” and “output” for directionality. I mean, if you have a wire connecting an input pin to an output pin and dropped a label in the middle of the wire, calling the label input or output really doesn’t make sense. Maybe instead of the regular types, the glyps for local labels should be called “flow indicators” or similar wording. Just offer “Left”, “Right”, “Both”, and “No Indication” and have the directionality referenced off of the reading flow of the label text for labels rotated vertically. If using this method, “No Indication” should be the default, especially when importing an older schematic that doesn’t have this feature.
I’m not sure if I would go with moving the connection point vertically justified in the center of the text. Often one wants to label a connection that is made with a wire on a schematic without breaking the wire. This is so one can easily find that net in PCBNew either for assigning a specific netclass, or just so one can pay attention to the specific routing of that signal. It is really awkward to use global labels like this because of the placement of the connection point relative to the baseline of the text. Think of feeding a signal (or address) bus to a busline. You want the wires close together for visual association and space saving, but each line needs to be individually labeled to differentiate (for example) Data3 from Data7 at all the bus breakouts. With default settings, the current local labels fit perfectly between two wires spaced 0.1" apart.
Be careful what you ask for, or you might get something like the above.
Great thoughts. Thanks for taking the time to express them thoroughly.
Personally, I find that a simple color pallet helps to express information on a computer display. I would limit it to no more than half a dozen distinct colors, max. I find it frustrating (and makes me angry) if I need to distinguish between, say, “Green”, “Teal”, “Emerald”, etc. Or differentiate based on the characteristic sometimes called “saturation”.
But when I move from computer display to paper copies . . . . the great majority of printing is done in monochrome. Yea, verily, as I sit at this workstation at this very moment, my computer monitor has a schematic in one window, and two paper copies of that schematic are on the worktable. (The paper copies are annotated with measured values, waveforms, thoughts and ideas, summaries of calculations, etc.) OK, so I’m the superannuated guy who started work when blueprints were blue, and smelled of ammonia from the reproduction process. But I see co-workers half my age doing the same things.
My point is, don’t depend on color to be the primary way to distinguish types of labels. I think you agree, which is why you selected several graphic shapes to go along with the colors. Yeah, they bear a resemblance to the graphics in a certain commercial simulation program, and I wonder if there is either a formal standard, or a de facto gentlemen’s agreement among CAD/CAE developers regarding what the shapes should be and how they are used.
As an alternative to your ideas, I might propose that the same shapes could be used for two of the symbol groups (“Global” and “Sheet”; or “Sheet” and “Local”) but make the shape outlines either solid lines, or dashed. Maybe even solid, dashed, and dotted, though that’s getting similar to the problems with “Green”, “Teal” and “Emerald”.
One instructor in college said he saw far superior proposals get passed over in favor of ones with better ‘sales’ formats. In addition to conveying a designers ideas as clearly as possible the software takes on even more meaning past that I’m afraid but not something to be discounted in laying out the software design either.