12 User interface
There are several decisions to be made when designing the user interface (UI).
Compactness△
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
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
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
This makes them far less obtrusive than normal buttons, so that they do not visually overtake the headings, especially given their numbers. Normally-rendered buttons are still used where they need to stand out.
Languages△
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. 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, so I intended to use the paid Azure Translation API, especially as it is half the cost of Google's API.
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
Unfortunately, the Azure translation API is woeful. There is no way to use it reliably as a programmatic tool, let alone as an on-the-fly translation service for HTML. It randomly translates tag and attribute names, and often only the opening tag, randomly adds in extra < or >s, puts translated text within a tag after an attribute, and leaves some text outside any tag. It doesn't seem to like non-Latin language scripts at all. It is a mess that requires far too much attention and understanding of the language being translated to fix, and certainly not programmatically.
With the Google Translation API, I wanted to get my server to curl the API without installing Google's library. However, all I came across is a page which required an Auth2.0 authorisation page and other irrelevant stuff just to get API credentials. So I searched around and came across another page that allowed me to download two access keys. From there I read more of their documentation, watch theirs and other's videos, but still couldn't find out how to use the keys. So I went to Copilot, which gave me some simple code, but despite our debugging, it didn't work.
At one point I decided to provide Copilot with the fieldnames in the access key file, which it noticed that the key was for a service account, and for which it suggested other code that did work. So, within a couple of days, I went from not knowing how to access the API to having 120 languages fully translated. With the source being HTML and many languages having translations with apostrophes, they were embedded as ', which had to be replaced as they were not needed for Excel or XML.
Manually inserting from the files dealt with that, but it was tedious, though not as tedious as inserting all 1100*120=132,000 text phrases manually. Some languages, like Hausa, have some very long-winded expressions for some single words in English though. Overall, I had dreaded and avoided doing the translations, even though I had good reason to delay until everything was stable. I am just grateful to have it all done within a few days. I expect there will be several reports citing translation errors over time, but they will be easy to fix.
Punctuation△
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 was not 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. I recommend not providing ending full stops, so the the program can add them where needed, while allowing substitutions without having to edit afterwards. That is minimal but useful smarts.
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 is not 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
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
This can be disconcerting as the text, even though it is in another language, does not 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
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.
Non-standard usage△
Most countries have national style guides that specify how to structure constructs like lists, but the internet doesn't always concur.
While most print publications tend to follow those style guides, including what quotation marks to use, because of the cultural pervasiveness of the US upon the early internet, " is commonly used online in South America and even in Europe, likely just because that is what younger generations were used to seeing. So, rather than try to match style guides that are mainly being ignored, I found that there were really only 17 different outer-inner quote mark combinations, so that is what is selectable against each locale.
To cater for possible similar online Anglicisation of other typographical elements, several of the standard language characters can be overridden, such as using lowercase ASCII (a to s) for alphabetical list characters, using . as a list item marker, using Western Arabic numerals (0 to 9) in the sequence element's time readings, using a . as a full stop/period, and a space between sentences. Each of these are selectable individually on a per locale basis.
Navigation△
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
The trick is to have consistent logical structures where such extra links can be, so at least those who do not 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
In general, in Smallsite Design, the breadcrumb jumps are to the IDs in the
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.
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, and having enough time to discover them before foisting a design on the public.