Feature Wiki

Information about planned and released features

Zakładka

Template and Organisation of KS-Inventory

1 Requirements

We suggest to organise the inventory around two major concepts:

  • Aggregation:
    • Elements: Elements are the smallest items in the UI that can be considered ‘whole’.
    • Collections: Collections combine elements.
    • Layouts: Layouts outline how elements and collections are put together to something greater than a collection.
  • Interactivity
    • Interactive: An entry is considered to be ‘interactive’ if one clicks on the respective control and then something happens.
    • Non-interactive:  An entry is considered to be ‘non-interactive’ if information is to be taken from it but no clicking is to be expected

The following template serves for describing UI-elements and collections.
The left column indicates the field title, whether it is mandatory and the type of data entered.

Name*:
(text)

Name by which this control is to be referred to.
Names will picked to communicate well to a wider audience. ILIAS Community idoms will be re-named according to the following in descending priority:

  1. Established name in web development
  2. Bootstrap naming
  3. Established ILIAS name
  4. ILIAS PHP Class name
  5. other name
                        
Example: Until ILIAS 5.1 the navigation underneath the Top Bar in the Main Header was called ‘Locator’, it is re-named to ‘Breadcrumb’ since Breadcrumb is an established name in web development.

DOM*:
LESS*:
JS*:
(code)
 
Screenshot*:
(JPEG)

After Acceptance:
All elements accepted by the Jour Fixe are demonstrated with a working HTML Example including JS and LESS.
 
Prior Acceptance:
One or more screenshots of the control to allow for identification. Some controls are ‘abstract’ meaning they are not used in the described general form, only as a specific sub-type. Such items do not have a screenshot attached.

PHP Class:
(code)

Class used in code to render this control.

PHP Example:
(code)

Code snippets to demonstrate usage of the PHP class to render the output. This code snippet along with the example might further be used for automated UI-Testing by PHP-Unit.

External Library:
(controlled vocabulary)

Title of library, if any
Displays title of library from the central list of external libraries including version information

Status of Entries*:
(controlled vocabulary)

There are 3 statuses

  • Accepted: This entry has been accepted by the JF.
  • Proposed: This entry has been revised and is proposed to the JF but has not yet been decided upon.
  • To be revised: This entry is still being worked on.

Status of Implementation*:
(controlled vocabulary)

There are 3 statuses:

  • Implemented for X.Y
  • Partly implemented for ILIAS X.Y
  • To be implemented for ILIAS X.Y

Description*:
(text)

The description states

  • Purpose: what is to be done by this control
  • Composition: what parts make it up and how they are arranged relative to each other
  • Effect: what happens if the control is operated
  • Rival elements: what other controls are similar, what is their distinction

Background:
(text)

Relevant academic information

Context*:
(text)

The context states

  • Occurrences: where this control is used specifically. This list might not be complete
  • Prevalence: how common is this control used
 
Abstract controls do not have a context, information on context is are only provided for concrete subtypes of the abstract entries.

Feature Wiki References:
(URL)

URLs to relevant articles

Rules:
(text)

Rules state

  • Specific requirements and restrictions on uses and placing
  • Specific restriction on interactions with other components
  • Specific restrictions on the usage and placing of other components used by this components
  • Specific restrictions on occurrences
  • Specific requirements and restrictions for the small screen
  • Specific requirements for approval by Jour Fixe
The following key words are used to signify the requirements of the rules (According to RFC2119):
  • MUST: This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the UI-Kitchen-Sink. Implementation not following such a guideline may be reported as bug.
  • MUST NOT: This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. Implementation not following such a guideline may be reported as bug.
  • SHOULD: This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. It depends strongly on the context if an object not following such a specification can be reported as bug.
  • SHOULD NOT: This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. It depends strongly on the context if an object not following such a specification can be reported as bug.
  • MAY: This word, or the adjective "OPTIONAL", mean that an item is truly optional.
RFC-2119 keywords are formatted in uppercase. When the keywords shown above are used in any other foramt they do not convey formal information in the RFC 2119 sense, and are merely explanatory.

Todo for ILIAS X.Y:
(text)

This to-do list comprises all issues that need to be addressed for this entry to get the status “Implemented” for the upcoming ILIAS version.
 
There are two different types of todos.

  • Todos for ILIAS 5.1 are considered as a bug.They are to be fixed without additional funding (see last section of this document).
  • Todos for ILIAS 5.2 are considered as feature (see last section of this document).
Let us know, if you feel that certain todos are wrongly classified according to your opinion. Also we ask you to add further todos, if you know if issues resulting with the proposed rules.

Relations

  • Is A:
  • Children:
(references)

Relations ties an entry to other entries in the inventory

2 Additional Information

  • Idea / concept: Timon Amstutz
  • Interest in funding: (please indicate if you are interested/able to fund this feature)
  • Maintainer: (will be set by Jour Fixe / maintainer)
  • Implementation of the feature is done by (will be set by Jour Fixe / maintainer)
  • Testcases by: (please add your name if you want to create the testcases for this feature)

3 Discussion

JourFixe, ILIAS [jourfixe], Dec 07, 2015: Template and organisation are accepted and appreciated.

4 Implementation

{please 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}

Approval

Approved at {date} by {user}.

Ostatnio zmieniono:: 11. Gru 2015, 11:14, Amstutz, Timon [amstutz]