Beiträge

Dein Argument "exakt wie vorgegeben" assoziiert auch die Beachtung der Gross- und Kleinschreibung ist nachvollziehbar. Es ist uns wichtig, dass Funktionen möglichst immer den Erwartungen entsprechen. Wir wollen wie gesagt nicht weitere Optionen zur Auswahl anbieten (mit / ohne case sense). Ich habe es jetzt grundsätzlich auf case sense gestellt und hoffe es gibt nicht so viele Fälle, wo dadurch jetzt ein Nachteil entsteht. Grundsätzlich muss man bei solchen Eingabeüberprüfungen immer gut zwischen Präzision und Frustration der Lernenden abwägen. Es werden zum Beispiel eine ganze Reihe von Bereinigungen vorgenommen - so werden mehrfachen Leerzeichen entfernt, diverse Anführungszeichen und Hochkommas alle gleich behandelt usw.

Viele Grüsse,
Michael

Lieber Stephan,

technisch gesehen wäre das kein Problem. Wir versuchen natürlich die Optionen und Varianten möglichst klein zu halten und bereits die Benennung der Varianten "mit Gross/Kleinschreibung" und ohne ist umständlich. Wir gehen davon aus, dass es nur selten den Bedarf geben wird, das die Schreibweise wichtig ist. Für kleine Sprachtests könntest du vielleicht auch eine LearningApp erstellen und einbinden? Dort hättest du solche Möglichkeiten (z.B. https://learningapps.org/create?new=74 ).

Viele Grüsse,
Michael

Merci vielmals Stephan, ich konnte das Problem identifizieren. Wir haben für Bildannotationen in der Datenbank maximal 64kb vorgesehen gehabt. Diese wurden in deinem Beispiel knapp überschritten und damit die neuen Daten nicht mehr gespeichert. Die Freihandzeichnungen nehmen durch die vielen Bildpunkte irgendwann doch etwas mehr Speicher ein. Wir haben die Grenze nun erhöht, womit das Problem nicht mehr entstehen kann.

Viele Grüsse,
Michael

Vielen Dank für die Meldung. Nach ersten Tests konnte ich das Problem leider nicht nachstellen. Ich habe das mit alfred ausprobiert und konnte problemlos ein weiteres Textfeld einfügen und es wieder löschen - es wurde jeweils gespeichert und die Frage gestellt, ob die Überarbeitung erneut abgegeben werden soll.
Könntest du mit einem Demo-Schüler irgendwie einen Ablauf rekonstruieren, wo der Fehler erneut auftritt? Sobald wir das Problem nachstellen können, sollten wir es auch beheben können.

Viele Grüsse,
Michael

Vielen Dank für eure Hinweise. Wir haben das Speicher-Verhalten auf Grund eurer Rückmeldungen angepasst. Es wird nun nur noch einmal am Ende der Bearbeitung auf den Server gespeichert. Das ist vermutlich für alle die bessere Lösung, zudem kann der Schüler dann nicht bereits teilkorrigierte Bearbeitungen sehen, wenn die Lehrperson gerade noch dran ist. Wir hatten etwas Sorge um möglichen Datenverlust, wenn nicht unmittelbar gespeichert wird - diese Sorge ist aber hoffentlich unbegründet.

Vielen Dank Stephan. Das ist ein schwieriges Problem. Wir haben den Aufgaben "Namen" über diese Kacheln bewusst begrenzt in der Anzeige, jedoch nicht auf n-Zeichen bei der Eingabe begrenzt. Es ist in verschiedenen Ansichten ungünstig, wenn die Namen zu lang werden. Durch den begrenzten Platz auf der Kachel gibt es eine gewisse Motivation für die Lehrperson einen möglichst kurzen Titel zu wählen. Zum Beispiel durch Abkürzungen usw. Es ist aus unseren Experimenten nicht von Vorteil, wenn die Kacheln mehr Text enthalten, da Schülerinnen und Schüler diese Texte ja auch lesen / erfassen müssen - damit würde man den Anspruch "auf einen Blick" eine Übersicht zu bieten entgegenwirken.
Eventuell lassen sich sehr lange Aufgabennamen auch über zusätzliche Themen "auslagern" - also ein Thema mehr hinzufügen mit Namen und Zielen und danach wiederum einfachere kürzere Aufgabentitel bezogen auf das Thema. Dadurch werden Aufgaben eventuell auch für die SuS strukturierter und thematisch gruppierter.

Wir haben dennoch ein klein wenig mehr Pixel pro Kachel für die Textbreite zugelassen, damit ggf. längere Wörter nicht so unschön umbrechen müssen. Dennoch bleibt das auch in Zukunft eine Herausforderung bei der Benennung von Aufgaben.

Viele Grüsse,
Michael

Vielen Dank für den Screenshot. Wir haben den Text an dieser Stelle etwas angepasst. Es erscheint nun:
"Dieser Code ist nicht mehr gültig. Verwende alternativ deinen Benutzernamen/Passwort zur Anmeldung, oder frage deine Lehrperson nach einem neuen Code. Hinweis: Solltest du dein Passwort geändert haben, wird auch der Login-Code ungültig."

In der Regel entsteht dieses Problem, wenn die SuS ihr Passwort ändern (auch dort steht ein Hinweis, dass der Login-Code dann ungültig wird).

Hattet ihr den Fall, wo dieser Text kam, aber der Code noch gültig war? Also später dann doch funktioniert hat? Das wäre eigentlich nur möglich, wenn beim Scannen des Codes ein falscher Inhalt erkannt worden wäre und damit ein ungültiger Code gelesen worden wäre - ich würde das nicht grundsätzlich ausschliessen wollen, aber eigentlich sollten die QR-Codes so aufgebaut sein, dass dies nicht passieren kann.

Vielen Dank für die Anregung. Wir haben eine sehr ähnliche Situation in Workshops zu LearningView und können das Problem somit sehr gut nachvollziehen. Wir haben auch bereits überlegt, wie wir das lösen.

Wir haben die Architektur von LV so aufgebaut, dass ein Konto niemals gleichzeitig Schüler und Lehrer sein kann - das wäre eine grosse Anpassung, um dies zu ermöglichen, da viele Menüs in Abhängigkeit von Schüler oder Lehrer dargestellt werden. Wir empfehlen deshalb für solche Veranstaltungen, dass du einen Kurs mit Schülerkonten anlegst und diese Logins austeilst (als QR-Codes oder User/Pass). Die teilnehmenden Lehrpersonen die bereits ein LV Konto haben wählen nun oben rechts "Benutzer wechseln", um sich gleichzeitig mit zwei Konten anzumelden. Sie können dann über "Benutzer wechseln" sehr schnell zwischen ihrem normalen und dem Kurs-Schüler wechseln. Wird das Schüler-Konto nicht mehr benötigt, können sie es einfach mit einem X aus der Liste angemeldeter Konten entfernen.
Du kannst die Schülerkonten auch wie den Kurs benennen: LVKursSommer2020S1, LVKursSommer2020S2 ... damit auch die Lehrpersonen sofort wissen, was für ein Konto das gewesen ist. So können sie auch jederzeit noch einmal in Unterlagen oder Aufgaben hineinschauen, die du für sie vorbereitet hast.
Optional kann man auch schauen, ob sich die Teilnehmenden nur mit ihrem Smartphone als Schüler anmelden und am PC/Tablet mit ihrem normalen Lehrerkonto.

Viele Grüsse,
Michael

Danke Stephan für deine Meldung. Wir haben eine kleine Anpassung vorgenommen, welche die aktuelle Zoomeinstellung zur Sicherheit erneut anwendet. Reproduzieren konnten wir das Problem aber nein - ich hoffe es ist auch bei dir gelöst.

Viele Grüsse,
Michael

Vielen Dank - vielleicht könnt ihr einen Screenshot davon machen, wenn ihr den Fehler bekommt. Das scannen vom QR-Code erfolgt ausschlieslich lokal im Client (Browser / App) womit es kein Kapazitätsproblem bei vielen gleichzeitigen Anmeldungen sein dürfte.

Lieber Stephan,

vielen Dank für die Idee mit einem Kurs-Bildchen. Diese haben wir aufgenommen und umgesetzt.

Kannst du bezüglich der Fehlermeldung erklären wo (mobile App, Mac/Win App oder Browser) das passiert und wie? Eigentlich sollte gar keine Meldung erscheinen, wenn man keinen Code einscannt - hast du einen Tipp, wie ich vorgehen kann, um den Fehler zu reproduzieren? Wir können dann ggf. eine aussagekräftigere Fehlermeldung hinzufügen.

Viele Grüsse,
Michael

Lieber Torsten,

grundsätzlich sind die Browser / App Versionen immer identisch (bei jedem App-Start wird die aktuelle Version vom Server geladen). Du könntest einmal probieren den Speicher der App zu leeren, dann musst du dich neu anmelden mit deinen Logindaten. Dazu oben im Menü "Edit" (unter Windows erst die "Alt" Taste einmal drücken, um das Menü anzuzeigen) gibt es den Punkt "Clear App Data". Wir haben vor einiger Zeit nochmal eine neue Mac-App Version bereitgestellt, die eine aktuellere Version des integrierten Browsers verwendet. Du kannst gern die App nochmals von learningview.org herunterladen und über die bestehende drüber kopieren - einfach, um dies als Fehlerquelle auszuschliessen.

Sollte das alles trotzdem nicht helfen, können wir ggf. mit deinem Konto noch einmal konkret schauen, ob Daten vorhanden sind, die Probleme bei dir verursachen.

Viele Grüsse,
Michael

Da wir die Frage bereits mehrfach gestellt bekommen haben: Wie kann man Schüler an die nächste Lehrperson weitergeben? Dafür gibt es in LearningView verschiedene Varianten. Hier die wichtigsten drei:

a) Ihr gebt den aktuellen Kurs mit allen Schülern und ausgeteilten Materialien darin und an die nächste Lehrperson weiter. Dazu fügt ihr unter "Kurs verwalten" eine weitere Lehrperson hinzu und setzt diese anschliessend auf "Hauptlehrperson" danach könnt ihr den Kurs bei euch löschen, da er dann der neuen Lehrerin gehört und ihr nicht mehr darauf zugreifen müsst. Dabei würde die neue Lehrperson ggf. die alten Inhalte aus dem Kurs entfernen und neu starten.

b) Ihr möchtet die alten Kurse für euch bzw. für die SuS behalten und die Inhalte so belassen wie sie sind. Dann ladet ihr die neue Lehrperson kurzzeitig in euren Kurs ein. Die neue Lehrperson erstellt einen eigenen Kurs und klickt bei der Schülerliste auf "aus anderem Kurs hinzufügen" ganz unten. Dann kann sie alle Schüler von euch in den neuen Kurs übertragen und startet mit ihrem Kurs neu. Sobald die Schüler übertragen wurden, könnt ihr die Lehrperson wieder aus dem alten Kurs entfernen.

c) Die neue Lehrperson erstellt einen leeren Kurs und gibt den Schülern den "Kurs-Code". Die SuS klicken oben links auf ihre Kurse und geben den Kurscode dort ein. Nun sind sie im neuen Kurs angemeldet und haben noch euren alten Kurs und können hin und her wechseln. Bei dieser Variante sieht die neue Lehrperson nicht, was ihr in euren Kursen einmal gemacht hat - sie kann das dafür aber auch ganz ohne eure Mithilfe tun.

Ihr könnt als Lehrpersonen eure abgeschlossenen Kurse "archivieren". Damit verschwinden sie bei euch in der Liste und wandern in eine Box (aus der man sie auch wieder zurückholen kann). Bei den SuS gibt es die Kurse dann unter "ehemalige Kurse" weiterhin zur Auswahl und sie können dort noch einmal hineinschauen und die Aufgaben und ihre Ergebnisse von damals nachschlagen.

Das von dir beschriebene Problem mit dem Stift zeichnen und verschieben haben wir extra versucht zu vermeiden, indem bei Touch-Geräten das Scrolling abgeschalten wird, sobald man den Stift einsetzt. Vielleicht hatte der Safari noch eine ältere Version im Cache oder so. Eigentlich sollte das schon so funktionieren.

Wir testen übrigens grundsätzlich nicht auf mobilen Browsern, da wir dort in jedem Fall die jeweilige App empfehlen zu nutzen. Die mobilen Browser sind meist noch etwas eingeschränkter was bestimmte Funktionen etwa zum Aufnehmen von Medien betrifft. Über das "ich bin Lehrperson" wurde man aber auch auf dem mobilen Gerät in den Browser geschickt zur Anmeldung was ungünstig ist. Wir haben das überarbeitet und auch die Lehrperson verbleibt nun in der App nach der Registrierung.

Viele Grüsse,
Michael

Es gibt jetzt im Bildeditor eine Zoom In/Out Funktion. Das Herunterladen dieser annotierten Bilder ist auf mobilen Geräten leider gar nicht einfach, da das ganze Sicherheits-/Dateikonzept von iOS/Android solche temporär generierten Dateien nicht mag. Das Bild wird deshalb jetzt erst als Datei auf dem Gerät gespeichert und dann mit dem Systemwerkzeug geöffnet. Eine bessere Lösung haben wir dafür im Moment leider nicht.

Könntest du das mit dem "nicht starr" noch einmal genauer beschreiben? Wir verwenden spezielle Funktionen für TouchGeräte, die beim Zeichnen das Scrollen im Bildeditor kurzzeitig ausschalten - da man sonst nicht zeichnen könnte. Ich könnte mir vorstellen, dass es irgendwie damit zusammenhängt. Du schreibst "in der App schon", meinst du damit, das du den Browser im iPad verwendet hast und es dort nicht richtig geht?

Viele Grüsse,
Michael