10. User interface

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.

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 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. Google cloud translation offered the most languages (132) with a free trial that even had a bonus amount to do document translation with.

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. I cloned all the English UI strings for the application and installation into a single Word file, with the references to where they are used so that I could cat-and-paste translation back to where they belonged in the master spreadsheet.

Google cloud translation costs US 15c per page, but I forgot to check how may pages I actually had in the page, so I didn't think to optimise the orientation and text size to minimise the number of pages. With 54 pages per file (lots of blank lines) by 132 languages, the page tally was 7,128, which at US$1069 blew my AU$611 out of the water. Fortunately, Google just listed the free trial as over and left it at that. However, that meant I couldn't do any fix up translations except by using the free online version.

I had to make sure that my special terms were accurate, such as subsite. When I translated this to Arabic, then back to English, it came back as sub site, which is not what I wanted. So I put in sub-site and that came back as subsite. Machine translation did not do simple stuff like punctuation nor the string of the first 20 alphabetic characters which I use for lists and table, so I had to do those manually.

For those who may want to use Google cloud to translate documents, the Translation Hub where all the configuration is done is not the same as the Translation Hub where documents are translated. That link is buried in some of the documentation, but seemingly not as a direct link from the former. I hope I avoided UI oversights like that.

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.