path: root/2021/captions/emacsconf-2021-design--on-the-design-of-text-editors--nicolas-p-rougier--main.vtt

WEBVTT

00:00.880 --> 00:02.386
Good afternoon. I'm Nicolas Rougier,

00:02.386 --> 00:04.080
and today I would like to present some of

00:04.080 --> 00:06.560
the experiments I've made with Emacs.

00:06.560 --> 00:08.400
My initial motivation was an

00:08.400 --> 00:09.920
inner feeling that something was

00:09.920 --> 00:12.559
wrong with most modern editors,

00:12.559 --> 00:14.559
and before I show you my experiment,

00:14.559 --> 00:16.004
I will try to demonstrate

00:16.004 --> 00:17.440
what I think is wrong.

00:17.440 --> 00:18.720
Note that this is mostly my

00:18.720 --> 00:20.640
personal feelings and I did not commit

00:20.640 --> 00:23.279
any experiment to test is this or

00:23.279 --> 00:25.279
that choice would be better.

00:25.279 --> 00:26.781
Of course, some of you might

00:26.781 --> 00:30.480
legitimately disagree with me.

00:30.480 --> 00:32.399
Let's start with a short review of a

00:32.399 --> 00:35.160
modern text editor. I chose Nova editor

00:35.160 --> 00:37.680
that is only available on OS X,

00:37.680 --> 00:39.920
but there are actually many other very

00:39.920 --> 00:42.960
similar editors, such as, for example,

00:42.960 --> 00:45.680
Atom, Sublime Text, or Visual Studio.

00:45.680 --> 00:47.760
Now it's quite interesting because I think

00:47.760 --> 00:50.239
it manages to gather everything what is

00:50.239 --> 00:53.120
wrong in this single screenshot that is

00:53.120 --> 00:55.920
also the teaser image on their website.

00:55.920 --> 00:58.160
So let me now review it according to my

00:58.160 --> 01:01.039
personal biases and for further analysis

01:01.039 --> 01:02.667
I can only recommend to attend

01:02.667 --> 01:05.680
David Wilson's talks tomorrow.

01:05.680 --> 01:07.360
The most (inaudible) thing that really

01:07.360 --> 01:11.583
bothers me is the actual area dedicated

01:11.583 --> 01:13.504
to the editing. When you measure

01:13.504 --> 01:15.553
this editing area as I did on the

01:15.553 --> 01:19.112
screenshot, you'll find an impressive 35%,

01:19.112 --> 01:22.316
which is ridiculously small

01:22.316 --> 01:24.240
compared to the side of the window.

01:24.240 --> 01:26.320
This means that two-thirds of the window

01:26.320 --> 01:30.079
area is dedicated to peripheral information

01:30.079 --> 01:32.079
that you don't look so often

01:32.079 --> 01:34.159
when writing code or prose.

01:34.159 --> 01:36.560
This results in the main editing area to

01:36.560 --> 01:39.119
be reduced to one third even if we tend

01:39.119 --> 01:42.040
to have larger and larger monitors, I think

01:42.040 --> 01:45.600
this is wrong to lost so much of space.

01:45.600 --> 01:47.759
If we now look closer at this peripheral

01:47.759 --> 01:49.920
information, we can immediately see that

01:49.920 --> 01:52.079
there is a lot of redundancy.

01:52.079 --> 01:53.617
For example, on the screenshot,

01:53.617 --> 01:55.709
I highlighted the information related

01:55.709 --> 01:57.759
to the file name being edited.

01:57.759 --> 02:00.640
Unless I missed, some this file name

02:00.640 --> 02:02.320
is displayed four times.

02:02.320 --> 02:04.399
This is way too much even if it

02:04.399 --> 02:06.320
displayed for different reasons

02:06.320 --> 02:08.959
in different contexts, but still I think

02:08.959 --> 02:10.720
you have a design problem if you need to

02:10.720 --> 02:14.560
repeat an information up to four times.

02:14.560 --> 02:15.947
If we now look at colors,

02:15.947 --> 02:18.160
you can count 15 different colors,

02:18.160 --> 02:20.560
such that it is impossible to guess

02:20.560 --> 02:22.959
which color indicates what.

02:22.959 --> 02:25.440
Such colorization based on syntax is

02:25.440 --> 02:28.720
actually quite widespread in code editors

02:28.720 --> 02:30.959
including Emacs, unfortunately.

02:30.959 --> 02:32.640
The problem is that we still don't know

02:32.640 --> 02:34.319
whether it helps or not.

02:34.319 --> 02:36.780
Some studies say yes, some others say no,

02:36.780 --> 02:38.239
and in the end the conclusion

02:38.239 --> 02:40.080
is not yet settled.

02:40.080 --> 02:41.840
Furthermore, there is another problem

02:41.840 --> 02:43.663
because there is no scientific method

02:43.663 --> 02:46.080
on how to enforce colonization.

02:46.080 --> 02:48.800
Should it be based on syntax, or semantic,

02:48.800 --> 02:51.519
or context, or something else?

02:51.519 --> 02:53.599
Developers are actually pretty free to do

02:53.599 --> 02:56.400
whatever they want, a lot of them will

02:56.400 --> 02:58.879
use syntax based colorization because it

02:58.879 --> 03:01.280
is the most simple to write.

03:01.280 --> 03:03.280
In the end, most of them achieve a

03:03.280 --> 03:06.080
Christmas tree effect.

03:06.080 --> 03:08.189
We know however, how to use colors

03:08.189 --> 03:10.560
to drag attention to a specific position

03:10.560 --> 03:13.920
as it is shown on the screenshot.

03:13.920 --> 03:15.760
This is called the pop-out effect,

03:15.760 --> 03:18.080
which is quite well known in neuroscience.

03:18.080 --> 03:20.000
Here, the media keyword has been

03:20.000 --> 03:23.120
made very silent just by setting

03:23.120 --> 03:25.760
the color in red while all other

03:25.760 --> 03:28.080
elements are desaturated.

03:28.080 --> 03:30.480
It literally pops out from the screen

03:30.480 --> 03:33.680
and point attention toward it.

03:33.680 --> 03:35.360
Finally, if we look at the overall

03:35.360 --> 03:36.879
structure of the Nova editor,

03:36.879 --> 03:39.353
we can characterize structural elements

03:39.353 --> 03:41.840
that are also present in a large number

03:41.840 --> 03:44.029
of modern editors namely,

03:44.029 --> 03:46.400
a file browser, a gutter, a mini map,

03:46.400 --> 03:47.844
a tab bar, a toolbar,

03:47.844 --> 03:49.920
and some versioning tools.

03:49.920 --> 03:52.477
I think this is too much information,

03:52.477 --> 03:54.879
and can lead to cognitive overload

03:54.879 --> 03:57.725
such that you end up to not pay attention

03:57.725 --> 03:59.599
to important information.

03:59.599 --> 04:02.720
So definitely more is not always better,

04:02.720 --> 04:05.280
and to paraphrase Edward Tufte in his book

04:05.280 --> 04:06.780
The Visual Display of

04:06.780 --> 04:08.720
Quantitative Information,

04:08.720 --> 04:12.560
"Above all else show the data."

04:12.560 --> 04:14.640
This is a reason that led me to

04:14.640 --> 04:16.720
experiment alternative design,

04:16.720 --> 04:18.079
and of course, to do that with

04:18.079 --> 04:19.840
the total freedom I didn't have

04:19.840 --> 04:24.080
much choice but to use and hack Emacs.

04:24.080 --> 04:27.001
My first iteration was called Elegant Emacs,

04:27.001 --> 04:29.271
and I try to enforce a few principles

04:29.271 --> 04:31.759
that I will detail into the next slide.

04:31.759 --> 04:33.919
But roughly, my idea was to

04:33.919 --> 04:35.857
enforce a radically different design

04:35.857 --> 04:38.320
by simply removing as much

04:38.320 --> 04:40.080
information as I could.

04:40.080 --> 04:42.240
Even so, vanilla Emacs is

04:42.240 --> 04:44.000
already quite simple.

04:44.000 --> 04:45.759
You can see the result on the screen,

04:45.759 --> 04:47.759
and I'm practically happy with the third

04:47.759 --> 04:50.240
screenshot that mimics the PDF layout of

04:50.240 --> 04:53.120
a scientific article by Stefan Monnier

04:53.120 --> 04:55.360
and Michael Sperber but rather

04:55.360 --> 04:58.160
fully inside Emacs.

04:58.160 --> 05:01.080
The second iteration is called NANO Emacs,

05:01.080 --> 05:03.680
and it is a version I try to maintain

05:03.680 --> 05:05.592
with a set of standalone packages

05:05.592 --> 05:07.759
that you can test individually.

05:07.759 --> 05:09.271
It is based on a set of

05:09.271 --> 05:11.919
a few principles, namely

05:11.919 --> 05:14.677
large margins, reduced number of faces,

05:14.677 --> 05:17.360
a simplified and contextual header line,

05:17.360 --> 05:19.280
and a default aspect ratio that

05:19.280 --> 05:21.759
mimics the A4 ISO format.

05:21.759 --> 05:24.240
I've been using this layout for a

05:24.240 --> 05:26.720
year and so far I'm quite happy with it.

05:26.720 --> 05:29.440
I know this is quite an opinionated

05:29.440 --> 05:31.680
design and some of you may totally

05:31.680 --> 05:34.240
disagree with me.

05:34.240 --> 05:36.630
Lately I've been experimenting

05:36.630 --> 05:38.682
with some special modes where

05:38.682 --> 05:41.919
the header line is made even simpler,

05:41.919 --> 05:44.080
this is the case for org-agenda,

05:44.080 --> 05:46.720
mu4e, deft, and elfeed.

05:46.720 --> 05:48.560
This worked reasonably well

05:48.560 --> 05:50.952
because these modes are search based,

05:50.952 --> 05:54.720
and it was easy to unify their design.

05:54.720 --> 05:56.960
I've also integrated some dynamic tags

05:56.960 --> 06:00.484
and icon in my agenda using svg-lib,

06:00.484 --> 06:02.400
which is available on ELPA.

06:02.400 --> 06:04.960
And for example, you can see the

06:04.960 --> 06:08.560
pie progress that help to show

06:08.560 --> 06:11.440
some incoming deadlines.

06:11.440 --> 06:13.261
There are still ongoing development

06:13.261 --> 06:15.120
to develop new packages to give

06:15.120 --> 06:17.280
a unified look and feel.

06:17.280 --> 06:18.792
I got a lot of feedback from

06:18.792 --> 06:20.768
the Emacs community,

06:20.768 --> 06:22.288
mostly in Reddit and GitHub,

06:22.288 --> 06:24.319
and I would like to thank them here

06:24.319 --> 06:26.880
because this is incredibly useful.

06:26.880 --> 06:29.039
If you want to follow or support my work,

06:29.039 --> 06:31.600
best place is probably GitHub.

06:31.600 --> 06:33.099
Thank you for your attention.

06:33.099 --> 06:34.479
I will be happy to answer

06:34.479 --> 06:36.874
any questions you may have.

06:36.874 --> 06:38.520
[captions by bhavin192 (Bhavin Gandhi)]