Summary

The Kitchen Sink (KS) describes the UI-Elements used in ILIAS. Since ILIAS 5.3 the status of the Kitchen Sink can be directly consulted through the openly available documentation of the UI-Elements in the latest ILIAS Version:

• Kitchen Sink Documentation of ILIAS 5.3: KS Documentation

If possible use the KS-Taxonomy of the KS when writing Feature Requests or Bug Reports. Even better, directly link to the entries.

Contribution

A complete documentation of how to contribute to the KS (e.g. adding a new element or changing an existing one) can be found in the corresponding readme.

If you feel overhelmed by this description and need help, do not hesitate to contact the corresponding maintainer of your project or the KS coordinators (see above).

Motivation

The UI-Kitchen-Sink Poject has been initiated due to main issues in the current UI of ILIAS:

1. Disparate UI diminishes learnability of the system and the user experience
2. Outdated libraries used for some elements, missing or outdated guidelines are used
3. UI-Components are barely tested

Goals

The main goal of this project is to have a centralized UI Service serving as home for new UI specific implementations and target place to move all existing ones.

The main goal of the UI-Kitchen-Sink is therefore to establish a tool and workflow to document, demonstrate, test and use UI components used in ILIAS by

• Building the foundation and structure along with guidelines for a centralized UI Service serving as home for new UI-specific implementations
• Moving existing UI-Implementations into this new central service.
• Creating a relevant resource for UI development and a place where it is easily found and consulted
• Documenting the status of the implementation of UI-Components
• Agree upon rules
• Include UI considerations into Jour Fixe on regular basis
• Fix UI elements that do not adhere to rules
• Prepare JS guidelines

In the beginning of the KS-Project we proposed KS-Entries as FR. With the Centralizing UI-Components Project we changed to PRs. The now depracated FR can be found here:

UI - Kitchen - Sink (deprecated)

Accepted:

• KS-Entry: Forms
  • KS-Entry: Titled Form Sections
  • KS-Entry: Form Settings
  • KS-Entry: Form Subsettings

• KS-Entry: Counter
  • KS-Entry: Novelty Counter
  • KS-Entry: Status Counter
• KS-Entry: Glyph
  • KS-Entry: Settings Glyph
  • KS-Entry: Collapse/Expand Glyph
  • KS-Entry: Add/Remove Glyph
  • KS-Entry: Up/Down Glyph
  • KS-Entry: Back/Next Glyph
  • KS-Entry: Sort Glyph
  • KS-Entry: User Glyph
  • KS-Entry: Mail Glyph
  • KS-Entry: Notification Glyph
  • KS-Entry: Tag Glyph
  • KS-Entry: Note Glyph
  • KS-Entry: Comment Glyph
• KS-Entry: Button
  • KS-Entry: Default Button
  • KS-Entry: Primary Button
  • KS-Entry: Close Button

• KS-Entry: Modal
  • KS-Entry: Round-Trip Modal
  • KS-Entry: Interruptive Modal
  • KS-Entry: Lightbox Modal
• KS-Entry: Reporting Panel

KS-Entry: Tab

• KS-Entry: Content Tab
• KS-Entry: Content Subtab

• KS-Entry: Overlay
  • KS-Entry: Modal (see accepted entries)
  • KS-Entry: Popover
    • KS-Entry: Preview Popover
    • KS-Entry: Interaction Popover
  • KS-Entry: Dropdown
    • KS-Entry: Fixed Dropdown
    • KS-Entry: Contextual Dropdown
  • KS-Entry: Toast
  • KS-Entry: Tooltip (Coming Soon)
    • KS-Entry: Generic Tooltip (Coming Soon)
    • KS-Entry: Help Tooltip (Coming Soon)
• KS-Entry: Instructional Overlay
• KS-Entry: Cards
• KS-Entry Deck of Cards
• KS-Entry: Toolbar

Those entries have been proposed but did not find acceptence by the JF:

• KS-Entry: Annotational Popover
• KS-Entry: View Regulating Popover

The following todos have been completed:

1. Generate an accepted Template: Template and Organisation of KS-Inventory
2. Initiate the 'Centralizing UI-Components' Project by generating FR a for it: Centralizing UI-Components. (amstutz)
3. Write FW article for adopting the Kitchesink in "Layout and Styles" in ILIAS Administration panel: KS: Integration in Layout and Styles. (amstutz)
4. Generate a Taxonomy of UI-Elements and generate entries for it (see image bellow).  This has been done by invastigating ILIAS and collect and order ILIAS UI-Components systematically. See: Pipeline

KS-Layout

Entries of the KS can have the following states:

• To be revised: The entry is still being worked on. Most of them are listed in the Pipeline Document.
• Proposed: The entry has been revisited and is proposed to the Jour Fixe, but has not yet been decided upon. To enter this state, create a pull request against the ILIAS trunk containing your proposed component and take it to the Jour Fixe. You need to provide a (mostly) complete definition of the component but an implementation is not required at this point. You will have better chances if you also bring some visual representation of your new component, you may use the ILIAS edge branch for that.
• Accepted: The entry has been accepted by the JF. This, as always, might need some iterations on the component.
• Implemented: The entry has been implemented and is ready to use in the current trunk version of ILIAS. The following image gives an overview of all currently collected entries along with their according states:

Child nodes have a is A relationship to their parents. Meaning a Default Button is A Button which is A Trigger Element. Please be aware that some categorization are still discussable. Also some hard to place item will always remain. E.g. the Rating Popover is placed in the Overlay class which are labaled as Container Collection. Obviously a Rating Popover could also be categorized as Input Collection. However we gave the nature Overlay here a higher priority than the nature Input.