kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hi Nick,

Am 25.04.20 um 12:58 schrieb Nick Østergaard:
> I don't think we gain anything by adding more complexity to the
> download page. It is after all just a download page.

I can't follow your reasoning here. Please pick up the users there they 
are and not there you think they are.
Writing some good explanations even for the MacOS users isn't that hard 
I'd say.

> If we really need to do very step-by-step and verbose explanations for
> those can't can't read the README in the installer,

Well, you've wrote "in the installer", so users might have some chicken 
/ egg problem here. You know you've done it wrong if you have broken it. 
It doesn't help users if you say them afterwards they did it wrong, this 
something they already know. Writing up same sharped sentences for MacOS 
users on the Download page what they need to do right before they start 
to download anything is better. Try to have a view from a users point of 
view who hasn't done any thing with KiCad before. We all here are quit 
deep in the software, project and so on and know how everything is 
working, but think back to the days once you started with KiCad.

> I think that is better suited in a chapter of the documentation,
> possible as a big section in the Getting Started in KiCad doc. Having
> it in the documentation will also make it easier to translate.
For sure this is some useful thing, but do you really think *most* of 
the users do really read some bigger documentation first before they 
install some software? :-)
You only have about 20-30 seconds off attention if people land on the 
Download page (or any other web page). So better you remember this 
always and try to transfer the needed knowledge within that time span. 
But its' easy to point to the relevant part of documentation there you 
can explain things more in deep.

> Also, don't forget that as it is now works for all other people, than
> a small handful of people. We can't help everyone always.

The smaller part of people or users that aren't satisfied can make some 
bigger damage on a project than the broader "normal" audience. So try to 
keep this one group of people, that you will never serve completely, 
always small as possible.

--
Regards
Carsten Schoenert