Open Source e-Learning
  • Login

Breadcrumb Navigation

Icon Wiki

Feature Wiki

Information about planned and released features


Page Layout Revision (Desktop)

This Feature is part of the General Layout and Menu Revision. See also mobile version Page Layout Revision (Mobile).
We have split the concept for desktop and mobile, although both have thought of each other and have the same goals, but need different implementations. The underlying concept of main bar and slate should be implemented as similarly as possible for both devices.
The attached PDF-file provides an overview of the current status of the Page Layout Rersion. All elements of the new layout are described and clearly separated. Mock Ups help you to uniquely identify the elements. In addition, rules are defined for the behavior of all elements.

1 Initial Problem

With ILIAS 5.0 we greatly revised the ILIAS overall look including the main Page Layout composed of Header, Content Section and Footer. This was an important and necessary step to push ILIAS forward into a responsive direction.

Some time has passed since then and we believe it is time to push the ILIAS main layout once again significantly forward.

Especially the following aspects of the current layout seem problematic in our view:
Crowded Top Navigation
The Top Navigation contains a various types of elements. Further, the space is limited and the elements that need to find a place there is growing (see e.g. Background Task Service User Interface).
Small Screen
Large Branding Section
We believe that the brandig area (white space on the image above) occupies to much space. 
Misplaced Explorer
We observe, that the switch to display the explorer is hard to find on the vey left side. The position is especially confusing, if the explorer is open, since it is not directly next to the object it operates.
Small screen
(see also DR 5.1: Issue 08: Presentation of Tree Explorer on small media devices from Design Revision Part 2
User has no access to tree of repository to navigate quickly trough repository. User needs to navigate trough list view.
Content Area
This point is controversial. We see the benefit of fixing the screen width for better readability of text and in several cases for shorter distances to operate the cursor. However, we believe that there are too many scenarios where this fixed width is frustrating, especially on big screens. This image shows such a case. 

2 Conceptual Summary

Further version and discussions of concept: Page Layout Revision (Desktop) - Pre-Stage

2.1 Navigation Patterns (Analysis)

Our main paradigm is to think ILIAS no longer as website, but as a full blown application, similar to Jira, Google-Mail, Google-Calendar, Google-Statistics and so on.
Based on our analysis of problematic issues we focussed on a main task we want to solve with the new page layout revision:

Simpler navigation concept
  • that works on small screens and desktop devices AND
  • has the possibility to be expanded by future developments.
At the moment ILIAS has four navigation elements in different places:
  1. Top Navigation
  2. Main Navigation
  3. Tree
  4. Breadcrumb
Current navigation
Detailed informations
These navigation elements have different tasks and benefits but are content related, f.e.
  • tree and search offer only a different kind of view on the content.
  • Some are kind of quick navigation (like Main Navigation),
  • some are quick navigations in combination with notification alarms (like Top Navigation).
  • And some are a way to navigate through a predefined path (like Breadcrumb and Tree).
These navigation elements are important as different navigation strategies, but their position and assignments do not use their whole potential. We like to revise ILIAS’ layout to a “navigation strategies based layout” to allow different ways to get the right content, but with a much more simpler and clearer navigation layout.
Desktop and Small Screen View
Our second task is to bring together desktop and small screen view even more closely. That’s because page layout revision has been made with components, which are well-known in mobile and desktop application context.
Expandability and Assignment
The crowded top navigation (especially for small screens, see chapter 1.) already shows an important issue for the new page layout: It isn’t arbitrary expandable. There is also no guideline, in what case a functionality will get a place in top navigation bar.
Side effects of revision
Breadcrumb is more visible and reflects better its importance.

2.2 New Navigation Strategy (Conclusion)

We reduce the visual navigation “clutter” to two main navigation points which are expandable and work for desktop and mobile devices:
  • A meta bar (header) with tools, that are collections of superordinate functionalities in the upper right corner: among other things a "notification center" unifies all functionalities of ILIAS, which has the ability to send push-notifications. A notification glyph summarize all current notifications (of email, chat requests, running tasks,...).
  • A main bar with around 5 entries (per default) at left side on desktop and at bottom on mobile devices. This navigation concept contains the main bar (menus) and a slate: This gives access to all relevant points of interests in ILIAS, like personal desktop, search, repository and more. 
The naming of all elements will be determined in the discussion of the respective UI-Elements.
Revised navigation
We like to have a clear concept, which elements get a place in the meta bar and which one are placed in main bar. Our suggestion:
  • Meta Bar: The system pitches the user
  • Main Bar (Menu bar and Slate): The user acts independently
Which elements are placed in which bar is determined in a separate discussion line: Default Configuration of Main Bar Items (6.0)

2.3 Conceptual Details

Meta Bar

2.3.1 Meta Bar

Meta bar for branding section and top menu actions. Could be always available or get smaller if user is scrolling.
Branding Section consists of the logo of the application and it's name. Upon click, the user is referred to the starting page. Main Menu elements (like "Personal Desktop" and "Repository") are transferred completely to Main Bar.
Top Menu is placed on the same line as the Branding Section. Items that pitch the user are placed here (see chapter 2.2). Items with push-notifications will be unified in a "Notification Center" (see Notification Center). Only items that make use of counters to inform the user about news (notifications) may stay in this notification center element. 
The details of such a Notification Center must be defined separately: Notification Center
The detailed conten of the MetaBar is defined in: Overview Metabar Content
Main Bar and other elements
Wording of Cockpit Elements (Desktop)
"Main bar" and a "slate" give access to all main navigation points, where a user needs to go to get all relevant informations and working possibilities.

2.3.2 Main Bar

The main bar contains various "entries". An "entry" groups the items or widgets in it. If main bar is open additional content is visible in a "slate". This slate contains appropriate content and functionalities ("widgets").
The main bar can be either collapsed or open. In it's collapsed form, the main bar only shows the glyphs of the respective items and it’s labels.
  • If opened, main content will be push together or wrap (like on mobile screens). A "slate" section extends and accordions for navigation entries or other functionalities of this service are shown.
  • To collapse the main bar, you can click on a close icon at the bottom of slate or you can click on the glyph in main bar again.
Good default, but customizable
As default we would provide as less as possible entries in main bar because of readability (see Hick's Law). Because institutions have different main focus and different activated functionalities, adaption is needed. Therefore a Customisable Main Menu is introduced:
  • Sorting can be adopted as system administrator for own installation.
  • Number of entries can be adapted by system administrator.
  • Sorting decides if they are visible in small screen view (see Page Layout Revision (Mobile)).
The details of such a Customisable Main Bar must be defined separately: Customisable Main Menu
What happens with the current "main menu"?
Which elements are placed in which "item group" is determined in a separate discussion line: Default Configuration of Main Bar Items (6.0)
What happens with "Overview" page on current Personal Desktop is determined in a separate concept: Overview Personal Desktop Revision

2.3.3 Slate

In a first execution, the slate will often contain links and link collections. However, it should be possible to provide more functions than just links. These are used f.e. by the context-related-entry ("Tools" entry, see 2.3.5), but also by candidates such as the who is online tool.

Also plausible would be e.g. a search field, which makes it possible to search for content within repository trees or learning module trees (needed for help). Furthermore it should also be possible to place content of plugins in a slate.

2.3.4 Tree

To use the repository tree, it is necessary that entries can be viewed and opened in parallel (accordion behavior). But it can also make sense to offer nested trees in a so-called drill-down menu, so that the essential contents are easier to see and do not disappear in a huge tree.

A combination of drill-down and accordion menus is therefore recommended. The first navigation level (f.e. "Repository") mainly offers drill-down menus. If you want to switch to a detailed tree (e.g. "Repository Tree" or "Learning Module Local Navigation") you have to switch to an accordion tree.
Note that the tree behaviour will need to be discussed in detail as soon as the PR for the tree is made: Tree for General Layout and Menu Revision
Mockups see: Desktop - Tree

2.3.5 Local Main Bar Entry "Tools"

A separate entry is added for the "Context Related Items". It contains elements that must be displayed parallel to the content.
  • This entry, currently called "Tools", appears as soon as at least one "Context Related Items" has been opened via a trigger from the content section or the header bar.
  • The different "tools" can be arranged side by side within the slate ("tabs").
  • They are available as long as the user needs them or "closes" them (e.g. Help), or until the content no longer needs these functions (e.g. page editor tools).
The "Context Related Items" are currently the following elements:
  • Local Navigation (incl. List of Question in Tests and Taxonomy Trees)
  • Help
  • Page editor functions
  • Assignment tasks
  • Conversations
Behaviour: The general "Tools" icon is already displayed in the main bar when you open a tool. If you click on a second tool, it will only occupy an already indicated place. The tool icon in the main bar does not change.
The temporary entry contains elements that have "tool character", but this does not mean that everything that has "tool character" should be put into this temporary entry.

2.3.6 Scrolling Behaviour

The meta bar including breadcrumb remains when scrolling. The main bar also remains. The content slides under the meta bar.
Mockups see: Desktop - Scrolling

2.3.7 Breadcrumb

The breadcrumb has a fixed place in the header area. It is only used on one line. If the breadcrumb is longer than one line, it is shortened (...).

When shortening, make sure that the first node is always visible (f.e. "Repository > ... > Category XY"). In addition, the node that was clicked on should remain visible first or at the very back as a reference.

If the breadcrumb is very long, it may be shortened both after the first node and at the very end of the line. The maximum width of the header is used and as many nodes as possible are displayed.

The arrow icons should no longer be linked. Since these are not clickable anyway, the user should be aware that they cannot be clicked.

Breadcrumb should only appear where it is already shown in ILIAS 5

2.3.8 Kiosk and Presentation Mode

If you are logged into the system, the entire main bar with entries is always displayed (e.g. Test Run, View Blog, View Portfolio). Currently the whole menu is not displayed for Blog and Portfolio. This is to be changed so that users can change the context at any time.

  • The test is performed in kiosk mode. Then no main bar is displayed. Depending on the setting, a header with minimized display (test title and user name) can be displayed.
  • Public blogs and portfolios are displayed without main bar. They will receive a special header (login header).

2.3.9 Widescreen and Customization

With a very large screen, the content is displayed in the middle. The main bar is displayed on the far left of the screen. Opening the slate has no effect on the content in the middle, while there is enough space (no sliding together).

2.3.10 Plugin-Slot

A plugin slot for the slate should make it possible to display and offer not only links, link collections and drilldown or accordion trees but also other elements within the slate (e.g. link to portfolio, learning progress display, plugin content, etc.).

3 User Interface Modifications

3.1 List of Affected Views

Since we propose a new overall layout, all those sections are tackled to some degree. However the main focus will be on the complete Header Section and on the Left Explorer.
Affected Views
The current layout of ILIAS can be structured as follows (see  KS Pipeline Document for a more complete description):


Header Section
  • Branding Section 
    • Logo
    • Main Menu
  • Title Section (Name of Application, e.g. ILIAS 5.2 Evaluation)
  • Top Navigation (Mail, Search, Help, User Images etc.)
Left Explorer 

Content Section
  • Breadcrumb
  • Content Title Section
    • Icon
    • Title
    • Description
    • Comments, Notes, Tags, …
    • Actions
  • Tabs
  • Subtabs
  • Content
    • Sidebar Left
    • Center Content
    • Sidebar Right


3.2 User Interface Details

Prototype: Behaviour Main Bar, Slate and Tools Entry
  1. Open first mockup.
  2. Click on "Play" button in the header (right)

3.2.1 Mobile (small screen)

Please have a look at Page Layout Revision (Mobile)

3.3 New User Interface Concepts

There is a range of new (or refactored existing) User Interface Concepts needed. In this section you find PR's suggesting elements to be added to the UI-Framework to implement this:Note that this list is yet incomplete.

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

  • Author of the Request: Seiler, Yvonne [yvseiler]Amstutz, Timon [amstutz]
  • Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
  • Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

7 Discussion

JourFixe, ILIAS [jourfixe], 10 SEP 2018 : We highly appreciate this suggestion and like it very much. The suggested layout revision goes into the right direction for us. We have the following comments:
  • We would like to know how clicking through the tree could be possible without the need to present more than two indentations (left aligned + one). Matthias made a related suggestion. But there is also the need for opening more than one node at once to administer the course or category.
  • We support the suggestion to always show the "Tools" menu item - even if only one tool is available at the moment. In our opinion this is easier to learn and helpful in case of support - except for the case when only one tool is offered at the installation (e.g. no help activated and only local navigation shown).
  • We agree that the breadcrumb should only appear where it is already shown in ILIAS 5.
Amstutz, Timon [amstutz], 08 FEB 2019: Sry, I was not aware that any reaction of mine was needed here.
  • Point 1: Good suggestion. Note that the tree behaviour will need to be discussed in detail as soon as the PR for the tree is made.
  • Point 2: No further discussion needed, will be done as asked by JF.
  • Point 3: No further discussion needed, will be done as asked by JF.
@Whoever is unsure about the status of this article: We (Universität Bern) thought the wording "we highly appreciate this suggestion" means accepted by JF. This is wrong due to the missing meta data. Note that this article is not yet accepted an will be needed to be discussed again.
Seiler, Yvonne [yvseiler], 10 FEB 2019: I have adjusted the FW entry according to the considerations of the JF from 10 SEP 2018 (see new FW Tree for General Layout and Menu Revision and set it on the JF agenda.
JourFixe, ILIAS [jourfixe], 11 FEB 2019 : We highly appreciate this suggestion and accept to discuss the tree behaviour is a separate feature request as suggested by Yvonne. Page Layout Revision (Desktop) is scheduled for 6.0.

8 Implementation

8.1 Adapt Administration to new Layout

{The maintainer has to give a description of the final implementation and add screenshots if possible.}
Test Cases
Test cases completed at {date} by {user}
  • {Test case number linked to Testrail} : {test case title}
Approved at {date} by {user}.

8.2 Integration of Glossary Term List into Slate

{The maintainer has to give a description of the final implementation and add screenshots if possible.}
Test Cases
Test cases completed at {date} by {user}
  • {Test case number linked to Testrail} : {test case title}
Approved at {date} by {user}.

Last edited: 20. May 2019, 17:50, Reuschenbach, Volker [vreuschen]

Search (Block)

Related Component/Module

Release Status

Development Status
Interest in funding

Funded by

Not available yet

Approval by Customer
Not approved yet

Wiki Functions (Block)


Recent Changes