...
TÄHÄN KAIVATAAN ESIMERKKEJÄ KUKA TEKEE, MISSÄ JÄRJESTYKSESSÄ ja MITEN (TiinaK: kuvattu musiikin osalta osittain keskitetyssä mallissa, pop/jazzmusiikin osalta hajautetussa mallissa).
Muita malleja????
Jaakko Rannilan kommentit:
Lukujärjestystyöryhmän kokouksessa esitetty seuraavaa:
Yksilöopetuksessa lähdetään toteutusten joukon suunnnittelussa liikkeelle työ- ja lukujärjestyssuunnittelusta. Työ- ja lukujärjestyssuunnittelussa pitää pystyä tekemään varauksia kalenteriin ja tiloihin, ilman, että niihin on liitettynä vielä mitään toteutusta. Toteutusten joukko syntyy vasta myöhemmässä vaiheessa. Tällöin lukujärjestyksen suunnitteluvälineeseen pitää pystyä tekemään varauksia/opetustapahtumia, joita ei ole vielä kiinnitetty mihinkään ryhmään tai toteutukseen. Varauksen/opetustapahtuman lisätiedoissa pitää kuitenkin pystyä kertomaan, mistä opintojaksosta on kyse, jotta tekijä pystyy toteutusjoukon luomisen jälkeen kiinnittämään oikeat toteutukset aikaisemmin tehtyihin varauksiin.
3.2.2 Sijoittelua alustava ryhmittely (mallipohjat tai "blokit")
Osa keskitetyn mallin suunnittelijoista aloittaa suunnittelun tekemällä eräänlaisia mallipohjia (Untiksessa blokit), joihin kerätään sijoitteluun liittyviä, aiemmin käsiteltyjä alkutietoja tarkempia lähtötietoja. Näitä lähtötietoja hyödyntämällä luodaan eräänlaisia varausryppäitä (kuten toistuva varaus). Tiedot muistuttavat hieman vuosisuunnittelun puolelta tuttuja tehtävärivejä. Mallipohjien tarkoituksena on kasata yksittäiset varaukset vähän suurempiin ryppäisiin joita on helpompi siirrellä kokonaisuuten sijoittelunäkymissä kuin että aina siirrettäisin jokaista yksittäistä varausta erikseen. Mallipohjiin voidaan liittää esim.
- Alkupvm (tehtävälle/toistuvalle varaukselle asetettava päivämääräväli)
- Loppupvm
- Sallitut viikonpäivät (ma-su)
- Toteutus, jonka päivittämällä myös seuraavat kentät täydentyvät automaattisesti
- Aihe (toteutuksen nimi)
- Opettaja(t)
- Ryhmä(t)
- Pienryhmä(t)
- Kesto (esim. jos halutaan näistä tuplatunteja niin voidaan laittaa esim 90min)
- Tila(t)
- Opetusväline(et)
Mallipohjan tekeminen saattaa lähteä liikkeelle esim. ihan vain ryhmätiedon lisäämisestä ja niitä aletaan sijoittelemaan kalenteriin, myöhemmin voidaan liittää toteutus, jolloin kentät täydentyvät. Samoin tämä malli mahdollistaa sen, että opetus suunnitellaan melkein valmiiksi ilman tiloja (sijoitellaan toteutukset, ryhmät, opettajat jne) ja vasta lopuksi etsitään opetukselle tilat. Mallipohjien suunnittelua varten tarvitaan oma näkymä, joka voi muistuttaa listanäkymiä.
3.2.
...
3 Priorisointi / sijoittelujärjestys
Kertokaa minkälaisista lähtökohdista joudutaan lähteä sijoittelemaa, mitkä ovat niitä kriteereitä mikä tekee joistain opintojen sijoitteluista "vaikeampia"
...
Toteutuksien listanäkymä antaa suunnittelijalle kokonaiskuvan toteutuksista, opettajista tai ryhmistä, joille suunnittelija rakentaa lukujärjestystä.
!! Heikki pystytkö laittamaan jonkun screenshotin Untiksesta tuohon esimerkiksi -Mika !!
Kommenttia edelliseen (Heikki Visti): En oikein tiedä minkä välineen näkymiä edellä tarkoitetaan. Oletan nyt, että se on se väline, jota lukujärjestysten laatija käyttää, eli joka esimerkiksi allekirjoittaneelle tällä hetkellä on Untis. Siinä työssä tärkein ja mielestäni melkein ainoa tarvittava listamuotoinen näkymä on näkymä opetusjaksoista. Vastaa Untiksen Oppitunnit-näkymää. Siinä pitäisi olla sarakkeet ainakin seuraaville asioille: viikkotuntimäärä, opettaja(t), ryhmä(t), tila, toteutus, oppiaineen nimi, alkamispäivämäärä, päättymispäivämäärä, lisätietoa. Joku muu keksii ehkä lisää. Kaikissa kohdissa ei välttämättä tarvitse mitään olla. Yksi rivi yhtä opetusjaksoa kohti. Rivejä pitää voida vaivattomasti lisätä ja niillä olevia tietoja pitää voida suoraan muokata ja kopioida. Listanäkymä pitää voida hakea ensisijaisesti ryhmätunnuksella ja opettajatunnuksella, lisäksi myös opintojakson tunnuksella (ehkä tässä hyödyllisempi kuin yksittäisen toteutuksen tunnus) ja miksei myös tilan tunnuksella. Tästä listanäkymästä pitää suoraan voida laittaa tavaraa lukujärjestykseen. Ihan suoraan hiirellä kalenteriin. Ja pitää voida liikutella siellä paikasta toiseen. Ja nimenomaan kalenteriin, ei tilaan. Tilatietoa ei edes tarvitse siinä vaiheessa olla. Näitä opetusjaksoja esimerkiksi minulle tulee tuhansia. Jos kaikkia kalenterivarauksia varten pitää jotain kellonaikoja näpytellä, niin siinä nyt varmasti menee ikä ja terveys.
(Kommentti TiinaK:lta 24.11.2010: erittäin kannatettavia näkökohtia! Musiikeissa opetustapahtumia pitäisi voida liittää listasta myös tilalukujärjestykseen)
Kyllä tähän näkymään jonkinlaiset pohjatiedot voi tulla suoraan jostakin suunnitteluvälineestä. Lukujärjestysten laatijan pitää niitä tietoja voida vaivattomasti muokata. Ei kaikkea tietoa tarvitse tähän tunkea, kyllä esimerkiksi opetusjärjestelyjä koskevat tiedot voi olla kerrottu jossain muualla. Olettakaamme esimerkiksi, että periodilla 3 on toteutus XXYYZZ/2000, johon on laitettu opettajat Kalle Karttakeppi ja Lasse Laskutikku ja johon on liitetty ryhmät Lu1 ja Lu2. Tästä toteutuksesta voisi suunnitteluväline antaa kaksi riviä, joissa kummassakin on sama toteutus ja opintojakson nimi sekä ryhmät-kohdassa molemmat ryhmät Lu1,Lu2. Toisella rivillä on opettaja Karttakeppi ja toisella opettaja Laskutikku. Toteutus-kohdassa voi olla joku hipsukka, josta pääsee katsomaan toteutuksen tarkempia tietoja. Siellä voi olla esimerkiksi kerrottu, että Kalle Karttakeppi pitää 4 viikkotuntia luentoja yhdessä kummallekin ryhmälle jossakin luokkahuoneessa ja Lasse Laskutikku 3 viikkotuntia labroja tilassa Lab1 kummallekin ryhmälle erikseen. Lukujärjestysten laatijan pitää sitten voida täydentää ja muokata näitä tietoja vaivattomasti.
Minulle tulee tämän tapaisia ajatuksia mieleen omien tarpeitteni ja tähänastisten kokemusteni perusteella, joku muu voi keksiä jotain parempaa tai ihan toisenlaista, kun on erilaiset käytännöt. Pitää kyllä miettiä ettei yritetä haukata liian suurta palaa, ei tuollaisen työvälineen rakentaminen ihan helppoa ole. Ainakaan jos siitä halutaan myös käyttökelpoinen.
Kommentteja Riikka 20.9.2010. Eli tässä Heikin versiossa toteutuksen tarkempi tieto tulee lisätietona muusta järjestelmästä. Tällöin tieto pitää purkaa useammaksi tapahtumaksi, jolloin kyseinen tapahtuma muodostaa usean rivin aikataulutettuna kalenteriin. Esimerkiksi Talotekniikan orientoivien opintojen osalta tämä tarkoittaa 16 eri riviä periodilla 1. Toinen ongelma muodostuu intensiiviopetuksesta. Kolmanneksi pitää miettiä kenen vastuulla on tietojen täydennys sillä roolit voivat olla nyt kovin erilaiset. Pelkästään opettajien varaan tätä ei voida jättää tai tietoja ei synny ajoissa.
Mika 20.9 - Tämä näkymä ei ole vielä sijoittelunäkymä. Haluatte siis että voisitte tässä näkymässä täydentää vuosisuunnittelusta tulleita tietoja (jakaa toteutuskohtaisiin aliryhmiin jne?) Mitä nuo 16 riviä tarkoittaa, voitko tarkentaa miten ne eroavat toisistaan (jos kyseessä on yksi toteutus, miksi 16 riviä?)
Heikki 22.9: Vaan mikä näkymä? Yritän vielä selventää ajatuksiani lähettämällä Mikalle yhtäältä Toisusta (vihreästä) otetun Excel-tulosteen ryhmän K10A kaikista toteutuksista ja toisaalta Untiksesta otetun tulosteen ryhmän K10A kaikista oppitunneista , kumpikin koko lukuvuodelta 2010-2011. En niitä saa tähän suoraan liitettyä, lähetän sähköpostin liitteenä, Mika voi tallentaa ne sopivaan paikkaan muidenkin tarkasteltaviksi. Toisusta otettuun tulosteeseen tulee yksi rivi jokaista toteutukseen laitettua tehtävää kohti. (Tästä seuraa myös se, että jos tehtävät on unohdettu laittaa, kuten joskus on käynyt, niin en näe tätä kautta koko toteutusta laisinkaan, siksi minun pitäisi päästä myös vuosisuunnittelun puolelle.) Sarakkeita tässä on pilvin pimein enkä kaikkien sisältöä ymmärrä eikä kaikilla ole minulle mitään merkitystä. Siellä on muun muassa sinänsä tärkeä sarake h/vko, jossa kuitenkin on ihan kummallisia lukuja joilla ei todellisen lukujärjestykseen tulevan viikkotuntimäärän kanssa ole mitään tekemistä. Se ilmeisesti jakaa vuosisuunnittelusta tulevan lähiopetustuntimäärän periodi(e)n viikkojen määrällä. Mutta kun esimerkiksi periodi 3 on 1.1. - 11.3. ja periodi 4 on 14.3. - 31.7. eikä kesä-heinäkuun viikoilla mitään opeteta, niin ei tuosta voikaan tulla oikeita tuntimääriä. Sarakkeeseen Tiedoksi muille suunnittelijoille on laitettu opetusjärjestelyjä koskevia lisätietoja. Tähän tietoja on laitettu kohtalaisesti, joihinkin niitä laitetaan yksityiskohtaisemmin, joihinkin ei juuri mitään. Saan opettajilta myös erikseen sähköpostitse opetusjärjestelyjä ja opetusaikoja koskevia toiveita. Näiden pohjalta teen Untikseen oppituntitiedot. Esimerkiksi toteutuksessa TM00AA03/2008 (Matematiikka 1) on vain yksi tehtävä ja Toisu näyttää siitä yhden rivin. Opettajan toive oli, että varataan 6 tuntia/viikko. Se toive tuli muuta kautta. Lukujärjestysteknisesti osoittautui parhaaksi tehdä kolme kaksoistuntia. Ne näkyvät Untiksesta oppituntinumeroina 5015, 3020 ja 3024. Tässä ei siis ole mitään kellonaikoja eikä tarkkoja päivämääriä, ainoastaan opetusjakson alkamis- ja päättymispäivämäärät. Kukin näistä kolmesta oppitunnista voidaan sijoittaa suoraan kalenteriin haluttuun kohtaan viikkoon. Ja ilman että siinä edes on kaikkia tietoja, edes tilaa ei tarvitse olla merkitty. Kalenterivaraus tulee kaikille viikoille alkamis- ja päättymispäivän välissä kaikille niille objekteille (tila, opettaja, ryhmä), joista tieto on olemassa. Tämän kaltaista oppituntinäkymää minä perään, se on se millä lukujärjestysten laatija operoi. Saa systeemi sallia senkin, että tiedot voivat tulla suunnitteluvälineestä tähän ihan yksityiskohtaisesti eikä tarvitse tehdä mitään muuta kuin laittaa tunteja kalenteriin. En kyllä usko että se on edes teoriassa mahdollista. Enhän edes minä voinut etukäteen tietää kannattiko tuo Matematiikka 1 jakaa kolmeksi kaksoistunniksi vaiko kahdeksi kolmoistunniksi. Eikä sopivia luokkatiloja voi mitenkään etukäteen lopullisesti merkitä.
Mika 22.9 Jep, jos ymmärsin oikein niin tarvitaan suunnittelijalle oma muistilista mihin noita voi jaotella toteutuskohtaisesti. Lisäksi tarvitaan toteutuslistauksia yms.. Näiden lisäksi tarvitaan vielä tilavarauslistauksia (käytetään sitten kun varauksia on jo tehty) jossa pystyään tekemään muutoksia yksittäisiin toteutustapahtumiin tai moneen tapahtumaan kerralla.. Eli nuo ensimmäiset listaukset ovat informatiivisia listoja ja jälkimmäisessä voisi suoraan käsitellä myös tilavarauksia. Olenko yhtään oikeilla jäljillä?
Miten järjestelmä tuo tiettäväksi ketjun alkupäässä syntyneet muutokset sen jälkeen kun lukujärjestyksen laatija on vienyt tarkemmat tiedot järjestelmään? Nyt ongelmana on se että tietoa muutoksesta ei synny kun järjestelmässä ei ole logia tällaiselle. Tähän pitäisi saada jokin automaattinen huomautus ja kommentti miten tieto on muuttunut edelliseen vaiheeseen verraten.
Heikki 23.9: Minun nähdäkseni lukujärjestysten laatija tarvitsee juuri nuo kaksi listausta jotka edellä on mainittu. Tai niitä vastaavat, ei niiden ulkonäöt juuri tuollaiset tarvitse olla. Vuosisuunnittelun puolelta pitää tulla lista toteutuksista. Eli se mikä vastaa tuota edellä mainittua Toisusta saatavaa. Toteutukset pitää voida rajata tietylle aikavälille ja pitää voida hakea ryhmätunnuksella tiettyä ryhmää tai tiettyja ryhmiä koskevat, opettajatunnuksella tiettyä opettajaa tai tiettyjä opettajia koskevat, opintojakson koodin perusteella tai yksittäinen toteutus. Varmaan joissakin tapauksissa on syytä voida hakea myös tilan tunnuksella, mikäli opetus pitää olla tietyssä tilassa ja tila jo suunnitteluvaiheessa merkitään. Ja haku pitää voida tehdä niin vähillä hiiren klinksautuksilla kuin vain mahdollista. Ja haki listan millä kriteerillä tahansa, niin se voi periaatteessa näyttää ihan samanlaiselta. Tämän listan tietoja ei lukujärjestyssuunnittelija muuttele, sitä editoivat vain suunnittelijat, mahdollisesti myös opettajat omien toteutustensa osalta. En osaa tarkasti sanoa mitä kaikkea tietoa tähän halutaan tunkea, kuitenkin sellaista mikä on järkeenkäypää, nykytoisun kaikista otsikoista minä en ainakaan ymmärrä mitään. Esimerkiksi opettajien aikatoiveiden yms. sijaintipaikkaa voi miettiä.
Sitten on erikseen varsinainen lukujärjestystyökalu eli Untiksen vastine, jossa toteutukset puretaan yksittäisiksi opetustapahtumiksi. Siellä näistä opetustapahtumista syntyy oma lista, joka vastaa tuota Untiksesta saatua, ja jonka tietoja pitää voida hakea samoilla edellä mainituilla kriteereillä. Sitä lukujärjestyssuunnittelijan taas pitää voida muokata hyvin helposti ja vaivattomasti. Pitää voida lisätä, poistaa ja kopioida rivejä ja muuttaa niiden tietoja kuten Excelissä ikään. Niitä pitää voida sijoittaa kalenteriin. Lukujärjestys rakentuu periaatteessa aina tällaisista opetustapahtumista ihan riippumatta siitä tehdäänkö ne keskitetysti tai hajautetusti tai millä työkalulla tai missä yksikössä tahansa, se on kyllä ymmärtääkseni absoluuttinen fakta. Tähän työkaluun voi olla suora tiedonsiirto suunnittelutyökalusta. Se millä tarkkuudella sinne oppituntitietoja tulee, voi riippua siitä miten tarkasti tietoja suunnittelutyökaluun laitetaan. Minimivaatimus on, että kun suunnittelutyökaluun tehdään toteutus, niin lukujärjestystyökaluun tulee tästä automaattisesti ainakin yksi rivi eli yksi oppituntitieto, joka sisältää toteutuksen tunnuksen, oppiaineen nimen, ryhmän tai ryhmät, joita opetus koskee ja opettajan, jos sellainen on tiedossa. Jos opettajia on useita, voi tulla rivi kutakin opettajaa kohti. Voi tulla muitakin tietoja, esimerkiksi viikkotuntimäärä, opetusjakson alkamis- ja päättymispäivä (näiden pitää silloin olla todellisia eikä esimerksi periodien alkamis- ja päättymispäiviä), tila, tietoa ryhmäjaosta tai opetustavasta (esim. teoria/labra) jne, mitä tarpeelliseksi katsotaan. Tätä riviä suunnittelijan tulee voida kopioida ja monistaa vapaasti eli jakaa niin moneksi opetustapahtumaksi kuin on tarpeen. Saa kaikki tulla jo valmiiksi jaoteltuna niin että ei tarvitse muuta kuin laittaa kalenteriin. En kyllä itse näe niin tärkeäksi sitä, että se pitäisi tulla näin valmiina.
Mikan yllä olevaan kysymykseen "Miten järjestelmä tuo tiettäväksi ketjun alkupäässä syntyneet muutokset sen jälkeen kun lukujärjestyksen laatija on vienyt tarkemmat tiedot järjestelmään?" vastaisin, että onhan tässä lukujärjestystyökalussakin tietoja, jotka ovat suunnittelijan vastuulla ja joita lukujärjestysten tekijän ei tarvitse muuttaa. Tällaisia ovat tietysti itse toteutuksen tunnus ja oppiaineen nimi, mutta myös toteutuksen opettajat, kaiketi myös joissain tapauksissa ajoitus ainakin periodin tarkkuudella. Tarkkaa ajoitusta tosin pitää voida muuttaa. Jos näitä tietoja muutetaan toteutuksessa, niin kyllä tiedonsiirto lukujärjestystyökaluun saa säilyä niin, että tiedot muuttuvat automaattisesti myös siellä. Nämä ovat mielestäni tärkeimmät oleellisesti lukujärjestyksiin vaikuttavat muutokset. Otan esimerkin: Ryhmille Lu1 ja Lu2 on tehty aikaisemmassa kommentissa mainittu toteutus XXYYZZ / 2000, opettajina Lasse Laskutikku ja Kalle Karttakeppi, periodilla 3. Minimissään tästä tulee suunnittelutyökaluun kaksi riviä, joista kumpikin sisältää toteutuksen tunnuksen ja oppiaineen nimen (sanokaamme Pontikankeiton perusteet). Toiseen riviin tulee opettaja Laskutikku ja toiseen Karttakeppi. Suotavaa kai olisi, että kumpaankin riviin tulee myös periodin 3 opetuksen alkamispäivämäärä ja päättymispäivämäärä, näiden tosin pitää olla muokattavissa. Lukujärjestysten laatija tietää, että Kalle Karttakeppi pitää luentoja kummallekin ryhmälle 4 viikkotuntia, ja myös, että hän haluaa opettaa sen kahtena kaksoistuntina eri päivinä. Siispä hän laittaa Karttakepille viikkotuntimääräksi 2 ja tekee kopion tästä rivistä. Silloin on kaksi opetustapahtumaa valmiina sijoitettavksi kalenteriin. Opetustilan voi laittaa tai olla laittamatta tässä vaiheessa. Se voi olla sama tila kummassakin tai sitten eri tila. Lasse Laskutikun tiedetään pitävän 3 viikkotuntia labroja kummallekin ryhmälle erikseen labrassa Lab1. Lukujärjestysten laatija siis laittaa Laskutikulle viikkotuntimääräksi 3, tekee kopion tästä rivistä ja muuttaa toiseen ryhmän Lu1 ja toiseen ryhmän Lu2 sekä laittaa tilaksi Lab1. Silloin on tämän toteutuksen kaikki opetustapahtumat valmiina kalenteriin sijoitettavaksi. Ei minulla ole mitään sitä vastaan, että tiedot voivat tulla suunnitteluvälineestä jo valmiiksi näin yksityiskohtaisesti jaoteltuina. Mutta kuinka ollakaan, koulutuspäällikkö ykskaks päättää, että koko opintojakso siirretään periodille 4 ja labroja tuleekin Lasse Laskutikun asemesta pitämään Matti Vanhanen. Hän siis muuttaa toteutuksessa ajoituksen periodille 4 ja vaihtaa Lasse Laskutikun Matti Vanhaseksi. Tiedonsiirto toimii niin, että kaikissa kyseisen toteutuksen opetustapahtumissa ajoitus vaihtuu periodin 4 alkamis- ja päättymispäiviksi ja Lasse Laskutikku vaihtuu Matti Vanhaseksi. Jos muutos tehdään niin myöhään, että tunteja on jo ehditty sijoitella kalenteriin, niin tässä tapauksessa ne kai poistuvat automaattisesti sieltä. Jos ajoitus säilyy periodilla 3 ja vain opettaja vaihtuu, niin kalenteriin sijoitetut tunnit säilyvät, vain opettaja muuttuu. Jos opetus silloin menee päällekkäin Matti Vanhasen muun jo kalenteriin sijoitetun opetuksen kanssa, olisi suotavaa, että myös muutoksen tekijälle välittyy varoitus, että muutokset enää tässä vaiheessa noin vain käy. Voi toteutuksessa tietysti muutua muutkin tiedot, esimerkiksi ryhmiä voidaan poistaa tai lisätä. En tiedä miten paljon pitää automaattisesti siirtyä lukujärjestyssysteemiin. Kyllä suunnittelijoillakin pitäisi olla velvollisuus informoida ainakin kovin myöhään tehtävistä muutoksista, ei kaikkea automaattikseksi kuitenkaan saada.
Tuo on yksi tapa mikä minulle tulee mieleen, voi olla että homman saa muullakin tavalla toimimaan. Minä tietysti olen jo lähes 10 vuotta tottunut Untiksen käyttöön ja minun ajattelumallini perustuu ainakin osaksi siihen miten homma siellä toimii. Onhan sitä pitkään kehitetty ja mietitty tarpeita nimenomaan lukujärjestysten laadinnan kannalta. Ei siellä tehtyjä ratkaisuja missään nimessä väheksyä kannata, pikemminkin niistä pitäisi ottaa oppia. Jos joku arvelee keksivänsä parempaa ruutia kuin on jo keksitty, niin voihan sitä yrittää. Kelvotonta työkalua en kyllä hyväksy, jos koen tästä tulevan sellaisen ja minut velvoitetaan sitä käyttämään, tulen keskittymään ainoastaan siihen, miten pääsen koko hommasta eroon.
On kyllä sitten vielä kolmaskin työkalu eli se paikka missä lukujärjestykset lopullisesti julkaistaan. Siis se mikä tällä hetkellä on tilanvarausjärjestelmä. Ei se ihan sellaisenaan voi olla edellä mainittu lukujärjestystyökalu, ainakaan silloin kun lukujärjestykset tehdään keskitetysti. Sehän elää työskenneltäessä koko ajan, ei sitä voi silloin julkisena pitää. Kyllä se ehkä suunnilleen yksi ja sama järjestelmä voi olla, mutta lukujärjestyssuunnittelijalla pitää olla aivan erityisokeudet siellä työskentelyyn. Hänen pitäisi sen kautta nähdä kaikki julkaisujärjestelmään tehdyt varaukset ja työskennellä siellä kenenkään näkemättä, tehdä ja muutella kalenterivarauksia mielin määrin ja sitten sopivalla hetkellä julkistaa muutokset. En tiedä miten tuo pystytään toteuttamaan, voi olla todella suuri haaste.
Mika 5.10. Tuon pitäisi hoitua statuksilla eli esim. opettaja ei näe varauksia joiden status on esim 1 joka voisi tarkoittaa samaa kuin "luonnos" tms.. Jos joku keksii yleispätevän säännön milloin joku muu kuin suunnittelija saa päästä muokkaamaan/lisäämään/säätämään merkintöjä niin tänne vaan ehdotusta. Tulevassakin järjestelmässä niin suunnitellut kuin julkaistutkin varaukset on hyvä tallentaa yhteen paikkaan ja työkaluissa/julkaisujärjestelmässä yms. kontrolloidaan noiden statuksian ja muiden sääntöjen avulla sitä kuka niitä pääsee katsomaan/muokkaamaan. Säännöilllä tarkoitan esim. päivämääräsääntöjä eli päivän X jälkeen voidaan olettaa että suunnittelu on tehty ja muillakin on oikeus mennä muuttamaan/tekemään varauksia vaikkapa toimipisteessä Y. Näissä tulee tosin se ongelma että kuka ne päivämäärät milloinkin määrittää (ja muistaako/osaako määrittää kaikissa toimipisteissä)...
Lukujärjestykset (listanäkymä)
...
6.1 Sijoiteltujen opetustapahtumien näkyvyys
Statuksien käyttö
Sijoittelutietojen (lukujärjestyksien) näkyvyyttä eri käyttäjille voidaan hallita statuksilla. Jokaisella merkinnällä pitää siis olla statustaso jonka mukaisesti eri käyttöliittymissä voidaan hallita tietojen näkyvyyttä. Tämä sikei että suunnittelun alkuvaiheessa merkintöjen ei välttämättä haluta näkyvän kaikille koska suunnittelu on vaikkapa pahasti kesken. Eli esim. opettaja ei näe varauksia joiden status on 1 joka voisi tarkoittaa samaa kuin "luonnos" tms. Tässä järjestelmässä niin suunnitellut kuin julkaistutkin varaukset on hyvä tallentaa yhteen paikkaan ja työkaluissa/julkaisujärjestelmässä yms. kontrolloidaan noiden statuksian ja muiden sääntöjen avulla sitä kuka niitä pääsee katsomaan/muokkaamaan. Säännöilllä tarkoitan esim. päivämääräsääntöjä eli päivän X jälkeen voidaan olettaa että suunnittelu on tehty ja muillakin on oikeus mennä muuttamaan/tekemään varauksia vaikkapa toimipisteessä Y. Näissä tulee tosin se ongelma että kuka ne päivämäärät milloinkin määrittää (ja muistaako/osaako määrittää kaikissa toimipisteissä).
Statuksien käytöstä kerrottu lisää kohdassa "Kommenttikierros".
Tilojen / opetusvälineiden resurssointi
Järjestelmässä voi tulla tarpeen resurssoida tilojen lisäksi myös välineitä kuten opetusnukke. Nämä välineet ovat joskus kriittinen tekijä resurssoinnille eli opetustapahtumaa ei voida pitää ilman ko. opetusvälinettä. Järjestelmään tulisi olla mahdollista lisätä resursseiki tilojen lisäksi myös opetusvälineet, kuten tietyissä opetustiloissa olevat tietokoneohjelmat (musiikeissa esim. Sibelius- nuotinnusohjelma).
6.2 Asetukset -sivu
Lukujärjestyssuunnittelijoita varten tarvitaan henkilökohtainen asetussivu, jossa on koottuna käyttäjän oletusasetuksia. Näihin vaikuttavat suoraan eri suunnittelunäkymiin ja vastaavasti eri näkymistä voisi linkittää suoraan näkymän asetuksiin (esimerksi kalenterinäkymässä voi olla linkki asetukset -sivulle kohtaan kalenteriasetukset tms.).
...
Oletuskiinteistö - Suunnittelija sijoittaa ei aina sijoitta tunteja usein vain yhteen kiinteistöön eli : suunnittelijan pitäisi voida valita mitkä kiinteistöt ja tilat näkee (turha näyttää aina koko koulun kaikkia tiloja listoissa). Esim. musiikilla neljä luokkaa Bulevardi 31:n toimipisteessä; ei tarvetta nähdä koko kiinteistön luokkavalikoimaa.
Kalenteri- / taulukkonäkymiin liittyvät:
...