Legge til mulighet for bilder

[drees123]

Det er et stort ønske designmessig å kunne legge til bilder i saker. Hva krever dette backend og drift @jarib @jonathanronen @henrikhelmers ?

[jarib]

Alternativer for bildehosting:

• Egen NFS-share
• Amazon S3
• http://www.blitline.com/
• http://cloudinary.com/

Jeg tror @dyresen er den som har mest NFS-erfaring av oss, hva tror du er lurest?

@henrikhelmers Fint om du også skriftlig kan melde inn litt hva som er drømmesituasjonen rundt formater/størrelser og eventuelle andre behov her.

[henrikhelmers]

Format - JPEG. Tre filer per bilde: Original, stor, liten. Vi komprimerer hardt med ImageMagick. Det enkleste med tanke på layout er å begynne med å støtte landskapsbilder (3:2).

Det er en fordel å bevare originalbildene så vi kan endre parametere senere. Bildene bør tas så de kan beskjæres til kvadrat (1:1) og fortsatt fungere.

[jarib]

Kunne det vært en idé å skaffe noen eksempelbilder i en 5-10 saker for å få en følelse med hvordan det vil fungere, både med tanke på teknikk og formidling?

[jarib]

Det vi trenger er en bildetjeneste som:

• laster opp bilder i en pool
• tilbyr API til hdo-site og UUIDs som kan kobles til modeller i hdo-site
• kan resize/croppe

[henrikhelmers]

Ved opplasting hadde det vært fint med følgende funksjonalitet:

• Støtte for store bilder.
• Mulighet til å skrive inn tittel / beskrivelse*.
• Støtte for versjonering, der tidligere bilder lagres og aktivt bilde settes.

Ved bruk hadde det vært fint med følgende:

• Forståelse for modellen, så f.eks. et representantbilde faller tilbake til parti, et saksbilde faller tilbake på kategori.
• Ønsket størrelse (?w=herp&h=derp) som parametre. Bildet skaleres og beskjæres for å passe.
• Oppskarping etter skalering (eller skalering med en skarpere algoritme enn bilinear).
• Etter første generering caches bildet.
• Vurder å bruke picture-elementet for å støtte HiDPI-skjermer og mobiltelefoner.
• Tittel/beskrivelse bør gå i alt-taggen, og være tilgjenglig som figcaption.

*Kan leses ut av Exif/IPTC.

Her er et eksempel på markup som jeg har brukt med picture polyfill(https://github.com/scottjehl/picturefill). Merk at den er veldig naiv med tanke på mobilstørrelser (det fungerer på min telefon).

<figure>
  <picture style="width: @width_param; height: @height_param">
    <!--[if IE 9]><video style='display: none'><![endif]-->
    <source media='(max-width:320px)' srcset='@path_mobile 2x'>
    <img srcset='@path_normal, @path_hidpi 2x' style="width: @width_param; height: @height_param">
    <!--[if IE 9]></video><![endif]-->
  </picture>
  <figcaption>
    <strong>@photo_title</strong>
    <span>@photo_description</span>
  </figcaption>
</figure>

[jarib]

Vi bør skissere ut hvordan vi ser for oss arkitekturen her. Hvordan er forholdet mellom hdo-front, hdo-site og bildetjenesten?

Det finnes mange eksisterende bildetjenester, så vi slipper nok å skrive noe eget for dette. Det finnes også forsøk på å standardisere hvordan slike tjenester bør se ut.

En strategi er å bygge alt inn i hdo-site, hvor vi allerede gjør litt bildebehandling. Det gjør det lettere å integrere med de andre dataene, men krever en del koding for å lage en bildevelger osv.

Alternativet er å ha en frittstående tjeneste, og lagre UUID/URLer dit i hdo-site-databasen.

Mens hdo-front bør være lykkelig uvitende om alt dette, og kun bry seg om det den får fra hdo-site-APIet.