ASCII art User Interface mockups

I have the pleasure of knowing the great mpt. He actually spent a couple of months in Brazil back in 2006 and we ended up sharing the same apartment during this period. One of the great things he masters is the art of writing ascii art mockups of user interfaces As I am a mere beginner might not be the best person to explain this. However I will make an attempt to explain the basic principles, in the effort of having this written down somewhere.

In this blog post I will focus on commonly used interactive widgets available in Gtk+, since these are the ones I tend to care the most about.


An entry is straight forward, you use brackets in the beginning and the end and underscores to fill up the allocated width of the widget:


If you want a text, just replace the underscores with letters

[Hello World____]


Buttons are similar to entries, the main difference is the lack of underscores and the use of capital letters. Icons are usually ignored as they often are rather tricky to represent using the ASCII alphabet. A cancel button looks like this:


GtkToggleButton and GtkRadioButton

Toggle buttons uses brackets around the toggle part and no brackets around the rest. If the value of the radio should be active, use a lowercase x to say so:

[ ] Buy milk and cheese for breakfast

[x] Eat strawberries after lunch

Radio buttons are similar but uses parenthesis and o, eg:

(o) Fresh fish

( ) Rotten eggs


Spin buttons are similar to entries, but they have two small arrows on the right hand side. To represent the arrows, use H:

[1234 H]

This might not look good in all fonts, but it’s the best that can be done, at least as far as I know.


A combobox tend to be represented again by using brackes in the beginning and the end. To represent the arrow, use a lower case v and separate it from the text by using a | (pipe) sign.

[ Stockholm | v]


Prett simple, use _ (underscore) and | (pipe) for the borders, titles and window manager buttons can usually be skipped since they are mostly noise to us in this context:

|                                |
| Do you want to close the open  |
| document and lose the changes  |
| made to it?                    |
|         [ CONTINUE ] [ QUIT ]  |

These are the widgets I usually end up using in my mockups. Have any missed any important onces? Or I have I done any serious mistakes? Comments appreciated!

This entry was posted in General, GNOME, olpc, PyGTK, Python. Bookmark the permalink.

19 Responses to ASCII art User Interface mockups

  1. John Levon says:

    I’ve long wanted to write a GUI (or,
    perhaps more appropriately a curses TUI) for creating these dialogs, but
    never found the time.

  2. ethana2 says:

    The double spacing in that last thing kind of kills it..

  3. Anders says:

    What about Web Kit

  4. Baptiste Mille-Mathias says:

    We need a script a export ascii in glade and to import glade in ascii 🙂

  5. kraptor says:

    This makes me remember the Cursed Gtk Project at

  6. Locktape says:

    I’m sorry, but I don’t really see the point…

  7. Calum says:

    Pretty much how I’ve always done them, although I tend to use ‘+’ signs to square off my window borders…

    | |
    | |

  8. Calum says:

    Bleah. That didn’t work very well, I thought tags would force a monospace font :)

  9. Alan Horkan says:

    I’ve always found supposedly Rapid Application Development tools ploddingly slow for creating user interfaces.

    The ability to transform quick and dirty ASCII text mockups into a first attempt at the user interface would certainly help speed things along. Menus particularly are something I’ve often listed and in text files in fairly structured way and wished I could more easily transform them into glade files. I suppose another top down approach would be to try and provide tools like Glade with improved a better system templates which might also help improve consistency.

    Conversely being able to export the menu layout of an application into a flat list can be useful as a crude form of documentation or reference index (no substitute for the well written prose you get in high quality documentation but better than no documentation at all).

  10. Staz says:

    Locktape > the point is to do quick textual mockups

  11. mpt says:

    I use ( Cancel ) rather than [ Cancel ] for two reasons: (1) it helps distinguish buttons from text fields, and (2) it helps distinguish command buttons from toolbuttons.

    Remember also [option menus :^] (not to be confused with [combo boxes|v]), / Tabs \, and sliders =O====.

  12. mpt says:

    And speaking of sliders, I wish GTK had =V==== sliders with snappable tick marks, as well as the =O==== sliders that don’t.

  13. Flying pie says:

    About button styles… The best button style is definately:

    > CANCEL < Toggled In

  14. Flying pie says:

    About button styles… The best button style is definately:

    > CANCEL < Toggled In

    Mostly for the ability to add a toggled in style. (]CANCEL[ and )CANCEL( don’t look too nice)

  15. Bryan says:

    I like to put a space inside the combobox such that the v has room on both sides.

    [ combo box | v ]

    But I like the ( Button ) much better since it is confusing to reuse the [ Text Brackets ] for buttons all the time.

    Also I use the slash to indicate insensitive buttons. So the following combo box would not be clickable, not sure if others have solutions for this.

    [ /combo box/ | v ]

  16. Pingback: Bryan Clark » Blog Archive » Signatures in Email

  17. Peter Lairo says:

    Default Button (double brackets):

    [[ OK ]]

    Better dialogs:
    |bla bla bla|
    |bla bla bla|
    |..[[ OK ]].|


  18. Peter Lairo says:

    Better dialogs:

    |bla bla bla|
    |bla bla bla|
    |..[[ OK ]].|

  19. hrongyorgy says:

    And what you think about

    ( NonToggled ) and [ Toggled ]
    In the normal buttons, the default active button is can be marked as
    (> Default )

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *