Maybe a turkey sacrifice is more appropriate given it’s thanksgiving (well, for you Americans at least).
3 Likes
Generic names would be better, but good reason have been given here why they should be recognizable in all contexts (e.g. several EDA software installed). Very good discussion indeed.
1 Like
Only just saw this thread. I look at this in terms of UI/UX and marketing.
Generic naming should be used so that Kicad looks integrated and complete. The current naming makes Kicad look like it is composed of random fragments of software rather than a monolithic designed system. No one should ever need to think about the names of the elements because they should be so self explanatory that they are just seen as steps in using the primary purpose of the software.
This should be a change before v5 rolls out and just get it done. Your new market share will thank you (or not because they should never need to think about random names!)
1 Like
After some thinking - generic “Board editor”, “Schematics editor” etc. would be OK for the UI and documentation. For those who love process trees or have to package software or otherwise like technical details the executable file names could be e.g. kischem, kiboard, kigerb etc. Short, punchy, self-evident, branded. But they could be kept off from UI, docs etc.
Just try to keep the user visible names short, too. Not “PCB board editor”, it’s redundant. “Gerber file viewer” is also unnecessary, “Gerber viewer” is enough.
As a former open source project developer I understand how developers grow attached to technical terms, bad usability etc. As an end user and as someone who has studied usability as part of University studies I understand that in usability and UX issues we dummy, stupid end users are always right. The first impression is important, technical and incomprehensible vocabulary should be kept at minimum. Sometimes good UX means great sacrifices for the developers, both in workload and at emotional level. Developers and technically oriented users who have grown to love their software tend to think that this and that is part of the brand, while in reality the best brand is being as unobtrusive, simple and welcoming as possible (as Apple tries to do).
1 Like
Remember, this is a multi-lingual effort. That adds to the complexity of naming things. I think just a short while ago the icons were looked at to address this very issue. Personally I don’t think in terms of Eeschma and PCBnew. I just know which icon to click.
1 Like
I don’t see why multilinguality would add complexity. In the project I was working on I wrote much (imperfect) English and translated the whole UI to Finnish. Translators must be creative and not translate slavishly. Proper names are not translated whether they are stupid like PvcPcb (or whatever our infamous example was) or human readable like OpenOffice. Descriptive names like Board Editor can be translated more or less freely to fit the receptor language. It’s not much more difficult than translating any UI text, although you may need to pay more attention because you are stuck with what you choose and it’s spread all over the UI, documentation and internet.
1 Like
It’s an important distinction to make: the executable names, and the display name in the UI.
The display name in the UI should be generic and function based so it can be translated correctly and still make sense. This eases use for other language users. The standardisation of the language used in Kicad is a whole other problem but is definitely linked to this. An agreed lexicon and/or taxonomy for Kicad terms and names would probably assist with this.
The executable names probably don’t matter too much, but I am a fan of naming them generically as well with the Ki- prefix attached to make them unique for OSes and users who need to trigger them individually, but still genericised so that it is clear they are a part of the Kicad design software package.