Pokaż dodatkowe informacjeUkryj dodatkowe informacje

Course Catalogue

1 Initial Problem

Employees want to browse a course catalogue. However they do not neccessarily have access to the repository (they lack 'view' permission at 'Repository - Home' but do have 'read' permission). 

They need a point at which they can view a list and book a course they are intrested in. 

2 Conceptual Summary

1. Users click on a dedicated sub-item in the Main Menu in the Repository-item. 
2. ILIAS presents the courses available to this user in a Presentation Table.  
3. Users browse the table and register with a course. 

"Courses available to the user" refers to those courses that are online, available and give this user 'view' and 'join' permission. This will be a performance issue. 

3 User Interface Modifications

3.1 List of Affected Views

• Presetation Table for Courses
• Main Menu item Repository gets new sub-item Course Catalogue
• Administration > Main Menu 

3.2 User Interface Details

The mock-up contains a screenshot from the KS-Presentation Table

3.3 New User Interface Concepts

none

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: Tödt, Alexandra [atoedt]
• Maintainer: Studer, Martin [mstuder]
• 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

Studer, Martin [mstuder] 11 March 2019: I support this feature request.

Kunkel, Matthias [mkunkel], 18 MAR 2019 : Thanks for this feature request. But I am a bit confused. You wrote as second sentence: "However they do not neccessarily have access to the repository." This means in my understanding that this catalogue should not be part of the repository (otherwise users could not see it) and that these users will access courses in 6.0 from the 'Courses' slate. But then on your screenshots it looks as if this catalogue is a repository object - at least it appears in the breadcrumb. But if users to not have access to the repository (except by bypassing it through their course membership), how should they access this catalogue? Is it a recommended content? Would be great to understand it.

And last but not least - why don't you have called this request "Course Catalogue"? I assume it gives a better clue about what you get here ;-)

Klees, Richard [rklees], 25 MAR 2019: I am convinced that ILIAS requires a feature like this that simplifies finding and joining courses. I'm clearly in the "Repository is for Administrators"-camp and do not like to send my users in the depth of the repository as well. So in general I support this.

This request here, though, is heavily underspecified and lacks the conceptual depth that I think is required to introduce a feature like this to the core.

I try to work from specific to general:

• The mockups show information that I cannot map to information available at ILIAS courses. Where do the "Goals", "Topics", "Location" and "Fee" come from? From where does this derive "Webinar", "Face2Face" etc.? Which information from the coure is shown where?
• What courses are shown here in general? What does "courses available to this user" mean?
• What courses are shown when I use the view-control for "Upcoming Events"?
• What does "book" mean? I'm aware of a "join course" procedure, but IMO "joining something" and "booking something" is considerably different. We might have a word-mess here anyway, because "joining a course" sometimes is done in the "course registration" (right?), which would suggest I'm registering for a course. So we should not throw "booking" in here anyway. Similar to this feature, we might want to think about what "booking a course" could mean in ILIAS and conceptualize that, but this IMO will require far more than this feature request currently delivers.
• How did you arrive at the solution to introduce this as a "hard-wired sub-item" for the main menu? This will have various drawbacks (or will require expansion of the GlobalScreen-service that IMO don't belong there): There is no place to introduce settings for that thing. If so, they would require one of these "underworlds". It will not be possible show or not show that thing depending on a users roles. It won't be possible to have multiple of these things shown to different people.
• How can a user have access to anything if he does not have access to the repository? Or put in another way: What do you mean by "having access to the repository"? I suspect it means that the entry point to the repository (i.e. that item in the menu bar) is hidden by some means, while on the RBAC-side of things the user indeed can read the repository and access items in it. Is that correct?
• Then: did you consider to add this "Course Catalogue" as a module to the repository? This will bypass several issues one can already foresee with the suggested approach to add the catalogue as a hard-wired main menu item.
• Did you consider the performance implications of this approach? Showing all "available courses" for any definition of "available" is a terribly expensive thing performance-wise. You will do a lot of roundtrips to the database to check permissions and other access-control related stuff.
• Are there any ideas how we would proceed with this feature and what people would want from such a "Course Catalogue" in the future? How would they fit the currently suggested implementation as a hard-wired main menu item?
• How is this related to the "Search"? How do we demarcate these features from each other? When would a user want to use the one and when the other? Conceptual clarity is a very important piece of usability, imo.

At CaT we have been developing a plugin with a similar direction for the last ~2-years. We did not arrive at an implementation that I would deem fit for the trunk, but we are happy to contribute more by-products (like the Presentation Table) from that development. At this point these will mostly be insights, some conceptual, some technical, which informed the questions and suggestions I wrote down above.

A "Course Catalogue" imo has a lot more to it than this request here suggests. We should not hastily implement such a thing without a sustainable concept. I would suggest that we discuss this further on a workshop.

As a side note: I wonder why Martin is listed as a maintainer here. If the "Related Component/Module" is correct, it should be Alex or Stefan. If this is about the "Main Menu" (which I would doubt) Fabian would be the correct maintainer. I do think, though, that a component like this would warrant a maintenance on its own. We (CaT) might be interested in that maintainership and also would have ressources and ideas to develop such a thing. I would be happy to discuss this issue on the JF.

Please note that this intervention here is made in good faith and ain't an attempt to just stop this feature to not have this in the core for whatever reasons. I hereby voiced my concerns and offered my knowledge. If there is the strong need to go an with this as suggested in this feature request, be it.

Strassner, Denis [dstrassner], 05 APR 2019: @Alexandra: Are 30 minutes really enough to answer all of Richard's questions and discuss them? Could you maybe provide some insights before the JF?

Tödt, Alexandra [atoedt] 2019-4-08: I did adress Richards questions in the article. The following two I would like to pick out 
How did you arrive at the solution to introduce this as a "hard-wired sub-item" for the main menu? This will have various drawbacks (or will require expansion of the GlobalScreen-service that IMO don't belong there): There is no place to introduce settings for that thing. If so, they would require one of these "underworlds". It will not be possible show or not show that thing depending on a users roles. It won't be possible to have multiple of these things shown to different people.
The settings are done in 'Administration > Main Menu', the underworld does already exist. This would be the locus at which the role-sensitivity should be dealt with. If it is ever required, which it is currently not. 

Then: did you consider to add this "Course Catalogue" as a module to the repository? This will bypass several issues one can already foresee with the suggested approach to add the catalogue as a hard-wired main menu item.
This is specifically required by the customer NOT to be a respository module. This must be outside the typical ListGUI / repository world because it is intended to serve as a spring board for more elaborated registration processes for courses as are needed for vocational training. This ought not confuse or burden the student users. This is why I need a new and not-repository entry point to cater to these more complex processes. 

JourFixe, ILIAS [jourfixe], 08 APR 2019: We postpone a final decision about this feature to the next Jour Fixe. We see the advantages of such a light course catalogue but give Martin additional two weeks to finalise the concept and probably suggest some changes. We assume that there will be no performance problems when using the presentation table together with a Show More button and filter.

Kunkel, Matthias [mkunkel], 17 APR 2019 : As already suggested in my previous post from March (see above), I strongly recommend to relabel this feature request and name it "Course Catalogue". The current one does not give a full impression about what this request is about.

Studer, Martin [mstuder], 05 MAY 2019: Here is my proposal for the configuration part for course catalogues: Catalogue

8 Implementation

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

Approval

Approved at {date} by {user}.