Hvordan lage en løsning der forelesere kan motta spørsmål fra studenter uten å bytte vindu under presentasjonen?

Slik løser du det

Design en plugin som kommuniserer med en nettside via en unik kode. Studenten sender spørsmål via nettsiden, og plugin-en trigger et varsel direkte i PowerPoint. Alternativt kan man ansette ekstern hjelp via Aneo-midler for å bygge en MVP. La oss forklare hvordan dette henger sammen. En «plugin» (også kalt add-in) er en liten programutvidelse som installeres i et eksisterende program – her PowerPoint – og legger til ny funksjonalitet uten at man bytter program. Microsoft tilbyr et offisielt rammeverk for dette, kalt Office Add-ins, som bygges med vanlige webteknologier (HTML, JavaScript og CSS). Det gjør idéen fullt mulig å realisere. Slik fungerer den foreslåtte arkitekturen i praksis: Foreleseren starter pluginen, som genererer en unik kode (omtrent som koden i Kahoot eller Mentimeter). Studentene går til en nettside, taster inn koden, og kobles dermed til akkurat denne presentasjonen. Når en student sender et spørsmål via nettsiden, lagres det på en server/database, og pluginen henter det og viser et diskret varsel inne i PowerPoint – for eksempel et tall som øker eller en liten notifikasjon. Poenget, og hele verdien, er at foreleseren slipper å bytte vindu midt i presentasjonen, noe som bryter flyten og virker uprofesjonelt. For sanntidsoppdatering kan man bruke teknologi som WebSockets (en metode for løpende toveis kommunikasjon mellom nettside og server) eller enkel periodisk «polling». Det andre rådet handler om gjennomføring: hvis teamet mangler teknisk kapasitet, kan dere ansette ekstern hjelp via Aneo-midler for å bygge en MVP. Aneo-midler er finansiering (fra samarbeidspartneren Aneo) som studentprosjekter hos Spark* kan søke om for å dekke utviklingskostnader. En MVP (Minimum Viable Product) er den enkleste fungerende versjonen som beviser at konseptet virker. Anbefalingen er altså å starte smalt: bygg kun kjernen (kode, spørsmål inn, varsel ut), test den i en ekte forelesning, og utvid etterpå. Vanlig fallgruve er å bygge for mange funksjoner før man har bekreftet at grunnidéen fungerer – hold første versjon så enkel som mulig.