Bokning
Vad en återkommande salsbokning egentligen är
Ni beskriver den som en människa säger det — varannan tisdag till maj. Det som lagras är något annat, och nästan varje överraskning efteråt kommer från glappet mellan de två.
Först: en bokning är inte en lektion
De ligger sida vid sida i samma raster och kommer från motsatta håll. En lektion är ett utdata: den finns för att ett schema byggdes, och den flyttas när schemat byggs om. En bokning är ett indata: någon har beslutat att den här salen är reserverad den här timmen, och ingenting genererar om den.
Den skillnaden är anledningen till att ett salsbokningssystem som bara är en kalender fastskruvad på sidan av ett schema orsakar problem inom en termin. De två måste leva på samma ställe, eftersom de konkurrerar om samma salar — men de är inte samma sorts objekt, och ett system som låtsas annat kommer förr eller senare att generera bort någons tenta.
En bokning kan bli flera, och det är rätt
En upprepad bokning lagras som en rektangel: en följd av undervisningsveckor, gånger en uppsättning veckodagar, vid en tidpunkt. Måndag till fredag i tre veckor är en enda rektangel och en enda rad. Måndag och onsdag är två rektanglar, eftersom en rektangel som täcker måndag till onsdag också skulle boka tisdag — vilket ingen bett om och som någon annan skulle ha velat ha.
Ett klick kan alltså ge tre bokningar, och var och en är sedan en bokning i sin egen rätt: separat synlig, separat redigerbar, separat avbokningsbar. Det är värt att veta innan ni avbokar den bokningen och finner att två tredjedelar av den fortfarande finns kvar.
Den ärliga versionen av detta, som leverantörer sällan själva berättar: det finns oftast inget som heter en serie. Fråga vad som händer när någon tar bort ett tillfälle ur en bokning på tolv veckor, och fråga sedan vad som händer när de vill flytta alla tolv.
Mönstren, och fällan i vart och ett
| Mönster | Vad det betyder | Fällan |
|---|---|---|
| Varje vecka | Samma veckodagar varje undervisningsvecka i intervallet. | Läsvecka. Ett mönster som löper över en bokar rakt igenom den om inte veckor utan undervisning undantas. |
| Varannan vecka | Varannan undervisningsvecka, räknat från intervallets första vecka. | Räknat från INTERVALLET, inte från vecka 1 på året. Två bokningar varannan vecka som startar en vecka isär krockar aldrig och sammanfaller aldrig. |
| Samma veckodag varje månad | Till exempel tredje tisdagen. | Ordningstalet tas oftast från startdatumet och efterfrågas aldrig. En bokning som startar sista tisdagen i månaden betyder SISTA — inte femte, och inte tredje. |
| Samma datum varje månad | Den 15:e, den 31:a. | En månad som är för kort för datumet bör HOPPAS ÖVER, inte vikas tillbaka. Om ert system bokar den 30 april åt en 31:a fattar det ett beslut det inte blev ombett att fatta. |
Tiderna landar på lärosätets egna linjer
Undervisningstimmar är inte ett fritt raster. Ett lärosäte kör perioder — 08:00 till 09:30, eller sex femtiominutersblock med tio minuters mellanrum — och en bokning måste börja där en period börjar och sluta där en slutar, annars slutar rastret betyda något.
Ett system som i det tysta avrundar 08:15 till 08:00 lagrar något som personen inte angett. Det bättre beteendet är att avvisa det och tala om vilka tider som är tillgängliga, vilket är samma princip som överallt annars här: rätta inte någon i det tysta, tala om vad som är i vägen.
En närliggande detalj som drabbar varje ny integration: efterföljande är inte överlappande. Ett pass som slutar 09:00 och ett som börjar 09:00 krockar inte. Om ert system rapporterar att de gör det är hälften av era salar obokningsbara utan anledning.
En krockkontroll måste se det som allmänheten inte kan
Det här är den del som oftast är i det tysta fel.
När ett bokningsformulär frågar är den här salen ledig måste det räkna allt som faktiskt håller salen: lektioner, andras bokningar och bokningar som fortfarande väntar på godkännande. En sal som hålls av en begäran som ingen godkänt ännu är inte ledig; den är väntande, och att erbjuda den åt någon annan skapar just den dispyt som godkännandesteget fanns för att förhindra.
Detsamma gäller salar som ett lärosäte inte publicerar. Ett institutionsmötesrum som hålls borta från den publika listan är ändå upptaget när det är upptaget.
Tillgänglighet är alltså ett faktum om salen, inte en vy av schemat — vilket är precis varför den som frågar bör behöva vara inloggad. En kontroll som är öppen för vem som helst ljuger antingen om väntande bokningar eller läcker deras titlar.
Vem som får boka vad, och vad en krock ska kosta
- Salsbehörigheter hör till salen, inte till skärmen. Vissa lärosäten låter vem som helst boka ett seminarierum och ingen boka föreläsningssalen utan att fråga. Den regeln måste upprätthållas där bokningen skrivs, annars är den ett förslag — boka en tillåten sal, redigera den sedan till en otillåten, och regeln är kringgången.
- En krock bör avvisas med skälen bifogade, inte med ett platt nej: vilka datum, och om det var salen, läraren eller gruppen som var upptagen. Två av de tre går ofta att åtgärda genom att flytta en vecka.
- Och en planerare som menar allvar bör kunna boka över den. Medveten dubbelbokning är normalt — en sal delad mellan två grupper, en föreläsning som med flit överlappar ett drop-in-pass. Det viktiga är att systemet registrerar att krocken var ett beslut, så att den som ser den i mars vet att den inte var en olyckshändelse.
- Godkännande är ett tillstånd, inte en separat kö. En bokning som väntar på godkännande bör redan vara synlig för dem som behöver planera runt den.
Var detta finns i Wise Timetable
Bokningar ligger i samma dokument som schemat, så tillgänglighet beräknas mot allt på en gång i stället för mot en andra kalender som måste stämmas av. Salsbokningssystemet täcker vad ett schemaläggningskansli ser; webbbokningsmodulen är självbetjäningssidan, för lärosäten som vill att personalen bokar sina egna salar utan att gå via kansliet.
För den som bygger en egen bokningsskärm är hela ytan dokumenterad i den publika REST API-handboken — inklusive tillgänglighetskontrollen, som returnerar de krockande datumen och de närmaste lediga alternativen i stället för ett ja eller ett nej.
Vill ni se hur det fungerar?
Boka en onlinepresentation på 45 minuter, så går vi igenom den mot ert eget lärosätes schemaläggningsproblem.