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

Structuring the Navigator

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.

  1. 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.
  2. Sub Folders – can be used to logically group functionality inside each top level folder.
    1. 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.

    2. 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.

  3. 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.

  4. 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.
  5. Reports – if reports are placed in the navigator they should be placed in the area/folder where they naturally belong.
  6. Structure Within Folders – a number of rules applies when it comes to structuring the contents within a folder:
    1. 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)

    2. 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.
    3. 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.
    4. Workflow Order – entries that are part of a workflow should be placed according to this workflow.
  7. Basic Data – when deciding where to place basic data, the following guidelines applies:
    1. 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.
    2. 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.
    3. 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.

Naming Navigator Entries

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.

  1. Miscellaneous Naming Principles – the following naming principles are valid for all or the specified types of navigator entries:
    1. 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.
    2. 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.
    3. 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.

    4. Abbreviations – it is allowed to use abbreviations if and only if they:
      1. 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.
      2. 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.
         
  2. Folders – should be named according to a logical function group name.
    1. Substantive – preferably a substantive should be used for naming folders.
    2. Singular – preferably the name should be in singular.
    3. 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

  3. 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

  4. 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

  5. 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:

    1. forms that end with Statistics, for example Delivery Statistics
    2. forms that end with History, for example Purchase Transaction History
    3. forms that are named in past tense, for example Invoiced Purchase Orders
  6. 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

  7. Reports – entries for reports should be named <object or descriptive word> followed by Report.

    Examples: Sales Price List Report, Supplier Blanket Report

  8. Basic Data Forms – should be named differently depending on whether they contain single or multiple types of basic data:
    1. 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

    2. 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