Okay, thank you everyone for coming. I'm going to read because it's easier. So this is Nojan.
Yes. And his talk is liquid prompt. Yes, we can drastically rethink the design of the shell prompt because
command lines are interfaces too. Isn't it? Yeah. People forget that. So take it away. Thank you.
Thank you. So this is challenging of course to come after this very interesting presentation by
interesting people, interesting and new interfaces while I'm here talking about this old piece of
software that's kind of specific if not the niche, the prompt. Right. So who here is using the terminal
or know what is a prompt? Okay. Okay. Okay. Okay. So I was seeing myself working on a niche
problem but maybe it's less the case. So of course I did introduction about what was shell prompt because I
thought that it was interesting but then maybe it would go fast on that since most of you should know what it is.
What's interesting is that the default prompt looks like that. That's a bash prompt in many distribution.
And its purpose of these default systems are to indicate where, when there are problems and follow the state of the
work. Right. So that's what we would want a prompt to do. I started working on that because I have many students
every year with whom I work and they would show me that when I said, okay, let's work. In my line of work, we are using a
lot of command lines and we're working on HPC cluster so that SSH is the only entry point on that in many
case and that's what my students are showing me. And honestly, the trick is do you know where the prompt is, for
instance, in such a case. That's the default these SSH prompt on my system. I just don't know where to look at.
So of course, people had the same problem for years now and there's a couple of existing prompts that you can install on
your system and just start using right away. These are the seven most known. And I happen to be the author of this one,
Liquid Prompt, which is historically the first one actually, but not the one that got the most successful at the end.
But I did a study recently because with the guy who was working on Liquid Prompt, we were wondering should we continue working on
that since there is this very well-known software. So we did an extensive study on the feature set and the design of all those
prompt systems. And I wrote an article that I will not explain in detail here because it's talking a lot of features and going into much details.
I will just show you those two tables. The first one is about the feature sets of those systems. And what I want to advertise, of course,
is that Liquid Prompt has, if not the best, the largest feature set, at least the one that are the most interesting, which I call the essentials,
the one that are tied up to the shell. Because many prompt systems are actually interested in listing as much environment as possible,
which is like the versions of tools, basically, like all the compilers. They would show you the version when they're...
But Liquid Prompt shows much more information tied up to how you use the shell, actually. So if you want to know more, you can go on the article.
As today, I want to talk about design. In the same article, I'm also talking about design.
So there's a couple of ideas we wanted to follow while designing Liquid Prompt. And we paid a lot of attention on that.
And they are summarized with those words. A good prompt should be what we call focus. I tried to use single words, so of course they are not completely the right choice,
but meaning that the prompt should target states that are actually useful to the user during a work session.
And it's not actually useful in most of, at least, my work session to know all the versions of my tools, for instance. Not always.
It should be seamless, which in a prompt basically means it should be fast and not showing too much information.
It should target the states of your system that actually change. You maybe are not interested in a state that you know from the beginning of your session to the end of the session that's the same.
It should embrace the fact that some states change less often than others. So there's states that you are willing to know more often, to look at more often.
And of course, those important information, they should be really visible.
And I'm not defining configuration because you know what that means.
So we did this extensive study again on the design across all those other prompt systems.
And here again, of course, I'm advertising my work.
But really, I want to emphasize that that's not a post hoc justification, right?
That we really wondered whether we should continue working on a liquid prompt.
And that's what came out at the end.
Okay, but you don't have to believe me, but you can read still the article to get more information.
Okay, so those other prompt systems that I'm making fun of with these tables, they look like that.
So this is a very classical. Those are screenshots of the Omaiposh system, which is another prompt system, which is quite good.
Technically, it's a good piece of software.
And each line, basically, or couple of lines is a different theme.
This one is the prompt with the more teams.
So basically, the approach to design of all those other prompt systems are like a sequence of colored segments,
which I call that segment rainbow.
And of course, for a prompt, there can be a lot of information to display.
If you have the feature set of liquid prompt, for instance, there's a hell of a lot of stuff you can show on the screen.
I did make this theme for liquid prompt not for everyday use, but of course, if you fancy it, you can use it.
That shows all the information we can actually show.
So of course, there's no question. You should not display that at all time.
I will not go into detail about everything.
So of course, we can do better than those rainbow of segments that just change every time you do something,
and it's difficult to spot where the information is.
The first idea is that we can show the important information first.
We can help visual passing.
We can avoid this list of segments, of course.
We can be colorblind friendly, of course, having a rainbow or stuff that's difficult.
And the guy with whom I'm working is actually colorblind friendly.
Is he friendly? He's colorblind.
Of course, he's friendly to other colorblind people.
I'm sorry.
And also, we want to avoid text overload, which happened very often also with those systems.
And another thing that I will be talking today is we can have logical sequences of information,
things that are linked together while you're reading them.
And I will also talk at the end on semantic threshold.
But it's difficult to introduce. I will just show you.
So to do that, LiquidPront comes with a default prompt, which is kind of the well-designed prompt you would think,
you know, text mode with some colors, but close to the classical approach.
But we did the dot matrix 10 theme, which is a theme for LiquidPront, that completely changes that.
It doesn't look at all like a classical prompt.
It looks like that, basically.
I'm going to show you a little bit of features and explain that.
The first thing is that it takes three lines, which may seem a lot,
but we thought that nowadays we are using these terminals in high resolution screen anyway.
So we have some room.
So the first thing is that we prioritize the information based on the location on the screen.
And we try to make it stable.
It doesn't change of places.
If you have this sequence of segments, every time an information or a state changes,
everything is moving around.
Here it's not the case. It's more stable, a lot more stable.
So we have just to say a few, the type of connection, who is connected, the name of the machine, where you are at.
Here you have the right align section that shows some sensors, the temperature, the CPU load, whatever.
We have this line that separates sections.
I'm going to show why we have that and shows everything that's stable.
But you would want to display, like I don't know if you're working in containers or you want to know these versions of this and that.
You can show them here.
And here we have the big version system repository management or display with the left side for the remote server,
the remote repository and the right side for the local repository.
I'm also going to explain that.
And here, very near to where you type the important stuff like errors.
Here you have an error code that's displayed.
So while this, for instance, these section lines, it's because if I display the same screen that I show you at the very beginning of the presentation,
but with dot matrix, you would see that.
It's a lot easier to parse, of course.
And for instance, in my line of work, we're working with a big build step that takes a lot of screens on the terminal.
And I'm very often scrolling up and down to find back where does that start, where does that end.
So of course, having these sections easily easy to spot, it's a good help.
As for the colors, you've noticed surely right now that we decided to go for these black and white segments,
which of course is easy or it's color blank friendly, right, for most of the case.
And we use only two colors, one for what we call notes, the blue one in the default system and yellow for the warnings or the errors.
And with those two colors, it's kind of enough to display what we want as an information.
And of course, you can switch depending on your color blindness, you can switch the pair of colors that you would need.
We're still working on the 256 color space, so not RGB, for compatibility reasons,
because there's not that much terminal emulator that supports the RGB color space, surprisingly.
But then we stick with that, which in our case, since we are only using four colors, black, white and two warning colors, is more than enough.
We did develop a tool that helps you select couples of colors based on the contrast.
So you would just, that's kind of a side note, but you can say, I want to have a good contrast with this color,
and it will find in the NC, there is very niche color space, what other color you can use in combination.
Okay, so now I will highlight a couple of design features of dot matrix.
I will not go over all the details, but just to name a few.
The first one that I liked is that to avoid having too much text and too much icons popping up,
we used negative space, which is actually actual space in the prompt that appears when there is some state that changed.
So here, for instance, on the first one, there's an SSH connection, and you can see that the user is actually disconnected from the left-most side.
Right, so you're not connected on your laptop, there is a space.
The same goes for the root user here, which also appears in the warning color.
Here, you have the user which is disconnected from the path, meaning that you don't have the right, right, right, I'm sorry, my accent is different.
You cannot write in this directory.
Another interesting idea, in my humble opinion, is the use of these logical sequences that you can see on the VCS section, so the last line.
It reads from right to left, so you are at the right, that's where you type your comments, right, you are doing git comments.
And what you can see, how do you interpret the first line, for instance, you have a commit, you have changes ongoing, that's the blue section with the numbers.
That's the number of lines that have been changed against the head state.
And there's an arrow on the left, meaning you can surely do a commit with that on the master branch.
So that's what the second here is doing.
Here, I picked up a part of the diff and I did a commit and it appears here.
What this section means is that the remote repository has seven commits on its own.
So you're going for a conflict here, which is you should have pulled before, you should have, you know you should pull before starting a new branch, but if you forgot, then LiquidPump is warning you.
There's probably a problem going ahead, but you can still push another commit and so on and so forth.
Yeah, okay. I cut the slide where I solved the commit issue because it was quite long, but you get the idea, for instance, that you have these commit paintings and if you add another commit, it would be there.
And then when you push, it would just disappear. You have nothing left to do, so there's no more warning to show you.
Here, what I'm showing is that we use these two colors, these pairs of colors, to give you a semantic hint on the urgency of what you're doing.
So since you have something going on, some work, some diff in your repository, if it becomes too long and you can, of course, tune the threshold as you want, it becomes yellow in the warning color.
And the same goes for the commit. Here, I've put the threshold at five. I know that if I have five commits, probably I want to push or pull or do something like that.
Surely your commit limit is higher than mine.
And that's it.
So I did not talk about everything. That's the summary of all the features that we can display with dot matrix.
So there's many, many, many things. I have shown about the space system around the kind of connection that we have.
You have a space for a team of screen connection, for instance, the read only. We saw that and so on and so forth.
And there's the diverse warning. For instance, if you're connected with telnet, there's this big yellow arrow that shows.
Anyway, the same goes for shrewd and so on and so forth. You can also summarize if you don't want to see the numbers of lines or commits, you can just get one icon and be done with it.
If you want to, again, in this article, we detailed a couple of thoughts on the design that you can go and read.
And thank you.
10 minutes for questions.
Perfect.
10 minutes for questions. So, if you make sure you repeat the question.
Yeah, I noticed that.
Thank you. Very nice to hear someone in line.
I was wondering if you ever did, like with your last example, for when you're telling someone it has to do something that might be expressed.
So do you do any user testing or at least student testing with your phone?
Yeah, so that's a good question. That's actually part of the reason why I decided to do, oh, yes, sorry.
Every time I saw the, why do they do it? It's obvious.
So the question is, did we do user testing to test the prompt and in particular the level of stress while we are telling them to do something?
So the answer is no.
Because I'm not a designer. I'm an obvious designer. I just happened to discover that quite recently.
And I liked it. So I read a lot and all, but I'm not a designer and I decided to come and force them in part because I thought, oh, maybe in this room there would be some designer that would have some idea and that would be able to answer my question.
I have a couple of questions. What would be best? Where to display the error stuff like that?
So yeah, no, no, but that would be, also because our user base is nothing compared to the previous talker, right?
We are not talking millions or we are talking a couple of thousand at most and most of them don't answer, communicate or...
So yeah, I have three users with whom I'm discussing basically. Myself comprised.
Yeah, so to continue on the design, it's really elegant with the negative space and everything, but how do you, if there are at least some good documentation to say what each icon or each sign represents
and how do you convey because sometimes I might forget what's the difference between one big arrow and two small arrows?
Yeah, yeah, yeah. Well again, the answer is no. There's no good... Yeah, sorry, sorry.
So the question was, is there a good documentation to remind the users what the features are and most precisely what does mean the negative space which is not completely obvious in itself?
So yeah, no, there's this kind of summary and there's a readme that lists all the features and all. I would not count that as a very good documentation.
Yeah.
So again, that's a tricky question. I did not manage to solve that myself except by playing with less. We did a single line version of the prompt though, or either two lines,
this one, sorry, two lines, in single line that's really not possible, which is a little bit more dense, but yeah, no, I did not find a good way to solve that either.