11. 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.
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.
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 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, especially one-word ones, as the translations would often not translate them as nouns. This is where I had to put them in a sentence, which is something I had wanted to do as part of the bulk translation, after what I thought would be the initial experimentation, but ended up doing them individually manually. Machine translation did not do simple stuff like the string of the first 19 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.
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 may 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 headers vertical, requiring that they be read sideways. Originally, I had the adjustment parameters laid out horizontal, so on the summary page for multiple locales, this made it easy to compare the values across the various locales.
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.
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 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.
It may seem like having a menu of jumps to every fifth item at the top of a list helps with getting to the wanted item more quickly, but unless needing to use the list, the keyboard still gets a lot of use because every item in the list still needs to be navigated, as well as each link in the navigation. This is where having a checkbox to at least minimise the navigation helps, but also having direct menu links to various parts of the page, coupled with back links every few items to go back to the top of a block, helps with speedier navigation.
It may seem like using a checkbox to hide the navigation for a list is not necessary if there are menu links to bypass the list altogether, but having a lot of navigation links makes getting to the first few items of the list tedious as the first navigation link jumps over them. In most lists I put up-links to the first item every few links, and then a link after that one to the start of the block. The up-links is rather a compromise as when going forward, they need to be clicked through along with the items along the way to get to the desired one.
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.