Was ist Astro?

Astro ist ein Framework für contentfokussierte Webprojekte, wie z.B. Blogs, E-Commerce- oder Marketing-Websites. Es setzt auf eine komponentenbasierte Web-Architektur, was bedeutet, dass das meiste als statische HTML-Seite gerendert wird und man kleine Islands mit JavaScript für Interaktivität hinzufügen kann. Astro verfolgt einen Server-first-Ansatz und kommt standardmäßig ohne JavaScript am Client aus, liefert aber bei Bedarf Unterstützung für Frameworks wie React, Vue, Svelte, Solid etc. Darüber hinaus bietet Astro Content Collections, mit denen sich Markdown-Inhalte strukturiert organisieren und mithilfe von TypeScript typsicher validieren lassen.

Projekt erstellen

npm create astro@latest (basic, helpful starter Projekt auswählen)

In VS Code gibt es eine Extension namens Astro, die hilfreich ist.

Ordnerstruktur (als Beispiel):

• assets
• components
• content (für Content Collections)
• layouts
• pages (file-based Routing)
• styles

Dateiaufbau und Astro-Komponenten

• Dateiendung: .astro
• Codeausführung:
  • serverseitig: --- --- (Frontmatter)
  • clientseitig: <script></script>
• JSX-ähnliche Ausdrücke
  • {variable} in HTML
  • Aber: Funktionen und Objekte können so nicht übergeben werden (wie z.B. bei React), stattdessen mit Script-Tag umsetzbar

Beispielsweise MyAstroComp.astro:

---
// Script mit JS, das am Server ausgeführt wird
const text = "Hello World";
---
<!-- Hier Template der Komponente mit HTML, CSS und JS -->
<div>{text}</div>

Was nicht funktioniert:

---
function handleClick() {
  console.log("clicked");
}
---
<button onclick="handleClick()">{text}</button>

Komponente in index.astro verwenden:

---
import MyAstroComp from "../components/MyAstroComp.astro";
---
<MyAstroComp />

• <slot /> für Children (wie {children} in React)
• Mit Astro.props auf Properties zugreifen

---
interface Props {
  name: string;
}
const { name } = Astro.props;
---
<h2>Hello {name}!</h2>

Unterschiede Astro vs. JSX

React hinzufügen

Interaktivität in Astro Komponenten einzubauen ist mühsam. Um mit einem Buttonklick umgehen zu können, müsste man ein <script> Tag hinzufügen. Stattdessen kann man aber auch ein beliebiges anderes Framework zum Projekt hinzufügen und so auch beispielsweise React-Komponenten bauen und nutzen.

Um React als Beispiel hinzuzufügen: npx astro add react

Achtung: Komponente wird by default nur am Server gerendert!

Für Interaktivität braucht es Hydration und eine Client Directive.

Client Directives

Die client:* Directive gibt an, wann das JavaScript an den Browser geschickt werden soll. Die Komponente wird zuerst am Server gerendert (außer bei client:only), dann wird das JS gesendet und somit wird die Komponte hydrated und interaktiv.

• client: load
  • JS: sofort beim Laden der Seite
• client: idle
  • JS: nach initialem Ladeprozess und wenn requestIdleCallback-Event ausgelöst wird
• client: visible / client:visible={{rootMargin}}
  • JS: sobald Komponente bzw. angegebener Margin sichtbar ist
• client:media={string}
  • JS: wenn CSS media query erfüllt wird (z.B. nur für bestimmte Bildschirmgrößen)
• client:only={string}
  • Überspringt SSR und rendert Komponente nur am Client. Framework muss als String übergeben werden.

Die Client Directive wird dort hinzufügt, wo die Komponente verwendet wird.

---
import MyReactButton from "../components/MyReactButton";
---
<MyReactButton client:load />

Output Type für Build

In der astro.config Datei kann der Output Type festgelegt werden. Dieser bestimmt, wann die Seiten standardmäßig gerendert werden (beim Builden oder on demand). Das gilt für alle Seiten, außer bei denen eine Ausnahme festgelegt ist.

In astro.config.mjs: output: 'static' oder 'server'

• static (default): SSG, Seiten werden vorgerendert (prerendered); Ergebnis: statische Website
• server: SSR, Seiten werden on demand gerendert; Ergebnis: server-rendered Website
• Für einzelne Seite ändern: export const prerender = false
  • wenn in config static: false
  • wenn in config server: true

Wichtig: Wenn eine Seite SSR verwendet, muss ein Server-Adapter (z.B. node) festgelegt werden: npx astro add node

Blog als Praxisbeispiel

Als Beispiel wird ein kleiner, einfacher Blog programmiert. Dieser beinhaltet zwei Seiten, wobei auf einer alle Einträge mit Bild, Datum und Titel aufgelistet werden (Übersichtsseite) und auf der anderen die Informationen des jeweiligen Eintrags stehen (Detailseite). Die einzelnen Blogbeiträge sollen in Form von Markdown-Dateien erstellt, bearbeitet und verwaltet werden können. Auf das Styling wird bei diesem Beispiel nicht eingegangen.

Content Collection erstellen

Content Collections helfen dabei, Markdown-Dateien zu organisieren. Genau das wird für die Blogbeiträge benötigt. Um eine Collection zu erstellen, muss diese in src/content.config.ts definiert werden.

import { glob } from "astro/loaders";
import { defineCollection, z } from "astro:content";

const blog = defineCollection({
  loader: glob({ base: "./src/content/blog", pattern: "**/*.{md,mdx}" }),
  schema: () =>
    z.object({
      title: z.string(),
      date: z.coerce.date(),
      img: z.string(),
    }),
});

export const collections = { blog };

Die Funktion defineCollection() verlangt dabei zwei Parameter, einerseits den Loader und andererseits optional das Schema. Der Loader legt fest, wie und von wo die Inhalte der Collection geladen werden. Astro stellt dabei zwei integrierte Varianten zur Verfügung:

• glob(): erstellt Einträge aus Ordnern mit Dateien
• file(): erstellt Einträge basierend auf einer lokalen Datei (z.B. JSON-File)

Das Schema wird mit zod erstellt. Wird ein Schema definiert, so werden die entsprechenden Markdown-Dateien dahingehend validiert. Außerdem können generierte Types verwendet werden (z.B. type Props = CollectionEntry<"blog">["data"];). Wichtig ist nur, dass der Dev-Server neu gestartet wird, wenn sich Änderungen am Schema ergeben, sodass Astro das mitbekommt.

Ein Blogeintrag soll in diesem Fall immer einen Titel, ein Datum und ein Bild beinhalten, sodass diese Informationen auf der Übersichtsseite angezeigt und auf der Detailseite immer gleich formatiert werden können.

Blogbeiträge hinzufügen

Es können jetzt diverse Blogbeiträge in Form von Markdown-Dateien unter content/blog erstellt werden (Pfad in content.config.ts festgelegt).

Beispiel: first-entry.md

---
title: "First Entry"
date: "2025-10-30"
img: "/favicon.svg"
---
Hello, this is my first entry.

## H2

This is a paragraph.

Im Frontmatter (innerhalb der drei Bindestriche) werden die drei Parameter angegeben, darunter folgt der Inhalt. Als Bild wird der Einfachheit halber das favicon im public-Ordner hergenommen. Der Blogbeitrag kann Überschriften, Absätze, Links, Codeteile, Tabellen und alles, was Markdown zu bieten hat, beinhalten. Wichtig ist nur, dass man das entsprechende Styling dafür definiert (h2, p, code, a etc.).

MDX

Es können nicht nur md-Dateien erstellt werden, sondern auch mdx-Dateien, in denen die eigenen Komponenten (egal ob Astro, React etc.) verwendet werden können. Es muss nur die entsprechende Astro-Integration installiert werden (npx astro add mdx) und mdx in der Definition der Content Collection berücksichtigt werden (wurde bereits getan).

Beispiel: second-entry.mdx

---
title: "Second Entry"
date: "2025-10-31"
img: "/favicon.svg"
---

This is my second entry.

import MyReactButton from "../../components/MyReactButton"

<MyReactButton client:load />

components/MyReactButton.tsx

export default function MyReactButton(){

    function handleClick(){
        console.log("Hello, you clicked me")
    }

    return (
        <button onClick={handleClick}>Click me</button>
    )
}

Seiten erstellen

Astro verwendet file-based Routing. Die Ordner- und Dateistruktur im pages-Ordner bestimmt somit automatisch, unter welchen URLs die Seiten aufgerufen werden können. Im pages-Ordner wird ein Unterordner blog und darin index.astro und [slug].astro angelegt. Der Blog ist somit unter /blog erreichbar. index.astro ist eine statische Route, während [slug].astro eine dynamische Route ist. Der Parameter slug kann dabei durch eine beliebige andere Bezeichnung ersetzt werden. Für mehr Tiefe kann auch ein Rest-Parameter verwendet werden: […path].astro.

Übersichtsseite

Für die index Seite wird zuerst ein Layout erstellt. Ein Layout ist dabei nichts anderes als eine normale Astro-Komponente.

layouts/Layout.astro

---
import "../styles/global.css";
---

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="generator" content={Astro.generator} />
    <title>My Blog</title>
  </head>
  <body>
    <slot />
  </body>
</html>

<style>
  html,
  body {
    margin: 0;
    width: 100%;
    height: 100%;
  }
</style>

Für den Header kann ebenso eine Astro-Komponente erstellt werden (components/Header.tsx).

<header>
  <nav>
    <a href="/blog">My Blog</a>
  </nav>
</header>

Nun kann index.astro befüllt werden:

---
import { getCollection } from "astro:content";
import Header from "../../components/Header.astro";
import Layout from "../../layouts/Layout.astro";

const posts = (await getCollection("blog")).sort((a, b) => {
  return b.data.date.valueOf() - a.data.date.valueOf();
});
---

<Layout>
  <Header />
  <ul>
    {
      posts.map((post) => (
        <li>
          <a href={"/blog/" + post.id}>
            <div>
              <img src={post.data.img} />
            </div>
            <div>{post.data.title}</div>
            <div>{post.data.date.toLocaleDateString()}</div>
          </a>
        </li>
      ))
    }
  </ul>
</Layout>

Mithilfe von getCollection() kann eine Collection, sprich ein Array von Einträgen, geholt werden. In diesem Beispiel werden die Einträge von der Blog-Collection zusätzlich nach dem Datum sortiert.

Detailseite

Für die Detailseite wird ebenso ein Layout erstellt, das den Titel, das Bild und das Datum übergeben bekommt und anzeigt.

layouts/BlogLayout.astro

---
import type { CollectionEntry } from "astro:content";
import Header from "../components/Header.astro";

type Props = CollectionEntry<"blog">["data"];

const { title, date, img} = Astro.props;
---

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="generator" content={Astro.generator} />
    <title>My Blog</title>
  </head>
  <body>
    <Header />
    <main>
      <article>
        <div>
          <img src={img} />
        </div>
        <div>{date.toLocaleDateString()}</div>
        <h1>{title}</h1>
        <div>
          <slot />
        </div>
      </article>
    </main>
  </body>
</html>

<style>
  html,
  body {
    margin: 0;
    width: 100%;
    height: 100%;
  }
</style>

Die Detailseite muss nun den Parameter slug auslesen und die entsprechenden Informationen dem BlogLayout übergeben. Es gibt zwei Varianten, das zu tun, je nachdem ob man SSR oder SSG verwenden möchte.

Variante 1: SSR (on demand Rendering)

---
import { render } from "astro:content";
import { getEntry } from "astro:content";
import BlogLayout from "../../layouts/BlogLayout.astro";

export const prerender = false;
const { slug } = Astro.params;

if (!slug) {
  return Astro.rewrite("/404");
}

const entry = await getEntry("blog", slug);

if (!entry) {
  return Astro.rewrite("/404");
}

const { Content } = await render(entry);
---

<BlogLayout {...entry.data}>
  <Content />
</BlogLayout>

Mithilfe von Astro.params kann der Parameter slug ausgelesen werden. Mit getEntry() wird dann der entsprechende Eintrag geholt. Wenn es keinen passenden Eintrag gibt, wird 404 angezeigt. Um den Inhalt der Zielseite anzuzeigen, ohne die URL zu verändern, wird Astro.rewrite() genutzt.

Variante 2: SSG (statische Seite)

---
import type { GetStaticPaths } from "astro";
import { render } from "astro:content";
import BlogLayout from "../../layouts/BlogLayout.astro";
import { getCollection } from "astro:content";

export const getStaticPaths = (async () => {
  const entries = await getCollection("blog");

  return entries.map((entry) => ({
    params: { slug: entry.id },
    props: entry,
  }));
}) satisfies GetStaticPaths;

const entry = Astro.props;

const { Content } = await render(entry);
---

<BlogLayout {...entry.data}>
  <Content />
</BlogLayout>

Soll eine dynamische Route statisch sein, so muss sie eine Funktion namens getStaticPaths() exportieren, die ein Array an Objekten mit dem property params zurückgibt. So werden alle möglichen Paths vordefiniert. In diesem Beispiel holt man sich also alle Einträge der Blog-Collection in der getStaticPaths()-Funktion und über die Properties (Astro.props) können dann die Informationen des einzelnen Eintrags ausgelesen werden.

Fazit

Mit Astro können schnelle Websites erstellt werden. Wenn man bereits Erfahrung mit HTML, JSX oder React hat, so fällt einem der Einstieg in das Framework besonders leicht, da man viele vertraute Konzepte wiederfindet. Nur bei komplexeren Websites stößt Astro irgendwann auf seine Grenzen.

Quelle

https://docs.astro.build/en

The post Workshop | Astro appeared first on Mobile USTP MKL.

Das Hauptziel des Forschungsprojekts besteht darin, mittels einer App klimafreundliches Verhalten zu fördern und passende regionale Aktivitäten (sogenannte Initiativen) zu präsentieren. Die App Erika soll informieren, durch spielerische Elemente motivieren und belohnen. Das Forschungsprojekt erfolgt am Beispiel der Region Waidhofen a/d Ybbs, weshalb auch eine Integration in die vorhandene Waidhofen-App vorgesehen ist.

In der App können Nutzer*innen an Initiativen teilnehmen, Aufgaben erfüllen und Belohnungen erhalten. Zusätzlich können sie Vorschläge für Initiativen machen und die von anderen bewerten.

Zielsetzung

Meine Aufgabe war es, ein funktionsfähiges CMS laut vorhandenem Prototyp umzusetzen. Dazu zählten sowohl die Umsetzung des Frontends als auch Anpassungen und Ergänzungen im bestehenden Backend. Das CMS sollte vor allem diverse Daten von Nutzer*innen, Initiativen etc. anzeigen, ein Login beinhalten und die Möglichkeit bieten, Inhalte für die App erstellen, bearbeiten und löschen zu können. Zudem sollten mit dem CMS PDFs generiert werden können, die für Initiativen und Belohnungen benötigt werden.

Vorgehensweise

Die genauen Funktionen des CMS wurden anfangs definiert und priorisiert, und später leicht angepasst. Zu Priorität 1 zählten vor allem die Authentifizierung, die Anzeige der verschiedenen Daten (Nutzer*innen, Initiativen und Belohnungsmöglichkeiten) und die Generierung von PDFs. Im nächsten Schritt lag der Fokus auf den Vorschlägen für Initiativen, die angezeigt und freigegeben werden können. Zum Schluss wurden die Funktionalitäten ergänzt, Initiativen anlegen, bearbeiten und löschen zu können.

Verwendete Technologien:

• Frontend: Low-Code-Framework Luisa, Vue.js und Axios
• Libraries für die PDF-Generierung (inkl. QR-Code): pdf-lib, qrcode und file-saver
• Prototyp: QuantUX
• Backend: Express Framework, Effect Library und Swagger

Während der Mitarbeit beim Forschungsprojekt teilte ich mir die Zeit selbst ein, machte mit dem Projektleiter Dipl.-Ing. Gernot Rottermanner vor allem separate Meetings aus und nahm vereinzelt am wöchentlichen Jour Fixe teil. Für das Frontend war ich allein zuständig, während ich beim Backend zusammen mit Dipl.-Ing. Ramon Brullo arbeitete, der vor allem die Funktionen für die App selbst und später das Erstellen und Bearbeiten von Initiativen umsetzte. Den Prototypen für das CMS hatte Dipl.-Ing. Gernot Rottermanner bereits entwickelt. Durch die Verwendung des Low-Code-Frameworks Luisa konnte ich das Design sofort übernehmen, mich auf die Funktionalität konzentrieren und musste in QuantUX nur noch an manchen Stellen Anpassungen vornehmen.

Ergebnisse

Hier können alle Initiativen eingesehen, bearbeitet und neue erstellt werden. Für jede Initiative lässt sich ein PDF und ein QR-Code generieren.

Auf dieser Seite kann eine neue Initiative mittels JSON erstellt und die Eingabe formatiert werden. Das Textfeld wird je nachdem, ob eine Initiative erstellt oder bearbeitet wird, mit einer Vorlage oder den richtigen Daten befüllt. Eine bestehende Initiative kann hier ebenso gelöscht werden.

Auf dieser Seite lassen sich alle eingereichten Ideen (Vorschläge für Initiativen) einsehen und freigeben, sowie alle Bewertungen der freigegeben Ideen nachsehen.

Die Benutzer:innen- und Einlösemöglichkeiten-Seite ähneln dem Rest. Auf ersterer werden alle Nutzer*innen inklusive ihrem Erstelldatum, der Anzahl der angemeldeten und teilgenommenen Initiativen und ihrem “Spielstatus” angezeigt. Auf zweiterer werden alle Einlösemöglichkeiten, sprich mögliche Belohnungen, aufgelistet. Für jede lässt sich ebenso ein entsprechender QR-Code und ein PDF generieren.

Retrospektive

Durch meine Mitarbeit bei Erika konnte ich meine Programmier-Kenntnisse erweitern und viele neue Technologien kennenlernen. Sowohl die komplette Backend-Struktur als auch das Low-Code-Framework Luisa waren neu für mich. Anfangs war das durchaus herausfordernd, doch schnell bekam ich einen Überblick und konnte alles wie geplant umsetzen. Die Verwendung von Luisa hat die Entwicklung des Frontends erheblich beschleunigt und es mir erlaubt, mich vor allem auf das Backend zu konzentrieren. Bei einfachen Projekten ist das Low-Code-Framework sehr praktisch, bei höheren Anforderungen wie z.B. responsive Tabellen stößt es jedoch an seine Grenzen. Insgesamt war das Projekt abwechslungsreich und ließ sich gut im Rahmen der vorgegebenen 80 Stunden umsetzen.

Link zum Forschungsprojekt: https://research.fhstp.ac.at/projekte/erika

The post TFG | Erika CMS appeared first on Mobile USTP MKL.

Was ist Low-Code?

Wie der Begriff schon verrät, ist das Ziel wenig Code selbst schreiben zu müssen. Nützlich ist das vor allem für Personen mit geringen Programmierkenntnissen. Die Idee ist, dass Fachleute sich um den visuellen Teil der Anwendung kümmern, der dann zur Laufzeit durch Softwarekomponenten interpretiert wird. Es gibt verschiedenste Frameworks, die unterschiedliche Ansätze verfolgen. Wichtig ist jedoch, das richtige Verhältnis zwischen Modellierung und Code zu finden, sodass im Endeffekt die Komplexität verringert und nicht erhöht wird.

Luisa

Luisa verfolgt den Ansatz, dass nur der Frontend-Code generiert wird, sprich HTML und CSS, die Businesslogik hingegen ist Aufgabe des Programmierers bzw. der Programmiererin. Zurzeit werden Figma und Quant-UX als Design-Tools und Vue.js als Framework unterstützt. Luisa ist Open Source und kann kostenfrei genutzt werden.

In seinem Code muss nur die Luisa-Komponente eingebaut werden, die dann den Rest erledigt. Im Development kann man Luisa mit dem Design-Projekt verbinden, sodass Design-Änderungen sofort in der Anwendung sichtbar sind. Für Production kann das Design-File auch heruntergeladen und eingebunden werden. Ändert sich etwas am Design muss das File erneut heruntergeladen werden. Um Logik hinzufügen zu können, werden Data- und Method-Binding benutzt. In Figma benötigt man dazu das Figma-Low-Code Plugin, in Quant-UX steht einem diese Funktion von Haus aus zur Verfügung. Im Code können ebenso Anpassungen beim Design gemacht und benutzerdefinierte Komponenten verwendet werden.

Beispiel

Nachfolgend wird ein kleines Beispiel durchgemacht, um zu sehen, wie Luisa eingebunden und verwendet wird. Die Applikation soll nach Eingabe eines Datums, die restlichen Tage bis dahin ausgeben. Hierbei wird Quant-UX verwendet.

Design erstellen

Zuallererst wird ein neues Projekt in Quant-UX erstellt und ein Screen hinzugefügt. Auf diesem wird nun ein Date Picker, ein Button und ein Text platziert.

Dann sieht es in etwa so aus:

Hinweis: Ich habe die Schriftgröße auf 16 px erhöht.

Projekt Setup

Da in diesem Beispiel ein neues Projekt erstellt wird, ist es am einfachsten das Starterprojekt zu klonen.

git clone https://github.com/KlausSchaefers/luisa-vue3-starter.git

Anschließend nicht vergessen, die node modules zu installieren.

npm install

In Home.vue muss nun der richtige Token zum Design-Projekt eingetragen werden. Diesen bekommt man in Quant-UX indem man auf das Projekt klickt und dann Share auswählt.

data: function () {
    return {
      design: "token...",
      viewModel: {
        date: '',
        result: defaultText
      },
      config: {
      }
    }
  },

Bei Quant-UX wird der Token so eingetragen. Bei Figma müssen sowohl die Figma File ID, welche man aus der URL herauslesen kann, als auch der Access Key, welchen man in den Settings bekommt, eingetragen werden.

Nun heißt es, Projekt starten und testen, ob das Design aus dem Quant-UX Projekt angezeigt wird.

npm run serve

Die Applikation sieht schon mal schön aus. Nun fehlt nur noch die Logik.

Logik hinzufügen

Um Daten auslesen und der Applikation sagen zu können, was sie beim Klick auf den Button tun soll, müssen in Quant-UX Variablen- und Methodennamen hinzugefügt werden. Dazu klickt man beispielsweise auf die Datumsauswahl, wählt auf der rechten Seite “Prototype” und fügt mit “Add Data Binding” eine neue Variable hinzu.

Um eine onClick-Methode hinzuzufügen, wählt man den Button aus und gibt unter “Low Code – Callbacks” den Methodennamen an.

Danach sollte es im Prototype-Modus ungefähr so aussehen:

• Date Picker: date
• Text: result
• Button: calculate

Nun kann wieder in das Vue.js Projekt gewechselt und anfangen werden, die Variablen zu verwenden und die Methode hinzuzufügen.

In Home.vue kann man unter “data” die verwendeten Variablen mit einem Defaultwert auflisten.

data: function () {
    return {
      design: "token...",
      viewModel: {
        date: undefined,
        result: "Select a date to calculate the remaining days"
      },
      config: {
      }
    }
  },

Die calculate Mathode kann man dem “methods” Objekt beifügen. Um zu sehen, ob alles funktioniert, kann man sich hier erstmal das Datum ausgeben lassen. Variablen können über das “viewModel” Objekt verwendet werden.

methods: {
    calculate() {
      console.log(this.viewModel.date)
    }
  }

Startet man das Projekt mit npm run serve bzw. läuft es noch, sollte man nachdem man ein Datum ausgewählt und auf den Button geklickt hat, dieses in der Konsole des Browsers sehen.

Nun kann der eigentliche Code geschrieben werden. Die Rechnung der übrigen Tage lässt sich der Übersicht halber in eine andere Funktion auslagern.

function calcRemaining(date) {
  const diff = new Date(date) - new Date()
  return diff > 0 ? Math.ceil(diff / (1000 * 60 * 60 * 24)) : 0;
}

methods: {
    calculate() {
      if (this.viewModel.date) {
        const days = calcRemaining(this.viewModel.date)
        this.viewModel.result = `${days} days left`
      } else {
        this.viewModel.result = "Select a date to calculate the remaining days"
      }
    },
  }

Gibt es ein Datum, so sollen die übrigen Tage bis dahin angezeigt werden, ansonsten soll den User*innen mitgeteilt werden, dass zuerst ein Datum ausgewählt werden muss.

Weitere nützliche Infos

Möchte man, dass sich der Button im gehoverten Zustand vom normalen unterscheidet, so kann man einfach in Quant-UX den Hover-State bearbeiten. Dafür wählt man den Button aus und ändert im Design-Fenster unten unter “Hover” beispielsweise die Hintergrundfarbe.

Was die Responsiveness betrifft, haben alle Komponenten von Haus aus eine relative Breite. Man kann im Design-Fenster allerdings auch festlegen, dass die Höhe und/oder die Breite fix sein soll (unter “Fixed Size”).

Ebenso kann man angeben, inwiefern das Element an das übergeordnete Element angeheftet werden soll, sodass es beispielsweise immer links, rechts oder mittig platziert wird (unter “Pin”).

Benutzerdefinierte Komponenten kann man in Quant-UX, wenn ein Element ausgewählt ist, unter “Prototype” – “Low Code – Rendering” angeben. Im Code muss dann das main.js File bearbeitet werden. Hat man beispielsweise MyTextComponent in Quant-UX hinterlegt und zum Vue-Projekt hinzugefügt, so würde man die Komponente in main.js so registrieren.

createApp(App)
    .use(router)
    .use(Luisa)
    .component('MyTextComponent', MyTextComponent)
    .mount('#app')

Fazit

Luisa beschleunigt den Entwicklungsprozess erheblich. Man muss keine Zeit mit HTML und CSS vergeuden, sondern kann direkt mit der Implementierung der Logik starten. Dadurch hat man genau eine Basis für das Design und sobald sich etwas am Prototyp ändert, ändert sich das auch im Projekt. Für einfache Anwendungen ist Luisa sehr praktisch. Bei komplexeren Projekten, speziellen Anforderungen oder einem hohen Bedarf an Individualisierung stößt das Framework jedoch an seine Grenzen. Im Bereich des Responsive Designs stößt man ebenfalls rasch an Einschränkungen. Verwendet man beispielsweise eine Tabelle, so ist diese immer gleich hoch und die Höhe der Zeilen variiert je nach Anzahl. An dieser Stelle sei erwähnt, dass ich noch nicht versucht habe, das CSS manuell anzupassen, und eventuell bietet Figma hier mehr Flexibilität. Das müsste noch genauer getestet werden. Die Dokumentation fällt insgesamt recht knapp aus. Es lohnt sich aber dennoch einmal hineinzuschauen und Luisa auszuprobieren.

Quellen

https://luisa.cloud/

https://javascript.plainenglish.io/luisa-the-low-code-ui-framework-5aad9a8bbf50

The post Luisa – Einführung in das Low-Code JS Framework appeared first on Mobile USTP MKL.

Screens und deren Features

Die App beinhaltet eine Authentifizierung, sodass die Funktionen erst nach dem Login bzw. der Registrierung genutzt werden können.

Profil

Hat man sich eingeloggt, kann man in seinem Profil alle seine geplanten Urlaube verwalten. Hier lässt sich einer der aufgelisteten Urlaube auswählen, der dann für alle anderen Tabs bzw. Screens gilt. Man kann einen neuen erstellen, einem beitreten oder einen löschen bzw. verlassen. Im Profil gibt es außerdem die Möglichkeit sich über das Menü wieder abzumelden.

Um einem Urlaub beizutreten, benötigt man den zugehörigen Code. Dem bzw. der Ersteller*in wird nach dem Erstellen des Urlaubs die Möglichkeit geboten, den Code mittels der „Share“-Funktion zu teilen.

Info

Auf dem Info-Screen werden alle Informationen zum aktuellen Urlaub angezeigt. Dazu gehören Titel, Zeitraum, Beschreibung und die Teilnehmer*innen. Hierbei kann man die Informationen auch bearbeiten und den Code nochmals teilen, falls man noch wen hinzufügen möchte.

Packliste

Die Packliste ermöglicht es mehreren Personen, gemeinsam eine Urlaubscheckliste zu erstellen und direkt zuzuweisen, wer was mitnimmt. Dabei gibt es oben den allgemeinen Bereich mit noch nicht zugeordneten Gegenständen und nachfolgend für jedes Mitglied einen eigenen, angefangen mit sich selbst. Es können Einträge hinzugefügt, gelöscht, in den eigenen oder in den allgemeinen Bereich verschoben und als eingepackt markiert werden.

Restliche Screens

Es soll auch noch weitere Screens bzw. Tabs geben, die beispielsweise einen Kostenrechner oder gemeinsame Notizen beinhalten. Im Zuge der 82 h wurden diese aber nicht umgesetzt.

Technologien

Backend

• NestJS
• Prisma
• Zod und zod-prisma-type für Type Generation
• Swagger
• Docker

Frontend

• React Native mit Expo
• Native Wind (Tailwind für React Native)
• Zustand für State Management
• OpenAPI Generator
• Libraries: react-native-bottom-sheet, react-native-elements, react-native-bouncy-checkbox etc.

Challenges und Learnings

Backend

Im Backend interessierte mich die Verwendung von Prisma. Dabei hat man ein zentrales Schema-File und kann sich die Types generieren lassen. Zusätzlich zu den generierten Types brauchte ich jedoch eigene DTOs, die ich mittels zod Schemas und Helper Methods umsetze. Ich habe auch auf eine ordentliche Swagger Dokumentation geachtet, sodass ich dann im Stande war, OpenAPI Generator für das Frontend zu verwenden. Es war einerseits sehr praktisch sich darum nicht kümmern zu müssen, andererseits wurde es mühsam, wenn man beispielsweise den Typ eines Objekts brauchte, welches nur innerhalb eines Arrays vorkommt. Diese stehen einem zwar auch zur Verfügung, doch die Namen werden immer länger und unleserlicher. Ich habe dann in solchen Fällen begonnen, eigene Types zu erstellen, die dann auf die generierten verweisen.

Es war anfangs eine Challenge herauszufinden, wie man bei zod Schemas Beispielwerte für Swagger mitgibt. Die Library @anatine/zod-openapi bietet hierbei mittels Methoden wie extendApi die Lösung.

Nachdem wir dieses Semester einen Docker-Workshop hatten, entschied ich mich dafür Docker auch für dieses Projekt zu verwenden und setzte erstmals alles selbst auf.

Frontend

Im Frontend musste ich mich erstmal zurechtfinden, da ich zwar bereits React verwendet hatte, aber nicht React Native. Anfangs war für mich klar, dass ich auch Native Wind einbaue, da ich sehr oft Tailwind CSS nutze. Bei Komponenten aus Libraries ist jedoch das Problem, dass viele (noch) kein Native Wind unterstützen, und somit musste ich oftmals auf gutes altes CSS zurückgreifen. Allgemein hatte ich das Gefühl, dass man bei React Native sehr oft auf Libraries der Community angewiesen ist, da React Native selbst nicht viele vorgestylte Komponenten bietet. Das ist ein Unterschied zu Ionic, den ich bemerkt habe.

Unter anderem verwendete ich das UI-Toolkit React Native Elements. Dieses kommt mit der Option, ein Theme zu erstellen, wobei neben Farben auch die default Styles der Komponenten festgelegt werden können, was sehr hilfreich war. React Native selbst bietet auch ein Color Theme, wodurch ich im Endeffekt beide nutze. Man müsste sich hier noch besser einlesen, was hierbei die Best Practice Lösung ist.

An der Kombination React Native mit Expo war sehr praktisch, dass man Änderungen mittels der Expo Go App schnell auf seinem Handy testen konnte. Das war auch sehr nötig, denn schnell wurde klar, es ist nicht so einfach die App bzw. die externen Komponenten auf jeder Plattform zum Laufen zu bringen, ohne dass unerwartete Verhaltensweisen auftreten. Manchmal gibt es auch Libraries, die nur Komponenten für iOS und Android zur Verfügung stellen, wodurch das Testen im Web schwierig wird.

Neben React Native habe ich mich im Rahmen des Projekts intensiv mit Zustand beschäftigt. Im Vergleich zu Redux ist es eine einfachere State Management Lösung, welche aber trotzdem eine Vielzahl nützlicher Features bietet. Um Logik zu trennen, habe ich meinen Store in Slices unterteilt. Zustand bietet außerdem die Funktion, den Store zu persistieren, wodurch ich manche Daten, wie z.B. den bzw. die User*in, den aktuellen Urlaub etc., zusätzlich lokal speichern konnte.

Fazit

Das Projekt hat mir vor allem einen Einblick in React Native mit Expo gegeben. Das Framework ist einerseits sehr mächtig, auf der anderen Seite können die vielen externen Komponenten mühsam werden. Ich habe aber auch viel Neues in Bezug auf Zustand und Prisma in Kombination mit zod gelernt. Auch die gesehenen Vor- und Nachteile von OpenAPI Generator werden hilfreich für weitere Projekte sein.

The post Projekt | TripSync appeared first on Mobile USTP MKL.

Aufgabenstellung

Die Aufgabenstellung und das MVP wurde uns größtenteils vorgegeben, wobei wir vor allem bei den optionalen zusätzlichen Features mitreden konnten. Prinzipiell war die Idee, eine App zu entwickeln, über die man gewisse Echtzeitdaten wie Standort, Geschwindigkeit, Herzfrequenz etc. mit einer Gruppe austauscht. Einsatzbereiche gibt es dabei mehrere. Beispielsweise könnte man sich auf den Sport- (Laufen, Radfahren etc.) oder auf den Gesundheitsbereich (inkl. Fallerkennung) fokussieren. Letztendlich haben wir uns für den Bereich “gegeneinander Laufen” entschieden.

MVP (Minimum Viable Product)

Um am Ende sagen zu können, dass wir die Aufgabe gemeistert haben, wurde ein MVP (Minimum Viable Product) mit den grundlegendsten Funktionen definiert. Was den Client betrifft, waren das Auslesen und sinnvolle Übertragen von Sensor-Daten, Login und Teambildung aber auch eine “coole Darstellung” wichtig. Vor allem beim letzten Punkt sollten wir uns wirklich Gedanken machen, was im Kontext gut funktioniert, anstatt einfach nur alle Daten in Zahlenform anzuzeigen.
Serverseitig lag der Fokus auf der Verteilung der Daten in Echtzeit im Team.
Außerdem sollte die App auf mindestens einer Plattform nativ im Testmodus verfügbar sein.

NTH (Nice to Have)

Neben dem MVP wurden auch optionale Features notiert, genannt “Nice to Haves”, die dann umgesetzt werden sollten, sobald das MVP fertig ist. Diese Liste wurde auch während der Woche erweitert.
Dazu gehörte die Distribution auf beiden Plattformen (iOS und Android) oder das Einführen eines Handicaps, welches dazu genutzt werden kann, dass unterschiedlich starke Leute in einer Sportart gegeneinander antreten können. Eine History vergangener Sessions, eine Exportmöglichkeit der Daten, Gamification, das Laufen der App im Hintergrund, Micro-Interactions und Vibration waren ebenso Punkte auf dieser Liste. Andere Ideen waren die Berechnung eines Leistungswerts, Tests oder die Verwendung eines QR-Codes zur Gruppenbildung.

Verwendete Technologien

Im Projekt setzten wir auf Technologien, die wir bereits im vorherigen Semester kennenlernen durften bzw. mit denen einige unserer Gruppenmitglieder*innen bereits Erfahrung hatten. Von Anfang an war klar, dass sich eine native Umsetzung unserer App für sowohl Android als auch iOS wohl zeitlich nicht ausgehen würde, weshalb wir im Frontend auf eine Cross-Plattform Technologie setzten.

Frontend

Im Frontend arbeiteten wir mit dem Cross-Platform Framework Ionic (Capacitor), in Kombination mit der Frontend-Technologie React – geschrieben in Typescript. Die Wahl fiel darauf, da wir im 1. Semester unseres Studiums sowohl ein Projekt mit React umsetzen mussten, als auch in unserer Masterklasse mit dem Ionic Framework arbeiteten.

Die ersten Screen-Prototypes designten wir mit der Design-Software Figma.

Backend

Im Backend verwendeten wir NestJS, ebenfalls in Kombination mit Typescript, da wir diese Backend-Technologie ebenfalls im 1. Semester unserer Masterklasse in einem Projekt verwendeten und so die Einstiegshürde wegfiel.

Da unsere App sehr stark auf Live-Daten angewiesen ist (sowohl das Senden der aktuellen Sensordaten eines Users, als auch das Erhalten der Live-Daten anderer User während einer Aktivität), entschieden wir uns, hierfür auf Websockets zurückzugreifen, welche nahtlos in NestJS unterstützt wurden. Beim Erstellen einer Session für alle Teilnehmer*innen wurde ein Websocket “Topic” erstellt, welches in den Apps aller Nutzer*innen subscribed werden konnte und mit welchem immer die aktuellen Live-Daten in einem fest definierten Intervall ausgetauscht wurden.

Datenbank

Für die Persistenz unserer Daten setzten wir auf eine PostgreSQL Datenbank, ergänzt durch den Object-Relational Mapper (ORM) TypeORM. Wir wählten PostgreSQL aufgrund seiner Zuverlässigkeit und weiten Verbreitung als relationale Datenbank, was uns eine solide Basis für unsere Anwendung bot und zukünftige Skalierbarkeit ermöglichte. Ein weiterer ausschlaggebender Faktor war die exzellente Kompatibilität mit NestJS und die vorhandene Teamerfahrung mit TypeORM.

Die Struktur unserer Datenbank wird ist in diesem ER-Diagramm veranschaulicht. Die Kernentitäten bilden User, Session und Messerwerte. Zwischen :

• User: Hier hinterlegen wir alle notwendigen Benutzerinformationen, darunter Id, Vorname, Nachname, Email, Passwort und physiologische Daten wie Geburtsdatum, Groesse, Gewicht und Geschlecht. Diese Informationen sind essenziell, insbesondere das Geburtsdatum für die Berechnung der individuellen Herzfrequenzzonen.
• Session: Diese Entität verwaltet die Details der Lauf-Sessions, wie Id, Status, Enddatum, Typ und Startdatum.
• User_Session: Als Verbindungstabelle stellt sie die Beziehung zwischen Benutzern und Sessions dar und speichert die Rolle des Teilnehmers innerhalb einer Session.
• Messwerte: Diese zentrale Entität ist für die Speicherung der während einer aktiven Session gesammelten Sensordaten zuständig. Dazu gehören Zeitstempel, Geschwindigkeit, Breitengrad, Längengrad, Lage, Richtung, Herzfrequenz und Schrittfrequenz. Diese Daten bilden die Grundlage für unsere Echtzeitanzeigen und potenzielle historische Analysen.

Mit unserer PostgreSQL DB wird somit das Rückgrat unserer App, indem alle statischen Benutzer- und Sitzungsdaten sowie die dynamischen Sensordaten gespeichert sind, die für die Kernfunktionen und die Visualisierung notwendig sind, gebildet.

Um diese DB stabil und einfach zu handhaben, nutzten wir Docker. Das erlaubte uns, die PostgreSQL-Datenbank in einem eigenen, isolierten “Container” laufen zu lassen. Dies vereinfacht nicht nur die Einrichtung erheblich, sondern stellt auch sicher, dass die Datenbank immer in einer konsistenten Umgebung läuft und ihre Daten sicher verwahrt bleiben. Dank dieser Docker-Einrichtung konnte sich unser Backend-Service problemlos und zuverlässig mit der Datenbank verbinden, sobald diese bereit war. Die Konfiguration mit TypeORM wiederum sorgte dafür, dass unsere App die Daten korrekt lesen, schreiben und verwalten konnte. Besonders wichtig dabei waren unsere TypeORM Datenbank-Migrationen. Diese funktionieren wie kleine, versionierte Skripte, die es uns ermöglichten, die Struktur der Datenbank (wie z.B. neue Spalten hinzufügen oder bestehende ändern) im Laufe der Entwicklung schrittweise und kontrolliert anzupassen, ohne Daten zu verlieren.

OpenAPI

Damit wir in unserem Frontend nicht noch einmal alle Backend Objekte doppelt anführen müssen und um Zeit zu sparen, haben wir uns dazu entscheiden, den OpenAPI Generator zu verwenden. Die grundsätzliche Funktion von diesem ist, dass man im Backend mithilfe eines Decorators, wie Swagger, die Endpunkte definiert und dokumentiert. Mithilfe dieser Dokumentation, kann man dann für das Frontend Client-Funktionen erstellen lassen, welche mit dem Backend konsistent und typensicher sind. In unserem Backend haben wir Swagger verwendet, um per Decorator die Endpoint Spezifikationen anzugeben. Im Frontend haben wir dann die @openapitools/openapi-generator-cli installiert, welche einen Befehl bereitstellt, mit welchem man die API erstellen kann. Davor ist noch eine OpenAPI Spec Datei benötigt, welche openapitool.json heißt, in welcher man die Einstellungen für die API angibt. Danach kann man jederzeit die API generieren lassen und sie verwenden.

CI/CD

Für unsere Backend-Applikation wurde uns ein Server auf unserer FH-Cloud zur Verfügung gestellt. Haben wir nun unsere NestJS Applikation per FTP auf diesen Server geladen? Natürlich nicht! Haben wir stattdessen viel Zeit in Continuous Integration und Deployment (CI/CD) investiert? Selbstverständlich! Schon am ersten Tag der Woche haben wir ein docker-compose.yml geschrieben. Damit ließ sich die Backend-Applikation mit einer Postgres Datenbank starten. Mit der Unterstützung unseres Masterklassenleiters Armin haben wir am Morgen des zweiten Tages Docker auf unserem Server installiert. Dann haben wir einen GitLab Runner mit dem Shell Executor eingerichtet und das .gitlab-ci.yml geschrieben. Darin haben wir einen Deploy Job definiert, der bei einem Commit auf den “main” Branch docker-compose ausführt und damit die neueste Version der Anwendung auf unserem Server startet. Ebenfalls haben wir den Build unserer Android-App automatisiert. Dafür brauchte es einen Job um die Dependencies der Ionic App zu installieren, einen Job um die Frontend-Applikation zu bauen, einen um das .apk zu bauen und schließlich einen Job um das .apk zu publishen. Damit wir reproduzierbare Builds und einen sauberen Server haben, wollten wir all diese Jobs in Containern ausführen. Dazu mussten wir einen weiteren GitLab Runner aufsetzen, der dieses Mal den Docker Executor verwendet. Der Build der Android App verwendet das Image alvrme/alpine-android und die anderen ein simples Node.js Image. Continuous Deployment war geschafft, Continuous Integration folgte.

Wenn man ein neues NestJS-Projekt startet, werden automatisch Eslint mit Prettier und Jest eingerichtet. Damit das Code-Linting/Formatting und die Tests auch in der Pipeline ausgeführt werden, haben wir dafür jeweils einen Job in einem “test” Step in unsere Pipeline erstellt. Vorgelagert findet ein Job statt, der die Dependencies installiert. Alle drei Jobs werden in einem Node.js Image ausgeführt. Hätten wir noch mehr Zeit gehabt, hätten wir noch für das Frontend einen Linting- und Test-Job erstellt.

Im Hinblick auf CI war zwar die Basis für Unit Tests im Backend gelegt, aber leider fehlten uns die Tests, um wirklich Nutzen davon zu haben. Der GitLab Test Reporter zeigt die traurige Situation unserer Unit Tests (siehe folgenden Screenshot). Um das zu kompensieren, haben wir End-To-End-Tests geschrieben, die zumindest einen Teil der User Flows abdecken. Mit Cypress durchlaufen wir den Registrierungs- und Anmeldeprozess und starten einen neuen Gruppenaktivität. Die Cypress Tests werden leider nicht in der Pipeline ausgeführt, da unsere GitLab Runner mit den existierenden Jobs bereits alle Hände voll zu tun hatten. Gegen Ende der Woche, als der Zeitdruck stieg, mussten wir sogar manche Pipeline Steps deaktivieren, um das Deployment zu beschleunigen.

Internes App-Publishing

Eine der Anforderungen unserer Auftraggeber war es, die fertige App auch auf zumindest einer der beiden Plattformen auf eine beliebige Weise öffentlich zur Verfügung zu stellen. Wir entschieden uns dafür Firebase App Distribution zu verwenden, um unsere Android App einer fest definierten Personengruppe ausliefern zu können. Es wurde ein Build Job in unserer GitLab Pipeline eingerichtet, der uns ein APK-File gebaut hat und dieses über die Firebase CLI in einen geschlossenen Test hochgeladen hat, in denen sowohl alle Teammitglieder*innen als auch unsere Dozenten eingeladen wurden. So wurde nach jedem Commit auf unseren master-branch eine neue App-Version veröffentlicht, die mit einem Klick in der Firebase App Distribution App heruntergeladen werden konnte.

Sensoren

In Bezug auf Sensoren wurden wir mit verschiedenen Heart Rate Monitors (HRMs) wie Wahoo Tickr Fit und einem Modell von Moofit ausgestattet. Um diese Daten auslesen zu können, haben wir das Capacitor Community Plugin “Bluetooth Low Energy” verwendet.

Arbeitsablauf

Generell haben wir beschlossen, dass wir jeden Tag um 9 Uhr mit der Arbeit beginnen werden. Wir haben auch die gesamte Woche vor Ort gearbeitet, da wir es als die bessere Option empfunden haben und gehört haben, wie schlecht es der Gruppe ging, welche nur im Home Office gearbeitet hat. Um uns besser organisieren zu können, haben wir jeden Tag um 10:00 ein Daily Standup abgehalten, wo wir unseren derzeitigen Stand den Dozenten gezeigt und erklärt haben und wir Feedback auf diesen erhalten haben. Bei diesen Standups haben wir auch unsere Ziele für den Tag festgelegt, damit wir wissen, auf was wir uns fokussieren werden.

Ziel des ersten Tages war es, ein Monorepo auf GitLab anzulegen und das Projekt zu initialisieren. Im Frontend beschäftigten wir uns mit den ersten Sensoren, und im Backend wurde die Datenbank aufgesetzt und mit den Websockets begonnen. Weiters richteten wir Firebase App Distribution für die Android Plattform ein.

Am Dienstag besprochen wir, wie unsere Entities/Daten aussehen würden. Das Feature “User Registrierung und Login” wurde implementiert, und wir machten uns Gedanken über das UI-Konzept und die Datenvisualisierung. Zusätzlich überlegten wir uns die Verwendung und Berechnung der Rohdaten der Sensoren, und implementierten automatisierte Android Builds.

Am Mittwoch, nachdem wir Feedback zu unserem UI-Konzept erhielten, verfeinerten wir dieses und überlegten uns ein bestimmtes Szenario für die Datenvisualisierung. Danach machten wir uns daran, die UI umzusetzen, ClientSDK zu generieren und Endpoints und Services im Backend zu erstellen. Weitere Ziele waren, Sensordaten über Websockets schicken und empfangen zu können, und eine Session sowohl im Frontend als auch im Backend erstellen zu können.

In den letzten beiden Tagen ging es darum, alle Features des MVP fertigzustellen und letzte Bugs zu fixen. Dazu gehörten: Auth (Route Guard, Token, …), alles rund um Sessions (Create, Join, End, Leave), die Kommunikation der Daten über Websockets, Edit Profile, Datenvalidierung (null, -1, …), Loading Indicator, und mehr.

Am Freitagnachmittag wurde das Endprodukt präsentiert – mehr dazu etwas später in diesem Blogbeitrag.

Neben der Arbeit kam aber auch nicht der Spaß zu kurz. Darum nutzten wir als Team am 4. Tag der Wild Week (Donnerstag) die Möglichkeit, beim FH internen “IMFix” Event vorbeizuschauen. Neben Snacks, Bier und guter Laune konnten wir uns bei mehreren Multiplayer Spielen entspannen, bevor es dann in die heiße Endphase des Projektes ging.

Abgeliefertes Endprodukt

Unsere App ist in mehrere übersichtliche Screens unterteilt, die den User Schritt für Schritt durch den gesamten Ablauf führen. Von der Anmeldung über die Erstellung oder Teilnahme an einer Session bis hin zur aktiven Nutzung während eines Laufs sind alle Funktionen klar strukturiert. Im Mittelpunkt stehen dabei das Dashboard als zentrale Steuerzentrale, der WaitingScreen zur Organisation der Teilnehmer*innen, sowie das Userprofil, in dem persönliche Daten verwaltet werden können. Während einer aktiven Session rücken das Leaderboard und die Kartenansicht in den Vordergrund. Hier werden in Echtzeit alle relevanten Informationen der Teilnehmer*innen angezeigt. 
Bevor jedoch der eigentliche Ablauf startet, erfolgt der Einstieg über den Login oder die Registrierung.

Login und Registrierung

Beim ersten Öffnen der App wird der User auf den Login-Screen weitergeleitet. Hier kann man sich entweder mit bestehenden Zugangsdaten anmelden oder sich neu registrieren. Die Registrierung erfolgt über ein kurzes Formular, bei dem grundlegende Daten wie Benutzername, E-Mail-Adresse und Passwort abgefragt werden.

Dashboard

Sobald der Login oder die Registrierung abgeschlossen ist, gelangt der User auf das Dashboard. Hier stehen zwei Optionen zur Verfügung: Entweder eine neue Session zu erstellen oder einer bestehenden Session beizutreten. Diese Optionen sind jedoch zu Beginn ausgegraut dargestellt und können erst genutzt werden, wenn bestimmte Voraussetzungen erfüllt sind.

Auf dem Dashboard befinden sich drei Buttons zur Aktivierung der benötigten Sensoren:

• GPS
• Herzfrequenzsensor (inkl. Bluetooth-Verbindung zu einem Wearable)
• Heading-Sensor

Zu Beginn sind alle drei Buttons rot eingefärbt, um anzuzeigen, dass die jeweiligen Sensoren noch nicht aktiv sind. Nach dem erfolgreichen Aktivieren – sei es durch das Einschalten eines Gerätesensors oder die Herstellung einer Verbindung – wechselt die Farbe auf grün, was visuell signalisiert, dass der jeweilige Sensor nun einsatzbereit ist.

Erst wenn entweder das GPS-Signal oder der Herzfrequenzsensor aktiviert wurde, werden die beiden Optionen „Session erstellen“ und „Session beitreten“ freigeschaltet und können ausgewählt werden. Optional kann zusätzlich der Heading-Sensor aktiviert werden, der später auf der Karte eine genauere Bewegungsrichtung ermöglicht.

Beim Beitritt zu einer Session muss zuvor die Session-ID, die man über einen QR-Code oder eine Nachricht erhalten hat, in ein Inputfeld eingegeben werden. Danach geht es automatisch weiter zum nächsten Screen.

WaitingScreen

Am WaitingScreen wird die aktuelle Teilnehmerliste angezeigt. Dort sieht der User, wer sich bereits angemeldet hat. Die Liste aktualisiert sich automatisch, sobald weitere Personen hinzukommen.

Über den Abmelde-Button kann sich der User jederzeit wieder von der Session entfernen. Man wird dabei direkt zurück ins Dashboard geleitet. Sollte jedoch der Host selbst auf „Abmelden“ klicken, wird nicht nur die eigene Verbindung getrennt, sondern die komplette Session gelöscht, inklusive aller Teilnehmerinnen. Auch in diesem Fall gelangen alle automatisch zurück ins Dashboard.

QR-Modal

Für den Ersteller der Session gibt es die Möglichkeit, einen QR-Code zu generieren. Dieser Button befindet sich oberhalb der Teilnehmerliste. Nach dem Klick öffnet sich ein Modal, in dem der QR-Code angezeigt wird. Dieser enthält die Session-ID und kann über einen Button ebenso in die Zwischenablage kopiert werden. Zusätzlich gibt es die Möglichkeit, die Session-ID direkt per Nachricht oder Social Media zu teilen. Wenn der Host entscheidet, dass alle bereit sind, kann die Session jederzeit über den Start-Button gestartet werden.

Sobald der Host einer Session auf “Start” klickt, kommen alle User*innen einer Session auf das Leaderboard. Dort befindet sich das Grundkonzept unserer App. Ganz oben am Screen findet man zwei Tabs, um zwischen 2 Ansichten zu wechseln: das Leaderboard und die Kartenansicht.

Leaderboard

Oben am Bildschirm findet der*die User*in die Ranganzeige. Der eigene Rang wird ziemlich groß dargestellt, damit man sofort erkennt, wo man sich am Leaderboard befindet. Gleich darunter findet sich das eigentlich wichtigste Feature unserer App, nämlich die visuelle Anzeige der Herzfrequenz und der Geschwindigkeit. Die Herzfrequenz wird bei uns in 3 Zonen eingeteilt. In der mittleren Zone befindet sich die “ideale Herzfrequenz” für den*die User*in für die aktuelle Aktivität. Sobald man sich in der linken oder in der rechten Zone befindet, bedeutet das, dass die Herzfrequenz zu niedrig bzw. zu hoch ist. Die “ideale Herzfrequenz” berechnet sich aus dem Alter des Users bzw. der Userin, damit die Fairness bei Teilnehmer*innen unterschiedlichen Alters erhalten bleibt. Die visuelle Darstellung wurde als Balken gelöst, da wir so die 3 Zonen in Farben unterteilen konnten und die aktive Herzfrequenz auf diesem Balken hin- und herwandern kann. Innerhalb der Balken befindet sich auch die Anzahl der Punkte, die man bekommt, je nachdem, in welcher Zone man sich befindet. Das Punktesystem für die Herzfrequenz wurde so gelöst, dass nur die mittlere Zone, also Zone 2, die meisten Punkte (+5 Punkte) bekommt. Die anderen zwei Zonen bekommen jeweils +2 Punkte. Somit bekommt der*die Nutzer*in alle 3 Sekunden, je nach Zone, die Punkte gutgeschrieben. 

Unterhalb des Herzfrequenz-Balkens befindet sich der Geschwindigkeits-Balken, dieser basiert auf dem gleichen Prinzip. Je nach Geschwindigkeit gehen die Punkte nach oben, je schneller desto mehr Punkte. Auch hier wurde der Balken in mehrere Zonen unterteilt, die farblich markiert sind.

Unterhalb der beiden Balken befindet sich auch schon das Leaderboard. Dort werden alle Teilnehmer*innen angezeigt, sowie deren Punktzahl. Alle Punkte werden permanent alle 3 Sekunden geupdatet, damit das Board ständig in Bewegung ist. Wenn sich Plätze ändern, passiert dies in einer überlappenden Animation. Außerdem werden Plätze 1-3 in den klassischen Farben Gold, Silber, Bronze dargestellt.

Kartenansicht

Auf dieser Seite befindet sich eine Karte von “Leaflet”, die in voller Bildschirmgröße dargestellt wird. Sie dient dazu, dass man jederzeit alle Teilnehmer*innen aktiv auf der Karte verfolgen kann, sollte sich beispielsweise ein*e User*in in einer anderen Stadt befinden. Alle Teilnehmer*innen werden jeweils als Dreieck, in einer individuellen Farbe, dargestellt. Wir haben uns für Dreiecke entschieden, weil wir so die Richtung anzeigen können, in die sich ein*e Nutzer*in bewegt. Aufgrund zeitlicher Begrenzung war das auch schon die Funktion unserer Karte.

User-Profil

Das Userprofile ist sehr simpel gehalten und bietet nur die Möglichkeit, Daten der Nutzer*innen zu ändern, wie zum Beispiel das Alter. Außerdem befindet sich dort der Logout Button.

Endpräsentation und Feedback

Ablauf der Präsentation / Abgabe

Am Nachmittag des fünften und letzten Tags der Extreme Programming Week war es soweit: das Produkt der Woche sollte präsentiert werden. Kurz vor dem ausgemachten Termin mit unseren Masterklasseleitern war es noch recht stressig, da noch einige kleine Bugs aufkamen, die gefixt werden mussten. Trotzdem schafften wir es recht pünktlich, mit der App-Demo anzufangen.

Zuerst installierten wir die App auf unseren Handys: auf Android via Firebase App Distribution und für iOS direkt von Xcode am Laptop auf das iPhone via USB-Kabel. Danach zeigten wir unseren Masterklasseleitern, wie man sich in der App registrieren und einloggen kann, und wie das Dashboard und die Account-Seite aussehen, sobald man eingeloggt ist. Die Herzfrequenz-Sensoren, welche wir zur Verfügung hatten, wurden unterschiedlichen Personen angelegt und mit Handys verbunden.

Schließlich war es Zeit für eine Demonstration der App in einem echten Szenario: eine Person unter uns erstellte eine Session und alle anderen traten dieser bei. Sobald alle drinnen waren, machten wir uns auf den Weg. Während einem Spaziergang rund um das Gebäude (der Rückweg wurde sogar gelaufen!) probierten wir die App aus und beobachteten dabei unsere eigenen Werte (Herzfrequenz, Position, Geschwindigkeit), sowie die Punkte auf dem Leaderboard.

Als wir zu dem Raum der Lehrveranstaltung zurückkehrten, gaben unsere Masterklasseleitern ihr Feedback zu unserem Endprodukt. Dadurch, dass wir die Anforderungen des MVP erfüllten, und auch noch einige Nice-To-Have-Funktionalitäten einbauten, war unser Projekt erfolgreich. Wir freuten uns über die positiven Rückmeldungen und über Ideen für mögliche Erweiterungen und Verbesserungen der App.

Erhaltenes Feedback: Verbesserungspotenzial

Im Laufe der interaktiven Live-Demo und im Anschluss zur Präsentation erhielten wir folgendes Feedback:

• Die WebSocket-Verbindung bricht öfters ab (z.B. beim Wechsel von WLAN zu Mobilen Daten, und auch nach einer Weile von Inaktivität). Eine Möglichkeit, sich (automatisch) wieder verbinden zu können, sollte implementiert werden.
• Die Berechnung der Daten (Punkte für das Leaderboard) wird momentan clientseitig durchgeführt. Die Berechnung sollte serverseitig passieren.
• Wenn sowohl die Herzfrequenz, als auch die GPS-Daten, null sind, verschwindet der visuelle Balken dieser Person im Leaderboard.
• Der Code, der eingegeben werden muss, um einer Session beizutreten, sollte kürzer sein. Zusätzlich wäre ein eingebauter QR-Code-Reader cool. (Dies hatten wir eigentlich vor, es ist sich zeitlich aber leider nicht ganz ausgegangen)
• Es wäre gut, während der Session sehen zu können…
  • …wie akkurat die Daten sind (z.B. Position).
  • …ob eine Person einen Herzfrequenz-Sensor verbunden hat. (Zusätzlich wäre es von Vorteil, sich während der Session auch später noch mit einem Herzfrequenz-Sensor verbinden zu können.)
  • …ob eine Person momentan disconnected ist.
• Ein Nice-To-Have wäre noch, dass man in dem Leaderboard während der Session auf einzelne User*innen draufklicken kann, um Detaildaten zu der Person zu sehen. Eventuell könnten in der View die Daten der anderen Person auch gleich mit den eigenen verglichen werden.

Fazit aller Teilnehmer*innen

Im folgenden Abschnitt möchten wir noch unser Fazit und unsere Erfahrungen teilen, die wir während der Extreme Programming Week sammeln konnten.

Katharina

Ich bin sehr stolz auf das, was wir in diesen fünf Tagen geleistet haben. Die Extreme Programming Week hat nicht nur unsere Zeitmanagement-Skills, sondern auch zum ersten Mal unsere koordinierte Zusammenarbeit als Team auf die Probe gestellt. Ich war positiv überrascht, wie gut dies funktioniert hat – ich glaube, die täglichen Meetings haben sehr stark zu unserem Erfolg beigetragen.

Meine Aufgaben während der Woche waren unter anderem das Leiten der Meetings, das Testen und Debuggen der nativen Funktionalitäten (insbesondere auf dem iPhone) und Frontend Development. Dabei habe ich mich zum Beispiel intensiv mit Device-Daten (Geolocation, Accelerometer, Gyroskop, etc.) beschäftigt, um diese einerseits in der App anzuzeigen, und andererseits, um sie zur Berechnung von Herzfrequenzzonen, Kalorienverbrauch und sogar einem Schrittzähler zu verwenden. Letzteres hat es aus Zeitgründen leider nicht in das Endprodukt geschafft, aber die Erfahrungen, welche ich dabei gesammelt habe, bleiben mir erhalten.

Im Laufe der Woche hatte ich auch die Möglichkeit, gemeinsam mit Caro im Pair-Programming-Stil an der Authentifizierung im Frontend zu arbeiten. Diese Art des Arbeitens war recht neu für mich, aber ich muss sagen, dass ich eine sehr positive Erfahrung damit gemacht habe – wenn zwei kreative Köpfe zusammenkommen, kann so einiges entstehen!

Zusammenfassend kann man sagen, dass die Woche recht stressig war, besonders gegen Ende hin, aber ich habe sehr viel dabei gelernt. Vom technischen Know-how bis hin zu Leadership, Zeitmanagement und Team-Skills war alles dabei. Ich wünschte, ich hätte noch mehr Einblick in das Backend und den CI/CD-Prozess bekommen können, aber aus Zeitgründen war das nicht möglich. Alles in allem blicke ich positiv auf die Extreme Programming Week zurück: es war eine spannende Woche voller wertvoller Erfahrungen, welche uns als Team noch enger zusammengeschweißt hat, und aus der ich viel neues Wissen für die Zukunft mitnehme.

David

Ich blicke gerne auf die Wild Week zurück und bin stolz auf das Endprodukt, das wir als Team in der Woche geschaffen haben. Es war schön zu sehen, wie jedes Teammitglied seine bisherigen technischen Erfahrungen bei den verschiedenen Teilaufgaben des Projekts einbringen konnte. Durch das Setup (alle Teammitglieder ständig in einem Raum) konnten wir das Know-How auch sehr gut mit allen teilen.

Sehr motivierend fand ich auch die Aufteilung in tägliche Sprints mit einem Meeting in der Früh, in dem wir immer die Aufgaben definierten und zwischen den Teammitgliedern verteilten, da man so ein festes Ziel für den Tag vor Augen hatte, auf das man hinarbeiten konnte.

Ich konnte auf jeden Fall ein paar persönliche Learnings aus der Wild Week mitnehmen: Da das zu entwickelnde Produkt ja am Freitag zu präsentieren war und dadurch die Zeit ein extrem limitierender Faktor, war es essentiell, sich auf das MVP zu konzentrieren und sich nicht in Details zu verlieren. Das hat im Laufe der Woche mal mehr, mal weniger gut geklappt. Es ist auch gar nicht so leicht, stets den Fokus auf die Grundfunktionalität zu behalten, da man bei Projekten mit kompletter Entscheidungsfreiheit als Entwickler automatisch darüber nachdenkt, welche Features man nicht noch hinzufügen könnte. Gegen Ende der Woche hat sich das Pareto-Prinzip aus meiner Sicht auch wieder zum Teil bewahrheitet. Durch Erfolgsmomente am Anfang des Projekts ist man leicht dazu verleitet anzunehmen, dass die Entwicklungsgeschwindigkeit im selben Tempo bis zum Abschluss beibehalten werden kann – was sich nicht bewahrheitet hat. In einem zukünftigen Projekt dieser Art wäre es für mich wichtig, mehr Fokus darauf zu legen, wirklich beim MVP zu bleiben und den ganzen Entscheidungsprozess über zusätzliche Features erst gar nicht aufkommen zu lassen.

Aus technischer Sicht fand ich super, mich wieder mehr mit React beschäftigen zu können. Hier habe ich einiges an Know-How aus der Woche mitnehmen können. Zusätzlich fand ich die Diskussionen mit meinen TeamkollegInnen über Architekturentscheidungen sehr spannend und fand es super, das ganze Tech Setup inkl. CI/CD für ein Projekt dieser Art von Grund auf einzurichten. Es war auch das erste Mal, dass ich an einer App gearbeitet habe, die hauptsächlich Websockets als Kommunikationskanal verwendet – es war spannend, mal mit einem anderen Schnittstelle als REST zu arbeiten.

Andreas

8 Teammitglieder, fast 5 Tage Entwicklungszeit und eine gemeinsame App-Idee realisieren – das war unser intensives und lehrreiches Projekt am Anfang des 2. Semesters, aus dem ich persönlich viel mitnehmen konnte. Die Woche war geprägt von enger Teamkommunikation, klarer Aufgabenverteilung und vielen kleinen Abstimmungen, die am Ende zu einem funktionierenden Gesamtprodukt geführt haben. Besonders interessant war für mich, wie unterschiedlich einzelne Teammitglieder an Aufgaben herangegangen sind – sowohl inhaltlich als auch methodisch. Dabei habe ich nicht nur verschiedene Denkansätze kennengelernt, sondern auch praktische Coding-Tipps und Lösungsstrategien aufgeschnappt, die mir in Zukunft sicher weiterhelfen werden.

Mein Fokus lag zu Beginn auf der Planung unserer Datenbank. Zusammen mit Matthias habe ich verschiedene Datenbanktypen – wie z.B. relationale, NoSQL und Time-Series DBs – hinsichtlich ihrer Eignung für unseren Use Case bewertet. Auf Basis dieser Überlegungen sind wird bei einer klassischen relationalen DB geblieben, für die Matthias und ich ein erstes ER-Diagramm entworfen haben, das wir anschließend im Team besprochen und gemeinsam überarbeitet haben. Auch wenn dieser Prozess Zeit gekostet hat, konnten wir dadurch eine saubere, tragfähige Struktur aufsetzen, die sich später fast vollständig problemlos in NestJS integrieren ließ. Im weiteren Verlauf (nachdem der technische Aufbau der DB gestanden ist) habe ich mich verstärkt dem Frontend gewidmet, insbesondere der Nebenmaske für die User*innendaten, die noch nicht von meinen Kolleg*innen bearbeitet wurden. Dort konnte ich eigenständig erste Komponenten entwickeln, gerade bei Bereichen mit direktem Bezug zur Datenbank. Bei komplexeren Problemen habe ich auf Pair Programming gesetzt, um gemeinsam mit dem gebündelten Stärken meiner Kolleg*innen gezielte Lösungen zu finden.

Eine besondere Herausforderung war auch für mich der Umgang mit dem begrenzten Zeitrahmen bei gleichzeitigem Anspruch auf sauberen, wartbaren Code. Ich habe gelernt, wie entscheidend es ist, in der Entwicklung frühzeitig sinnvolle Prioritäten zu setzen – also die „richtige“ Reihenfolge zu finden: Was muss funktionieren, was ist optional, und was kann man notfalls zurückstellen? Diese Balance war nicht immer einfach, aber essenziell, um alle Kernfunktionen zuverlässig umzusetzen. Mein Versuch, am Ende noch die Safe-Area technisch sauber zu integrieren, ist trotz mehrerer Ansätze gescheitert – aber genau daraus habe ich am meisten gelernt: Nicht jede Idee lässt sich unter Zeitdruck noch sinnvoll umsetzen, und pragmatisches Handeln ist oft wichtiger als Perfektion im Detail.

Um mein Fazit abzurunden, möchte ich gerne festhalten, dass dieses Projekt nicht nur meine technischen Fähigkeiten weiterentwickelt, sondern auch mein Verständnis für effiziente Teamarbeit unter Druck geschärft hat. Besonders der Umgang mit begrenzter Zeit und die bewusste Fokussierung auf das Wesentliche haben mir gezeigt, worauf es in realen Entwicklungsprozessen wirklich ankommt.

Felix

Die Programming Week war für mich auf jeden Fall ein Highlight. In einer relativ großen Gruppe so ein Projekt in nur 5 Tagen umzusetzen war nicht nur super anstrengend, sondern auch spannend und lustig. Ich muss echt sagen, dass ich sehr viel gelernt habe, auch wenn ich leider von manchen Bereichen des Projekts nicht so viel mitbekommen habe, was aber durchaus verständlich ist, wenn man unter diesem Zeitdruck steht.

Ich habe viel im Pair-Programming gearbeitet und das vor allem am Frontend. Das war für mich echt nützlich, da ich so schneller in das Projekt und in React reinfinden konnte. Ich habe mit Caro zuallererst begonnen, dass wir den Heart-Rate-Sensor mit Bluetooth verbinden können und die Daten auslesen können, das hat Anfangs ein bisschen schwierig funktioniert, aber dann haben wir zusammen auch schnell eine Lösung gefunden, was gerade am ersten Tag super motivierend war. Auch sonst war das gesamte Projekt sehr gut aufgebaut, weil wir jeden Tag mit einem Meeting begonnen haben, um die heutigen Ziele festzulegen. Anfangs dachte ich, dass wird ja dann echt einfach am Freitag fertig zu werden, wenn alles so schnell weitergeht, aber wie so oft unterschätzt man dann den Stress der letzten Tage. Wie ich schon einmal erwähnt habe, hätte ich noch sehr gerne mehr in das Backend und in die Websockets geschaut, aber leider war das zeitlich nicht mehr ganz möglich, aber dafür konnte ich im Frontend fast überall mitarbeiten, was natürlich auch dort mein Wissen verbessert hat.

Das gesamte Projekt haben wir echt gut als Gruppe gemeistert. Wir hatten Spaß, waren gestresst und haben alle glaube ich sehr viel dabei gelernt. Das Endprodukt konnte sich bei der Präsentation auch sehen lassen, außer vielleicht ein paar kleine Bugs. Ich konnte auf jeden Fall sehr viel lernen und würde diese Art von Projekt gerne wiederholen, auch wenn eine Pause nach dieser Woche sehr gut getan hat. 

Caroline

Es war sehr spannend zu sehen, wie viel man zu acht in einer Woche bzw. 5 Tagen schafft zu entwickeln. Ich habe mich vor allem mit dem Frontend beschäftigt und dabei meist Pair Programming mit verschiedenen Personen betrieben. Dieses Konzept ist mir bereits aus dem Bachelor bekannt und mir persönlich gefällt es sehr gut, da man so schneller Fehler bemerkt.

Montags habe ich mich mit Felix um die Verbindung zum Heart Rate Sensor gekümmert. Anfangs gab es ein paar Schwierigkeiten, doch dann folgte das Erfolgserlebnis. Die Verwendung von HRMs und Bluetooth LE war für mich neu, aber sehr interessant. Dienstags habe ich mich vor allem mit dem Login- und Registrierungs-Screen beschäftigt und dafür anfangs Farben und Schriftarten global definiert und Tailwind aufgesetzt. In Bezug auf die Formulare auf den zwei Screens nutze ich React Hook Form, wobei ich die Library zu einem späteren Zeitpunkt ersetzt habe, da der State nicht immer aktualisiert wurde. Nachdem wir am Mittwoch unser UI-Konzept und die Datenvisualisierung überarbeitet hatten, habe ich mit Felix die Umsetzung des LiveActivity-Screens begonnen. Donnerstags war ich mit Katharina für den Authentifizierungscheck beim Aufruf gewisser Routen verantwortlich und habe Andi beim Bearbeiten der Profilinformationen geholfen. Am letzten Tag war Endspurt angesagt und somit auch Bug Fixing. Dabei habe ich einerseits David bei der Verwendung der WebSockets im Frontend unterstützt, andererseits Matthias bei der Session Erstellung/Teilnahme.

Ich finde, wir haben das als Gruppe sehr gut gemeistert, mit dem Daily Planning am Anfang war klar definiert, was gemacht wird, und das Endprodukt (bis auf die paar Bugs) kann sich sehen lassen. Vor allem was die Verbindung mit den Sensoren und die Erstellung eigener sogenannter Guarded Routes betrifft, habe ich einiges gelernt, was auch in Zukunft hilfreich sein könnte. Neben den technischen Aspekten habe ich nochmals gesehen, wie wichtig es ist, sich zuerst auf das MVP zu konzentrieren und sicherzustellen, dass das die anderen auch tun, da man sonst Zeit verliert und sich verrennen kann.

Sebastian

Die Wild Week war ein wirklich interessantes und spannendes Erlebnis. Ein ganzes Projekt in nicht einmal 5 Tagen auf die Beine zu stellen war extremst stressig, aber auch wirklich toll zu sehen, was man eigentlich in so kurzer Zeit auf die Beine stellen kann, wenn man sich wirklich ins Zeug lägt. Auch konnte ich einiges aus dieser Woche mitnehmen.

Zum einen hatte ich bisher noch keine Erfahrung mit Ionic in Verbindung mit React. Ich habe nur Ionic und Angular oder React Native verwendet, aber nicht beide zusammen. Auch habe ich einiges über die Verwendung von Herz Sensoren erfahren, auch wenn meine Erfahrung hier etwas kurz gekommen ist, da ich größtenteils im Backend zuständig war. Ich hätte sehr gerne auch andere Bereiche mir angeschaut, aber aufgrund des Zeitstresses ist es verständlich, dass dies nicht wirklich möglich war. In der Woche habe ich manchmal allein gearbeitet, zum Beispiel für die Erforschung, wie das Accelerometer im Handy funktioniert oder im Backend die Datenspeicherung über die passenden Endpoints zu ermöglichen, habe aber auch einiges im Pair Programming gemacht. Auf beiden Seiten. Auch wenn ich diese Technik schon aus dem Bachelor kannte, ist es trotzdem immer interessant zu sehen, wie gut Pair Programming funktioniert. Eine weitere Person neben sich zu haben, die sich nur darauf konzentrieren kann, was geschrieben wird und sofort erkennen kann, wenn man eine Sache vergisst oder welche einem bei Problemen hilft, ist sehr wertvoll, vor allem wenn nicht jede Person im Team an einer eignen Sache arbeiten kann.

Im großen und ganzem finde ich das die Wild Week wirklich toll gelaufen ist. Wir haben uns viel vorgenommen, dies aber auch toll hinbekommen. Mit den Daily Stand-ups, welche wir immer in der Früh gemacht haben, konnten wir uns jeden Tag auf unsere Ziele festlegen und auf diese fokussieren. Man konnte auch wirklich gut erkenne, weshalb das Prinzip eines MVPs existiertet. Ich hätte nichts dagegen, einmal wieder so ein Projekt zu wiederholen.

Jan

Es war eine spannende Woche! In fünf Tagen haben wir viel diskutiert, Entscheidungen getroffen und fleißig in die Tasten gehauen. Das Ergebnis ist ein Proof of Concept, der unsere interessante App-Idee greifbar macht. Mit diesem Ergebnis sind wir insgesamt sehr zufrieden. Allerdings schwingt beim „insgesamt“ auch ein kleiner Vorbehalt mit: Hätten wir vielleicht noch mehr aus dieser Woche herausholen können?

Viel Zeit hat unser Team zur Konzeption der App aufgewendet. Diese Zeit scheint mir rückblickend gut investiert. Es war wichtig, eine Idee auszuarbeiten, die wir spannend und sinnvoll fanden. Erst mit dieser klaren Vorstellung konnten wir mit Elan loslegen. Unsere Schwächen sehe ich eher bei der Aufteilung und Priorisierung der Arbeit. Die Features der App haben wir in Backend und Frontend unterteilt und zu unabhängig voneinander umgesetzt. Das führte dazu, dass im Backend Funktionen implementiert wurden, die im Frontend letztlich keine Verwendung fanden. Wie im Kapitel zu CI/CD erwähnt, haben wir außerdem zu viel Energie in unsere Pipelines gesteckt. Ein weiteres Problem der Aufteilung war, dass das Zusammenführen der Arbeiten erst spät erfolgte, wodurch wir auch erst spät auf Probleme aufmerksam wurden. Sinnvoller wäre es wohl gewesen, wenn Sub-Teams End-to-End an einzelnen Features gearbeitet hätten, sodass die App schrittweise gewachsen wäre.

Insgesamt war es jedoch eine produktive Woche, in der wir als Team nicht nur viel geschafft, sondern auch viel Spaß gehabt haben. Es war wirklich schön, sich fünf Tage lang intensiv in ein völlig neues Thema zu vertiefen – eine willkommene Abwechslung! Die Erfahrungen aus dieser Woche und das gestärkte Teamgefühl werden uns im nächsten Projektsemester mit Sicherheit zugutekommen.

The post Blog | MoveMates appeared first on Mobile USTP MKL.

Was ist Prisma ORM?

Prisma ORM ist, wie der Name schon verrät, ein ORM (object-relational mapping), also eine Objektrelationale Abbildung für TypeScript und Node.js. ORMs abstrahieren die Komplexität der Datenbank, indem sie über Objekte eine Schnittstelle zum Holen, Erstellen, Bearbeiten und Löschen von Daten bieten. Es werden Modelle bzw. Klassen geschrieben, die den Tabellen in der Datenbank entsprechen. Prisma ORM verfolgt dabei allerdings einen schema-first Ansatz. Das bedeutet, dass es ein zentrales Schema-File gibt, auf dem alles basiert. Außerdem ist Prisma ORM open-source (bis auf Prisma Sudio – siehe nächster Abschnitt).

Bestandteile

Prisma besteht aus folgenden drei Teilen:

• Prisma Client
• Prisma Migrate
• Prisma Studio

Prisma Client

Der Prisma Client ist eine automatisch basierend auf dem Prisma-Schema generierte, typsichere API, mit der Datenbankabfragen durchgeführt werden können. Es muss also nicht manuell SQL geschrieben werden und durch die Typsicherheit werden Fehler frühzeitig vermieden. Dieser Bestandteil ist der Teil von Prisma ORM, der am häufigsten vorkommt, weshalb er oftmals auch nur Prisma genannt wird.

Prisma Migrate

Prisma Migrate ist ein Tool zum Verwalten von Datenbankschemas. In Form von Migrationen können leicht Änderungen an der Struktur der Datenbank vorgenommen werden. Dadurch können Code und Datenbank synchron gehalten werden.

Prisma Studio

Prisma Studio bietet einen grafische Benutzeroberfläche, um die Datenbank durchsuchen zu können und die Daten verwalten zu können. Auf diesen Teil wird in dem Blogartikel nicht genauer eingegangen.

Erste Schritte

Im folgenden Abschnitt wird nun erklärt wie Prisma ORM beispielhaft in einem NestJS Projekt installiert und verwendet werden kann.

1. Projekt aufsetzen

Zuerst muss NestJS CLI installiert und ein neues Projekt erstellt werden. Wenn ein bestehendes Projekt verwendet wird, kann dieser Schritt übersprungen werden

npm i -g @nestjs/cli
nest new prisma-test

Im Ordner des Projekts, muss nun Prisma CLI installiert und ein neues Prisma-Projekt initialisiert werden.

npm i prisma --save-dev
npx prisma init

Nun muss die Datenbankverbindung hergestellt werden. Dazu muss im .env File die richtige URL gesetzt (siehe dazu https://www.prisma.io/docs/orm/reference/connection-urls) und in der schema.prisma Datei der provider im datasource Block angepasst werden. Ich arbeite lokal mit XAMPP und einer MySQL Datenbank. Prisma ORM kann aber mit PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Supabase und vielen weiteren Datenbanken genutzt werden.

2. Tabellen erstellen

Um Tabellen zu erstellen, müssen zuerst Models im Prisma Schema erstellt werden. Das prisma.schema File könnte beispielsweise so aussehen:

model User {
  id       Int    @id @default(autoincrement())
  username String @unique
  posts    Post[]
}

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  text      String?
  published Boolean? @default(false)
  author    User?    @relation(fields: [authorId], references: [id])
  authorId  Int?
}

Zuerst wird der Name des Feldes definiert, dann der Typ (? für optional) angegeben und abschließend die Eigenschaften angeführt.

Hinweis zu VS Code:

Arbeitet man in VS Code, so empfiehlt es sich, die Extension “Prisma” von Prisma selbst herunterzuladen, um die Lesbarkeit des Schemas durch Syntax Highlighting zu verbessern.

Nachdem die Datei gespeichert wurde, können nun mittels Prisma Migrate die Migration Files erstellt werden, die dann unter prisma/migrations zu finden sind.

npx prisma migrate dev --name init

3. Prisma Client installieren und verwenden

npm i @prisma/client

Mit der Installation wird auch schon prisma generate ausgeführt. In der Zukunft muss nach jeder Änderung am Model dieser Befehl ausgeführt werden, um den Prisma Client up-to-date zu halten.

Nun erstellen wir ein Prisma Service (prisma.service.ts) im src Ordner, welches wir dann in anderen Services verwenden können.

import { Injectable, OnModuleInit } from '@nestjs/common';
import { PrismaClient } from '@prisma/client';

@Injectable()
export class PrismaService extends PrismaClient implements OnModuleInit {
  async onModuleInit() {
    await this.$connect();
  }
}

Um ein Module, ein Service und einen Controller in NestJS zu erstellen werden folgende Befehle benötigt:

nest g mo user
nest g s user
nest g co user

Dasselbe macht man für die Posts. Dann kann das User Service erweitert werden. Um das Prisma Service verwenden zu können, muss es im App Module und jedem weiteren wie z.B. User Module unter Providers hinzugefügt werden.

So könnte das User Service aussehen:

import { Injectable } from '@nestjs/common';
import { PrismaService } from '../prisma.service';
import { Prisma, User } from '@prisma/client';

@Injectable()
export class UserService {
    constructor(private prisma: PrismaService) { }

    async findUserById(
        id: number,
    ): Promise<User | null> {
        return this.prisma.user.findUnique({
            where: { id },
        });
    }

    async findAllUsers(): Promise<User[]> {
        return this.prisma.user.findMany();
    }

    async createUser(data: Prisma.UserCreateInput): Promise<User> {
        return this.prisma.user.create({
            data,
        });
    }

    async updateUser(params: {
        id: number;
        data: Prisma.UserUpdateInput;
    }): Promise<User> {
        const { id, data } = params;
        return this.prisma.user.update({
            where: { id },
            data: data
        });
    }

    async deleteUser(id: number): Promise<User> {
        return this.prisma.user.delete({
            where: { id }
        });
    }
}

Das Prisma Service (bzw. der Prisma Client) stellt einem die CRUD Methoden zur Verfügung und auch die Types können direkt von Prisma übernommen werden. Nach demselben Prinzp kann das Post Service erweitert werden.

Möchte man beim Laden eines Posts auch die Informationen des Autors bzw. der Autorin mitgeben, so kann include oder select verwendet werden.

async findPostById(
        id: number,
    ): Promise<Post | null> {
        return this.prisma.post.findUnique({
            where: { id },
            include: {
                author: true
            }
        });
    }

Es gibt unzählige Query Optionen, die verwendet werden können um nach bestimmten Daten zu suchen, sortieren, filtern etc. Siehe https://www.prisma.io/docs/orm/prisma-client/queries.

4. Endpoints definieren

In den Controllern definiert man dann seine Endpoints und ruft die Methoden des spezifischen Services auf.

import { Body, Controller, Get, Post } from '@nestjs/common';
import { UserService } from './user.service';
import { User } from '@prisma/client';

@Controller('user')
export class UserController {
    constructor(
        private readonly userService: UserService,
    ) { }

    @Post()
    async createUser(
        @Body() userData: { username: string; },
    ): Promise<User> {
        return this.userService.createUser(userData);
    }

    @Get()
    async getAllUsers(): Promise<Array<User>> {
        return this.userService.findAllUsers();
    }
}

Da dies NestJS spezifisch ist und nichts direkt mit Prisma zu tun hat, wird darauf hier nicht näher eingegangen.

Mit npm run start:dev kann die Applikation gestartet werden.

Fazit

Prisma ORM vereinfacht den Umgang mit der Datenbank erheblich und ist leicht zu erlernen. Im Vergleich zu anderen ORMs wie zum Beipsiel TypeORM werden die Models genau in einem File, dem Prisma Schema, definiert und alles andere wird basierend darauf generiert. Bei TypeORM hingegen definiert man zuerst die Entity-Klassen in mehreren Dateien und versieht die enthaltenen Properties mit Decoratorn, woraufhin TypeORM diese in Datenbank Informationen verwandelt. Prisma ORM unterstützt automatische Datenbank-Migrationen, ohne eigene Befehle im package.json ergänzen zu müssen. Außerdem sind die automatisch generierten Types sehr praktisch und allgemein ist die Typsicherheit höher (z.B. bei den Relationen und beim Filtern), wodurch Fehler bereits zur Kompilierzeit erkannt werden. Und was dabei aber nie verloren geht, sind die Personalisierungsmöglichkeiten bei den Queries. Bei sehr komplexen Abfrageszenarien bietet TypeORM mit dem QueryBuilder wiederum Unterstützung bei Raw-SQL-Abfragen.

Die Wahl eines ORMs hängt somit unter anderem davon ab, wie man sein Schema definieren und verwalten möchte und wie feingranular die Kontrolle über Datenbankabfragen sein muss. Hier spielen aber vor allem auch persönliche Präferenzen eine große Rolle.

Quellen

https://www.prisma.io/docs/orm/overview/prisma-in-your-stack/is-prisma-an-orm

https://medium.com/@binayakgourishankar/getting-started-with-prisma-orm-89c2fcda5026

https://docs.nestjs.com/recipes/prisma

https://dev.to/afl_ext/prisma-vs-typeorm-description-and-comparison-4bob

https://www.prisma.io/docs/orm/overview/databases

https://www.prisma.io/docs/orm/more/comparisons/prisma-and-typeorm

https://spin.atomicobject.com/prisma-vs-typeorm/

Logo vom Beitragsbild

https://github.com/prisma/presskit

The post Prisma ORM: Ein Überblick über die moderne ORM-Lösung für TypeScript und Node.js appeared first on Mobile USTP MKL.

ABSTRACT

Manipulative Designstrategien, bekannt als Dark oder Deceptive Patterns, finden häufig Verwendung in digitalen Medien, um Nutzer*innen zu unbewussten Entscheidungen zu verleiten. Ziel des Artikels ist zu erforschen, inwiefern die verschiedenen Typen dieser Muster in bekannten mobilen Applikationen zum Einsatz kommen und welche Auswirkungen sie allgemein auf das Nutzungsverhalten haben. Die Ergebnisse zeigen, dass diese jedenfalls einen Einfluss auf die Nutzer*innen haben, die diese Strategien wiederum nicht erkennen. In der Praxis treten die verschiedenen Muster, zu denen Nagging, Obstruction, Sneaking, Interface Interference und Forced Action zählen, oft in Kombination miteinander auf. In den Bereichen Bildung, soziale Netzwerke und E-Commerce stößt man vor allem auf visuell hervorgehobene Optionen, zu denen Nutzer*innen tendieren sollen, oder Maßnahmen, die die Löschung des Accounts oder die Kündigung des Abonnements erschweren.

1 Einleitung

In der digitalen Welt von heute spielen mobile Anwendungen eine zentrale Rolle im Alltag vieler Menschen. Gleichzeitig wächst die Zahl an Strategien, die nicht darauf abzielen, den Nutzer*innen einen Mehrwert zu bieten, sondern sie gezielt zu täuschen oder zu manipulieren. Derartige manipulative Designstrategien werden als Deceptive Patterns (oder auch Dark Patterns) bezeichnet. Sie nutzen irreführende Gestaltungselemente, Verschleierung und psychologische Schwächen, um zu Entscheidungen zu verleiten, die im Interesse der Betreiber und nicht der Nutzer*innen sind (Brignull, 2023; Gray et al., 2018).

Ziel dieses Artikels ist aufzuzeigen, welche verschiedenen Deceptive Patterns existieren und wie diese in der Praxis verwendet werden, um so ein Bewusstsein für die versteckten Beeinflussungs-techniken zu schaffen. Zunächst wird definiert, was Deceptive Patterns sind und welche verschiedenen Typen existieren, beispielsweise Roach Motel oder Forced Continuity. Anschließend werden die drei Apps Duolingo, Instagram und Amazon auf Grundlage von einschlägiger Literatur und eigenen Beobachtungen analysiert, um die Verbreitung solcher Muster in den Bereichen Bildung, soziale Netzwerke und E-Commerce zu beleuchten. Zuletzt werden die Wirkung und Erkennung von Deceptive Patterns angeschnitten.

2 Definition

2010 definierte Brignull (2023) den Begriff Dark Pattern. Darunter versteht man, dass Nutzer*innen durch bestimmte Tricks im User Interface zu Interaktionen und Handlungen bewegt werden, die nicht in ihrem Interesse sind. Beispielsweise werden sie zum Abschluss eines Abonnements verführt oder ihnen wird mehrmals die Möglichkeit von In-App-Käufen angeboten. (Brignull, 2023; Gray et al., 2018, S. 1). Nun empfindet Brignull diesen Begriff allerdings als veraltet und verwendet in seinen neuesten Werken stattdessen die Bezeichnung Deceptive Pattern (zu Deutsch trügerische Muster), welche eine Kurzform für Deceptive or Manipulative Pattern ist (Brignull, 2023).

3 Arten von Deceptive Patterns

In der Literatur tauchen mehrere Möglichkeiten auf, wie Dark Patterns kategorisiert werden können. Conti und Sobiesk (2010) gehen von elf Kategorien aus, darunter Verwirrung, Ablenkung, Verschleierung, Ausnutzung von Fehlern und Schock, während Brignull et al. (2023) auf ihrer Webseite 16 Arten aufzählen (Confirmshaming, Fake Scarcity, Fake urgency, Hard to cancel etc.). Gray et al. (2018) teilen Deceptive Patterns wiederum in fünf Kategorien ein: Nagging, Obstruction, Sneaking, Interface Interference und Forced Action. Diese Einteilung findet sich öfters in der Literatur und wird als aktuell bezeichnet, weshalb diese auch in diesem Artikel herangezogen wird.

3.1 Nagging

Beim Nagging wird der oder die Nutzer*in bei einer Interaktion einmal oder mehrmals durch eine andere Aufgabe unterbrochen, die nicht mit der Interaktion im Zusammenhang steht. Beispiele hierfür sind Pop-Ups oder ablenkende Audiosignale, wodurch die Aufmerksamkeit in eine andere Richtung gelenkt wird (Gray et al., 2018, S. 5).

3.2 Obstruction

Obstruction bedeutet, dass den Nutzer*innen die Durchführbarkeit einer Aufgabe oder Interaktion erschwert wird, um sie davon abzuhalten. Hierbei gibt es drei Unterkategorien (Gray et al., 2018, S. 5-6):

3.2.1 Roach Motel (Kakerlakenfalle). Es ist zwar leicht in eine Situation zu kommen, doch umso schwerer ist es hinauszugelangen. Zum Beispiel ist das Löschen eines Accounts im Vergleich zu dessen Erstellung viel schwieriger oder sogar unmöglich, weil zum Beispiel eine Telefonnummer angerufen werden muss.

3.2.2 Price Comparison Prevention (Verhinderung von Preisvergleichen). Dem oder der Nutzer*in wird der Preisvergleich von Dienstleistungen oder Produkten erschwert.

3.2.3 Intermediate Currency (Zwischenwährung). Hierbei wird mittels echten Geldes eine virtuelle Währung in der Applikation gekauft, die gegen Dienstleistungen oder Waren getauscht werden kann (z.B. In-App-Käufe). Den Nutzer*innen soll somit das Gefühl für den echten Geldwert genommen werden.

3.3 Sneaking

Oftmals werden den Nutzer*innen relevante Informationen verheimlicht, verschleiert oder erst verzögert mitgeteilt, sodass diese veranlasst werden, bestimmte Handlungen auszuführen, die sie mit vollem Wissensstand nicht durchführen würden. Beispielsweise treten unvorhergesehen Kosten auf oder unerwünschte Auswirkungen der Handlung machen sich im Nachhinein bemerkbar. Dies wird unter dem Begriff Sneaking zusammengefasst und dabei unterscheidet man vier verschiedene Arten (Gray et al., 2018, S. 6-7):

3.3.1 Forced Continuity (Erzwungene Kontinuität). Nach dem Ablaufdatum eines zeitlich begrenzten Diensts oder einer kostenlosen Testphase werden dem oder der Nutzer*in Kosten verrechnet. Es wird die Versäumnis ausgenutzt und davon ausgegangen, dass der Service weiterhin oder nun eine gebührenpflichtige Version genutzt werden möchte.

3.3.2 Hidden Costs (Versteckte Kosten). Hierbei werden bestimmte Kosten erst später offengelegt. Eine Dienstleistung oder Ware wird im ersten Moment mit einem speziellen Preis beworben, der sich durch hohe Versandkosten, eine zeitliche Begrenzung oder zusätzliche Gebühren dann allerdings erhöht.

3.3.3 Sneak into Basket (In den Warenkorb schleichen). Es werden Artikel in den Warenkorb gelegt, die dann unwissentlich von den Nutzer*innen gekauft werden. Argumentiert wird, dass die Artikel Vorschläge basierend auf den vorherigen Käufen sind.

3.3.4 Bait and Switch (Lockvogeltaktik). Auf eine bestimmte Handlung des oder der Nutzer*in folgt ein unvorhergesehenes und womöglich unerwünschtes Ereignis, welches nicht den Erwartungen entspricht. Beispielsweise wird beim Klick auf das rote „X“ nicht das Dialogfenster geschlossen, sondern die Webseite der Marke geöffnet.

3.4 Interface Interference

Unter Interface Interference versteht man jegliche Manipulation des User Interfaces (Benutzeroberfläche), sodass bestimmte Interaktionen wahrscheinlicher auftreten als andere. Dabei soll der oder die Nutzer*in verwirrt werden und die Auffindbarkeit von gewissen Interaktionsmöglichkeiten eingeschränkt werden. Diese Täuschungen lassen sich in drei Kategorien einteilen (Gray et al., 2018, S. 7-8):

3.4.1 Hidden Information (Versteckte Informationen). Den Nutzer*innen werden wichtige Handlungsmöglichkeiten verschwiegen, indem sie schwer oder nicht sofort zugänglich gemacht werden. Ziel ist, diese irrelevant erscheinen zu lassen. Die Informationen oder Optionen können sich beispielsweise im Kleingedruckten, in Form eines verfärbten Texts oder in den AGBs verstecken.

3.4.2 Preselection (Vorauswahl). Hierbei wird eine Option vorausgewählt, die aus der Sicht des Betreibers die gewünschte Wahl ist, jedoch nicht aus der Sicht der Nutzer*innen. Dadurch akzeptieren sie diese Standardoption eher, denn sie denken, dass in ihrem Interesse gehandelt wird.

3.4.3 Aesthetic Manipulation (Ästhetische Manipulation). Durch gewisse Designentscheidungen wird die Aufmerksamkeit der Nutzer*innen in eine bestimmte Richtung gelenkt, sodass sie davon überzeugt sind oder von anderen Informationen abgelenkt werden. Innerhalb dieser Kategorie gibt es vier genauere Unterteilungen (Gray et al., 2018, S. 7-8):

3.5 Forced Action

Die letzte Kategorie an Deceptive Patterns umfasst Aktionen, die der oder die Nutzer*in ausführen muss, um den Zugriff zu speziellen Funktionen zu erhalten oder aufrechtzuerhalten. Diese können als letzter Schritt eines Vorgangs oder als vorteilhafte Option getarnt sein. Hierbei wird nochmal zwischen drei verschiedene Arten unterschieden (Gray et al., 2018, S. 8):

3.5.1 Social Pyramid (Soziale Pyramide). Der oder die Nutzer*in muss weitere Personen einladen, ebenfalls die Applikation zu nutzen, um Vorteile zu erhalten oder exklusive Funktionen nutzen zu können. Häufig sieht man dieses Muster in Online-Spielen oder sozialen Medien.

3.5.2 Privacy Zuckering. Darunter fallen verwirrende Privatsphäre-Einstellungen, wodurch die Nutzer*innen mehr Informationen von sich preisgeben, als sie eigentlich möchten. Ein Beispiel dafür ist der in den AGBs oder Datenschutzrichtlinien verankerte Verkauf von Nutzerdaten an Dritte.

3.5.3 Gamification. Allgemein versteht man unter Gamification, dass Elemente aus Videospielen außerhalb des spielerischen Kontexts verwendet werden, um das Nutzungserlebnis zu verbessern (Deterding et al., 2011). Zu dieser Untergruppe von Deceptive Patterns zählen Situationen, in der sich wiederholende, meist unerwünschte Aufgaben erledigt werden müssen, um sich bestimmte Aspekte des Services zu verdienen. Oftmals können In-App-Käufe genutzt werden, um dies zu beschleunigen (Gray et al., 2018, S. 8).

4 Deceptive Patterns in mobilen Applikationen

Di Geronimo et al. (2020) untersuchten 240 kostenlose Apps aus den acht beliebtesten Kategorien aus dem Google Play Store, darunter Amazon, Netflix, Facebook und Spotify. Dabei fanden sie heraus, dass 95% der Apps mindestens ein Deceptive Pattern enthalten. Insgesamt wurden bei der Analyse 1.787 Deceptive Patterns gefunden, was bedeutet, dass eine App durchschnittlich sieben verschiedene Arten verwendet. Die häufigsten Strategien sind Nagging, False Hierarchy und Preselection (Di Geronimo et al., 2020). In den folgenden Unterkapiteln werden beispielhaft Apps aus drei Kategorien angeführt und beschrieben, wie diese Deceptive Patterns verwenden.

4.1 Duolingo – Bildung

Duolingo ist eine beliebte gamifizierte Sprachlern-App, bei der Vokabel und Grammatik in immer schwieriger werdenden Lektionen erlernt werden. Wird eine Frage falsch beantwortet, so verliert der oder die Nutzer*in ein Herz. Sind alle Herzen verbraucht, so muss er oder sie einen bestimmten Zeitraum abwarten oder kann durch In-App-Käufe die Herzen wieder auffüllen. Dabei wird eine virtuelle Währung namens „Gems“ verwendet, mit denen Power-Ups und Herzen erkauft werden können, sodass die Nutzer*innen das Gefühl für den tatsächlichen Geldwert verlieren (Intermediate Currency). Das Forced Action Deceptive Pattern zeigt sich durch die Möglichkeit, ein Werbevideo anzuschauen, um eine Truhe mit Gems zu erhalten (Peter, 2023). Wird die App für mindestens zehn Minuten verwendet, so fallen noch weitere Muster auf. Es werden wiederholt für mehrere Sekunden andauernde Werbevideos oder interaktive Anzeigen geschaltet (Nagging und Disguised Ad), wobei der oder die Nutzer*in bei einer Interaktion unerwarteterweise zum App Store geleitet wird (Bait and Switch). Außerdem kann ein kostenpflichtiges Abonnement („Super Duolingo“) abgeschlossen werden, welches keine Werbung, unbegrenzte Herzen und vieles mehr enthält. Dabei werden vor allem Deceptive Patterns aus der Kategorie Interface Interference genutzt (siehe Abbildung 1). Es wird das Jahres-Einzelabo vorselektiert (Preselection) und es scheint so, als gäbe es nur zwei Möglichkeiten. Hinter dem Button „Alle Abos anzeigen“ versteckt sich allerdings eine dritte Option, die monatlich gezahlt wird (Hidden Information). Allgemein findet man in der App oft visuell hervorgehobene Auswahlmöglichkeiten (siehe Abbildung 1), wodurch der oder die Nutzer*in zu bestimmten Aktionen gedrängt wird (Aesthetic Manipulation: Toying with Emotion und False Hierarchy). Was das Abonnement betrifft, so wird es nach der kostenlosen Testphase automatisch verlängert (Forced Continuity).

4.2 Instagram – Soziale Netzwerke

In sozialen Netzwerken wie Instagram lassen sich mehrere Deceptive Patterns finden. Ein Account lässt sich leicht erstellen, die Funktion, diesen wieder zu löschen, ist allerdings versteckt. Diese Aktion wird den Nutzer*innen somit erschwert, was auf die Verwendung des Roach Motels hindeutet (Di Geronimo et al., 2020, S. 6). Oftmals wird bei Dialogfenstern eine von zwei Optionen hervorgehoben (z.B. der Button zum Erlauben des Zugriffs auf die Kontakte), was dem Interface Interference entspricht. Weiters wird das Privacy Zuckering angewendet (Mildner, Freye, et al., 2023, S. 2367). Laut Mildner, Savino et al. (2023) lassen sich alle fünf Arten aus Kapitel 3 in der App finden. Auch andere soziale Netzwerke wie Facebook, X und TikTok verwenden vor allem Deceptive Patterns wie Interface Interference, Obstruction und Privacy Zuckering (Mildner, Freye, et al., 2023, S. 2366).

4.3 Amazon – E-Commerce

Das Roach Motel Deceptive Pattern wird auch von der beliebten E-Commerce-Plattform Amazon genutzt. Die Kündigung einer Prime-Mitgliedschaft ist im Vergleich zu dessen Abschluss schwieriger aufzufinden und durchzuführen (Di Geronimo et al., 2020, S. 6). Weiters spielt Amazon mit den Gefühlen der Nutzer*innen, indem ihnen klargemacht wird, dass sie sofort alle Vorteile verlieren würden, und zählt diese erneut auf (Toying with Emotion) (siehe Abbildung 2). Allgemein werden bestimmte Farben und Formulierungen genutzt, um die Nutzer*innen davon abzuhalten die Mitgliedschaft zu kündigen (Aesthetic Manipulation) (Verbraucherzentrale Bundesverband e.V., 2022, S. 2-3). Aesthetic Manipulation wird auch, wie bei vielen anderen Webseiten und Applikationen, im Cookie-Banner verwendet (siehe Abbildung 2).

5 Wirkung und Erkennung

Luguri und Strahilevitz (2021) erforschten die Wirkung von milden und aggressiven Deceptive Patterns. Die Ergebnisse zeigen, dass beide einen Einfluss auf das Verhalten der Nutzer*innen haben.  Die Wahrscheinlichkeit, sich für einen bedenklichen Service zu registrieren, war in dem durchgeführten Experiment bei den Nutzer*innen, die mit milden Deceptive Patterns konfrontiert wurden, doppelt und bei denen, die aggressiven Deceptive Patterns ausgesetzt wurden, viermal so hoch wie bei der Kontrollgruppe. Die aggressiven Formen wurden allerdings auch als störender empfunden als die milderen. Zu den Deceptive Patterns, die am meisten Wirkung zeigten und die Nutzer*innen manipulierten bestimmte Entscheidungen zu treffen, die nicht in ihrem Interesse sind, zählen Hidden Information, Trick Questions und Obstruction.

Di Geronimo et al. (2020) untersuchten mittels einer Online-Umfrage die Erkennung von fünf bzw. sechs Deceptive Patterns: Nagging, Intermediate Currency, Sneak into Basket in Kombi-nation mit Preselection, False Hierarchy und Forced Action. Dabei stellten sie fest, dass Nutzer*innen diese Muster oft nicht erkennen, und sprechen deshalb von einer DP-Blindheit (DP-blindness).

FAZIT

Es gibt viele verschiedene Arten von Deceptive Patterns, die häufig in mobilen Applikationen zum Einsatz kommen. 95% der Apps im Google Play Store nutzen mindestens eines dieser Muster. Diese können in fünf Kategorien eingeteilt werden, nämlich Nagging, Obstruction, Sneaking, Interface Interference und Forced Action. Viele davon finden auch in den Bereichen Bildung, soziale Netzwerke und E-Commerce Verwendung. In der gamifizierten Sprachlern-App Duolingo findet man beispielsweise In-App-Käufe mit einer eigenen virtuellen Währung, freiwillige und unfreiwillige Werbe-Unterbrechungen und visuell hervorgehobene Buttons. Bei der Bewerbung des kostenpflichtigen Abonnements wird wiederum eine Option vorselektiert und andere versteckt. Sowohl hier als auch bei Amazon wird das Abo bzw. die Mitgliedschaft nach Ablauf verlängert, was den Betreibern zugutekommt. Die Kündigung der Mitgliedschaft bzw. die Löschung des Accounts wird den Nutzer*innen auf Plattformen wie Amazon oder Instagram ebenso erschwert. Allgemein kann gesagt werden, dass viele der Deceptive Patterns in gewissen Kombinationen auftreten und dass vor allem oft Aesthetic Manipulation genutzt wird, genauer gesagt Toying with Emotion und False Hierarchy. Während die einen Deceptive Patterns als störend empfunden werden, fallen andere den Nutzer*innen gar nicht auf. Jedenfalls haben sie einen gewissen Einfluss auf ihre Handlungsentscheidungen, weshalb es umso interessanter ist, spezifische Apps hinsichtlich der Verwendung und Wirkung solcher Muster noch genauer zu untersuchen. Hinzu kommen Fragen nach ethischen Grundsetzen und der Erkennung solcher Muster, mit denen man sich beschäftigen muss, wenn die Häufigkeit von Deceptive Patterns in Zukunft weiter zunimmt.

LITERATUR

Brignull, H. (2023). Deceptive Patterns: Exposing the Tricks Tech Companies Use to Control You. Testimonium Ltd.

Brignull, H., Leiser, M., Santos, C., & Doshi, K. (2023, 25. April). Deceptive patterns – user interfaces designed to trick you. https://www.deceptive.design/ (Abgerufen am 23.11.2024)

Conti, G., & Sobiesk, E. (2010). Malicious interface design: Exploiting the user. Proceedings of the 19th international conference on World wide web, 271–280. https://doi.org/10.1145/1772690.1772719

Deterding, S., Dixon, D., Khaled, R., & Nacke, L. (2011). From game design elements to gamefulness: Defining „gamification“. Proceedings of the 15th International Academic MindTrek Conference: Envisioning Future Media Environments, 9–15. https://doi.org/10.1145/2181037.2181040

Di Geronimo, L., Braz, L., Fregnan, E., Palomba, F., & Bacchelli, A. (2020). UI Dark Patterns and Where to Find Them: A Study on Mobile Applications and User Perception. Proceedings of the 2020 CHI Conference on Human Factors in Computing Systems, 1–14. https://doi.org/10.1145/3313831.3376600

Gray, C. M., Kou, Y., Battles, B., Hoggatt, J., & Toombs, A. L. (2018). The Dark (Patterns) Side of UX Design. Proceedings of the 2018 CHI Conference on Human Factors in Computing Systems, 1–14. https://doi.org/10.1145/3173574.3174108

Luguri, J., & Strahilevitz, L. J. (2021). Shining a Light on Dark Patterns. Journal of Legal Analysis, 13(1), 43–109. https://doi.org/10.1093/jla/laaa006

Mildner, T., Freye, M., Savino, G.-L., Doyle, P. R., Cowan, B. R., & Malaka, R. (2023). Defending Against the Dark Arts: Recognising Dark Patterns in Social Media. Proceedings of the 2023 ACM Designing Interactive Systems Conference, 2362–2374. https://doi.org/10.1145/3563657.3595964

Mildner, T., Savino, G.-L., Doyle, P. R., Cowan, B. R., & Malaka, R. (2023). About Engaging and Governing Strategies: A Thematic Analysis of Dark Patterns in Social Networking Services. Proceedings of the 2023 CHI Conference on Human Factors in Computing Systems, 1–15. https://doi.org/10.1145/3544548.3580695

Peter, M. (2023, 6. Februar). Dark Patterns in Popular Mobile Apps. Medium. https://medium.com/@marcpeter1997/dark-patterns-in-popular-mobile-apps-296011029579

Verbraucherzentrale Bundesverband e.V. (2022). Dark Patterns—Manipulatives Design im Internet: Fallsammlung aus dem Verbraucheraufruf „Dark Patterns“ der Marktbeobachtung Digitales (Stand: 09.02.2022). https://www.edpb.europa.eu/system/files/2022-05/2021-02-09_fallsammlung_verbraucheraufruf_dark_patterns.pdf

The post SOTA | Versteckte Beeinflussung: Deceptive Patterns in beliebten mobilen Applikationen appeared first on Mobile USTP MKL.