Innhold
Denne artikkelen dukket opp første gang i nummer 229 av .net magazine - verdens mest solgte magasin for webdesignere og utviklere.
Som. Les senere. +1. Kvitring. Tumblr. Snuble over. I løpet av de siste årene har små chicletknapper spredt seg som meslinger over hele nettet og dukket opp og forsvinner når nye verktøy og tjenester stiger og faller i popularitet. Den populære ShareThis-knappen, som gir nettstedseiere muligheten til å i det minste korrigere alle disse sosiale tjenestene i en popup-rute, tilbyr for øyeblikket over 120 potensielle destinasjoner - og selv om ingen noen gang faktisk lister dem alle direkte, er det ofte vanskelig å fortelle nøyaktig hvem alle alternativene hjelper.
Det er et problem som trenger å fikse, og et problem som både Google og Mozilla har løsninger som skal håndteres - henholdsvis Web Intents og Web Actions / Activities. Henrettelsene deres varierer, men det grunnleggende målet er det samme: å bevege seg vekk fra nettstedet / app-skaperen som må koble til spesifikke tjenester for å få ting gjort, til fordel for å bare gjøre det mulig for dem å gi verb som nettleseren kan håndtere på en bruker- brukergrunnlag.
Hva vil dette bety i praksis? Vel, for eksempel: for øyeblikket er det mange forskjellige bokmerkeverktøy, hvor to av de mest populære er Delicious og Pinboard. For å integrere en bokmerkknapp på slutten av en artikkel, må nettstedseieren legge til to forskjellige koder. I en Web Intents / Actions-verden ville dette ganske enkelt bli en “Bookmark This” -knapp. Når brukeren klikker på den, ser nettleseren verbet, konsulterer listen over registrerte tjenester og overleverer dataene.
Det er bare det enkleste mulige scenariet. Det som stopper Web Intents / Actions som en forherliget ‘mailto: link’ er at de er i stand til langt mer, inkludert toveis interaksjon som gjør dem egnet for komplette webapplikasjoner, så vel som bare erstatning av chiclet. Gjeldende Web Intents spesifikasjoner håndterer verbene Discover, Share, Edit, View, Pick, Subscribe and Save. Med veldig lite koding kan du for eksempel både sende et bilde til en redaktør og motta den berørte versjonen, like enkelt som å hente informasjon som kontaktdetaljer ut av en ekstern adressebok og inn i en bestemt form - alt uten enkelt tilpasset API-anrop eller til og med å vite hva den andre parten faktisk er.
Det er selvfølgelig mer subtilitet i det enn dette. Akkurat som Mac og Windows håndterer bildefiler basert på type i stedet for bare filer og bilder, kan også apper spesifisere formater og datatyper. En nettbasert bilderedigerer kan for eksempel bli involvert når du arbeider med en JPEG, mens du høflig holder deg unna PNG-er eller MP3. I tilfelle flere registrerte klienter og tjenester kan håndtere en forespørsel, viser nettleseren ganske enkelt en meny for brukeren å velge hvilken de vil bruke. Forutsatt riktig implementering, vil samme kodebit fungere for dem alle.
Ulike visjoner
Fangsten er at mens Google og Mozilla deler omtrent den samme visjonen, er implementeringene og de endelige målene litt forskjellige.
"Selv om utvikling av nettleserfunksjoner nå gjøres ute i det fri under paraplyen til standardorganer, føles det fortsatt som et møte mellom forskjellige frimurerordner," forklarer Glenn Jones, en av arrangørene av Web Intents Design Push-arrangementet i februar. ”Så lenge jeg ikke har misforstått håndtrykkene, handler noen forskjeller her om omfanget av det alle prøver å oppnå.
“Chrome-teamet fokuserer sterkt på nettapplikasjoner og er for eksempel interessert i funksjonen som fungerer offline. Mozilla er mer interessert i det bredere bruksområdet for sosiale medier, og ønsker å holde løsningen litt mer forenklet.
‘Forenklet’ er ikke overraskende ikke ordet som brukes av Tantek elik, nettstandarder i Mozilla. "Vi tror at Mozillas nettaktiviteter er en mer fokusert tilnærming [enn Web Intents] som er avhengig av det åpne webapp-systemet for å oppdage," forklarer han. "Målet med å basere funn på nettapper er en antagelse om at det å kreve brukerinstallerte apper er en brukersentrert mekanisme som er mer sikker, personvernforbedrende og forståelig."
En spesifikk teknologisk klage fra Mozilla-siden er at Web Intents stoler sterkt på JavaScript, med en shim som for øyeblikket er tilgjengelig for alle som ønsker å eksperimentere med dem. "Dette er en ikke-startpakke for mange nettsteder og applikasjoner, ettersom de trenger å fungere på enheter med begrenset kapasitet, eller når brukere slår av JavaScript, eller på annen måte ikke får tilgang til eksterne skript," fortsetter elik. "Vi vet fra Twitters eksempel og gode fremgangsmåter for bruk av enkle hyperkoblingskoder at det er mulig å få webhandlinger til å fungere uten JavaScript, derfor bør netthandlinger også fungere uten JavaScript."
Det begge sider er enige om er at brukergrensesnittets side av teknologien fortsatt trenger arbeid. Hva skjer for eksempel når brukeren klikker på et verb de ikke har registrert en tjeneste for, eller hvis tjenesten mislykkes? Hvor raskt vil nettsteder som for øyeblikket bruker Facebook Like-knapper for å drive trafikk, velge å tilpasse seg en verden der "Del" kan sprette trafikk rundt alt fra Google Plus til MySpace? Mer til poenget, hvordan vil disse tjenestene ta dette treffet til informasjonskartene sine?
"De siste månedene er det tapet av skjult verdi som Facebook / Twitter / Google og så videre kan kreve ved å spore folks nettleserhistorikk på nettet med alt dette injiserte JavaScript som bekymrer meg," sier Jones. “Disse dataene har stor økonomisk verdi for de involverte selskapene, og hvis de ikke har JavaScript på sider som stille sporer brukernes nettleserhistorikk, kan det motvirke dem fra å tilby grensesnitt. Dette er en stor grunn for brukere å like Web Intents / Actions, men det kan redusere opptaket av slike som Facebook. ”
Jobber sammen
Disse og flere problemer må fortsatt løses før enten Web Intents eller Web Activities kan bli utbredt nok til å være en standard byggestein.
“Jeg tror ikke det er i noen interesse å utvikle forskjellige standarder innenfor dette rommet,” sier Jones, “forhåpentligvis er spørsmålet om at en vinner mot en annen, vanskelig. Jeg hilser på det faktum at Ian Hickson (et medlem av Google Standards Development-teamet, og forfatteren / vedlikeholderen av syre nettleserkompatibilitetstester) nå vurderer å slå sammen registerProtocolHandler (), registerContentHandler () fungerer med Web Intents. ”
For å sammenligne de to teknologiene, er det beste utgangspunktet Google-nettstedet, som tilbyr mange live-demoer, en JavaScript-shim å eksperimentere med, og mange spørsmål og svar som forklarer både hvorfor denne typen teknologi er viktig, og hvorfor den krever ny teknologi. Mozilla-versjonen er mer utviklerfokusert og antar mer bakgrunnskunnskap, men du finner hovednavet her.
