HJLauener 23 Nov 2011:
 
[JL] Ich habe damit jetzt in 4.3 begonnen, aber dazu noch ein paar Fragen: die Erweiterung der Attendance List um Leerspalten und die ID-Auswahl ist soweit klar (siehe Anhang "session"). Laut dem Feature Wiki soll diese Funktion nun auch für Kurse und Gruppen (?)
 
Ja, diese Funktionen müssen für Kurse und Gruppen vorhanden sein, da dies sinnvoll ist, und es soweit ich weiss einen "internen" Beschluss gibt, dass Kurse und Gruppen von den Funktionalitäten her möglichst angepasst sein sollen.
 
[JL] im jeweiligen Members-Tab verfügbar sein. Vorschlag bisher ist ein neuer Subtab. Wäre es hier nicht einfacher der Member-List einen Button "[Generate] Attendance List" hinzuzufügen (siehe Anhang "course")?
 
Mmm, wäre wohl einfacher. Was meinen Alex und Matthias dazu? Ich will das nicht entscheiden.
 
[JL] Da es im Kurs ja bereits eine Print-Funktion gibt, könnte man diese nicht erweitern bzw. irgendwie die beiden Funktionen zusammenführen?
 
Da ist zu unterscheiden:
 
a) Die jetzige "Print"-Funktion im Kurs bewirkt, dass in einer Tabelle die Metadaten: Name, User Name, Role, Learning Progress, Last Access und Status Passed aufgelistet werden. Sortiert nach dem Nachnamen. Das ist also eine Liste, die administrative Kursverwaltungsfunktionen innehat: Der Admin sieht in einer Print-Version, wer welchen Status hat, wann zuletzt zugegriffen hat, der Learning Progress usw. Diese Liste muss wohl so unverändert bleiben, da dies sicher so eingesetzt wird, bzw. eine Anforderung von früher ist. Den Button würde ich aber umbenennen, und diesen neuen Namen auch im Ausdruck klar einsetzen. Varianten: "Print General list", "Print Standard list" oder "Print User list".
 
b) Die "Print"-Funktion
 
[JL] Auf der Wiki-Seite werden zwei Spalten "Registered" und "Participated" gezeigt, sind diese neu bzw. in welcher Ansicht bereits verfügbar?
 
vgl. "Print"-Funktion in Sitzung.
 
Die Print-Funktion der Sitzung sollte unverändert übernommen werden, mit den Kolonnen "Note", "Comment", "Participated". => ABER: Die Kolonne "Registered" ist nur in der Sitzung notwendig, diese Funktion erscheint dort, wenn man in den Sitzungs-Einstellungen erlaubt, dass sich User für die Sitzung registrieren können. Also hier auf Kurs/Gruppenebene die Kolonne "Registered" nicht umsetzen. Ich würde dieser Print-Funktion z.B. den Namen "Print Participant List" geben, damit es von der Print-Funktion a) unterscheidbar ist.
 
c) Die letzte Funktion wäre unverändert "Generate attendance List".
 
Zu deinem Mockup session.png:

• was bedeutet der Bereich "ID" (mit dem Dropdownmenu und Login vorausgewählt)?
• Im Featurewiki habe ich geschrieben: "In the option: "Generate Attendance list" a new option "Add blank columns" (with the possibility to add a numerical number) » "Blank columns": √ Generate ««xy»» blank columns.". Wir haben uns nun noch einmal durch das ILIAS durchgearbeitet, und wir sind zur Überzeugung gekommen, dass vom User-Interaction-Design her das "GRÜNE PLUS (+)" aus dem Testmodul am sinnvollsten wäre. Der User müsste dann nicht sagen: Add xy blank columns, er könnte einfach das Plus drücken, einen Text (Spaltentitel) eingeben - und die Spalte inkl. Spaltentitel wären vorbereitet. Sinnvoll wäre ausserdem, wenn dies gespeichert würde, dass dann beim nächsten Aufrufen die zusätzlichen Spalten wieder erscheinen.

Drei Nebenbemerkungen:

• Seltsam ist, dass die Druckansicht von a) sich von den Druckansichten b) und c) unterscheidet. Bei b) und c) ist der Verlauf schon etwas strange.
• In der Sitzungsansicht sollte es nicht heissen: "Edit Properties", sondern "Edit Settings".
• Kann es sein, dass die Funktionaltät "Generate attendance list" in der aktuellen Funktionalität mit einem veralteten User-Interface arbeitet?

HJLauener 03 Apr 2012:
 
Wir haben folgende Anregungen:

1. Im Feature-Wiki habe ich angeregt, dass die vom User vorgenommenen Einstellungen gespeichert werden "Sinnvoll wäre ausserdem, wenn dies gespeichert würde, dass dann beim nächsten Aufrufen die zusätzlichen Spalten wieder erscheinen.". [...] Habt ihr das Im JF diskutiert? Falls es klar ist, dass dies eh eine grössere Entwicklung wäre, dann kann man aber gut ohne Speicherung leben.
2. Wir schlagen dann aber vor, nur wenige wichtige Defaultwerte als voreingestellt angekreuzt zu haben:
   1. Teilnehmerliste erstellen: Name und E-Mail
   2. Teilnehmerauswahl: Da würden wir alle drei angekreuzt sehen: Admins, Tutoren und Mitglieder
3. Die User-Interaction (grünes Plus, rotes Minus) beim Hinzufügen bzw. Löschen von zusätzlichen Spalten unterscheidet sich von der User-Interaction beim Testsystem. Sollte man die verschiedenen User-Interactions vereinheitlichen? Uns persönlich gefällt die Darstellung und das Verhalten beim Testing besser.
4. Administratoren, Tutoren, Mitglieder (und weitere Rollen) sollen als separate Listen aufgeführt werden, nicht in einer Liste. (wie bisher in: Sitzung » Teilnehmer verwalten » Drucken). Zusätzlich ist es sinnvoll, einen Rand anzuzeigen. (vgl. auch Attachment - Bild vom bisherigen "Drucken" in der Sitzung).
5. In der Attendance List der Sitzungen fehlt die Unterschrift, die gab es bisher und soll wieder vorkommen (so dass man nur ein Häkchen setzen muss).
6. Ein grundsätzliches Problem sehen wir auch noch beim Wording: Es steht immer wieder "Teilnehmerliste erstellen", obwohl es nicht in jedem Fall eine Teilnehmerliste sein wird (z.B. Name, E-Mail und Note == Notenliste). Mein Vorschlag:
   1. Sowohl auf Kursebene, Gruppenebene und in der Sitzung sollte im entsprechenden Reiter der Button überall gleich wie folgt heissen: "Liste erstellen". In der Gruppe heisst der Button noch  -grp_print_list-, auch dieser Button sollte heissen: "Liste erstellen".
   2. Dann sollte die Überschrift in der Auswahlmasken nicht mehr "Teilnehmerliste erstellen" heissen, sondern überall nur noch "Liste erstellen", und statt dem Button "Teilnehmerliste drucken" heisst der Button "Liste drucken"
   3. Zu klären wäre dann noch die Namensgebung und Darstellung bei den Screens nach dem Button "Liste drucken". Hier sollten die Titel und Darstellung so gewählt werden, dass es sowohl für Teilnehmerlisten, Notenlisten, usw. gültig ist. Seht ihr da eine Lösung?

JF 16 Apr 2012: We discussed the feedback from HJ Lauener (April 03):

• Ad 1: We support the idea to save the settings (per user per course).
• Ad 2: We keep the defaults as they are currently implmented.
• Ad 3: We agree.
• Ad 4: We disagree. We want the possibility to have one list with all users of the course. If three separate lists are needed, they can be printed subsequently.
• Ad 5: ok.
• Ad 6: 1+2 ok. 3: What about a "list title" field with a default "List of Participants".