[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Emacs User Survey 2020 Results

From: Jean Louis
Subject: Re: Emacs User Survey 2020 Results
Date: Thu, 10 Dec 2020 01:20:51 +0300
User-agent: Mutt/2.0 (3d08634) (2020-11-07)

* Adrien Brochard <abrochard@gmx.com> [2020-12-10 00:39]:
> Let's just chill about Matlab please. There was no Matlab involved
> here.  I'm 100% against Matlab.

What I know is that there was link with Matlab, after my comment there
is no such link any more. Maybe it was what it was. Or was not there
at all? If it was not there, then why would I be mentioning it? And
why would you mentioning it back. I do not mind any more as it is
really not there.
> > > Now, the choice of Google forms is not great, but nobody forced anybody
> > > to fill in the survey, and nobody has the right or authority to decide
> > > with which software people get to use the name of Emacs with. That sort
> > > of language policing is easily fascistic, whatever the yardstick looks
> > > like.  Also, looking over your email again, I see no link to any online
> > > survey tools that could replace the use of Google Forms here.
> Also no Google forms involved. I used Jotform which is not free software
> indeed, but much more compliant (HIPAA for example). But also correct
> that nobody was forced and email answers were an option specifically for
> that purpose.

So why not make your own HTML? It is very simple to make it especially
when editing in any text editor.

Do you have logical reason to use Javascript? I have not seen
any. Javascript on forms is used when user would dynamically add some
lines of text, let us say additional checkboxes or similar. I have not
seen anything complex in your form. Just ask, I would help you to make
the form right.

>From your website:

> Why does the online form use Javascript?
> It is true that it is possible to do an online form with no Javascript
> at all. However, I think that Javascript contributes overall to a much
> better experience. For example, it offers better feedback regarding
> input validation and saves the user session in case of browser
> crash.

I did not see nothing that contribute to better experience. I have
seen simple, not complex form with repetitive check boxes, questions,
etc. All can be done with any editor within 20-30 minutes. One has to
know basic HTML. In general, I must say that I find it funny
entertaining project of you as it is related to Emacs that we like and

Regarding better feedback regarding input validation, we worked with
input validation 15 and 20 years back. Those issues are solved in
majority programming languages handling server side inputs. And if
user turns off javascript, what input validation you get if you rely
on Javascript only? None.

Additionally this problem has been solved in HTML5 since quite some
time, so you may directly validate input with tags, please see here:

Saving user session if browser crushes? I think one good reason that
browser could crush today is some wrong Javascript, but HTML
hardly. Anyway that browser crushing stuff does not really look as
good justification.

In general I would expect Emacs user survey to be usable with eww, and
probably it was, I did not try it. But that would be good design goal.

> My position is that filling out the survey should be as pleasant as
> possbile. People are choosing to spend their time to do it, we
> should not ask for more if asking for less is possible.

Not impressed on that. Keep your persistence, as I do not mean it
bad. It does not justify nothing. You could at least ask people and I
would give you or even make that for you. 

> Also, a no-Javascript solution means a homemade solution as all big
> online forms platform use Javascript.

What is wrong with homemade solutions? Emacs survey is simple website
and there is no need to compare your website to other websites. It is
successful and would be anyway successful without it.

> And to me that is just not an option at this point. I am web
> developer during the day and I know how much time it would cost to
> build a reliable online survey solution and monitor it during the
> six weeks the survey runs for. That is simply not a price I am
> willing to pay, and I find it a much better deal to turn to an
> online platform that will be safer and much more reliable.

Due to my experience I cannot see why it would cost much. Not more
than maybe few hours of work on which work you have spent probably
days. It is also matter of which programming languages you know or not
know. Maybe Javascript is not so good for server side solution. I have
no idea about Javascript and never used it for anything. But I do know
there is json format and just maybe, by guessing, I think Javascript
could convert the form element data into json structure and submit as
a simple POST. On the server side the POST data could be saved into
simple file. Finished there. Later you just run the conversion program
over all the files to get the csv or what other data for graphical

I would not torture me with it. Since two decades I have been using
generic form that accepts any kind of form data and sends by
email. Later I have rewritten it to Common Lisp and save data into
encrypted files. If data is in Lisp or any other structure, it is easy
to iterate over such to form anything else like CSV or even to import
it into SQL database.

Emacs CGI package also exists, it can accept data from online form.

There is Perl CGI, form validators, you name it on CPAN Perl
archive. It supports sessions without end, multi pages forms and so
on, and is simple to setup.

That is why, technically your justifications do not hold. 

I am taking it so that you like and prefer Javascript. That would be
much better explanation. 

> > German quality LimeSurvey is free software:
> > https://demo.limesurvey.org/index.php?r=admin/authentication/sa/login
> I did look at them. Their hosted version is prohibitively expensive for
> the volume we had. And I am not willing to self-host.

You have a website, so you are already self-hosting and you are


reply via email to

[Prev in Thread] Current Thread [Next in Thread]