Navigator Standards for Enterprise Explorer
The IFS Navigator structure is shared between all user interfaces of IFS Applications.
This means that there is a single navigator containing links to all Application
Forms, Features, Web Pages in IFS Applications. It is then a user setting to choose
whether to see just Application Forms and Features when using IFS Enterprise Explorer, or whether
to also see all the Web Pages in the navigator.
Although there are many different ways to navigate in IFS Enterprise Explorer
(traditional tree navigator, link pages, breadcrumbs, shortcuts, etc.) all these
navigation tools are driven by one common navigator structure. Therefore it is important
that the navigator structure is well designed and constructed in a way so that it
supports all the different navigation tools in a good way. To achieve this, the
following rules should be followed when designing the navigator.
In this document, the word entry is used as a common expression for all navigator forms
and folders.
Contents
The standard navigator in IFS Applications should be a functional break down
of the functionality. For future versions of IFS Enterprise Explorer, support for
multiple structures (say both a functional breakdown and a strict process breakdown)
will be considered, but for now it should be a functional break down. Primarily,
this means
grouping functions by functional area, and on other natural groupings,
often referred to in regular conversations. Examples could be from big areas like Financials
or Procurement to smaller ones like HR Self Service or Project
Follow-Up.
When you decide where in the navigator you should place certain types of content, base
your decision on where you think an inexperienced user most likely would search for
the desired functionality.
- Top Level Folders – should reflect the main application area. Top
level folders should be more granular than our six product areas, but less granular
than our 150 components. A suitable number would be 15-30. Top level folder
names are decided centrally for all of IFS Applications, i.e. it is not allowed
for a project or product team to add or modify a top folder without involving
concerned people.
- Sub Folders – can be used to logically group functionality inside
each top level folder.
- Allowed Number of Entries – if possible, try to avoid having more
than 15 entries inside a folder. If the number of entries is growing,
investigate creating another level of subfolders.
Having a reasonable
number of entries in each folder is important to allow the eye to quickly
scan the list and find the entry wanted. By keeping the number of entries
on the right level you avoid the need to scroll the breadcrumb drop-down
and the link pages in most cases.
- Allowed Levels of Folders – if possible, try to avoid having more
than 3 levels of folders (top folder, sub folder level 1, sub folder level
2). Only when motivated, 4 levels may be used.
Keeping the number of folders
down is important to minimize number of clicks, for example in link pages, and to make sure that the breadcrumb and
navigator tree will not get too wide and thus fit into their allocated horizontal
space in most cases.
- Forms Appearance in Navigator – a form or page should preferably
only appear once in the navigator, so try to avoid placing the same form in
multiple folders. A limited number of exceptions can be allowed when a main
area need to contain a small number of key forms for basic
data owned by another main area.
This rule is important
to make it possible for the breadcrumb and navigator to automatically find and
show the current location in the navigator. Consider a user having a Customer
Order screen open. User chooses to zoom/link to Customer (frmCustomer
). Now
the navigator must find and select/highlight the navigator entry for frmCustomer
.
If more than one exists, it will be impossible for the navigator to know which
one is intended. Therefore, it is better if each form only exists once in
the navigator.
- Analysis, Basic Data, Reports, History, and Statistics Folders –
if a folder contains multiple forms (3 or more) of the same type, e.g. Analysis,
Basic Data, Reports, History, or Statistics, then those forms should be placed
in a subfolder with that name.
- Reports – if reports are placed in the navigator they should be placed
in the area/folder where they naturally belong.
- Structure Within Folders – a number of rules applies when
it comes to structuring the contents within a folder:
- Placing Detail and Overview Form Together – if a folder contains
both a detail form (singular) and a list/overview form (plural) for the
same window, then the two items should be placed together with the singular
version first.
Example:
Customer
Customers
Supplier
Suppliers
By placing the detail and list/overview form together, it becomes easier
for the eye to distinguish between them. Please, note that the two types
also can be distinguishable through their icons which looks clearly different.
In very rare cases, you could end up in a situation where a form and the
corresponding overview should have the same name according to naming principles.
In such cases the forms should be distinguished by adding a suffix. If the
window is a table window, the use of the suffix List is preferred.
Example:
Project Budget Control Rules (shows multiple rules in a master-detail
window)
Project Budget Control Rules List (shows multiple rules in a table
window)
- Mixing Folders and Form Entries – it is allowed and encouraged
to mix both navigator entries and folders on the same level in the navigator.
If mixed inside a folder, it is preferred to place the forms above the folders.
- Placing Analysis, Basic Data, Reports, and Statistics Folders Last
– if a folder contains Analysis, Basic Data, Reports, or Statistics subfolders,
these should be placed below the other subfolders.
- Workflow Order – entries that are part of a
workflow should be placed according to this workflow.
- Basic Data – when deciding where to place basic data, the following
guidelines applies:
- One Functional Area - basic data that is only used by one area
of functionality, should be placed in the folder for that area. For example
Call Center Basic Data should be placed in the Call Center folder.
- Multiple Main Processes and Areas – basic data that is shared
by multiple main processes and areas in IFS Applications, and that is frequently
updated, should be placed in a shared high level folder. For example different
types of part information could be placed in a top or high level folder
dealing with parts. When it is very well motivated from usability needs
(but please be restrictive here), a small selection of forms from such basic
data areas may be repeated in the folders for other main areas.
- Shared by all IFS Application – basic data that is shared by all or major parts of IFS Applications and typically only updated during
the initial set-up phase, or during major changes in the business processes,
should be placed under the top level folder Application Base Setup. Examples
of such data are companies, sites, etc.
Navigator entries should be fast to read and understand for the human eye. To
achieve good names, use the below name conventions combined with common sense. These
guidelines do not cover every case, but try to consider these, as well as
the principles above, when selecting names for navigator entries.
- Miscellaneous Naming Principles – the following naming principles
are valid for all or the specified types of navigator entries:
- Most Important Information First – navigator entries should be
named with the most important information first, and if possible (without
making it linguistically incorrect) avoid generic words like overview
or query in the beginning of the name. Such general prefixes just become
extra work for the eye to read and take up space from the important.
- Unique Names – note that this bullet does not apply for folders.
Form names should be describing and unique throughout the entire navigator.
For example, if there is a purchase order form in the Procurement folder,
and a customer order form in the Sales folder, these should be called Purchase
Order and Customer Order respectively. It is not allowed to call both
these different form Order even if they are placed inside folders that
clearly describe what type of order they are. The unique naming of forms
is important for the user to easily recognize the forms inside
the Recent Screens function (where only the form name, not the navigator
location, is shown). It is also important for the navigator history and for the navigator filter
to be really useful.
- Using Verbs – verbs should be avoided in navigator names for
table and form windows. A verb implies an activity, and the name of the
entry should not limit the use of the table or form. What activity, or
activities, a user is expected to perform within
a window should be described in the documentation rather than in the
name of the entry to not limit the use of the table or window.
For Assistants,
Dialogs, and other window objects that invoke generation routines
etc, verbs should be used.
- Abbreviations – it is allowed to use abbreviations if and only
if they:
- Are universally well known and established in business language.
For example it is allowed to use GL as an abbreviation for General
Ledger, but not allowed to use CO as an abbreviation for Customer Oder
simply
because CO is not established.
Examples: Archived GL Vouchers, MRO Work Order.
- Constitute a significant shortening of the navigator entry.
For example there is no point abbreviating Project with Proj as
the difference is only a few characters. Please be aware that abbreviations recognized in local language might
not be well recognized in English, and vice versa.
- Folders – should be named according to a logical function group name.
- Substantive – preferably a substantive should be used for naming
folders.
- Singular – preferably the name should be in singular.
- Slim Naming – folder names should be kept
as short as possible to make it easier for the eye to quickly scan the navigator.
Avoid repeating names already used in the parent folders. This is important
for the user to understand the context of where they are when they look
in the navigator and/or the breadcrumb. It is however allowed to have the
same sub folder name within two different parent folders as the breadcrumb
etc. always will be shown within the context of the parent folder
Example:
Sales/Order
Rather than:
Customer Order/Customer Order
- Form Windows – entries for a form that show a single object or a
master-detail window should be named <object singular>.
Examples: Customer, Material Requisition
- Table Windows – entries for forms that show a plain list of objects
should be named <object plural>. No prefix or suffix should be used.
Examples:
Customers, Purchase Orders, Expense Sheets, Pallet Handled Inventory Parts
- Analysis Windows – entries for forms designed specifically for analysis
by use of ad-hoc queries should be named <object> followed by Analysis or <analysis name>.
The former is used when the form shows just a suitable aggregated list of objects,
whereas the latter is used when there is a known and established name for this particular
type of analysis. These forms are always read-only.
Examples (<object> Analysis): Customer Order Line Analysis, Order Commission
Analysis
Examples (<analysis name>): Contribution Margin, Inventory Value per Period
Examples of established names, where no Analysis suffix is needed:
- forms that end with Statistics, for example Delivery Statistics
- forms that end with History, for example Purchase Transaction
History
- forms that are named in past tense, for example Invoiced Purchase
Orders
- Assistants – entries for wizards or other form of guide input should
be named <object> / <task> followed by Assistant if the assistant allows you to perform
different tasks. However if the assistant is specifically designed to only create
new objects, then the name should be New <object> Assistant. Essentially Assistant
is the new name for Wizard.
Examples:
External Voucher Assistant, New Case Assistant, Find Purchase Part
by Characteristics Assistant
- Reports – entries for reports should be named <object or descriptive
word> followed by Report.
Examples: Sales Price List Report, Supplier Blanket Report
- Basic Data Forms – should be named differently depending on
whether they contain single or multiple types of basic data:
- Multiple Types – should be named <functional area>
followed by Basic Data.
Typically these forms have multiple master tabs.
Examples: Sub Contract Basic Data, Sales Basic Data, Split Checklist
Basic Data
- Single Type – should be named like regular overview/detail forms;
i.e. <object singular/plural> using the same rules to decide singular/plural
form as for normal windows. Typically these forms are either plain table
windows, or forms with a single master record with or without detail tabs.
Examples: Technical Class Groups