Reproduction of this paper, in any form, in whole or in part,
without written permission of Symbian Ltd, is prohibited.
| Copyright © 1999 Symbian Ltd. All rights reserved. Reproduction of this paper, in any form, in whole or in part, without written permission of Symbian Ltd, is prohibited. | |
EPOC and the EIKON graphical user interface are the result of knowledge built up through over a decade of developing software for devices with small screen sizes. This document is distilled from these years of knowledge and experience and gives advice and guidance on UI design for such devices.
EPOC is a software component produced by Symbian Ltd. It consists of the following components:
NOTE: EPOC is adaptable and is designed to be run on a variety of different machines with different screen sizes and dimensions. An EPOC machine and PC package may contain any, all, or just some of the above components. The present document refers mainly to the half-VGA screen size; separate documents are available for other screen sizes.
This document is intended as a guide and reference source for all those developing and customising programs for EPOC machines with half-VGA screens, and who wish their own products to have a consistent look-and-feel with Symbian’s own software. It also contains general guidelines on how to approach development of program User Interfaces that are applicable no matter what the development environment or destination machine.
Symbian's goal in UI design is: Make every user experience a good one. Users may or may not have read the instructions, and may or may not be particularly knowledgeable. They may not be paying attention, or they may be in a rush. They may be experimenting. These are all perfectly reasonable situations for people to be in, so software should try to make the experience a good one in all these cases.
Quite simply, if a program is difficult or unintuitive to use it won’t sell very well and the authors won’t get rich. It doesn’t matter how packed with features it is, how many months - or years - it took to design and code it, or how clever the programmers know that it is, if the intended user can’t figure out they’ll use something else.
Symbian gained its enviable reputation largely because of sales of the Psion Series 3, Series 5 and Siena ranges of palmtop computers, for which we (in our previous guise as Psion Software) designed and produced the software. Far and away the biggest reason for the success of these machines in the marketplace was that they were so usable; ordinary non-technical people were able to work out how to do most of the things they wanted to do on them. As a result the machines had impressive reviews from the computing press (who promoted them as must-have items), ordinary people bought them and recommended them to their friends, and there were many repeat sales from people who upgraded from the Series 3 to the Series 3a, and then to the Series 3c and Series 5.
The same user- and quality-centric approach still applies today. Our software is designed to run on a wide variety of different machines made by different manufacturers, and we work with them to ensure that our UI principles are applied to every machine which carries the EPOC logo. From the very beginning and inception of an idea, we strive to apply the principles outlined in this document so that the end product is as user-friendly and delightful as it can possibly be.
So what makes EPOC software so usable? The biggest contribution to usability has come from the programs that run on the machines. A long, long time was spent designing, testing and improving the programs to ensure they had the functionality users wanted, accessed via a UI they could understand, and were reliable and usable.
UI design can reduce costs and make products more profitable. The better the UI for programs, the less is needed in the way of documentation and technical support, both of which can be costly elements of supporting a product. The easier it is for a user to intuitively use the software, the less likely they will be in need of assistance and the more confident they will feel in terms of purchasing and learning to use a new product.
Good UIs create a standard that other products have to live up to. If UIs don’t keep up with the standards set by the best in the industry, the software will eventually fail. The number of companies in the software market is increasing and users are becoming more sophisticated and demanding; in this climate the development of UIs is becoming a critical factor in terms of competitive edge.
No matter which machine the software is being designed to run on, the ultimate goals are the same:
A program can be designed to perform a lot of different actions, but the majority of users (e.g. 80%) are only likely to use a limited set of actions. A successful program will allow those 80% of users to do all the things that they are interested in. Only then is it fit for the purpose for which the user purchased it.
If the features required by the other 20% of users can also be incorporated without adversely affecting the most important 80%, all well and good; if they can’t, then those features should be left out.
If users don't understand something, they won't have an enjoyable experience.
Inside, the program works one way. The user has a set of desires, concepts, things they understand. The UI’s job is to get the former across in terms as close to the latter as possible so that the UI becomes intuitive to use. If the user cannot find a function, or cannot use it properly, then it will either go unused, or will require a lot of user support in the form of documentation and phone line support.
When the first two goals have been achieved, try to distinguish the program from the crowd of other programs on offer by implementing things which will make the user say Wow that’s really clever, Wow that looks really good, etc. and make them tell their friends, family and work colleagues about it. These will be the same things that get the program rave reviews in the press.
Sometimes the wow factor can be provided quite cheaply - nice graphics and layout on the screen, intuitive actions when the user taps on particular places on screen, or presses a particular keypress - while at other times it can be quite expensive to include.
Different people have different preferred working methods, so the program should allow users to set it up according to their preferences (if possible).
The principles outlined here are the ones that guide our software development here at Symbian. Although they apply equally well to the development of PC or handheld programs, they are arguably more critical to handheld program designs (PC users have invested a lot more in their equipment and will tolerate problems with software more than handheld users).
A program doesn’t succeed because it has whizzo features, it succeeds when nothing’s broken and when all the day-to-day features are powerful enough and easy enough to use for normal people. When advanced features haven’t spoiled simple ones, & simple features spoiled advanced ones.
Key things to consider are:
And, on the downside:
Time is much better spent on things like the above than on fine-tuning whizzo features.
Seemingly simple questions or designs often involve complex discussions in order to come to the best decisions. Think carefully about the variety of things normal users will want to do, and which words and ideas they’ll understand.
Keep asking for comment from others. Be prepared for repeated tweaking as more and more things are found that aren’t sufficiently good enough for real users.
Occasionally a new idea or approach breaks the established norm, ideas such as those following can create lots of extra resistance and debate:
It took large amounts of discussion just to generate these ideas in the first place, then much more afterwards before they were accepted.
Take time with wording - error messages, dialog titles, prompts and so on. The misunderstandings that result from poor wording in UIs are one of the main reasons why ordinary people have problems with using computers. People who design UIs need to take the time to communicate with the user in clear, intelligible, unambiguous words, that can be understood by someone who hasn’t passed an exam in industry jargon.
For example a sequence of setup dialogs might end with the line: Save current settings as default? [Y/N]. But to most people, current settings means those which are currently set - in other words, the way they were before they were changed. A better, and less ambiguous, message would be Save these as default settings? [Y/N]. But, then again, what’s a default? It’s largely industry jargon. So maybe something like: Use settings for: [Just this connection] [All future connections] would be best.
Express things the user’s way, don’t allow the way the program works to influence what is shown to the user, and try always to reduce the average amount of user confusion.
Pay attention to detail:
Some other things to bear in mind:
Starting with release 5, EPOC can also support colour. As much as possible, programs should use the standard colours (as defined in Eikon) rather than have their own colour schemes hardcoded into them. This avoids having programs that use colours which may not be consistent - or may appear unpleasant - with the colours used on a particular device.
In colouring the platform a number of decisions were made which should be adhered to when considering the colourisation of future products:
It is also worth bearing in mind that different devices may have different capabilities (especially in hardware terms), and whereas one may show graphics on screen in all their glory another may dither any too-subtle colours to a uniform grey.
This section contains guidelines relating to the Toolbar, which appears down the right hand side of a program and comprises four buttons and a clock. The shortcut Ctrl-T should be used to show/hide the Toolbar.
With a program that has different views on the same information, and enough oft-used commands that are common to all views, e.g. Agenda, try to use the same buttons on the Toolbar in each view. This allows the user to perform the same actions by the same means in all the views (something that they will expect), and reduces the amount of things that change on screen when they switch view (cosmetically pleasing and results in less confusion...”I’m sure there was a button somewhere that let me do that, but I can’t remember which screen it was on...” etc.).
With a program that has different information in each view, but that has some common and oft-used commands in all the views, e.g. Sheet, include as many of the common commands as buttons on the Toolbar as possible. Where there are not enough common commands, or where there are commands that are more often used than the ones that are common, use buttons that are specific to the individual views. Note that the buttons that are common to all views should appear in the same place on the Toolbar in each view.
With a program that displays different information in each view and no commands that are common to all views, obviously there should be different buttons in each view.
The cascade symbol, shown below, is used to show that there is a list of options, while ellipses indicate that the option displays a dialog.
Reasons being:
People will use these buttons to find out at a glance which view they are on, so avoid having buttons that can be latched down at the same time on the Toolbar. E.g. In Sheet, the Sheet view started off having the Titles button on the Toolbar. Problem with this was that with the Titles on, a user might wonder “which view am I on - the Sheet view or the Titles view?”.
When a button is unavailable it will still depress as normal when pressed, then (typically) the app will display an Infoprint explaining why it is unavailable.
Latching icons are possible, to reflect the current state of something.
The keyboard user must be able to duplicate each Toolbar action by selecting a menu command (which has a shortcut key). (Because it’s important that there doesn’t appear to be 2 sets of functionality in the interface - menus and Toolbars.) In a few cases, though, the keyboard user may then require an extra keystroke or two. Examples of the unusual cases:
Generally, Toolbar buttons should have an icon and some accompanying text. Sometimes an icon works just as well (or better) without text - see the Sketch Toolbar for an example - but it’s very rare to find a situation which works best with text but no icons. Icons are in general more powerful reminders than text. Humans have great visual abilities - pattern recognition. To be really effective, though, icons have to represent things or ideas from the user’s world, of course - and, ideally, be guessable (for example, a pair of binoculars is used to represent find).
Programs that have the same buttons ought to have them in the same position, e.g. Print appears at the bottom of the Toolbar. The following criteria should be used when choosing default Toolbar buttons:
|
Criteria |
Examples |
|
1. Used frequently |
E.g. Today in the Agenda |
|
2. Advertise the major functionality of the program |
Find, Add, Change view, Spell, Print |
|
3. Are “valid” for a high proportion of the time |
Most of the above |
|
4. For “instant” operations. |
e.g. Changing the view - things which don’t need to go via dialogs and/or further keyboard actions |
|
5. Reflect PC apps’ buttons - which actions they are, in which order, and with what sort of icons. |
Both W4W and Excel have this order: New, Open, Save Print, Print Preview, Spell Cut, Copy, Paste, Format painter Undo, Redo/Repeat Bold, Italic, Underline Right, Centre, Left, Justified TipWizard, Help |
|
6. Related to “pen-activity” |
Navigation. |
Agenda (in all views) is like this:
|
Button |
Explanation |
|
View |
Tabs out to a list of all views - shows the major functionality |
|
Sketch |
The main purpose of a Sketch is to enter data quickly, and it’s a pen activity. |
|
Today |
Most frequent operation |
|
Goto |
Calendar navigation - pen activity |
If a Toolbar is provided, it should also be able to be turned off in order to maximise the available workspace.
If multiple views are available in a program, it is important to include Toolbar buttons for moving between them because it advertises the fact that more views are available.
It may be appropriate to have a button for each view, e.g. Sheet, or one button that gives access to commands for each of the views, e.g. Agenda - it depends how many views there are to move to (if there are more than four, use a single button for moving between views), and how many buttons should be included for other often-used commands.
Toolbars are to provide non-novices with the sort of actions mentioned above. Things to avoid on Toolbars include:
There are standard positions for some Toolbar items, which should be followed if possible:
|
Topmost |
Spell |
|
Second |
Find or Sketch |
|
Third |
Find or New |
|
Bottom |
Go To |
This section contains guidelines relating to the Toolband, which appears along the top of a program and typically contains text and paragraph formatting options. The shortcut Ctrl-Shift-T should be used to show/hide the Toolband.
For cosmetic reasons, the spacing and size of buttons on the Toolband should be as regular as possible.
Try to group related buttons together and separate the groups with spaces. E.g. in Word:
Style - Font - Font size - | B I U | - Alignment - Borders - Bullets
Buttons for changing font, then buttons for emphases, then buttons for formatting entire paragraphs.
Similarly in Sheet:
Font - Font size - | B I U | - Alignment - Borders - Shading - | Freeze Panes - Sum - Functions
Buttons for changing font, then buttons for emphases, then buttons for formatting highlighted blocks of cells, then special features.
Don’t have all the buttons squished up to one end leaving the other end empty, or buttons at either end of the Toolband with a big gap in the middle, or irregular spacing between buttons.
The best approach is to group buttons where possible (e.g. keep the font name and font size buttons together, the B I U ones together), then spread the groups of buttons out along the length of the Toolband so that the gaps between the groups are the same.
Note that some machines may have larger screens; for this reason Toolbars should automatically rescale so that the spaces remain even.
For cosmetic reasons, limit the number of sizes of Toolband buttons. Allowing many different sizes of buttons in the Toolband makes them look untidy and unprofessional. Ideally, just one single size of button would be used in the Toolband, for neatness sake. However there are different sized icons and text to place on the buttons, and some buttons need a little down arrow to indicate that they drop down a list, so 4 different sizes of button are used. Each program should use no more than 3 of the 4 sizes available, as follows:
Some programs may need to have custom buttons. E.g. Sheet Graph view has an 83 pixel sized button for Label type, Legends etc.
Buttons on the Toolband should be reserved for actions that take immediate effect and should not be used for actions that require a dialog to be displayed first
Wherever possible - wherever it can be done without compromising anything else - make controls big enough to be pressed by a finger.
The arrow keys are used to navigate up, down, left and right - normally one step (e.g. one time slot, or one item on a list) per press. The Ctrl and Fn keys are used to increase the size of the steps.
Pressing Ctrl+ arrow key increases the size of the step, Fn+ arrow key (the Home keypress) increases it still more, and Ctrl+Fn+ arrow key moves the maximum possible in the appropriate direction. However, if there is a different action which might be expected (e.g. from PC usage) by a Home keypress, use this instead. For example, in the day view of Agenda, Home/End go to the top/bottom of the view, while Ctrl+Fn+left/right still move by a bigger amount (which in this case is move-by-week).
Use dogears to indicate the area of the screen to tap to turn pages rather than single arrows when the screen display is a representation of a physical page e.g. Agenda.
Wherever a user can select an item without necessarily performing an action on it, e.g. selecting a file in the System screen, use a single-tap to select the item and a second tap to perform an action on that item - as opposed to a double tap. (Of course, the user can double-tap if they desire, it has the same effect as two single clicks.)
Double-taps are provided for in Eikon, but are not specifically used in the built-in programs because it is an awkward action for users to achieve on the screen - especially on the move. 3rd party developers can use this feature, although this will not be consistent with EPOC.
EPOC programs are referred to by their names. These are generally single words derived from a description of what the program is or does - for example Word is the word processor (not the word processor program), Contacts is the contacts manager (not the contacts manager program), etc.
Try not to use a full stop if the line of text comes in two parts; use a hyphen to separate them instead. For example, instead of Cannot paste. Copy and paste areas are different use Cannot paste - copy and paste areas are different
Where the text is user-generated, e.g. the name of a user’s file, or the text string that they have chosen to replace, use double quotes - for example, “Diary” found.
Note: filenames that are generated by the machine, e.g. Word(01) etc., should be treated as though the user has entered the name of the file, otherwise we’ll have inconsistent use of quote marks around the names of files the user can edit.
Where the text is generated by the machine, e.g. the name of a program, or a system file that the user cannot edit, use single quotes, e.g. `Word’ not present.
If the source is uncertain, e.g. for countries in Time, treat them as though they are generated by the user.
EPOC filenames are case-sensitive at a UI level, and retain the capitalisation they were given when created, but the filing system does not distinguish between upper and lower case. It is therefore not possible to have two files of the same name in the same folder, even if they are capitalised differently (e.g. Fred and FRED)
Files and folders created by EPOC programs should always have an initial capital letter. If the file or folder name consists of more than one word, any subsequent words should not be capitalised unless they are a proper name.
Files and folders created by the user should maintain the capitalisation given them by the user.
Use capital letters on the first word in a menu command only, i.e. Create new file and not Create New File or Create new File (or Create New file)
Similarly, only the first word in dialog line text should be capitalised.
Be consistent in use of capitalisation in UI (inconsistent use of capitals makes the UI look messy and unpolished).
To be consistent with EPOC, use a capital letter on the first word of resource strings only unless a subsequent word is a proper noun. For example, use Day entry preferences as a command, not Day Entry Preferences, or Day entry Preferences. For multi-word dialog lines and menu commands, use one initial capital letter only - e.g. Create new agenda, not Create New Agenda.
When the name of a folder or file is a single-word contraction of two or more words, e.g. EikExtra.dll, the first letter of the second word may appear as a capital letter within the filename.
Files and folders created by a user should appear in the form in which the user entered the name (either at the time of its creation or during a later rename), with upper- and lower case letters appearing exactly as the user entered them.
File names are displayed using the capitalisation as entered by the user and not automatically capitalised (though the pre-defined files have capitalised names).
If the user types “xyz” they get it in lower case.
However the user cannot have two files with the same name in the same folder, even if they are capitalised differently (e.g. “FREDA” and “freda”). This happens automatically.
This section contains guidelines for the menus and shortcut keys.
Cascading menus are the commands which lead to further options, indicated by an >.
Consider cascaded menus wherever there are more than 6 (for half-VGA screens; adjust appropriately for other DFRDs) commands on a menu, and some of them are rarely-used or hard-to-understand commands.
Because otherwise:
Cascaded menus are best kept towards the bottom of a menu tile, to stop menu users being shocked by the appearance of the cascade while moving down to a non-cascaded command they want.
Cascaded commands should still be accessible by shortcut-keys where appropriate.
Don’t get too keen with cascaded menus as there are drawbacks, such as people unable to find commands & having to go into every submenu to find them, and menu users finding it all too fiddly.
Also, always consider - can a single command be used, with a multi-page dialog, instead of several commands?
Notes:
Switch View: <list of views> or Alignment: <Left, Right, etc.>.
The half-VGA EPOC machine has a relatively small screen size, all the more reason to hide some commands behind a more cascade
If a cascaded menu looks poor in the middle of a menu try putting it at the end, especially if it contains commands that toggle and that are likely to be frequently used.
For example, in a read-only Agenda file, the Create new entry cascade on the Entry menu should still display its commands even when the file is read-only, and the commands are dimmed. The user must be able to see what all the commands are, even if they cannot use them at this moment, otherwise it appears that commands disappear and then reappear later.
For example, on the File menu when viewing an inserted document there may only be 2 options: Print and Close. Since a cascaded command should not be first one on a menu, and it would look odd anyway, all Print options should appear on the top level here.
Cascaded commands should be kept should short, so instead of:
More >
Create new this
Create new that
Create new other
the cascade should contain just the closing half of the item, as in:
Create new >
This
That
Other
This is to avoid the situation where the cascade is forced to pop up on the left of the menu rather than the right, because of the length of the text in the cascaded commands.
Menu cascades should be thought of like Option buttons in a dialog. Do not re-state the prompt for each item.
Menu tiles should not be too wide either.
App authors should consider re-arranging menu tiles, combining menu options, using multi-page dialogs, etc. to avoid the problem.
However this problem is fixed, it is never going to be as good as avoiding the problem in the first place.
Try not to use More as the name of a cascaded menu command. If at all possible, try to find a better term for further commands. More should only be used as a last resort term.
E.g. instead of having a cascade like:
More >
>Edit sketch
>Edit voice note
>Edit memo
Try using
Edit object >
>Sketch
>Voice note
>Memo
If there is a More command on the File menu, it can contain any of the following commands (in this order):
Save as...
Save
Revert to saved
Merge in...
Import text file...
Export/Export as text file...
Tidy/archive file...
This is a bit of a murky area, and may vary between programs, but in general the differences are as follows:
Settings
This menu command should be used for setting things which, once set, will probably be left alone - e.g. a communications program might have modem settings.
Preferences
This should be used for commands that allow the user to customise the program, i.e. change the way things are presented on screen, change the features that are available, change the default settings for things etc.
Options
This should be avoided, if possible - try to find an alternative which gives a better idea of what it leads to. If it is used it should contain commands that are alternatives to each other.
Use More… instead of Options to give access to additional commands that won’t fit on the top level on a menu.
This section contains general guidelines about menus and shortcuts, and lists the standard menu commands.
Otherwise they are too difficult to use in practice.
In the same way that dialog lines that are currently unavailable are greyed out, menu commands should also be greyed out.
Makes it obvious to the user that they are unavailable by providing an infoprint, because this is much more satisfactory than providing a host of messages that say Cannot do this... etc. etc.
Note: where a menu command is a cascade, all its options should appear greyed when unavailable. Do not hide the commands otherwise the user may think that something has gone wrong.
E.g. Record & replace in Record, instead of Record and replace. It looks neater and makes the text string shorter.
Use them to group commands that have some relationship to each other, and separate them from commands that are unrelated, but that appear on the same menu, e.g.:
Create new file
Open file
-------------------
Close
Do not use lines around single commands, unless the command is at the top or bottom of the menu. A menu tile will quickly seem line-bound if there are lines around single commands in the middle of the menu. E.g. don’t have:
Create new file
Open file
-------------------
Printing
-------------------
More
-------------------
Close
If this happens, try rearranging the menu tiles. E.g. the above could be:
Create new file
Open file
Printing
More
-------------------
Close
Do not use lines between commands on cascades. This makes the cascaded command appear even more complex.
Move commands to other menus, create more cascades, or try changing the wording of the commands so that they fit more happily within a group.
So that users notice them first.
Although the first command on a menu has prominence, don’t forget that users will also notice the command at the bottom of a menu just as much.
All menu commands that display a dialog should have an ellipsis at the end, e.g. Page setup.... To keep the menu command as short as possible, there shouldn’t be a space between the last letter of the command name and the ellipsis character.
Note that commands that display a dialog to give information about the progress of something that has started as a result of selecting a menu command, e.g. Infrared Send and Infrared Receive, should not have ellipses. The action has already started before the dialog is displayed.
All commands that move up and down a small number of settings - like Zoom in and Zoom out - should cycle round the various settings, rather than coming to the end of the list and forcing the user to use the other command to go back. A user who is trying to find the best setting should be able to move between them all without changing keypress. This mirrors the action of the arrow keys when moving between menus, and between commands on a menu (the right arrow key, for example, goes all the way to the right until it gets to the end, when it goes back to the far left).
If there are more items than will fit comfortably onto a menu (for a half-VGA screen eight items is just about the limit), try reorganising them, or move infrequently used options onto a cascade. If an extra option has to go onto a menu, try using fewer dividing lines between them.
Don’t use scrolling menus if at all possible. If a scrolling menu is unavoidable, don’t allow it to wrap back to the top when the last item is reached.
Commands which lead to dialogs should be shown ending in the ... character.
Commands which have a cascaded menu are shown ending in the right-pointing triangle character.
(There’s no need to use these characters if/when referring to them elsewhere - e.g. in Help, Infoprints etc.)
The menu contents should generally be fixed. For example, the commands should not change around when e.g. shifting to a new view. (If it’s an entirely different view, requiring entirely new menus, then sure - like in Sheet - because the user’s asked for a completely different mode. But avoid subtle changes, as they only confuse.)
Some entries change their names slightly to reflect the state of the program. For example, Undo might become Undo Deletion.
Avoid flip-flop command names - like Wrap on becoming Wrap off - for the obvious reason that users often aren’t sure whether it’s saying what the setting is, or what it will be if the command is used. Use tickboxes on menu commands instead. This example should just always be e.g. Wrap to screen, and have a tickbox.
Since the Save as and Merge in dialogs need to be kept as simple as possible, all the import/export stuff should be put in separate dialogs (rather than adding a File type line to the Save as and Merge in dialogs).
So the appropriate apps will need Import file and Export file commands. The commands should be at the end of the More choice list on the File menu.
As:
Infrared >
> Send
> Receive
Reasons: Not used very often. Also makes the last menu tile narrower - good plan because this helps to prevent other cascades having to appear to the left of the menu tile.
The Switch view command (if applicable) should cycle through preferred views, and should use the Ctrl-Q shortcut.
Switch view should also cascade, giving the list of alternate views:
Switch view >
>> Day view
>> Week view
etc.
etc.
Note - the Switch view shortcut key cycles through the views.
If the shortcut for a menu command will not work while the menu is displayed, the shortcut key should not be displayed on the menu unless it’s a very common command that users might want to know the shortcut for.
For example, in Word, the Insert - Page break command is shown with a Ctrl+Enter shortcut. However this keypress does not work while the menu is displayed and a user might get confused if they call up the menu and then use the keypress. In this case the keypress is shown anyway, because it advertises functionality and is a very useful one to know, but generally this type of shortcut keypress should not be shown on the menu.
For example, don’t include shortcuts for the commands that cascade from a View button in the Toolbar (See Agenda for an example), or that cascade from the Command icons to the left of the screen (Infrared Send and Receive etc.).
These commands are all pen activated when they are selected from the button, so they do not need keyboard shortcuts. They have shortcuts for the equivalent commands available from the menu bar.
Including shortcuts would also make the lists of commands too wide.
Use the standard ones for standard commands, then allocate shortcuts so that the most commonly used commands are given priority. When all those have shortcuts, consider the less often used commands.
Choose shortcuts that are easy to remember - using a letter from the command name is a often a good plan, or a letter that sounds like the command.
Don’t have e.g. Undo & Redo using the same key, one of them shifted and the other not. Users may forget whether or not they are supposed to use shift with the shortcut, so make sure that the exact opposite of the user’s intention is not carried out if they press the wrong keypress.
If a standard shortcut has to be used for a non-standard command, make sure that the standard command is not also used with a different shortcut, and that nothing bad happens if the user presses the shortcut anticipating the standard action.
If not, allocate them to the most frequently used commands and/or the most inaccessible ones (e.g. those on cascades) first.
Provide shortcut keys for the more commonly used menu commands. Shortcut keys should contain either CTRL, or CTRL & SHIFT and a letter. They should not contain numbers.
In the table that follows, CTRL+ letter shortcuts are denoted just by the letter, e.g. U means CTRL+U, while shifted shortcuts are denoted SH-U.
Here are the standard menu tiles and their contents:
|
File |
Edit |
View |
Insert |
Format |
Tools |
|
Create new file N Open file O |
Undo Z Redo Y |
Zoom in M Zoom out Sh- M |
Sketch Graph Other |
Bold B Italic I Underline U Paragraph > >Indents >Tab positions >Horizontal alignment >Vertical spacing |
View preferences K General preferences Sh-K |
|
Password Sh-Q |
Cut X Copy C Paste V Delete/Delete all D Select all A |
Show Toolbar T Show Toolband Sh-T Wrap to screen W |
|
|
Spell check L Thesaurus Sh- L Word count Sh- W |
|
Printing > >Page setup Sh-U >Print setup Sh-P >Print preview Sh-V >Print P |
Find F > > Find next J > Replace H > Go to G |
Switch view Q > > List of views > Name view |
|
|
Infrared > > Send > Receive |
|
major, app-specific |
major, app-specific |
major, app-specific |
|
major, app-specific |
* Help on program Sh- H * About program Sh- A |
|
More> >Save as Sh- S >Save S >Revert to saved R >Merge in Sh -I > Import > Export >minor, app-specific |
Object> > Edit object... Sh- Z > Format object... Sh- J More> > minor, app-specific |
More> > minor, app-specific |
|
More> > minor, app-specific |
major, app-specific |
|
Close E |
|
|
|
|
More> >minor, app-specific |
* = 3rd party programs only
Note: If a program has an Insert menu, it should be positioned between the View and Format menu tiles.
Try not to have more commands than will fit tidily on a menu (for half-VGA screens the sensible maximum is eight) - use cascaded commands to avoid this. This menu tile layout shows 9 on the Edit menu for the purposes of showing which commands should be included on this menu. In practice none of the apps use all the Edit commands that are listed here.
Below is a list of all the standard system shortcuts. Avoid all of these shortcuts for program specific functions and use the remaining unclaimed shifted shortcuts instead. Bear in mind that it is only necessary to supply shortcuts for the most commonly used functions - keyboard users always have the option of doing the three-key <menu>-<tile>-<command> keystroke to invoke a menu command - so it’s not a big deal not to have a shortcut for everything.
The platform-wide “standards” (in English) will be:
|
Ctrl+ |
Normal keystroke |
Shifted keystroke |
|
A |
Select all |
* About Program name |
|
B |
Bold |
|
|
C |
Copy |
Insert special character |
|
D |
Delete |
|
|
E |
Close |
|
|
F |
Find |
Font |
|
G |
Go to |
|
|
H |
Replace |
* Help on Program name |
|
I |
Italic |
Merge in |
|
J |
Find next |
Format object |
|
K |
Preferences |
|
|
L |
Spell |
Thesaurus |
|
M |
Zoom in |
Zoom out |
|
N |
Create new |
|
|
O |
Open |
Insert object |
|
P |
|
Print setup |
|
Q |
Switch view |
Password |
|
R |
Revert to saved |
|
|
S |
Save |
Save as |
|
T |
Show Toolbar |
Show Toolband |
|
U |
Underline |
Page setup |
|
V |
Paste |
Print preview |
|
W |
Wrap |
|
|
X |
Cut |
|
|
Y |
Redo |
|
|
Z |
Undo |
Edit object |
applies to 3rd party programs only.
Don’t change the menu contents, grey them out & display a message instead when they are not available. Tickboxes are better than flip-flop commands.
Use dividing lines between related commands and standard shortcut keys.
Hide scary, unimportant, or little used commands away on sub-menus.
As with menus, the overriding principles are clarity, simplicity and reassurance. Be positive if at all possible, and word dialogs in such a way that it's easy to understand what they mean. If they have advanced (ie incomprehensible) settings, then add an Advanced... button.
This section contains guidelines about dialogs.
Generally:
Many dialogs won’t need anything other than the command name. Use longer dialog titles wherever it helps explain what the dialog is for. For example (as mentioned elsewhere) certain dialog titles can give a big hint that Agenda(s), WP documents etc. are different types of “files”: the title for the Create new file dialog should be Create new Data file; for Open other file it should be e.g. Open other Word file.
If the dialog title needs further explanation, try rewording the menu command to make it clearer what it means.
For example, with a dialog to give information about an object that has been inserted in the current file, the title Inserted object info would be much better as Information on inserted object because the dialog is then linked to the name(s) of the commands, etc., that are used to insert objects (e.g. in Word).
Don’t show the effects of any changes the user makes in a dialog, until the dialog has been confirmed, i.e. don’t have the screen redrawn behind the dialog.
For example, Data has a dialog to change the layout of columns and the fonts used. The effects of any change the user makes to the layout and font are not shown until the dialog has been confirmed and removed, because:
In multi-page sequential dialogs and wizards, don’t save the settings until either the sequence is over or the user presses OK to exit the sequence. If the user presses Cancel, all changes made should be lost (though a confirmation dialog would help here).
If a dialog has so much text or other contents that it is necessary to scroll through more than a single page, do not wrap the dialog - i.e. don’t return to the top when the last item is reached.
When dialog lines are dimmed because they aren’t available, the controls should also be made invisible as well. For example: in the Tools-Sound dialog in the Time program the Silent for (hh:mm) setting is dimmed unless the Alarm sound”on the above line is set to Silent for. When the text Silent for (hh:mm) is dimmed, so should the controls 00:30.
Dialog lines should be dimmed rather than made invisible when they aren’t available.
In dialogs that have edit boxes for numbers in a particular unit of measurement, e.g. the Indents dialog in Word, put the measurement unit that is currently in use as small text after the edit box rather than before it. For example:
Indent: Left [0.00] in
rather than
Indent: Left (in) [0.00]
Putting a second question in the dialog implies that the user can’t be trusted to make the decision without a second confirmation.
Instead, phrase the confirmation in the form:
You will lose all the changes
Revert to saved?
Y/N
Exit and lose changes? is much clearer.
(Or anywhere else, for that matter). Check the following example - it isn’t clear that closing the link will render it inactive.
Close link to desktop?
Link to desktop is active
No Yes
Some dialogs are not understandable at first glance, no matter how carefully they are worded, and others contain jargon or abbreviations that may not be familiar to many people.
In these dialogs, add a short line of explanatory text at the top of the dialog to make things a bit clearer.
E.g. in the Time program, in the Add city dialog, the explanatory line GMT offset’ is time difference from Greenwich Mean Time appears, and the Add name dialog in Sheet says Note: Value can be a number, text, cell or range reference.
Dialogs that contain long text strings and a lot of settings can appear overwhelming and difficult to understand to the user, but they can also cause problems with localisation - text strings in other languages are generally longer than in English. A dialog whose dialog lines & setting boxes look alright and fit in English may not work when translated into German, for example.
When localised into other languages, text strings grow by about 30%. Make sure that the English wording leaves enough room on the dialog for them to grow by that much. A rule of thumb is: for each dialog consider the longest text string used to label a setting box, and the longest text string within the list of settings for that box. If these two together won't fit in the dialog when they grow by 30%, localisation won't be easy and the text needs changing.
If a dialog has long text strings and/or too many settings, try:
It looks neater and makes the line of text shorter.
When the setting on a dialog line (let’s call it Line B) is related to the setting made on a previous dialog line (let’s call this line, Line A), should show this relationship to the user. There are a number of ways to do it, depending on the relationship involved:
If the setting on the Line A determines whether or not the user can change Line B, use dimming. Line B should be active only when the appropriate setting has been selected on Line A.
Note: if the dimmed label of Line B does not indicate that Line B is related to Line A, indent Line B as well. E.g. in the Import options dialog in Data, the text Use on the line following Text delimiter does not make it sufficiently clear on first glance that this line is related to the Text delimiter line. So the Use line is indented to make it clear that this line is related to the line above.
If there is a dynamic relationship between the Lines A and B such that a change on either line updates the other, then use indents to show the relationship between the two. For example, in Agenda Find dialog between the lines Find range and the From and To lines that follow.
If the EPOC machine has a special Help key combination, this should always display the default machine Help. 3rd party apps should include a command (on the Tools menu, if it exists) called Help on program name, and a further command to display the About program name dialog.
Some 3rd party programs, and additional programs, will need About dialogs. Where they are to be included, they should be accessible from an About xx command which should be placed at the bottom of the Tools menu in the program.
The shortcut for the command should be Ctrl-Sh-A.
The text and/or graphics that appear in the dialog should be determined by the owner of the particular program.
The text should contain, as a minimum, details of:
Program name and version.
Copyright symbol, copyright holder name and date.
All the rest is up to the program owner to decide.
If there are a number of preferences that control how the information looks on screen and how the program works (e.g. 3 view preferences and 2 control settings), separate the View preferences from the control preferences and refer to the control preferences as General preferences, but if there is only e.g. one view preference and one control preference, just have one Preferences command on the Tools menu.
Keeping the view and control preferences separate like this allows more space to increase the number of preferences in future versions of the program, if necessary, and also advertises the fact that both the appearance and behaviour of the program can be changed.
In dialogs where not retrying can cause loss of data (e.g. in disk error dialogs) or an action to remain unfinished, use Stop and Retry buttons instead of Abort or Cancel. Abort can have unpleasant associations and Cancel implies that the situation can be returned to the way it was before (untrue, because data will have been lost).
If a button in a dialog for a standard program command has a shortcut keypress of Shift+keypress, also allow the unshifted keypress to perform the same function and display the unshifted shortcut as the legend under the button.
E.g. a Font button in a dialog should be activated by the normal associated shortcut (Sh+Ctrl+F) and also Ctrl+F. Ctrl+F should be displayed as the legend under the button.
And other words that users may not know
It is quite common for error messages to leave out the verb, with the result that users who don’t know which words are jargon can’t work out the syntax of the sentence. For example, take the error message Cursor not on entry. What does this mean? Is cursor an imperative (i.e. don’t cursor on an entry)? Cursor is not on an entry is clearer.
In almost all current software, error messages are full of these! Re-read any error messages from the point of view of a novice with no knowledge of terminology etc., and try hard to misunderstand it. Check that it is jargon-free or, if jargon is unavoidable, is it clearly marked as such (e.g. in quote marks)? If the user does not know which words are jargon and which are not, the dialog should still be clear and unambiguous. Could any of the nouns be misread as a verb, or vice versa?
File does not exist should be File not found or similar. The user may have mistyped the filename, or be in the wrong folder, and not realise it; File does not exist implies that the file has vanished.
There is an unrecoverable error on file XXX. To the user, unrecoverable means you cannot now recover your file! Should be something like Problem while trying to save file. Check your file is OK.
If possible, give likely explanations and/or courses of action. Ideally if printing fails don’t say Invalid printer or some such, say what it might be (the printer’s off-line?) and e.g. have buttons for actions like print it when possible (i.e. spool it) etc. Try not just to say wrong!. Matching requires sorted file - well why not tell them how to sort the file then? Use the Sorting option before matching?
If a program has to stop responding for a few moments, e.g. while searching or sorting, tell the user that it’s OK for this to happen, try to indicate how long there is left (if possible), and let them cancel it if at all possible. When displaying a progress bar for e.g. a multiple file delete, try to indicate the time remaining for the entire process (and not individual progress bars for each file).
Try to avoid messages saying things like Invalid data if a user enters something the program can’t handle. Try instead to find a way to make the program handle a variety of possible inputs. For example, if a dialog asks for a distance in the form Distance is [ ] cm, try to do the right thing if a user types 5 cm (or 2 ins) in the entry box.
Don’t make it sound like it’s the user’s fault for not knowing. Don’t say Invalid data if the data may look perfectly valid to the user.
Don’t say please this, please that. Instead of Please enter a number, just say Enter a number. Users can get irritated by having to read a large number of pleases, and this also makes for shorter text in other languages.
If the user presses Enter in a dialog and fails to set a line that is validated before the dialog can be closed, display a message saying e.g. No xx name entered and move the cursor to the line that the user must set.
If the user has failed to set several lines in a multi-page dialog, display the same message and take them to the first line to set then, when they press Enter again, display another message and take them to the second line to set, and so on.
Beware of these - users may not know how to turn the dialog back on once they have turned it off. If this option is included on a dialog, include the option to turn it back on again with the program’s preferences..
Because the annotation text is smaller than the dialog text, it appears to the eye that the annotation text is always linked to the dialog line above it.
Instead of using two or more paragraphs for annotation text, try to use a single paragraph with line breaks in the resource file where necessary.
This helps during translation because text can wrap more easily with wordy languages, and doesn't take up so much space.
Whenever a program quotes some text which appears elsewhere, the quoted text should appear in quotation marks. Whether to use single or double quotes depends on the source of the quoted text.
When a file name has been generated by the machine, e.g. Word(01), this should be treated as though it were user-created (i.e. double quotes) in order to be consistent with quote marks around editable filenames.
Sometimes, dialogs in software seem to appear for no reason other than for the programmer to throw up all the settings they know about, at a point convenient to them (it’s almost as if they’re saying OK, I understand these settings. You can try and set any of these things - if you know what they mean, that is).
This is an appalling thing to do in a UI. Generally the user doesn’t usually want to see a dialog at all, they just want to tell the program to get on and do a nice simple thing (if these settings really need to be made available hide them behind an Advanced button)!
Two things to bear in mind:
Infoprints show feedback messages clearly but in a non-intrusive way - they don’t require an OK click to make them go away.
Infoprints and messages are used to give the user feedback about something that is going on, and yet they often seem to be among those areas of UI which have had the least attention paid to them. Error messages, particularly, often give the appearance of being whatever the programmers fancied saying, whenever they fancied saying it. So a little attention to detail here can make a big difference.
Users need feedback to know that the command they’ve selected has been carried out.
In most situations something will happen on the screen to mark the action, e.g. a dialog will appear, or the text they’ve typed will change in some way. Other commands, however, cause no change to the contents of the screen; provide an Infoprint to show the action has been carried out - Copied, Saved etc. - or sound a Beep when an Infoprint isn’t appropriate.
If a command cycles between settings which have no obvious effect on screen, display a message in the bottom left corner of the screen to let the user know that the action has taken place.
In certain situations (mainly in the event of potential or actual loss of user data) it is better to use a confirmation dialog rather than just displaying an infoprint - e.g. say Are you sure? Your entire Agenda will be deleted rather than your entire agenda has been deleted.
For example, instead of displaying Please wait (which gives the user no clue as to what they are waiting for), display a specific message. e.g. while a merge in is taking place, display Merging in....
And put ... at the end - it implies that the user has to wait, without saying so specifically.
If a program is trying to say e.g. Everything’s fine, or You have a virus!, it had better make sure it’s clear which it’s saying. A common virus checker says, after checking a file named Mydoc.doc:
Scanning C:\MYDOC.DOC
Summary report on MYDOC.DOC
File(s)
Analyzed…………………. 1
Scanned………………….. 0
Possibly Infected……… 0
Time: 00:00.00
But it’s difficult to understand what this means. If it analyzed the file, why didn’t it scan it? This is undoubtedly some program-specific use of the words analysed and scanned - but that’s no reason to throw them as-is at normal users, to whom it just looks like a mistake.
Also, here the phrase Possibly infected leaps out at the user. There’s a zero which is related to it, but it so far over to the right of the screen it isn’t obvious at first glance; it is failing the principle of having simple indications of goodness and badness. Instead of Possibly Infected…..0, What's wrong with No files infected (or no viruses found)?
And what about Time: 00:00.00 - is this the current time (ie it’s reset the PC’s clock to midnight), or is it saying how long it took to run the program? If the latter, does the fact that it took no time at all to run mean that it didn’t run after all? (What use is this information anyway, even if it was saying a non-zero time? Since other apps don’t say how long they took to run, it just makes people think this app must have some special time-critical nature which they don’t know about.)
Static messages, e.g. infoprints like Entry copied, should appear in the top right-hand corner of the screen where people are likely to notice them. Busy messages, on the other hand, should appear in the bottom left corner of the screen. The reason for this is that the two types of messages can’t appear in the same place on the screen, and the user is likely to move their hand away from the screen while busy messages are displayed (no further actions can be performed while these messages are on screen).
For example: when something which has been copied cannot be pasted somewhere else, because the destination does not accept the type of information that has been copied, don’t say Cannot paste - different type of data required here, just say Nothing to paste.
Remember that they are only on the screen for a short amount of time, so users will not be able to read and understand a message that’s very long. For example, the message: The disk has been removed - please replace it, can be shortened to Disk is not present without any loss in meaning for the user.
Don’t use Busy if the user is having to wait because the program is searching for something, display a Searching... message.
Likewise if the program is recalculating, say Recalculating....
For instance, if a message or status bar would otherwise say xx file(s) selected, use two different messages: 1 file selected and xx files selected. This avoids the ugly and inaccurate message 1 file(s) selected.
Where xxx refers to the thing that is to be named - e.g. No folder name entered.
Infoprints and messages should only be used as on-screen confirmation that something has happened, or not happened, not for explaining why certain things occur, or don’t occur.
They stop the proceedings and interrupt the user’s interaction.
A hammer has a good UI. If it is used properly all is well, but if it is used badly it doesn’t stop and say: You Bent The Nail Five Degrees (You Idiot)! [Abort].
Just state the possible causes of the problem. For example, the message Problem with Infrared - check that the serial port is not in use, and that there is enough free memory would be better as Problem with Infrared - serial port may be use, or there is not enough memory
This section contains guidelines for error messages.
Only display error messages when it is unavoidable, and word them carefully. Sometimes error messages just look like stupidity on the part of the program; most, even though they seem innocuous to the programmer, make many users think they’re being told they are stupid. Most people would rather that if they did make a mistake it got lost in the noise, or ignored, or (ideally) taken care of.
Try to indicate exactly what has gone wrong. E.g. don’t give a message like Invalid data when the cause of the problem is that the user has set a combination of margins that is too large for the page size that they have set to print to. Display a message like Combined margins too large for paper size. That way, they will see that they either have to change the margins or the paper size in order to solve the problem.
And what sort of language to use
If a command is disabled or temporarily unavailable (e.g. in Time/World the Infrared Send and Infrared Receive commands are not applicable) it should nevertheless be displayed, but dimmed-out to show that it cannot be used.
Provide an infoprint, e.g. This item is not available, to confirm that the user has indeed tried to implement it and that the machine has received the command.
This section provides guidelines for buttons in dialogs.
(other than OK and Cancel.) They’re OK, but they’re not great. Use e.g. multi-page dialogs instead, where possible.
Buttons are not intuitive to keyboard users - the keypresses they require often seem random or unrelated to the action.
If a dialog has Cancel and OK buttons (which the vast majority of dialogs do), they should appear as a pair at the bottom right of the dialog. OK at the far right-hand side, Cancel to the left of OK. Any other buttons should go above the OK button, starting at the top right of the dialog and working downwards. If you have a New button, this should be positioned at the bottom left.
If necessary (e.g. the full screen width is needed for the rest of the dialog, or the dialog looks too unbalanced with buttons on the right) other buttons can appear in a row along the bottom starting from the left-hand side, but try to keep the Cancel and OK buttons in their default position.
On a multi-page dialog all exit/confirm buttons (i.e. those which exit the dialog) must be outside the pages. (Cancel must cancel ALL settings made on a multi-page dialog.) Those which apply to a particular page must be on that page.
Always have standard exit button names. 90% of dialogs should just have OK/Cancel (at the bottom right). Alternatives which should cover most other dialogs are:
Don’t use OK as a confirmation when telling the user something bad. Continue (or maybe even Sorry!) is better when a situation is clearly not OK! Also, bear in mind that the meaning of an OK button may not be obvious to people who are not familiar with computers; for example when presented with a disk format dialog which says formatting will remove all files from this disk and has an OK button, how many people would take OK to mean I understand what you’ve just told me or start formatting now?
Avoid using double negatives between dialog text and button text (e.g. Cancel changes? [OK] [Cancel]).
Except in rare circumstances, don’t change the meaning or wording of a button or keypress on a dialog. Such a change in meaning would have to be sufficiently obvious to the user to override the general consistency principle.
Don’t change modally - keep menu commands and button text the same no matter what the context. In other words, if a button performs a particular function don’t make it do something else in another context. If necessary dim out any which do not apply.
Enter is the Do it key in dialogs, but is not always a dialog completion key.
For example, imagine a dialog which was exclusively for entering as many numbers as the user wanted to enter. In this case Enter might be used to mean Enter number, and the dialog would be closed by means of a Done button. In this situation it might be that no overall Cancel action were required, or else Esc might be the Done key with a confirmation to Save Changes, for example.
Users will therefore know that whenever they see an ellipsis the command/button (whatever) presents a dialog requiring further information before performing an action, and that whenever there is an arrow on a button there will be two or more options to choose from.
Any dialog whose title ends in a question mark should have Yes/No buttons, and not OK/Cancel buttons.
Y/N buttons in dialogs (used instead of OK/Cancel in dialogs where the title is a question) should also be activated by Y/N. N should also be activated by Esc, but Y should not be activated by the Enter key (it’s too easy for users to make a mistake in confirmation dialogs that use Y and N).
This shows the user that they are working on an inserted object and not a separate file. It also confirms that any changes will be saved as opposed to Exit or Cancel buttons which might imply that any changes would be lost.
When a dialog has a Save button, which saves changes but does not dismiss the dialog (e.g. the New entry dialog in Data), a Close button should be used to exit the dialog. Using Cancel might make the user think that all the entries they’d added will disappear.
Use Close rather than Finished because it is the same word which is used instead of exit in the programs (also it fits better on the button).
Buttons in dialogs normally have the keyboard equivalent printed underneath them. The exceptions are the OK and Cancel buttons in dialogs, which don’t need explanatory text unless the keyboard alternatives are other than Enter (which means do it) and Esc (which means remove the dialog and don’t do it).
Always specify keynames for buttons that use other than Esc and Enter.
If there are only two buttons in a dialog (e.g. Insert text and Cancel), don’t put a legend under the Insert text button unless the key that activates it is something other than Enter. Do not put Esc under the Cancel button either.
If a dialog has a secondary dialog which appears as a result of an action on the first dialog, any buttons on the secondary dialog should be in an equivalent position to those on the first (e.g. if the first dialog has buttons along the bottom, the second should also have them there and not down the side). However, they should not be in exactly the same position on screen pixel-for-pixel.
For example, the Create new entry dialog in Agenda has Alarm/More…, Cancel, and OK buttons down the right-hand side. The OK and Cancel buttons in the dialog which appears when the Alarm/More button is pressed are also down the right-hand side, but not directly over the buttons in the previous dialog.
Dialogs with more than 2 buttons will typically have a mixture of labelled and unlabelled buttons. If the buttons are placed along the bottom of the dialog this can look odd, so they should be placed vertically down the RHS with some extra space between the labelled button(s) at the top and the Cancel and OK ones at the bottom.
If all the buttons have to appear along the bottom of the dialog, keep the labelled one(s) to the left/middle and separated from Cancel and OK by some extra space (if possible).
If a button has two words on it, put the second word on a new line under the first to make a deeper button rather than making the button wider. In some situations (e.g. the Slot definitions button in Agenda) this may be unavoidable.
When a dialog contains a text editor (e.g. the Text page of the Edit entry details dialog in Agenda), the text formatting buttons should be next to each other to form a miniature Toolbar underneath the text box (see below).
All the buttons should be activated by the standard shortcuts for those functions, and the standard keyboard shortcuts for the buttons should apply.
Commands that cascade from these buttons do not have shortcuts because the shortcuts are reserved for buttons that may be required in the dialogs. Any developer who wishes to give these controls shortcuts in their own programs will need to provide their own customised controls, but they should follow the conventions and use the standard shortcuts that are used for the menu commands that are associated with these functions.
For example, they might add the following Format commands:
And these Insert commands:
If at all possible. If an action cannot be undone afterwards, warn the user with a confirmation message, e.g.:
Ask what might the user try? Giving them something unexpected can delight
The importance of having a universal Undo command - it lets the user explore things and try things out.
Show the user where they are - the cursor is very important.
File extensions are not used to differentiate files of the same name, except where they are required - e.g. an OPL program called FRED translates to FRED.OPO.
This section contains guidelines about where to keep files which are not created by the user directly.
Any files that are not explicitly user data must go under the System folder (which is hidden by default), out of the way of most users.
There are a number of reasons for this; one is that there is a temptation for people to delete files they do not recognise, another is that the filing system can look very messy if there are system files, temporary files and programs scattered all over the place (as with PCs).
Additionally, folder names under \System are language independent. In other words, a folder named \System\Alarms\ can be relied upon to contain alarms for all machines in all languages. If C:\Alarms were used instead, the text C:\Alarms would have to come from a resource file and all programs and system components that used it would have to load this name from the resource file. Almost inevitably some apps (e.g. 3rd party apps) would forget this and there would be problems on foreign machines - or on earlier ROM machines without this resource file, etc.
When creating files for programs, e.g. a log of an email session or log of synchronisation changes for example, don’t put that file in one of the user’s folders. Never put anything in a user’s folder that they aren’t explicitly aware of - they may wonder what is that? I haven’t created a file called that, and then delete it.
If such a file is necessary it should be placed in a hidden folder, but one that the user can get access to for technical support purposes later if need be.
An appropriate place for such a file would be in a \System\logs folder on the same disk as the program is stored on, if the program is EPOC based.
For a log file for a PC based program, e.g. a log of changes made during synchronisation with the PC, the best place for it is on the PC; again in a \log subfolder of the folder that is used by the PC program (not a user’s documents folder).
It is important to retain the distinction between files (e.g. those created by Word and Sheet) and objects (e.g. those created by Word and Sheet) inserted in other files. For this reason, if an inserted object allows the import or export of its contents as a separate file, do not use Open file or Save file as… commands. Instead, use Import or Merge in file and Export as file. The user should not be encouraged to consider that an inserted object is like a normal file.
Whenever an EPOC program, e.g. Word, is opened, it automatically attempts to load the last-used file (if it is capable of doing so).
Note that this is not necessarily the file which was opened, rather it is the file that was in use when the program was closed. This is the most intuitive behaviour for the user and means that the file they were last viewing is the one that is loaded when the program is next opened. The difference is obvious if multiple instances of a program are running simultaneously and are all closed down; when the program is restarted it will use the last file to have been closed, which may not have been the last one opened.
EPOC Connect is the PC-based connectivity software which enables communication between the EPOC machine and a PC. As such it conforms to Microsoft Windows style guidelines (available elsewhere), but there are some specific matters which are relevant to mention here.
Icons in the system tray on the PC’s Start menu should BE 16x16 pixels on a transparent or grey background.
|
Term to use |
Terms not to use |
Use for |
|
EPOC Connect |
Psion Explorer, PsiWin |
For the program that runs on the PC. |
|
Docking cable |
3Link, serial link, cable, link cable |
|
|
arrow keys |
cursor keys |
|
|
|
Email, E-mail, e-mail |
When referring to messages, service providers, etc., but not to the name of the email program. |
|
|
|
The name of the EPOC email program |
|
handles |
|
For the square blobs that appear on a selected inserted object that allows the size of the object to be changed. |
|
List of open files and programs |
task list |
For the list of open files and running programs. |
|
Program icons |
buttonbar |
For the buttons that move between different programs. |
|
Command icons |
sidebar |
For the buttons along the left edge of the screen. |
|
IrDA |
IRDA irda |
|
|
Infrared |
infra red infra-red |
|
|
menu bar |
menubar |
|
|
Toolbar |
status window |
For the row of buttons and the clock on the right hand side of the screen. |
|
Toolband |
|
For the row of buttons along the top edge of the screen. |
|
Command, menu command |
option, menu option, menu item |
|
|
menu cascade |
cascading menu |
|
|
dialog |
dialog box |
|
|
tabs |
|
On the top of multi-page dialogs that go to the different “pages” in the dialog. |
|
dialog lines |
dialog items |
|
|
shortcut key |
hot-key |
E.g. for Ctrl+X, Ctrl+C. Key combinations are usually written with a “+” nowadays, e.g. CTRL+F rather than CTRL-F. |
|
File |
document |
|
|
filename |
file name |
|
|
folder |
directory |
|
|
disk |
drive |
|
|
Internal disk |
|
For the disk built into the machine. |
|
Memory disk |
|
For the plug in cards. |
|
Program |
application |
|
|
object |
document file |
For inserted files because Windows users will pick up the above much faster than the alternatives. |
|
Tap |
click |
For the pen tapping the screen. This also helps guard against thinking in terms of mice. |
|
Entry |
record |
For what is often called a record in the database. |
|
Term |
Reason for avoiding it |
Alternative |
|
abort |
Too “techie”. Also unpleasant connotations in English. |
stop or cancel, depending on context. |
|
Application |
|
“program” |
|
Are you sure? |
|
Remove completely and make sure title of confirmation dialog is a question and ends with “?” |
|
default |
Too “techie”. |
Better as “standard”, or “preferred” (in Time e.g. “preferred alarm time”) |
|
directory |
|
“folder” |
|
drive |
|
“disk” |
|
embedded file, embedded object |
|
“Inserted object” |
|
exit/exited |
|
“close/closed” |
|
hide/hidden |
Hide seen as a negative action. |
Turn the whole thing round so instead of having options to hide things, use options to “show” things. Except for e.g. hidden files |
|
jump to |
|
“go to”. Matches similar options in Windows apps. |
|
Just |
Does not work in some places, so “only” was chosen for reasons of consistency. |
“only”. |
|
Loading |
|
“opening” |
|
location (on screen) |
Could be confused in e.g. World with location on map. |
“position” |
|
path |
|
“folder” |
|
picture |
|
“sketch” if inserting a file that was created in the Sketch app. Matches the name of program in which pictures are created, and so points the user to the correct program to create them. |
|
record |
|
“entry” |
|
search |
|
“find” in menu commands. Matches similar options in Windows. But “search for” in the Find dialogs. |
|
status window |
|
“Toolbar ” |
|
task |
|
“file” or “program”, depending on context |
|
task bar |
|
“list of open files” |
|
task list |
|
“list of open files” |
For ease of localisation, all programs that have a single resource file should have items in the following order:
Debugging messages and other text that is to be removed for the candidate release
Symbian licenses, develops and supports the EPOC operating system, providing leading software, user interfaces, application frameworks and development tools for Wireless Information Devices such as Communicators and Smartphones. Symbian is based in London, with offices worldwide. See http://www.symbian.com/ for more technical papers, information about Symbian, and information about EPOC.
Symbian and the Symbian logo, EPOC and the EPOC logo are the trademarks of Symbian Ltd.
All other trademarks are acknowledged.
The author wishes to thank ... who supplied valuable information and review comments.