To main heading

Smallsite Design


12. User interface

There are several decisions to be made when designing the user interface (UI).


While a normal web page can be made fairly plain and well spaced out, pages for accomplishing complex tasks often need to be very information dense.

For public-facing pages, where a visitor may have never come across the site before, information is best fully explicit rather than behind elements that require some familiarity to use or even know that they hide some information or all of it!. Hamburger menus are an example, as they are compact, but may be hiding core services, as Creative Commons does on mobile, though they now label it Menu. However, this product is for those who want to provide mainly textual information in straightforward ways, so menus options are explicit, with sections and subsections to make the structure of articles clear.

Some languages can occupy twice as much space as others for terms with the same meaning, so when wanting to make a UI that is as compact as possible to be able to include as much information as possible, symbols offer the most consistency of sizing and minimal space. However, they are only useful if people already know what they mean, using them often enough to remember, or a legend is provided.

On most pages, there is enough space to use full words rather than symbols, but IDs are used instead of full headings and the often-English international standard IDs for entities like locales and timezones rather than full translations. It is when editing that the need for minimal space becomes critical as the element blocks can hold a lot of status information. Here there are symbols with a legend at the bottom of the page. There are also ℹ help links in the blocks, as there are for every management page and section, to the online documentation where there are more-expansive descriptions.

Buttons as normally used are meant to be fairly rare and stand out. However, in an web-based application environment, there is a need to provide context information when changing pages or triggering changes, and to avoid that information being in the URLs, forms and buttons are required rather than links. In Smallsite Design, these are known as jumps and the buttons are rendered as bold and without borders or backgrounds, similar to the navigation links in this page.

This makes them far less obtrusive than normal buttons, so that they don't visually overtake the headings, especially given their numbers. Normally-rendered buttons are still used where they need to stand out.


An application that is meant to cater for many languages needs its user interface to be offered in many languages, but that is not trivial.

Smallsite Design has about 1100 unique items of user interface (UI) text and another 90 items for the installation UI. It was not useful to do any translation until the application was complete, as any changes would have to be replicated across all the languages. Any major changes would mean a lot of translation work.

I had originally thought I would use locales for the UI, but during research I discovered that while the way languages are spoken can vary dramatically, how they are written is fairly consistent, except for some spelling differences, like between US and UK English. I decided that since I was dealing with a limited number of terms, most of which were single words, I would stick to just languages, not locales. In Australia, we tend to use UK spellings, so that is the version of English I used, though I tried to avoid using words that might be spelt differently.

However, scripts are another thing, especially where different scripts for the same language might be in different rendering directions. By convention, if a language has only one script, it is not included in its ID, but where possible, it would be best to have the UI in all scripts for a language.

It is always best to use real and experienced translators, but since I wanted to cater for a lot of languages from the start, I decided to go for machine translation to substantially reduce the time and cost involved, as it had been a single-person operation up until then, with very little way to pay for it. While Google and Microsoft (MS) cloud translation services both offer 130+ languages, that is pared down to 110+ when only including those matching CLDR locales. In comparing the quality of translation in their free offerings, I found the MS ones matched my intent better.

I have all my UI strings in an Excel spreadsheet so that I could use formulae to minimise the amount of redundant translation, both between languages using a fall-over hierarchy rooted in English, but also where some terms were used in multiple situations but still needed to be separate. This is the case where some words may be used standalone in the UI, but may also need to be part of a set of options for an attribute and having them altogether greatly simplifies extraction of the text in a loop through all the options.

There is a column in the spreadsheet that indicates the row of the first occurrence of the current term, so if it already exists, the cell formula gets the first one, bypassing the need for a repeat translation.

I cloned all the English UI strings for the application and installation into a single web page, with the references to where they are used so that I could automate the translations to where they belonged in the master spreadsheet. I had to make sure that my special terms were accurate, especially one-word ones, as the translator might not translate them correctly if they could be used as nouns or verbs. To do this, I put each of them in a sentence, but formatted the wanted part of them in b tags so I could programmatically extract them after translation.


Given a choice, people are often inconsistent about full stops in places like table cells. So is locking down strong rules needed?

While avoiding trying to make the program too smart, which usually ends up becoming a nuisance for those who have their own preferences, the only place where such smarts exists is in adding full stops at the end of standalone rich-text elements like paragraphs. At the other end, full stops are stripped off article and section heading and navigation text.

It wasn't always so simple. Up until very late in development, I restricted where full stops could be added, mostly excluding them from inline elements in an effort to prevent rich-text elements being lumped with ending full stops where they might not be appropriate, like before the colon in an introduction. In the end, I cannot protect users from themselves completely. It will be up to them to edit in or out full stops in substituted rich-text elements.

Trying to do that programmatically is a minefield as there can be situations that are the exception, especially with mixed opposite rendering scripts.

Rendering direction and alignment△

Mixing scripts with different rendering directions is problematic.

Related to languages is the scripts used to render them. If absolutely all text was only ever in one script, there would be no issues. However, the web was started in English, so all the underlying technology for rendering was optimised for left-to-right rendering, and that had likely led to inbuilt technical biases. While there was – and still is – the clunky code pages for different scripts, if the correct one isn't used for a page, some text will be just strange symbols, and forget about multiple scripts in the one page.

Unicode and UTF-8 really made the multilingual web practical, but unfortunately there is more to being able to have scripts with different directions intermixed. While many mixed-script scenarios may take care of themselves, the standard way to force some layouts to behave properly is to either wrap the different text in a bdo tag with a dir attribute, or place special Unicode characters that specify what the current direction is for following text. These basically work, though some situations are still tricky, but the issues do not stop there.

In relation to text, there is the rendering direction, and there is the alignment. That means that left-to-right scripts are aligned to the left, and vice versa, though the bulk of the text is justified by default. The product has a locale hierarchy, so if there is not text for one locale, text will appear in the script for the next locale. This can occur at the article level where the whole article is rendered with the script of the resultant locale. All fine so far.

However, the fall-through also occurs at a per text item or block level, where if text for a locale with a script rendering in one direction is not available because it was missed by mistake, the text may be replaced with another locale with the opposite rendering direction. The simple way to handle this is to set the dir attribute to auto on the enclosing tag, and let the browser sort out the rendering and alignment. While this works alright for multiple lines, when the text is short, it can appear on the opposite side of the page due to the changed alignment.

This can be disconcerting as the text, even though it is in another language, doesn't appear where it is supposed to, but instead there is blank space. The solution I chose was to let the enclosing tag default to the page settings, but include the text in a span tag with its dir attribute set to auto. This causes the text as a whole to be positioned aligned to the page, but it is internally aligned according to the script in the span tag. This makes all the blocks have text where they are expected, but the contents flow properly within according to the script.

It is not always possible to know all the issues that will result from higher-level decisions, and many will have to be made simply on an aesthetic basis, like here with the alignment. Those who are used to working with mixed-script rendering may be used to looking at the other side of the page for missing text. Less experienced people or those with a different neuropathy might prefer positional familiarity, despite possibly not knowing what the text actually says. However, after finding the text, an experienced person might wonder why the alignment is not matching the script.

It's a tradeoff. While the product should be designed with the writer's needs in mind, in this situation where text is missing, I think a design should bias in favour of the sensibilities of the readers, of which there are hopefully many, and not the writer. In a precision marching band, it is less visually disruptive for the audience if a marcher has lost their hat than if they move in the opposite direction to everyone else. It is about how to make mistakes less disruptive.

Text direction△

Changes in text direction can make reading it difficult, but there may be situations where it may be better than the alternatives.

For almost all pages, there is no need for text to be anything but horizontal. However, for the banner adjustment parameters, while I could make the English header labels fit in a compact way, in German they made the columns so wide that the table extended beyond the page. The column values were not wide, so the most expedient solution was to make the column headings vertical, requiring that they be read sideways. On the summary page for multiple locales, it is easy to compare the values across the various locales by looking down the columns.

However, on the view where the adjustments were made, where there is only one locale shown, having vertical text that was often referenced while making adjustments was inconvenient. I originally had a table underneath with the minimum, default and maximum values, but decided to merge them into one table with the parameters in the rows instead, and with the current, minimum, default and maximum values in the columns. This highlighted the necessity of putting usability first, rather than uniformity, and as a bonus here, it made it all look more simple and elegant as well.

Having to go back to a single page to get to anywhere else can be quite tedious, but having jumps to every page relevant to the current one can lead to a lot of clutter.

User interfaces thus need a hybrid approach where those who prefer having a basic navigation process can continue to do that, but those who can handle having multiple navigation paths can have them. For example, in the Article head page, going to an article's category can be done by going to the Work list page, drilling down to the category in the Access section, then clicking the category ID, but this involves remembering the category and many clicks. Clicking the ID in the Category row of the Details section is much more direct.

The trick is to have consistent logical structures where such extra links can be, so at least those who don't like to use them can ignore them, rather like people train themselves to ignore ads down the sides of web pages. One such structure is called breadcrumb navigation, one version of which is to show the place of the current page in a hierarchy of links. This serves as a passive reminder of where a user is, but is also a means to jump to those other pages, or at least to its place in the full hierarchy list.

In general, in Smallsite Design, the breadcrumb jumps are to the IDs in the Work list page, whereas those within Details sections are directly to the associated page. Even though the breadcrumb jumps are not direct to the pages, they are only an extra click or Enter press away. Where the element in the Work list page has children, their list is expanded.

There are bidirectional jumps between references to elements in pages and to the pages where those elements can be edited. This aids auditing of links and file usage, which is necessary to determine what might be preventing an element being deleted.

Keyboard navigation△

We are very used to using our fingers or a mouse to directly activate what we want, but not everybody has the dexterity to do that.

Using a TV remote to enter text is enough to become acquainted with how much effort those who have to rely upon keyboards have to operate in a slowed down world to get anything done. Just having the ability in the on-screen TV keyboard to move to the start of a line of letters by arrow-keying past the end feels like a blessing as it saves so many button presses. Even for those who can use a mouse, having a keyboard way of doing without the mouse means that while typing, not having to swap to the mouse just to do one thing only before going back to typing means keeping a train of thought.

In a computer program, keys can often be pressed before the screen has been updated because there is a keyboard buffer, whereas with a mouse, a button cannot be clicked upon until it appears. In a well designed program, keyboard operation can thus be more efficient than using a mouse. At one client years ago, with MultiMate they could open the program, open a template, update it for a client, and save it faster with a keyboard than Windows Word 2 could open on their hardware.

Those particular advantages of a keyboard do not work with the round-tripping to the server and back because the keyboard buffer gets reset, but the tediousness for keyboard-bound users is the same. I did not think about keyboard users in early designing, but after back-fitting adjustments as I thought of them, I switched to building in keyboard alternatives or extras as I designed various functional blocks and elements. Now bullets for list items, row numbers for tables and terms for glossaries, are links to the first-letter of their parent's introduction.

In the management pages, where there are rows of items to select from, there is usually an up-link every five rows going to the checkbox that controls the visibility of the list. If there are more than five rows, a navigation menu will be shown to jump to every fifth row. However, if there are more than two items in the navigation menu, there is a checkbox to hide all the links. This unclutters the menu for those who use a mouse, but also for those keyboard users who probably don't want to tab through 20 links or so just to get to one of the first four rows.

It is an iterative process to really understand what makes for good navigation, let alone with only using a keyboard. This is the type of learning lessons that occur along the way when designing products for wide usage.

  • •Picking the philosophy
  • •Facilities
  • •Minified
  • •Contact   
  • •Categories   Feed   Site map

  • This site doesn't store cookies or other files on your device when visiting public pages.
    External sites: Open in a new tab or window, and might store cookies or other files on your device. Visit them at your own risk.
    Powered by: Smallsite Design ©Patanjali Sokaris