My name is Hartmut. I'm leading a design team at Canonical. I also have a passion project and
I'm going to talk about the passion project today. If you think design systems is a
daunting task, I think CLI design is actually for most designers, quite a daunting task.
My colleagues told me I should start with this. This is what I'm going to talk about
after I finish the motivation of it, but I'll start with the motivation of it.
So I would love to talk about CLI's and design. These are just like Wikipedia, of course,
and a famous non-designer who made a quite nice statement about design.
And what I find really interesting is that CLI's, even though nowadays I might see
as something that's always been there, were actually invented to improve the user experience.
So before that you had punch cards, and then suddenly you had something that was interactive
and it was user-friendly. And this is something that I think we can double down on.
And I think design is a perfect support in doing so, because design for me is not so
much about how you arrange graphics. It's more about how something should work.
And of course that includes some graphic elements. And this is just to show.
There is a need for CLI tools to improve because they can get pretty complex.
And it can create critical situations. And if someone is able to explain to me all of those statements,
I had to look them up. Please find me after the talk and I'll buy your coffee.
So this is just to say, you can have fatal consequences. A lot of these things are not trivial to understand.
And for designers, I think to challenge is even greater than for designers who want to involve themselves
with open source, to involve themselves with CLI's. And this is really trying to motivate you.
You should be doing that even if today's CLI's are sometimes really nicely, I would say,
using colors and layout and feel very complex. Or there is, I would say, a lot of things going on,
so that you have to really think about the state that you are dealing with.
So this is something that I think makes it really fun to work with CLI's.
And so I want to start with building some bridges, maybe.
So developers should definitely be involved when talking about CLI's.
And I think developers can contribute to CLI design and to really meaningful ways.
Because they have been working with the material, how what you can actually do for a long time.
So they know what is possible. And sometimes they are also really interested to what might be possible.
Because that's what this is a little bit about, how to extend what is currently possible.
So they can actually share the limits and help you explore something if you have an idea.
But they also have the users of CLI's. Most developers work with CLI's all day long.
And that does not mean they are the user for the specific CLI that you are trying to design,
they have the CLI mindset and they can actually also share with you the joys of using a CLI.
So things that like a CLI can feel make you feel extremely powerful, which is something that I think is a really good quality in one that we want to keep.
But on the other side of the bridge designers, most designers I know, bring a curiosity with them.
So that they really try to understand what is the goal that someone tries to achieve.
And that can be really useful because if you want to build something not just for yourself,
I know a lot of open stories is building things for yourself.
But if you want to reach others, it makes sense from time to time also to look into the context of what other people are trying to achieve.
And then help them do that.
Also designers get taught skills that provide structure and flow.
And both of these things are something that we want to have in CLI.
So that you can actually try to redefine the solution space to meet the mental models that users might have.
So now I'm getting to the part where I'm talking about how the magic actually happens.
Before I do that, just to cover it, CLIs are different and also have this open source joke.
But there is no graphical UI, which makes it really hard for you as a designer to say, let's just do something.
I'll send you a scribble because what will you scribble in CLI?
They're also used by experts.
And that might feel like you don't need design because experts actually like really complex things that are hard to do because then they can only, they're the only ones who can do it.
And that's kind of a good thing.
But also experts want to do their job.
So it makes sense to have things that are simple and that they don't have to relearn every time they use them.
And one thing that is particularly interesting for you when looking at CLIs is when you're looking at a graphical user interface, you see state.
You're looking at something and what you're looking at represents what the system state is.
If you're working with a CLI, you're giving a command and then something happens, but there's no state.
So that's fundamental difference and one that makes designing for CLIs extremely interesting.
And this is what you can do as a designer.
You can work on accessibility.
And it's actually accessibility for CLIs is a very thankful topic because a lot of it is built in.
You can work on visual hierarchy because spacing and typography matter.
You can work on colors, which is hard, even harder than for graphical user interfaces because sometimes most of the time you actually can determine what the color will look like, you just have a rough idea of it.
You can work on iconography, which, again, means you show the icons that someone else will have made.
And you can work on copy, which means you can really try to be clear when something is communicated.
And there are actually really nice talks about this.
So I will try to focus on the last three bits.
And that is, you can work on information architecture.
And I would call it conceptual architecture and I hope to be able to explain in the minute why.
You can work on flows and you can work on error handling.
So let's start with the conceptual architecture.
And this is something I find really, really fascinating.
When working with a CLI, you have to be extremely clear what are the things that you work with, the object and what are the actions that you want to execute.
And these are things that, in a graphical user interface, you also will have to decide what are these things.
But it doesn't necessarily force you to do so.
And with the CLI, this is a really important question to answer because it will create the structure of your CLI.
And the structure or the shape of your CLI will be what users see and what will help them understand what is your command actually doing.
And one example for that is, or how to deal that is, we are working on an internal standard and canonical.
And we are trying to define what is the grammar that we use for commands.
So this is not the only way that you can do it, even though it says canonical grammar.
This is how we want to do it. But what we want to do is we want to be very clear about what kinds of words do we use for commands.
And in our case, we said, let's use verbs. And then we have something that is like the primary thing that a tool does.
And as long as you're doing something that is like the primary purpose of a tool, let's keep it extremely simple, just use verbs.
And then if you're building more and more stuff into a draw, which we tend to do, then you're allowed to say, okay there's other things that this tool can do.
And in that case, you can get a little bit more complex, but really be clear about what your primary purpose is.
And these are rules that we can hand out to engineers so that they can actually have something where they can say, okay, if I'm doing it like this, I'm aligning.
So we are writing a standard and I also want this to become a design system at some point. And this is one example of an output that we want to achieve, where
being canonical, we build our own tool to install software on Ubuntu. And what's nice about this is that there is a really small set of core commands.
And this is what you like look at first and then you understand, oh, this thing is doing five things or six things and I can deal with that.
And then at some point you might find out this is not enough. I want to do more. And then we have these 50 other commands that are nicely grouped that help you do more advanced things with the same tool.
So it's kind of a layer to approach, but one where we try to really highlight the primary purpose of tool.
Second flows, use states and feedback. And here I find myself and my designers often asking the question, what is important, so for views.
How can we show what is important? And there are some things in CLIs that are different than graphical user interfaces or in web designs.
For example, there's nothing like the above the folding and web. It's actually the last thing that you put on a command line is often the thing that is most visible because it's just above the next command that someone will enter.
It's like the last thing that you said to someone is maybe something they will remember.
And then there's also structure that you want to bring into your output. So it's extremely important to be consistent about tabular data.
And we are making effort to differentiate between tabular data that we showed humans.
And tabular data that is piped into another program. Because the second needs to be exactly formatted the same every time.
And the first needs to be as clear as possible. So we're trying to actually differentiate between those.
We're necessary. For states and feedback, again, what's important is actually really hard with command line tools because you have so little space to show something.
It's really important to think hard about what would a user need to know and only give that feedback.
But don't omit anything that they might want. And that means that when you're building a CLIs, you're actually not building one interface, you're actually building a couple of interfaces.
Because you need to choose the user say, I want this to be quiet, I want this to be verbose, I want the back input output.
So you're actually not building one piece of feedback, you're building seven or six or five modes in parallel.
And last progress is extremely important. This can be very simple.
And it's been there actually since the 80s. There's a very nice video I found. Like the invention of the progress bar.
And we did some research how to actually build like the for us optimal progress bar.
And we also have some standards how to make progress really small and compact. And how to have like a hierarchy of different things that are progressing and then something that subsumes that.
And this is something that we also want to standardize.
And finally, our handling. And in our handling, this is something that most CLIs don't do very well.
So when you are having a dialogue with someone, that's fine. It's actually really like, I mean, there was this.
Surgeons of command lines, I think when chatGPD came out and people suddenly laughed having like a conversation with someone.
You can also have conversation with a command line tool, but it can also and really badly if there is something that goes wrong.
Because in that moment, you want to know what actually went wrong. And when you followed my advice and said, don't give too much output.
It might be that there's not enough to understand what is actually happening.
So what you might want to consider adding is suggestions for first time users, but also for infrequent errors.
Because yes, if someone has seen an error a thousand times and kind of expected that happens maybe a dozen teenagers explanation.
But if you have a tool that is rarely used or an error that is not very frequent.
Feel free to give a lot of information about that. And finally, you're describing the shape of the command.
But that doesn't mean you have to limit yourself to understanding just the words that you said you want to understand.
So what you can do is when you build a CLIs, you can be a lot more forgiving and say, oh, you said this word.
Did you perhaps mean this one?
And you don't have to train people to use this other word, but you can be like a little bit more friendly than saying command not found in that case.
And there's a nice example for that last one in Ubuntu.
This was done a long before my time. If you run a command in the command, something you can't do it will actually help you install the application that you wanted to run.
So this is kind of a really nice standard feature.
We also in Ubuntu have both extremely short version of feedback.
So snap gives you the minimum amount of feedback and apt.
The other install tool for Ubuntu gives you like all the feedback that you never wanted.
So finally, again, back to the motivations. What's in it for you as a designer? I think as a designer limitations are a really good thing because they help you focus.
So if you are trying out CLI design, if you are more lighting as a CLI designer, that will make you more aware of the things that you can do with CLIs.
And that CLIs ask you basically to do, and that can make your better designer overall.
So that is everything I wanted to present today.
There's also an open design group at Canonical that's the NEMA address.
And one of my colleagues has built prototyping tool for CLIs.
And if you want to try that out, you can scan the QR code and he'll get an email from you.
Thank you.
Do you have time for questions?
Yeah.
Yes, please.
Some people are told the unaware of the good or bad user interface.
So the comment was some people are not aware of not able to differentiate between a good and bad interface.
You mean people that are developing a tool?
I think if you have someone that is for themselves not able to differentiate what sometimes helps is if you bring them together with the people who are using the tool.
Because then they might be able to develop a sense of, okay, there's actually a problem.
Might work, might not work.
Yes, please.
One, you know, a fringe, but not that it's important for you that interacting with terminals is screen readers.
And real chemical of maybe you see them could use guidelines on how to structure your CLIs output.
You know, to play well with computers.
That's for example, you know, well, it's really very rough.
So we have to use the asking, you know, control codes to produce like colors or links.
Yeah.
You have to send me to the data that is textual.
So the question was, will someone maybe my team work on accessibility for CLIs?
And the answer is to a certain degree, yes, I would say.
So we're already including like everything that I showed, like the transient communication.
Can only be something that you add to make it nicer.
It cannot be something that you rely on, same with color.
Color can only be something that you add to make it nicer.
You cannot rely on it because you are not like sure that everyone will be seeing that.
You're actually sure that not everyone will be seeing that.
So that element is baked into like the guidelines that we are currently writing.
The addition of like if you want to help screen readers understand what is actually happening at the moment and give them hints.
Let's a topic that would need, I would say, further investment that we haven't done so far.
But if you're willing to help us, please reach out.
We are definitely interested in making that.
Yeah.
So my question was treated by the fact that you spray dry patches to like modular progress bar.
Yeah.
And then you know, you don't know someone to listen to over.
Yeah, but at the moment our approach for screen readers would be to respect of no color flag and respect like so if we do that in every single eye that we build.
So that we don't make it harder for the screen.
We also would like to make it easier if possible.
Yes, please.
Okay.
So the question was, there might be some.
So I don't know if you should focus on.
What do we do anymore, maybe?
Short one.
Okay.
So the question was, there might be some.
So I don't know if you should focus on.
What do we do anymore, maybe?
Short one.
Okay.
So the question was, there might be some like some problem with people sharing a command online probably to some others where they're using what we would call a short flag.
So one letter.
And I'd say short flags are there for a reason.
They are extremely convenient.
So what we do is we say if you have a short flag, always have a long flag.
So people can use the long flag.
And only have short flags for things that people use frequently.
So we encourage the use of long flags.
But we do not enforce them for everything.
And you want to answer to that.
Okay.
Then we.
If we remove the short versions, people are forced use of long versions, which makes the sharing better.
And I would say.
I do not completely disagree with that, but I'm a little bit careful with taking convenience away where it does make sense.
And for some of our commands that are extremely often used and actually type manually, I would say, I would be careful with doing that.
As I said, like, for 90% of our flags, we are using long flags for the ones.
That are short.
They are usually so frequent that people know them.
And you can always find out by using help.
So it's, I would say, a trade off.
But one where we lean on.
We have ever possible.
Take a long flag.
And then leave the rest to the designers of the tool themselves.
I'm going to come from that.
We're trying to share some of the question.
Just come on.
Also have some documentation regarding the arguments of the format.
Okay.
Let's say I have a certain cloud.
And I will create secrets.
With the.
Okay.
Cloud points.
Create secret or secret.
Create.
Yes.
I would prefer.
Has been separated by the main.
So like.
Yeah.
Yes.
We do have an internal.
Sorry, the question.
Thank you.
The question was, would we use like an inverse.
Notation for using like if we have a subcommand using a noun and then the verb.
And at canonical we decided not to do that.
It's I think it's a perfectly valid.
Like approach and one that I've seen other people use to to to success.
I would say.
The canonical we said we want to focus on the action.
The action is the most important bit.
So in that case if we have a commanded.
Coincidentally sometimes great clouds.
We would say it's create cloud.
If it is the main purpose.
Then we would find a word that.
I'm not sure create is a good word for clouds.
That would be a good verb.
That helps you understand.
You're now.
Like creating that cloud.
That's the second thing that that's been helpful.
I used to use a somewhat different.
With all of these stops.
So.
Yeah.
The other thing that makes it accessible to me for the.
The one cloud.
It's okay.
And the secret creates.
And if I just like,
Secret and prestige.
Yeah.
All of which is really.
Yeah.
So you, VPN notation would be easier for auto completion.
That's definitely true.
That's also an argument we discussed with our engineers.
engineers, but what we also will be doing as we can control or to complete, we can also
give you just if you press cloud, we can give you the option of completing that to create cloud.
So that's how we will deal with that. That's kind of not saying type cloud first, but
like accepting you type in cloud first and then helping you.
We have time for one very quick question.
This one in.
If there's a design pattern that links the CLI to the API layer, we have done,
yeah, that was a question, I think. Yeah.
We have thought about that, and our feeling was no,
like the answer that we have currently is no because when you design an API,
what you want to do is you want to have a separation of domains.
That is very, very clear. And that would be closer to the command line structure where you
start with the noun and then have the verb. I think in that case you can have an alignment
of the API and the CLI and our case we can't because we start with the verb.
Is that a bad or a good thing? We don't think it's necessary a bad thing because if you want to keep
alignment that would mean if you change the API, you have to change the CLI, if you change the CLI,
you have to change the API. And that would include, I think, a connection between the two,
that would create more problems than solve things.
Okay, I'm sorry, I'm out of questions, but I can wait outside if you have more questions.
Thank you.