Open Source e-Learning
  • Login

Breadcrumb Navigation

Icon Wiki

Feature Wiki

Information about planned and released features

Tabs

UI Kitchen Sink

What? Why? and How?
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:
If possible use the KS-Taxonomy of the KS when writting 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 eement or changing an exsiting 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 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 and
  • Include UI considerations into Jour Fixe on regular basis
  • Fix UI elements that do not adhere to rules
  • Prepare JS guidelines

1 Suggested Features

Suggesting Specific UI Elements
Note that KS-Entries are suggested as pull requests. You find all currently KS-related pull requests in the ILIAS repo in git: Open KS-PRs.

A list of all pull requests (open, closed and merged) related to the KS can be accessed here: All KS-PRs.
In the following list you can add a request for a new feature or pick-up an already suggested feature about that should be decided again. The lists after show existing suggestions and scheduled features of this component.
suggested for 6.1
suggested for 6.0
Already Suggested
Scheduled and Implemented

2 History

Project History II
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. Your 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 allways, 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.

3 Redundant and Rejected Feature Requests

Requests that are redundant (already implemented in other requests)
Rejected Feature Requests
Note that most of those "rejected features" have been replaced by a PR due to the change in the process of proposing new KS-Entries. 

Last edited: 16. Jul 2019, 11:58, [elena]


Search (Block)

Related Component/Module

Release Status
-

Development Status
-

Funded by
-

Testcases
-

Approval by Customer
-

Wiki Functions (Block)

Info

Recent Changes