Übungsaufgaben zu Webtechnologien

Kopiere den Text in ein KI-Sprachmodell Deiner Wahl und passe Kompetenzstufe, Anzahl, Bearbeitungszeit und Szenario bei Bedarf an. Wie die Aufgaben aufgebaut sind, beschreibt der Artikel Wie sind die Aufgaben aufgebaut?. Prüfe die Ergebnisse mit dem Lehrartikel: KI-Sprachmodelle machen Fehler.

Erstelle neue Übungsaufgaben zum Thema „Webtechnologien“.

Bauplan: Halte Dich an Aufbau, Kompetenzstufen, Operatoren,
Anforderungsbereiche, Punkte und Zeitschätzung, die im Artikel
https://oer-informatik.de/aufgaben-aufbau beschrieben sind.

Fachliche Grundlage:
- https://oer-informatik.de/webtechnologien
- https://oer-informatik.de/usability-barrierefreiheit
- https://oer-informatik.de/wiki-cms
- https://oer-informatik.de/nutzwertanalyse-make-or-buy
- Stilbeispiel: https://oer-informatik.de/webtechnologien-uebungsaufgaben

Die Aufgaben sollen Inhalte zu diesen Schlagwörtern abdecken:
- HTML
- CSS
- dynamische Website
- Web-App
- native App
- Progressive Web App
- Frontend
- Backend
- Zeichenkodierung

Kompetenzstufe: Profilkompetenz (alternativ: Basiskompetenz, Kernkompetenz, Expertise)
Anzahl: 1 Aufgabe mit Teilaufgaben
Bearbeitungszeit in Minuten ca.: <5 bis 30 min>
Szenario: eines der Szenarien aus dem Bauplan

Vorgehen:
1. Lies zuerst die verlinkten Artikel. Kannst Du keine Webseiten
   abrufen, sag mir das, statt zu raten.
2. Steht bei einer Angabe noch ein Platzhalter in <…>, frag mich
   zuerst danach. Richte Punkte und Zahl der Teilaufgaben nach der
   Bearbeitungszeit (ca. 0,9 min je Punkt).
3. Gib je Aufgabe Titel mit Kompetenzstufe, Ausgangssituation und
   Teilaufgaben mit Operator und Punktzahl aus, dazu die geschätzte
   Bearbeitungszeit.
4. Gib die Beispiellösungen mit Punkteverteilung erst aus, wenn ich
   danach frage.

Die Aussage verwechselt Bewegung und Gestaltung mit Dynamik (1 Punkt): Animationen und Farbwechsel legt das Stylesheet fest, der Inhalt bleibt für alle gleich. Eine statische Website besteht aus fertigen Dateien, die der Server unverändert ausliefert; eine neue Session erscheint erst, wenn jemand die Datei ändert und hochlädt (1 Punkt). Bei einer dynamischen Website erzeugt ein Programm auf dem Server die Seite erst beim Aufruf, z. B. aus der Datenbank der eingereichten Sessions (2 Punkte). Nur so zeigt der Sessionplan ohne Handarbeit den aktuellen Stand.

• eine serverseitige Laufzeitumgebung für die Sprache, in der die Seite programmiert ist, z. B. ein PHP-Interpreter, Python mit einem Web-Framework oder Node.js (1 Punkt),
• eine Datenbank (z. B. MariaDB) oder eine andere Datenquelle für Sessions, Räume und Zeiten (1 Punkt).

HTML und CSS allein reichen nicht, weil der Browser sie nur darstellt.

1 – H, 2 – C, 3 – J, 4 – C, 5 – H, 6 – J (je richtiger Zuordnung 0,5 Punkte).

Je Aussage 1 Punkt:

1. trifft nicht zu: Eine Webanwendung läuft im Browser. Updates werden nur auf dem Server eingespielt und gelten sofort an beiden Terminals.
2. trifft zu: Ein lokal installiertes Programm kann Daten auf dem PC speichern und ohne Netz darauf zugreifen.
3. trifft nicht zu: Eine native App ist an das Betriebssystem gebunden, für das sie entwickelt wurde. Für Windows müsste sie neu oder mit einem plattformübergreifenden Framework entwickelt werden.

Je Zeile 2 Punkte:

• Zeile 1: Die Dokumenttyp-Angabe teilt dem Browser mit, dass das Dokument dem HTML5-Standard entspricht. Er stellt die Seite dann standardkonform dar (ohne Kompatibilitätsmodus).

• Zeile 4: Legt die Zeichenkodierung UTF-8 fest, damit Umlaute wie in „Gütersloh“ und Sonderzeichen richtig angezeigt werden.

• Zeile 5: Der Browser lädt die Seite alle 60 Sekunden automatisch neu. So zeigen die Monitore ohne Bedienung immer die aktuellen Fahrten.

• Zeile 7: Bindet die externe CSS-Datei flurmonitor.css ein, die die Darstellung (Schriftgröße, Farben, Layout) der Seite festlegt.

Aufgabe (1 Punkt): flurmonitor.css ist ein Stylesheet. Es legt die Darstellung fest (Schriftgröße, Farben, Rahmen, Layout), getrennt vom Inhalt im HTML. Fehlt es, nutzt der Browser seine Standarddarstellung.

Ursachen (je 2 Punkte), z. B.:

• Der Player erhält beim Abruf von flurmonitor.css einen Fehler, z. B. weil die Datei auf dem Server umbenannt wurde oder der Abruf im WLAN abbricht; das HTML kommt an, das Stylesheet nicht.
• Auf diesem Player ist eine andere Adresse eingetragen (z. B. eine lokal gespeicherte Kopie der Seite); der relative Pfad flurmonitor.css zeigt dann ins Leere.
• Ein Web-Filter der Schule oder eine Browsererweiterung blockiert die CSS-Datei.

• Responsive Design (1 Punkt): Eine Seite passt ihr Layout an die Bildschirmbreite an, statt für jedes Gerät eine eigene Fassung zu haben, z. B. wird die Tabelle auf schmalen Bildschirmen zu untereinanderstehenden Karten.
• Media Query (1 Punkt): CSS-Regeln, die nur unter einer Bedingung gelten, z. B. @media (max-width: 600px) { … } für schmale Bildschirme.
• Zeile (1 Punkt): <meta name="viewport" content="width=device-width, initial-scale=1">
• Begründung (1 Punkt): Ohne diese Angabe stellt der Smartphone-Browser die Seite wie auf einem breiten Bildschirm dar und verkleinert sie; die Media Queries für schmale Bildschirme greifen dann nicht.

• Entstehung (2 Punkte): Die Datei ist in UTF-8 gespeichert. Dort belegt „ü“ zwei Byte (hexadezimal C3 BC), Buchstaben aus dem ASCII-Bereich je ein Byte. Windows-1252 ordnet jedem Byte ein eigenes Zeichen zu: C3 wird als „Ó, BC als „¼“ angezeigt.
• Speicherbedarf (1 Punkt): 8 ASCII-Zeichen · 1 Byte + 1 · 2 Byte = 10 Byte.
• Abhilfe (1 Punkt): Zeile 4 <meta charset="UTF-8"> wieder einfügen oder den Webserver den Header Content-Type: text/html; charset=utf-8 senden lassen.

Je sinnvollem Kriterium 0,5 Punkte, je zutreffender Bewertung 0,5 Punkte, z. B.:

Auch andere Kriterien sind zu werten, z. B. Erreichbarkeit ohne Installation, Abhängigkeit von Store-Regeln, Zugriff auf Gerätefunktionen, Datenschutz, Offline-Nutzung.

PWA (2 Punkte): Eine Web-App, die sich zusätzlich wie eine App verhält: Über eine Manifest-Datei lässt sie sich mit Symbol auf dem Startbildschirm ablegen und im eigenen Fenster ohne Browserleiste starten; ein Service Worker speichert Daten für den Offline-Betrieb und empfängt Push-Nachrichten. Sie bleibt eine Anwendung mit einer Codebasis ohne Store.

Wünsche (3 Punkte):

• Startbildschirm: erfüllt; die Nutzenden legen die PWA über „Zum Home-Bildschirm“ ab.

• Erinnerung: möglich über Web-Push-Benachrichtigungen. Die Nutzenden müssen der Benachrichtigung zustimmen. Auf iPhones funktionieren Push-Nachrichten erst ab iOS 16.4 und nur, wenn die PWA zum Home-Bildschirm hinzugefügt wurde. Das muss in der Anleitung stehen; für ältere Geräte bleibt z. B. eine Erinnerung per E-Mail.

Fazit: Eine PWA erfüllt die Wünsche weitgehend, ohne zwei native Apps entwickeln zu müssen.

Je sinnvollem Prüfschritt 1 Punkt, z. B.:

• Service Worker (Frontend): In den Entwicklerwerkzeugen des Browsers prüfen, ob der Service Worker registriert und aktiv ist; ohne ihn kommt keine Push-Nachricht an.
• Abonnement übertragen (Frontend → Backend): Im Netzwerk-Tab prüfen, ob das Push-Abonnement nach der Zustimmung tatsächlich an den Server gesendet wird und welche Antwort zurückkommt.
• Abonnement gespeichert (Backend): In der Datenbank nachsehen, ob zu den Testpersonen Abonnements gespeichert sind.
• Zeitgesteuerter Dienst (Backend): Im Log prüfen, ob der Dienst läuft und die Testfahrten findet (z. B. Fehler durch Zeitzone UTC statt Ortszeit).
• Versand (Backend): Antwort des Push-Dienstes auswerten; ein Fehlercode zeigt z. B. ein abgelaufenes Abonnement oder einen falschen Schlüssel.
• Direkttest: eine Testnachricht von Hand an ein gespeichertes Abonnement senden; kommt sie an, liegt der Fehler in der Zeitsteuerung, nicht im Frontend.

Je Anforderung 1 Punkt, z. B.: Formularfelder mit zugeordneten Beschriftungen (label), vollständige Bedienung per Tastatur bzw. Bildschirmgesten, Alternativtexte für Symbole und Grafiken, ausreichende Kontraste und skalierbare Schrift, sinnvolle Überschriftenstruktur, Statusmeldungen, die der Screenreader vorliest.

JavaScript läuft auf dem Gerät der Nutzenden und kann abgeschaltet, verändert oder umgangen werden, z. B. indem Daten direkt an die Schnittstelle des Servers geschickt werden. Nur die Prüfung im Backend stellt sicher, dass ungültige oder manipulierte Daten (z. B. eingeschleuste Befehle) nicht gespeichert werden (2 Punkte).

Z. B.: „Wir empfehlen, die bestehende Web-App zu einer PWA zu erweitern. Damit erfüllen wir beide Wünsche der SV, behalten aber eine einzige Codebasis und zentrale Updates. Zwei native Apps würden die Kosten etwa verdoppeln, ohne für RatzFahrt einen wesentlichen Mehrwert zu bringen. Für iPhones mit älterem System bieten wir die Erinnerung zusätzlich per E-Mail an.“

Bewertung: klare Empfehlung 1 Punkt, Begründung mit mindestens zwei Kriterien aus der Tabelle 2 Punkte. Eine begründete andere Empfehlung ist ebenfalls zu werten.

Probleme (je beschriebenem Problem 2 Punkte, zwei davon):

• Ohne Pflichtangaben online: Zwischen Schritt 2 und 3 ist ein geschäftlicher Auftritt ohne Impressum (§ 5 DDG) und ohne Datenschutzinformationen (Art. 13 DSGVO) öffentlich, obwohl er schon beworben wird. Das kann abgemahnt werden.
• Freischalten vor dem DNS-Eintrag: Solange die Subdomain nicht auf den Webserver zeigt (Schritt 5), ist die beworbene Adresse gar nicht erreichbar; die Kundschaft landet auf einer Fehlerseite.
• Zertifikat vor dem DNS-Eintrag: Automatisch ausgestellte Zertifikate (z. B. über ACME) setzen voraus, dass die Subdomain schon auf den Server zeigt. Bis dahin erscheint beim Aufruf eine Zertifikatswarnung, und Eingaben im Kontaktformular würden nicht verschlüsselt übertragen.

Reihenfolge (1 Punkt), z. B.: 1 → 3 → 5 → 4 → 2. Inhalte und Pflichtangaben sind fertig, bevor die Adresse erreichbar und abgesichert ist; beworben wird erst zum Schluss.

Eigenschaften (je 1 Punkt), z. B.: Inhalte werden über eine Redaktionsoberfläche ohne HTML-Kenntnisse gepflegt; Trennung von Inhalt und Gestaltung durch Vorlagen (Themes); Rechteverwaltung für Redakteur*innen; Seiten werden dynamisch beim Aufruf aus der Datenbank erzeugt; Erweiterungen (Plugins) z. B. für Formulare.

Begründung (3 Punkte), z. B.: Ein CMS ist sinnvoll, weil Bastian Ludwig Inhalte, die sich regelmäßig ändern (saisonale Öffnungszeiten, Preise, Neuigkeiten), selbst und ohne Programmierkenntnisse aktualisieren kann; die Gestaltung bleibt durch die Vorlage einheitlich. Dafür müssen Updates des CMS regelmäßig eingespielt werden. Auch die Gegenposition ist mit Begründung zu werten (z. B. wenige, kaum veränderliche Seiten → statische Seite schneller und sicherer).

Je gefundenem und korrigiertem Fehler 1 Punkt (sechs der sieben genügen):

Möglichkeiten (je 1 Punkt, zwei davon):

• extern: in einer eigenen CSS-Datei, die jede Seite mit <link rel="stylesheet" href="werkstatt.css"> einbindet,
• intern: im Kopf eines Dokuments innerhalb eines <style>-Elements,
• inline: direkt am Element im Attribut style, z. B. <p style="color: red">.

Begründung (2 Punkte): Für den gesamten Auftritt sollte eine externe, zentrale CSS-Datei genutzt werden. Alle Seiten nutzen dieselben Regeln (einheitliches Corporate Design), Änderungen erfolgen an einer Stelle, und der Browser lädt die Datei nur einmal.