Feature Wiki
Tabs
User Connections / Approved Contacts
Page Overview
[Hide]1 Requirements
The following requirements build upon those of the Buddy System. We do not think the term "Buddy" is appropriate in a vocational education setting. This is why we have dropped the term. The label for this feature is still under discussion, the working title is "user connections" or "approved contacts".
What is a user connection / an approved contact?
An approved contact is a connection between two people that have actively consented to enter a relationship for learning or collaborating. Contacts are requested and approved by messages.
This feature is extending the functionality "Contacts" in the Personal Desktop.
We are aware that the same code is providing the PD drop-down-entry "Contacts" and a subsection of the PD drop-down-entry "Mail". It is important to resolve the navigational issues resulting from the different stackings of the navigation in these two features. We want to keep the tabs in both places with the according labels with the exception of the tab Contacts that might need re-labeling.
Where are contacts shown?
- New Block "Contacts" directly on Personal Desktop should be created to make users more aware of the functionality.
- "Contacts" in drop-down-entry of Personal Desktop will serve as the place to manage contacts. It comprises two views of one's contacts:
- The list of contacts is supposed to be presented as a gallery like in courses and groups. This is attractive but does not allow to carry out an action for multiple contacts.
- The list of contacts is supposed to be presented as a table allowing for carrying out an action for multiple contacts and column configuartation as in courses and groups. In the table view a click on the name will no longer trigger sending a mail but the respective Personal Profile will be shown. In this table there should be a proper filter. Filters should be available for: Name (entryfield), Status (drop down), courses / groups (drop down)
1.1 Process of forming user connections / contacts
1. Search user
In most cases the requests for contact will not be send after searching for somebody but rather from the Members Gallery of a course or group. But a search must nevertheless be available. There are different ways to search for the user to whom one wants to send a request for contact.:
- Search for known name In the PD entry "Contacts" in the tab "My Contacts should offer a toolbar with a user search. This user search allows to find people one can pose a request for contact. The search results presents the name and an action-link "Request Contact"
- Pick from list of members In PD entry "Contacts" in the tab "My Courses" or "My Groups" one can pick users from a list of members. There should be an action-link "List Members". Please consider to make the course/groupname clickable, if this was a link maybe the bulky "Path"-column can go and the table would be lighter. (see Mock-up 2) Sfter a course or group is selected, ILIAS will list it's members. In the column "Status of Contact" the status of the contact request will be displayed. (see Mock-up 3)The different status are:
- Approved
- Declines
- No Contact
- Pending Request
- Blocked
2. Send request for contact to user
The main scenario for requesting contact however is not going through the serach or the "Contacts" of the PD but to directly request contact via the Member Gallery of a course or Group. The user entry of the Members Gallery should be extended to bear a link "Request Contact" for every member one has no contact with. The other possible status might (Pending Request,...) be displayed instead.
But any Request, coming from a search or a link in the Members Gallery will be a "Request for Contact"-message organised like:
- Sender: User that requests the contact
- Recipient: User that is asked to approve the connection
- Topic (optional):
- Request text: A standard text will be offered, but it can be edited by the user.
- Accept and Decline Buttons
3. Answer request for contact
The user that received the request for contact can accept or decline and can optionally write a text to go along with that. If the request is accepted, thecontact is approved and a connection is formed between those two people. If the request is declined, the process ends here.
It remains an open question, whether the "Request for Contact"-meassage is a mail and thus will may get 'burried' in the mail or whether it should be displayed additionall mor prominent.
One option could be to create a dedicated contact icon and display it in the utilities bar in the top right corner. (see Mock-up 4)
The user opens the Request for Contact and answers it: either by simply clicking [Approve] or [Decline] or by additionally writing a few word accompanying that decision.
If the user approves of the request for contact, both sender and recipient of the request for contact will be listed as "Approved Contact" in the respective liste in "Contacts" of the PD.
If the user declines that person will be featured with the status "Declined". It is possbile to write a new request for contact to a user who decline an earlier request. To stop stalking a status "blocked" should be implemented even though this would add complexity.
4. Administer contacts
Changes to the status of a contact are to be carried out in the "Contacts" section of the PD.
1.2 Contacts in the Administration-Panel
Currently the "Contacts" are activated / deactivated in the "Personal Desktop"-section of the Administration-Panel. This activation at least needs a explanatory by-line, stating that activated contacts are relevant for the use of the Awareness Tool.
It should be discussed if the Awareness Tool can be used if the "Contacts" on the PD is deactivated. Can users use the Awareness Tool when they cannot use contacts? Can users manage their contacts somehow clumsily in the Awareness Tool itself? What happens if the Personal Desktop is deactivated altogether?
Handling Heritage Data
In the Contacts on the PD we have three types of entries: Users without ILIAS account, not approved contacts and approved contacts.
At least for the ENCOA-installation we assume that there will be entries of users without ILIAS account. They should be preserved. But we will move the cron-job that is currently triggered by users in the Actions and is listed in the Update column to a general feature in the Administration-Panel. This feature will be generally activated / deactivated and not longer be configurable by users.
2 Additional Information
- Idea / concept: Alexandra Tödt, toedt at leifos.com
- Interest in funding: …
- Maintainer: (will be set by Jour Fixe)
- Implementation of the feature is done by Jansen, Michael [mjansen], Databay AG AG
- Test cases by / status: (name, e-mail), (status information set after implementation)
3 Discussion
CK 20150410: We most likely have funding from N.N. (you might want to update the ticket) for this, with the following modifications:
- no block 'contacts' on the personal desktop (this could be deferred to a later iteration of this feature..)
- the status 'request declined' should be 'request ignored' (i.e. the requesting person does not get notified about the request being ignored)
- we probably don't have funding for the "blocking users completely" sub-feature (could be deferred to a later iteration of the approved contacts feature - or could even be independ of approved contacts)
- It should be possible to deactivate/hide the addressbook, when approved contacts are used to have a minimalistic user experience
- When searching for users we would like to present the result as a gallery, exactly like the members gallery in a course or group (the same code and templates for the presentation should be used). An alternative table view can make sense in both cases (compare Printable Member List for Members) and could be accessible via some switch to flip between both presentation modes (gallery vs. table). The gallery should be the default presentation and there should be settings. In the table presentation of (user) search results, we would like to omit the relevance column (would anyone miss it?).
- We would like to add the following to the 'awareness/contacts' menu:
- 'search users' box (in turn we would like to _remove_ it from the usual search box, so there would be a more clear separation between 'search users' and 'search content')
- a quick link to my contacts (or even the lists of other course members)
- We would like discuss the possibility to manage 'incoming' requests directly in this menu, i.e. accepting / ignoring requests without navigation to 'my contacts'
- Where should the approved contact feature be configured? Does it still fit into Administration > Personal Desktop?
I hope this is not to complicated - it shall help to have a clear understanding of the intended implementation of this feature. The following is a list of all possible states for the relation of two users A / B and the possible transitions. We have 4 general classes of states, of which 2 are asymmetrical (i.e. there exists an inverse, as described below). From the individual perspective of one user the relation with another user can be in 6=4+2 states, because of the asymmetry of 2 states.
General Classes of States (4)
- N : No Contact / No Contact [symmetrical]
- R : Pending Request / Incoming Request [asymmetrical -> inverse is a separate state]
- I : Pending Request / Ignored [asymmetrical -> inverse is a separate state]
- A : Approved / Approved [symmetrical]
- r : Incoming Request / Pending Request
- i : Ignored / Pending Request
=> total: 6 states
=> 30 possible transitions (=6x5) to be discussed
Allowed state transitions (7)
- N -> R : A sends request
- R -> N : A cancels request
- R -> I : B ignores request
- R -> A : B accepts request
- I -> N : A cancels request
- I -> A : B accepts request
- A -> N : A or B cancel contact
- N -> r : B sends request
- r -> N : B cancels request
- r -> i : A ignores request
- r -> A : A accepts request
- i -> N : B cancels request
- i -> A : A accepts request
- N -> I : does not make sense
- N -> A : does not make sense
- I -> R : does not make sense
- A -> R : does not make sense
- A -> I : does not make sense
- N -> i : does not make sense
- i -> r : does not make sense
- A -> r : does not make sense
- A -> i : does not make sense
- R -> r : does not make sense
- R -> i : does not make sense
- r -> R : does not make sense
- r -> I : does not make sense
- I -> r : does not make sense
- I -> i : does not make sense
- i -> R : does not make sense
- i -> I : does not make sense
EDIT: Maybe it's much simpler to have a split-status model for contact + request - the transitions would stay the same as in the combined status model of course.
Symmetrical Contact-Status [A <-> B]:
- N: no contact (implicit)
- R: Request in Progress (-> reference to request)
- A: Approved
- P/p: Pending (initiated by A/B)
- I/i: Ignored (initiated by A/B, but ignored by B/A)
CK 20150410:
- We suggest to add a setting to omit the custom explanation-messages, when adding / removing contacts (to simplify the process)
- Sorting should default to status approved > pending > ignored (> not connected) and then name
- In 'my contacts' we propose a checkbox 'show suggestions for new contacts' which also shows all other members of my courses and groups which I am not connected to (however they are shown after my approved and pending contacts, because sorting should default to status)
- In 'my contacts' we would like *not* to implement the 'filter after name'. Instead we propose to embed the user search to be able to find users globally. The presentation of user search results should default to a gallery presentation (switching to table possible)
JF 27 Apr 2015: We appreciate the feature in general and schedule it for 5.1, please provide some general mock-ups of the finally envisaged screens.
- A personal desktop block for contacts is not needed, the main contacts list should be accessible via the personal desktop drop down.
- Having a status "Ignored" instead of "Blocked" is ok for us.
- Colins state concept is fine for us.
- It shoud be possible to deactivate the possibility to add non-ILIAS users to the adress book feature in the mail component.
- Approved contacts should always be listed in the adress book.
- Please check the possibility of implementing a general contact GUI element that is able to present approved contacts, internal users (as being added to the classic adress book) and "external" contacts (no ILIAS user, but in adress book) in different contexts. E.g. when adding users to a group a user should be able to select users from her personal contact list (including approved contacts and internal users of the adress book).
- Using ajax requests in the contact workflow is ok.
- A text message when asking a user for contact approval is not necessary.
JourFixe, ILIAS [jourfixe], 6 July 2015:
- Please provide an ILIAS mail (with permalinks for accepting the contact, redirecting to the profile of the requesting user, if available, otherwise to the personal desktop) and OSD, if new contacts are sent, if possible
- The requests for contacts should be integrated into the awareness tool, the awareness list should be updated immediatly after contacts have been accepted/ignored/...
- The number of contact requests should be displayed in orange.
- We support the centralization of the members gallery. Matthias will try to provide a design proposal for the members gallery.
- Request Contacts should be visualized as an orange number on the top right, general number of users in the awareness list in mid grey on the lower right. Timon will make the badge use a topic in the UI kitchen sink.
- Additionally to the gallery view, the contacts should be listed as a table, too.
- The "mail" button should be omitted in the gallery view.
- The "Request" button should only use existing button classes btn-default.
- Instead of "Link" the initial button should be callsed "Request Contact"
- Please remove the "clock" glyph in the button (and similar ones that appear in other cases)
- The user result should feature a button to request contacts.
- It should be possible to (de-)activate the "Contacts" feature globally.
Kunkel, Matthias [mkunkel], August 05, 2015: I have read again this feature request and the postings and decisions today. And I ask myself if we really still need a dedicated "Address Book" in 5.1 when we have "My Contacts" and the extended "Who-is-online?" (aka Awareness Tool). I see sound usability problems and superfluous clutter when ILIAS presents a sub-tab "My Contacts" next to a sub-tab "Address Book" and both contain users - but one is used for contacting them in ILIAS and another for contacting them per e-mail. Do we really need these both lists of users?
My suggestion:
- We get rid of the Address Book.
- We extend "My Contacts" with the capability to select users and send them a mail (easy to implement in "List" view of contacts by just adding checkboxes in front of each row and an option "Send Mail", more difficult on a "Gallery" view at least for more than one user).
- We abstain from the sparely used option to add mail addresses without any relation to an existing ILIAS user. (I would declare myself as a power user and I even use address book and mailing list feature in ILIAS - but there is not a single e-mail address of an external person in my address book.)
Last comment: The option "Requires mail permission" under "Enable Contacts" in Administration » Personal Desktop should be removed as the Contact feature is no longer only a mail feature. Even if a user has no permission to use mail in ILIAS, the contact feature might be needed because of an activated awareness tool / ‘Who-is-online?’.
Jansen, Michael [mjansen], August 05, 2015: I totally agree with Matthias.
Kunkel, Matthias [mkunkel], August 06, 2015: Thanks, Michael, for your statement. Feature page is on JF agenda to get a final decision about my suggestion.
JourFixe, ILIAS [jourfixe], August 17, 2015: We appreciate the suggestion to abandon the address book. There should be a page for Abandon Address Book where all relevant information is presented to notify administrators about the change with 5.1. Entries for system users in the address book should be migrated to unconfirmed user contacts (or to confirmed users when both users have each others in their address books). Entries that consists only of an e-mail address shall be deleted. Inactive users are migrated, too.
Jansen, Michael [mjansen], August 19, 2015: I added a migration step. This will not work on the official edge test installation (because the address book is aldready deleted).
Kunkel, Matthias [mkunkel], Nov 09, 2015: For privacy reasons we need a general setting to enable the contacts feature in the administration and a personal setting for users to prevent being contacted. The new administration node will be placed under ‘Who is online?’-Tool. The new personal setting "Allow to contact me" should be placed on the Personal settings under "Hide me in Who is online?". An icon for the new administration node will be provided soon.
Jansen, Michael [mjansen], Nov 09 2015: I already added the new administration node where administrators are able to enable the feature globally.
Jansen, Michael [mjansen], Nov 10 2015: I also added a new personal setting "Allow to contact me". This setting only affects the state unlinked and prevents other users from requesting a user's friendship.
4 Implementation
Jansen, Michael [mjansen] September 30, 2015: Implementation processed according to status model described in the comments.
- We did not integrate a specific search toolbar (mentioned in 1.1 Process of forming user connections / contacts, section 1). Instead the button widget was included in the results of the global user search.
- We do not offer a topic or request text for a user connection request
- The contacts feature is activated if either the "Who is online?" or the "mail system" is enabled (resp. the access for the user is granted)
Jansen, Michael [mjansen] September 30, 2015: We abandoned the address book feature which was part of ILIAS <= v. 5.0.x (see: Abandon Address Book)
Test Cases
Test cases completed at 26.08.2015 by Suittenpointner, Florian [suittenpointner]
- C6403: Kontaktanfrage an Benutzer senden (über Benutzerprofil)
- C6404: Kontaktanfrage an Benutzer senden (über Suchergebnis der Benutzersuche)
- C6405: Kontaktanfrage an Benutzer senden (über Mitgliedergalerie eines Kurses)
- C6406: Kontaktanfrage an Benutzer senden (über Mitgliedergalerie einer Gruppe)
- C6407: Mit deaktiviertem Profil Kontaktanfrage an Benutzer senden (exemplarisch über Benutzerprofil)
- C6408: Kontaktanfrage an Benutzer mit deaktiviertem Profil senden (exemplarisch über Mitgliedergalerie eines Kurses)
- C6409: Kontaktanfrage zurückziehen
- C6410: Aktuelle Kontaktanfrage bestätigen
- C6448: Aktuelle Kontaktanfrage bestätigen (via Pop-up)
- C6470: Aktuelle Kontaktanfrage bestätigen (via E-Mail)
- C6455: Aktuelle Kontaktanfrage von Benutzer mit deaktiviertem Profil bestätigen (via Pop-up)
- C6411: Aktuelle Kontaktanfrage ignorieren
- C6450: Aktuelle Kontaktanfrage ignorieren (via Pop-up)
- C6471: Aktuelle Kontaktanfrage ignorieren (via E-Mail)
- C6454: Aktuelle Kontaktanfrage von Benutzer mit deaktiviertem Profil ignorieren (via Pop-up)
- C6412: Bestehenden Kontakt beenden (Kontakt-Status ändern: Bestätigt > Kein Kontakt)
- C6413: Anfrage später annehmen (Kontakt-Status ändern: Ignoriert > Bestätigt)
Approval
Tested successfully in the customer branch and approved at 18.05.2015 by . However we did not test the notification mail and removal of the address book which was not a requirement of our customer so far. This should be covered by the test cases however.
Last edited: 20. Mar 2023, 09:16, Samoila, Oliver [oliver.samoila]