Guided Tour

1 Initial Problem

• Some users actively explore learning plattforms.  Some other users feel anxious and want guidance. They feel insecure about their options.
• Complex software requires complex navigation. We have been discussing and implementing improvements for a long time, but ILIAS will likely never be completely self-explanatory.
• The current Online Help supports users, but makes it hard to refer to concrete navigational controls. It is much easier to show these things in person by pointing at the screen. 

A software version of "pointing at the screen" would be a guided tour!

It could be used for classic Help contexts, onboarding of new users and even for a new and shiny ILIAS demo!

Example of guided tours:

• Bootstrap tours
• Userlane tours

2 Conceptual Summary

The Guided Tour complements the work instructions and the tool tips.

• Guided Tours can be created per screen / tab and point out information for a certain element.  
• Guided Tours cannot open or click elements, they merely draw attention to the existence of element.
• This may be extened to clicking&opening if the KS-elementen used in Main and Metabar and the Global Screen service provide a stable mechanism to do so.
• Blobs can hold page editor content.

Starting Guided Tours 

• Guided Tours are presented once a users opens a screen.
• She is presented with blobs pointing to important controls. Blobs are presented in a predefined sequence.
• There is no manual starting of a Guided Tour. 
• In order to present the Tour only once, ILIAS must save that somebody has never seen the tour, refused to see it, completed it. 

Ending Tours

• User can only end the Guided Tour by clicking on [End Tour]. 
• Any Tour that was ended will never be shown again. Users can not call upon the Guided Tour again. 
• Unless the Tour was ended it will be presented again if user revisits the context. 

Adressability of controls 

• Ebentually the Global Screen Service is to manage all adresses. This endeavor may take until ILIAS 11. 
• Thus there will be transition from the exiting adresses (Help Screen IDs and Tooltip IDs) to the new ones. This wil cause disruption of one kind or the other. A caveat is advised to all users. 
• What can be adressed? Mainbar entries, Metabar entries, Tabs / Sub-Tabs, KS-Buttons, KS-Buttons in Toolbars, Secondary Panels and Main Panels are to be adressible. 
  • Tabs / Subtabs would be very desirable but if they cannot be included this is noshow stopper. 

Adding Guided Tours 

• Guided Tours are added and managed in a new tab at Administration > System Setting and Maintenance > Help System > Guided Tours
• Tours can be added to one specific screen, identified by its adress. 
• Steps can be added to Tours comprising the adress of the hook and the content of the blob. 

Editing Guided tours

• How do Editors harvest Purpose IDs? Does global Screen deliver and I get drop Downs? like ilControl? Then I cannot make mistakes. If that is not possible how do editors present Ids for manual harvesting. 

3 User Interface Modifications

3.1 List of Affected Views

• potenially all screens
• Administration > System Setting and Maintenance > Help System > Guided Tours (new)

3.2 User Interface Details

3.3 New User Interface Concepts

We would like to use the Kitchensink-Element Popover. Maybe it needs to be amended with a spotlight or similar means to focus attention. 

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 Privacy Information

It will be stored whether or not a user has shut down the tour / taken the tour. 

6 Security Implications

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

7 Contact

• Author of the Request: Tödt, Alexandra [atoedt]
• Maintainer: Killing, Alexander [alex]
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• ILIAS.nrw (Heinrich Heine Universität Düsseldorf)

9 Discussion

Kruse, Fabian [Fabian], 23.11.2020: This would be a great way to contribute to better user adaptation of ILIAS. It could be used not just as part of the help, but also in our new demo and in other places.

I would consider using existing software to implement this, like the tools linked above.

10 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}.