Exploring the speed of text commands when wireframing
Part 2 of the series exploring the potential of a True UX tool. I’m building and sharing small prototypes and writing about it. The goal is to gain a deep understanding and perhaps build something valuable along the way.
The desktop prototype
Part 1 was about UX source files. I also built a Slack Bot, where you can write commands to create wireframes. The plan was to let part 2 be about how to integrate user scenarios. But when I made a desktop prototype of the TrueUX tool for testing and general curiosity, it became clear that I had to first write about speed.
Let’s start by showing what the prototype can do at the moment.
Fast
First let’s take a quick look back to the last prototype. The Slack prototype shows it is possible to make use of a concise language. It is easy to quickly write down commands and have a clear understanding of what those will do. The commands are short and the source is quite readable.
Sadly, it.. is.. slow.. It can take half a second to get a result from a command, and worse, you have to scroll down to actually see it.
Using the desktop prototype you see the result when you press enter almost instantly. It was immediately clear that this speed made the prototype much more attractive and valuable to use.
How commands work
In order to explain the changes made when porting the Slack prototype to the desktop, I need to quickly go over how a command works. You write commands like this: update footer; height 3
The first word signals the action that is going to be taken, followed by what needs to be manipulated. You can shorten the command by only typing the first letters of the action and attributes: u footer;h3
While it looks kind of mysterious if you read it for the first time, typing is not harder than using control c to copy and control v to paste. You don’t need to be a programmer to be able to use commands.
Faster
When I started using the first version of the desktop application based on the Slack commands, the parts that slowed me down started to stick out. One of the most tedious parts, was typing the names of the blocks that make up the wireframes. Therefore I added the following two features.
Pre-selections. The last blocks you changed are highlighted and selected beforehand. Any command you type is then applied to this selection. Say for example that you made a mistake and want to delete a block you just created, then you simply type d, and press enter.
Selecting by first letters. To speed up selections you are allowed to skip writing all the letters of a block, and only type the first letters. If multiple blocks start with the same letter, you can select them all by just typing that letter.
Using these features, I shaved of seconds of creating often used commands. It started to become quite a bit faster to create wireframes.
Even faster
When exploring and communicating different design options, we often use pen and paper. It feels faster and easier to express yourself that way. You keep your mind in a creative flow that allows for both experimentation and deep thinking. This thought brought me to the following design goal:
‘ faster than sketching with pen on paper’
For very simple wireframes this may already be the case, and I’ve come up with some future features to make it even faster.
- Smart auto-complete. Names suggestions while you are typing could be suggested based on position. For example, in the top row of a wireframe, ‘menu’ and ‘search’ are good suggestions, where at the bottom ‘footer’ makes more sense.
- Components. A group of blocks that can be created and loaded into your wireframe.
- Additional commands. For example: copy & paste, flip horizontally, merge and split.
- Improved feed-present and feed-forward. The lesser known siblings of feed-back; providing the user with information on what is happening right now and what is going to happen. These give the user the confidence to use the tool swiftly. As you can see in the example above, the current blue highlights show what will be manipulated. In the same fashion, red lines could be used for deletions, and grey lines for what may be added.
The essence
We’ve just started this journey, but this starts to look like quite an a-typical UX tool. What UX tool comes to mind that you could also run in the terminal like this?
Using text commands to manipulate wireframes sounds counter-intuitive. But it doesn’t have to be. Simply look at it like this; it’s like Vim for UX.
Vim is a text editor mostly used by programmers, that has different modes. In the normal mode typing on your keyboard does not insert text (!), but it lets you navigate and manipulate text. For example: Typing ci” will let you quickly replace what is in between quotes. This command will move your selector to within the quotes and activates ‘insert mode’, where you can start typing.
If quite a learning curve, but it’s worth the investment, considering the time a software developer needs to make these type of text changes regularly. And once you have the commands in muscle memory, you can get in a flow.
Jaime Buelta explains this in Vim Speed is not really the point:
..using the editor to change the code is a small part of my working day. Saving some keystrokes is not going to allow me going home two hours earlier. And trying to optimise in keystrokes can take a lot of time just thinking.
But, when I make a change, I am able to do it spending less mental energy. It feels more natural. I need to think less in the characters. The editor gets less into the way of getting the text into the image in my mind. I still have to think about what action to do, but it is a much more natural approach.
This describes the user experience I want users of the UX tool to have. It should be like driving a car; perhaps not easy to learn, but once you know how to do it, you only have to focus on where you want to go and let your muscle memory do the rest.
For this user experience to work, close to immediate feedback is essential as Jakob Nielsen has found.
0.1 second: Limit for users feeling that they are directly manipulating objects in the UI.
Nielsen writes about the speed of feedback on user input like clicking. However, my goal is to shorten the time from user intent to having it be done. All the time in between is just a speed bump on your thoughts.
Ease of use
Early tests showed that Rabbit (somewhat guided by the hands of my 3-year-old daughter) was able to create a wireframe with a few blocks.
More tests are needed.
The focus right now is on learning how to make a powerful tool, that you can use with speed an precision. It may be that these qualities are fundamentally tied to a more steep learning curve. Again, it may be like driving a car in that sense. But, it’s hard to say since the prototype is still quite rough around the edges.
What about touch?
The speed of using the commands is not tied to the keyboard, it emerges from the definition of what a wireframe is. Current UX tools define a wireframe as a canvas where you can freely place elements on. I see it like this:
A wireframe is a rectangle made out of other rectangles.
If you look at it like that, it’s easy to imagine a touch version that would use gestures like swiping to split a block and a simple tap at the bottom to create a footer.
I started my first UX tool article with the sentence ‘I draw squares for a living’, and I always felt that dragging the edges of boxes to align, was a bit of a drag. One of the advantges of the current approach is that you get alignment for free.
The proof is in the pudding
To learn more, I’ve started with dogfooding my prototype. Here is a wireframe of the layout of the next version of the TrueUX prototype, made in TrueUX.
This wireframe gives a clear (and simple) picture, but the fixed straight lines do leave much for the imagination. It would be great to have it be rendered like this:
The style of the sketch makes it clear to the client that things are not yet set in stone and decreases the formal and mechanical feel. I’m researching how to best achieve this style. At the moment I’m looking at this XKCD library, but if you have any tips let me know!
Besides the style, the sketch also shows things like links, tabs and buttons. These types of blocks are not yet in the prototype, but I’m working on that.
Rounding up
I’m getting quite excited about the progress and potential of the new TrueUX desktop prototype and I love to get your feedback. But first, some quick comments:
- Our Slack prototype has been used, so it’s confirmed to work.
- I started to wonder how hand-handicapped UX professionals create wireframes. So I asked this on Reddit and Twitter:
- On to the next part: I’ll be looking into user scenarios for the next article and prototype. What do you think is the best definition of a user scenario? And what do you think about TrueUX? Would you try it?
Love to learn what you think. You can provide feedback, or sign up to the newsletter. Thanks!
Update November 2022 — My new low fidelity UX app
I created a low fidelity UX tool for the mobile phone. For now it’s about capturing your UX ideas while you are on the go, in the train, in bed or on the toilet. For mobile typing doesn’t really make sense. But the app is grid-based, and I do plan to add online web-based features in the future. It would be fun to revisit this edit-by-typing idea.
Read about it here:
