Feature Wiki

Information about planned and released features

Tabs

UI - Kitchen - Sink (deprecated)

Page Overview

[Hide]

1 Requirements

Context
The introduction of Bootstrap as HTML, CSS and JS framework sets the Client-Side of ILIAS on a solid foundation for further innovations and usability improvements.  The implementation of UI-Framework led to several further design revisions as described in  Design-Revision. For further improvement we believe a tighter coupling of ILIAS and Bootstrap to be necessary. Many members of the Community at the „Customizing ILIAS“ workshop at the Conference in Bozen expressed their wish that Bootstrap classes and elements are to be used whenever possible. Usage of Elements not provided by Bootstrap has to be reasonably justified. This automatically leads to an easy usage of Bootstrap Themes outside the ILIAS world and would lead to a quick popularity gain of ILIAS as a product. However, the transition of the large number of UI-Elements used in ILIAS to Bootstrap classes and concepts might turn out to be a big challenge. There has already been a lot of work done listing the differen UI-Elements in the feature wiki, which is a great start for further steps. We believe that the whole structure of ILIAS has to be changed from top-down, starting with the grid of the ILIAS layout going down to every template. To complete this task we propose the initiation of the UI-Kitchen-Sink (de.wikipedia.org/wiki/Kitchen_Sink)

Proposed Solution
The UI-Kitchen-Sink is the presentation of all UI-Elements of ILIAS in a static webpage along with a short description and the used less variables. The name of the service GUI-Class rendering this UI-Element is also necessary, if available. Further, a distinction of the context in which an element is allowed to be used has to be stated if there are restrictions. The key behind the UI-Kitchen would be that it is only composed of UI-Elements that ILIAS is using. Meaning: If tabs are used in the UI-Kitchen-Page, those would be the ILIAS tabs, the whole skeleton of the page would be the skeleton of ILIAS using Bootstrap elements. A very incomplete draft of such a UI-Kitch-Sink is demonstrated here: Demo. Be aware that this serves as an example of how such a UI-Kitchen-Sink could look like – no more than that. So far, this demo is more or less a listing of some quite common bootstrap UI-Elements. Also note that this demo page can be directly styled by change less variables. The context menu to do this can be opened by clicking on the button on the top right ("Customize").
 
All UI-Elements available should be visible on this static webpage. The developer and also the customer planning new features immediately see the UI-Elements that can be used to implement such innovations. If an element is missing, a request to the JF can be made to add a certain element in a future version of ILIAS.

Key Aspects
The UI-Kitchen-Sink (and therefore in the long term also ILIAS) would need to:

  • rely on bootstrap elements wherever possible
  • be completely customizable by only changing less variables (each UI-Elements needs to be adaptable through less variables). Whenever possible only Bootstrap-Less variables should be used.
  • only rely on a bare minimum of custom ILIAS css (delos). Important, the development should start by using none of the css used by ILIAS today.
  • only be altered by approval of the JF once a first version is finished.
  • Include all used UI-Elements such as dropdowns, tabs, buttons, form elements, tables etc.
  • display the name of the service GUI class to use to render the UI-Element
  • give html snippets used in the template for this UI-Element
  • explain the context in which a specific element is allowed to be used (if there are restrictions)
The UI-Kitchen-Sink would have the following benefits:
  • All in ILIAS used design elements are properly documented and signed off by JF.
  • Developers do not make design decisions; they have a catalog with visual examples of UI-Elements that can and should be used along with the GUI-Class or html snippet.
  • Developers are not allowed to use module specific css anymore. If they need to, they have to create a feature request for a service with a GUI class for this UI-Element, which requires a JF approval. This leads to a transparent overview of UI-Elements used in ILIAS.
  • Mainstreaming design elements in ILIAS
  • Maintainability of the design
  • The development of ILIAS can be better tailored to future Bootstrap developments. This will lead to better maintainability of the design elements (keyword: browser compatibility)
  • Individuals with knowledge of Bootstrap will easily be able to write ILIAS-templates.
  • Fast template creation (maybe even completely through adapting less variables in the administration)
  • Fast mockup creation
  • Simplified communication between customers and developers since all UI-Elements available can be shown in the UI-Kitchen-Sink when discussing a mockup
We propose the UI-Kitchen-Sink to be a static web page because:
  • Drafts of Elements can be discussed before they need to be implemented into ILIAS (they could be marked as “Proposal for 5.1" or similar)
  • The Designer of the first version of the UI-Kitchen-Sink can actually focus on designing client side elements without having to worry about aspects of the server side implementation. The creation would therefore be much quicker.

Milestones [edited on 25 June by Amstutz, Timon [amstutz] and again on 7. September by Amstutz, Timon [amstutz] ]
The creation of the UI-Kitchen-Sink would consist of the following milestones:
 

  1. November 2015: Workshop with interested developers and members heavily involved with UI
  2. January 2015: Present Base version of UI-Kitchen-Sink at JF
  3. February 2016: Integrate UI-Kitchen-Sink into ILIAS Development workflow
Remark
  1. The proposals in the UI-Kichten-Sink will change the DOM structure of future ILIAS versions.
  2. They might also change the visual appearence of visual elements if needed
  3. The proposals will change interaction with elements only if absolutly necessary

Roles
Proposed project roles:

  • Development: studer + raimann ag and University of Berne
  • Project leader: Timon Amstutz, timon.amstutz@ilub.unibe.ch

2 Status

3 Additional Information

Contact the following persons if you want to know more about this feature, its implementation or funding:

  • Information about concept: Timon Amstutz, timon.amstutz@ilub.unibe.ch
  • Information about funding: (name, e-mail)
  • Information about implementation: (name, e-mail)

4 Discussion

Patrick: Bootflat Framework as a Kitchen-Sink. Another example: http://bootflat.github.io/documentation.html - However, please note that's only the Design of Bootstrap Elements.

JF 16 Mar 2014: We support the general idea. Since this is not a feature request, it is not necessary to schedule this item. We are unsure how much effort will be needed to make this project a success. At some point we have to evaluate how much budget is additionally necessary to come to in most parts of ILIAS "final" solution.
 
Some changes/additions to the text above:

  • customization as far as possible by less vars
  • "not yet implemented" stamp for elements
  • link to dev guide, if available
  • in the future, if available, ILIAS UI classes should be used to generate the HTML (proposals will be made in HTML)
  • third party plugins should be avoided whenever possible.

Killing, Alexander [alex], 24 June 2015: This page still states that the base version of the Kitchen Sink will be presented during May and a final version will come in July. @Timon: Please provide updates on the schedule and put this on the Jour Fixe agenda. Also the dependency kitchen sink/design revision should be clarified (text still says that the design revison has to wait for the kitchen sink) again in the Jour Fixe.

Amstutz, Timon [amstutz], 25 June 2015: @Alex: Thank you for the remark. You are correct, I did neglect to update this page. I did now refresh the milestones. As communicated to developers per mail april, the work on the guidilines takes longer than expected. The University of Berne managed to organized additionial ressources to handle this project. On the down side, the UI-Kitchen-Sink will not offer much help to the developers for 5.1. This project grew bigger than initially expected, therefore the milestones had to be shifted back.

Concerning the Design Revision 5.1 we are in contact with Mathias Kunkel. Together with him we installed a DC giving an overview of the current state of the Design Revision 5.1 state (Overview).

JourFixe, ILIAS [jourfixe], 6 July 2015:

  • The kitchen sink group will make some design proposals for ILIAS 5.1 until today.
  • The kitchen sink will make a inventory of all elements already used in ILIAS until January 2016.
  • We would like to schedule a workshop for september/beginning of october to discuss general concepts and components in a larger group.

Amstutz, Timon [amstutz], September 7, 2015: Due to a longer vacation in october we have to schedule the workshop in november. Please fill out the following doodle to fix a date: http://doodle.com/poll/gy7cwbiik7htt3gk#table

We published to current version of the UI-Kitchen-Sink at: http://ilublx1.unibe.ch. This is an early working draft of the UI-Kitchen-Sink with some sketched idea the still need a lot of work before being able to be published.

The GIT repo is also openly available at: https://github.com/studer-raimann/UI-Kitchen-Sink

Please give us feedback to the following questions:

  • Do you have comments/additions/critique to the proposed workflows?
  • Do you have comments/additions/critique to the proposed guidelines?
  • Do you have comments/additions/critique to the proposed naming of future DOM-Elements?
  • Do you have comments/additions/critique to the proposed naming of less classes and variables?
  • Do you have suggestions for additional categories or do you think a category should be renamed/changed/removed?
Please note: On July 6. we decided on the JF, that we will make an inventory OF ALL elements already used in ILIAS. Unfortunately we had to give up on this tasks, since those elements currently come in to many forms and shapes. Instead we started and will continue to adapt frequently used items according to the guidelines and propose them the the JF.

Neumann, Fred [fneumann] September 15, 2015: Do you already check the accessibility of the GUI elements? I don't have a clue if the new bootstrap layout and it's DOM fits better or worse for the WCAG guidelines, but I fear that topic got a bit out of focus, though it is still important in public institutions. It would be good if the kitchen sink takes care of that and declares the conformance level (A, AA or AAA) of its elements.

Amstutz, Timon [amstutz] September 17, 2015: @Neumann, Fred [fneumann], thank you for your feedback. In general I personally feel, that the accessability got rather worse than better with the change to bootstrap. I was myself not completely aware of the importance of that topic untill Killing, Alexander [alex] reminded me kindly this summer to look out for that. The problem is, that a lot of RIA-Tools of today make it rather hard to keep the page accessible. You are right in pointing out that we keep to look out for that and check carefully by implenting new functionality or adding external libraries. The Accessible Rich Internet Applications document gives an excelent recomendations on the topic. Any suggestions for guidelines and/or ratings for suggested objects are very welcome.  I think we should defenitly think about declaring the conformance level of each element. Do you know if tools for automated conformance testing are reliable?

Neumann, Fred [fneumann], September 22, 2015: To be honest, I'm not up to date with the most recent guidelines and conformance testing tools. I know from a former project of the Bundesagentur für Arbeit for ILIAS 4.0, that the the formal guidelines not necessarily match the real needs. At that time we got the best insights from a session at their Cometence Center, seeing a live demonstration of assistive tools and how they behave with ILIAS. E.g. the widelly discussed use of html tables was nearly obsolete by introducing the "datatable" attribute. 
I think we also need to priorize the accessibility of ILIAS functions. Login, Navigation, Course and Group registration should have the highest priority, as they are prerequisites for viewing contents (which may be offered with alternatives). Drag&Drop questions in test will probably not have a chance to get accessible without larger developments.
My current question is motivated by the statement of a blind student who had problems with the course registration. I hope we can win her for cooperation.

5 Implementation

...

Last edited: 15. Dec 2021, 09:09, Schmid, Fabian [fschmid]