Dokumentointikamera 2.0

Vanhan dokumentointikameran sivu

Tämä teksti liittyy web-kehityksen kurssiin, jos siellä olisi kiinnostusta lähteä rakentamaan uutta läbikameraa.


Tarkoitus

Dokumentointikamera on tapa jakaa jästenten ottamia yhteisiä läbin valokuvia keskitetysti samaan paikkaan. Tämänhetkinen toteutus on poissa käytöstä ja tarvittaisiin uusi ratkaisu. Vanha järjestelmä perustui jaettuun yhteiseen action-kameraan, uusi voisi olla hajautetumpi ja kamerana voisi toimia jokaisen oma puhelin. Toinen lisätoiminto aiempaan verrattuna olisi kuvien moderointi, johon voidaan käyttää joko tähän tarkoitukseen rakennettua työkalua, tai sitten rakennetaan botti vaikka Slackiin.

Vanha toteutus lyhyesti

  • yhteinen kamera, jolla on määritelty oma paikkansa
  • perustuu wifi-yhteyteen, josta RasPi hakee uudet kuvat ja työntää ne sellaisenaan Flickriin
  • Flickrin apia kutsutaan jakamalla uudet kuvat päiväkohtaisiin albumeihin, uusi albumi vain jos uusia kuvia (albumijaon aikakatko aina aamukolmen kohdalla)
  • kamera on urheilukamera, joka kestää kolhuja, vettä ja pudotuksia
  • moderointi vasta julkaisun jälkeen, jos kuvaaja ei ehdi poistamaan kuvia kameran muistikortilta heti kuvan ottamisen jälkeen
  • wifi-kortti osa poistaa kuvat itse, kun ne ovat siirretty
  • huonoja puolia mm. kuvien siirtymisen epävarmuus ja kuvien poistamispyyntöjen käsittelyn hankaluus ja hitaus

Uusi toteutus, ehdotus

  • läbin lähiverkossa toimiva palvelu, jossa nettisivu pyytää lupaa päästä käyttämään puhelimen kameraa
  • kuvista poistetaan turhat metatiedot
  • Flickr edelleen julkaistavien kuvien sijoituspaikka
  • jonkinlainen moderointikeino kuvien käsittelyyn, johon voivat osallistua myös muut kuin kuvia ottavat henkilöt
  • extrana voisi olla kuvien sisällön kuvailun mahdollisuus julkaisun yhteydessä

Käyttäjäkertomuksia

Kuvan ottaminen

  • kuvaaja on yhteydessä läbin ei-julkiseen wifi-verkkoon ja avaa osoitteen kamera.local.
  • sivu kysyy lupaa käyttää puhelimen kameraa.
  • kuvaaja ottaa kuvan ja se siirtyy palveluun, kuvaaja näkee äsken ottamansa kuvan sivulla.
  • kuvaaja voi poistaa epäonnistuneen otoksen.
  • kuva ilmestyy moderointijonoon heti tapahtuman jälkeen.

Kuvien moderointi

Tämä esimerkki on siinä tapauksessa, että moderointi tapahtuu Slack-botin kautta:

  • Uusi kuva ilmestyy Slackiin kamerakanavalle
  • Jos kuvalle ei tehdä mitään, se julkaistaan 3h päästä Flickrissä
  • Jos joku antaa kuvalle peukun alaspäin, sen julkaisu estyy, kunnes peukku mahdollisesti poistetaan
  • Jos ylläpitäjä poistaa kuvan, sitä ei julkaista

Yllä oleva on vielä tosi keskeneräinen luonnos, enkä tiedä, toimisiko järjestely vai ei. Voidaanko reaktioita ylipäänsä käyttää moderoinnissa vai ei. Pitääkö ylläpitäjällä olla jokin mahdollisuus julkaista kuva, vaikka peukkuja tulisi alaspäin? Muita ideoita? Moderoinnille sittenkin oma työkalu, joka toimii vain läbiverkossa?

1 Like

Noin hätäisesti miettien, löytyisikö jo jokin valmisratkaisu, joka toteuttaisi pääkohdat.
Ei tunnu mitenkään erikoisilta vaatimuksilta.

Minusta tämä on kiinnostava käyttöcase web-kehitys -kurssin yhteydessä toteutettavaksi ja testattavaksi. Tekisin sen Firebase:n Cloud Storage ja Cloud Functions -alustoilla. Tuolloin koko sovellus olisi netissä ladattavissa (ei riipu labin palvelimesta), sisältäisi autentikaation (kuka kuvan otti) ja taustayhteys Slackiin toimisi erillisenä taustapalveluna. Ansaitsee paremmat speksit, jotka ajattelin tehdä vasta kurssin alettua.

Pohdiskelin huvikseni dokumenttikamerakysymystä eräänä päivänä ja keksin itse toisenlaisen speksin. En esitä sitä käyttöön, mutta esittelen idean nyt kuitenkin tässä. Ajattelin prototyypata sen harrastusmielessä, mutta näyttää siltä, että muut kiireet tulevat edelle. Kommentit ovat kuitenkin tervetulleita.

Pohdiskelin siis, miten ihmiset voisivat kätevimmin lähettää kuvia omista puhelimistaan labin Flickriin. Web-sovellus, jossa on upload-lomake, ja joka poistaa metatiedot ja puskee sitten Flickrin API:iin, esim. yllä kuvatun Slack-moderoinnin kautta, on suht “suoraviivainen”, mutta ongelma on miten rajataan sen käyttäjät labikävijöihin, mielellään fyysisesti labille.

Labin lähiverkon käyttämisen sijaan oma ratkaisuni tähän on kertakäyttöinen URL, jonka voi saada ainoastaan fyysisesti labilla.

Teknisenä toteutuksena hahmottelin:

  • Edellä mainittu Flickr-upload -palvelin. Käytännössä web-sivu, jossa on lomake, jolla voi valita ja lähettää kuvia kännykän kuvakirjastosta.
  • Jokin sopiva pieni lauta, esim. Raspi Pico, jota voi ohjelmoida CircuitPythonilla,
  • Laudassa on kiinni e-Ink -näyttö, painonappi (ja paristovarmennettu RTC).
  • Nappia painamalla laite generoi kertakäyttöisen URL:n upload-lomakkeelle ja näyttää sen QR-koodina näytöllä.
  • Laite ja web app omistavat saman salaisuuden, mikä mahdollistaa esim. JWT:n (JSON web token) tai muun allekirjoitetun tokenin generoimisen ja validoimisen.
  • Laudan generoima URL sisältää em. tokenin, jonka avulla palvelin tietää, että URL tulee labilla olevalta laitteelta.
  • Lisäksi token sisältää aikaleiman milloin se on luotu, ja palvelin hyväksyy vain riittävän tuoreen tokenin, joten käyttäjän on täytynyt olla labilla painamassa sitä nappia esim. viimeisen 5 minuutin aikana.

Tuon QR-koodeja generoivan laitteen ei tarvitse olla verkossa kiinni, eikä sen tarvitse oikeastaan tehdä mitään muuta kuin nappia painaessa generoida uusi token ja päivittää se näytölle. Aikaleimojen vuoksi siinä täytyy tosin olla toimiva kello. QR-koodeista tulee n. 50x50 pikselin kokoisia.

1 Like

Tuo kuulostaa ihan hyvältä. Se vastaa yhteen asiaan - miten tiedetään, että käyttäjä on labilla. Se ei ota kantaa uploadin ja niin eespäin ulkoasuun, mitä voisi sitten parantaa matkan varrella.

Onko Hacklabilla jotain tapaa tehdä vaatimusmäärittelyjä jne. tällaiseen hankkeeseen? Pelkään, että keskustelupalstoilla asiat sammaloituvat. On hyvä nykäistä projektia seuraavalle tasolle, tietoisena, mitä sen jälkeen tehtäisiin.