Share
Jeg hadde stor glede av å levere den avsluttende keynoten på Responsive Day Out 3: The Final Breakpoint. Hentet i Brighton, Storbritannia, 19. juni 2015 var konferansen en samling av designere og utviklere som delte arbeidsflytstrategier, teknikker og erfaringer med responsiv webdesign.
Her er hva jeg måtte si.
I dag har det gitt en fantastisk tur til verden av responsiv design. Vi har sett hvordan vi skal utjevne våre arbeidsflyter og prosesser. Vi har lært nye måter å forbedre tilgjengeligheten til våre produkter. Vi har grepet med moderne CSS- og HTML-kapasiteter som hjelper oss med å omfavne de svært varierende skjermstørrelsene som virvler og virker rundt oss.
Vi har undersøkt fremtiden for modulær kode og nettleserens kapasitet til å arbeide uten nettverkstilkobling. Og vi har selv tatt en tur inn i mulig fremtid for hvor nettet kan gå.
Vi har kommet langt siden Ethans artikkel, fluidnett, fleksible medier og medieforespørsler. Disse tre prinsippene sådde et frø som har vokst og blomstret som vi har kommet for å bedre forstå implikasjonene av enhetsproliferasjon. Vi har sett at nettet er i stand til å gå hvor som helst og gjøre stort sett alt.
Jeg ville hevde at "Responsive Web Design" var den første artikkelen som virkelig klarte å fange opp de konseptene John Allsopp hadde diskutert så mange år tidligere i "A Dao of Web Design" og destillert dem til noe design- og utviklingssamfunnet virkelig kunne synke tennene deres inn i. Det ga et konkret eksempel på nettets evne til å bøye seg og forme seg i hvilken form den måtte ta på seg.
Det var første gang mange designere hadde kommet til ideen om at "erfaring" ikke var noe monolitisk ting.
Jo, mange av oss i nettverksstandardsamfunnet hadde snakket snakk og gå tur med hensyn til progressiv forbedring. Og vi fikk konverter, men fremgangen var langsom. Ethan demonstrerte - direkte og kortfattet - hva den progressive forbedringen av visuell design kunne se ut.
Å gi en identisk opplevelse for hvert menneske som prøver å få tilgang til våre nettsteder, ville være umulig. Det er rett og slett altfor mange faktorer å vurdere. Vi har skjermstørrelse, skjermtetthet, CPU-hastighet, mengde RAM, sensor tilgjengelighet, funksjon tilgjengelighet, grensesnitt metoder ... puste ... operativsystemtype, operativsystemversjon, nettlesertype, nettleserversjon, plug-ins installert, nettverkshastighet, nettverksdrift, nettverksbelastning, brannmurer, proxyer, rutere, og sannsynligvis et dusin andre faktorer, er tankene mine ikke i stand til å plukke midt i virvelvinden av tekniske hensyn.
Og det overveier ikke engang våre brukere.
Når det gjelder folket vi trenger for å nå frem til arbeidet vårt for å faktisk saken, må vi vurdere leseferdighetsnivå, lese akumen, nivå av domenekunnskap, kognitive funksjonsnedsettelser som læringshemming og dysleksi, oppmerksomhetsunderskuddsproblemer, miljøforstyrrelser, synshemming, hørselshemmede, motorisk funksjonsnedsettelse, hvor mye de forstår hvordan de skal bruke enheten, hvor mye de forstår hvordan de skal bruke nettleseren, hvordan de er velbevandste i vanlige webkonvensjoner og en rekke andre "menneskelige faktorer".
Hver person er forskjellig og alle kommer til nettet med sitt eget sett med spesielle behov. Noen er alltid med dem, for eksempel blindhet. Andre er forbigående, som å bryte din mousing arm. Fortsatt andre er rent situasjonsmessige og avhengig av enheten du bruker på tiden, og dens tekniske evner eller begrensninger.
Forsøker å utarbeide en monolitisk opplevelse for hver person å ha i enhver sammenheng som vurderer hver eneste faktor, ville være umulig. Og likevel hadde sir Tim Berners-Lee en visjon for et web som var i stand til å gå hvor som helst. Var han vanvittig?
Sir Tims visjon for Internett var at innholdet kunne opprettes en gang og nås fra hvor som helst. Ulike, men relaterte biter av "hypermedia" spredt over hele verden kan være koblet til hverandre via linker. Videre vil de bli hentbare av noen på en hvilken som helst enhet som er i stand til å lese HTML. Gratis.
Til slutt fant Sir Tim universell tilgjengelighet.
For mange av oss er det en ettertanke å sikre at våre nettsider er tilgjengelige. Vi snakker et godt spill når det gjelder "bruker-sentrert" dette eller det, men behandler ofte ordet "tilgjengelighet" som et synonym for "skjermleser". Det er så mye mer enn det. "Tilgjengelighet" handler om mennesker. Folk bruker innhold og bruker grensesnitt på mange forskjellige måter, noen liknende og noen ganske forskjellig fra hvordan vi gjør det.
Visst, folk med synsfeil bruker ofte en skjermleser til å konsumere innhold. Men de kan også bruke en Braille-tilbakemeldingsanordning eller en Braille-skriver. De bruker sannsynligvis også et tastatur. Eller de kan bruke en berøringsskjerm i samspill med lyd-signaler. Eller de kan til og med bruke et kamera for å tillate dem å "lese" innhold via OCR og tekst-til-tale. Og ja, synshemming påvirker en anstendig prosentandel av befolkningen (spesielt når vi alder), men det er bare en del av "tilgjengelighet" -puslespillet.
Kontrasten mellom tekst og bakgrunn er en viktig faktor for å sikre at innholdet fortsatt er lesbart i forskjellige belysningssituasjoner. Fargevalg er en tilgjengelighetsproblemer.
Språket vi bruker på våre sider og i våre grensesnitt påvirker direkte hvor enkelt det er for brukerne å forstå hva vi gjør, produktene vi tilbyr, og hvorfor det betyr noe. Det påvirker også hvordan vi får brukerne til å føle seg selv, deres erfaring og våre selskaper. Språk er en tilgjengelighet bekymring.
Størrelsen på våre nettsider har en direkte effekt på hvor lenge sidene våre tar for å laste ned, hvor mye det koster kundene våre å få tilgang til dem, og (noen ganger) selv om innholdet kan nås. Ytelse er en tilgjengelighetsproblemer.
Jeg kunne fortsette å gå, men jeg er sikker på at du får poenget.
Tilgang er å gi gode erfaringer for alle, uavhengig av fysiske eller mentale evner, kjønn, rase eller språk. Det anerkjenner at vi alle har spesielle behov - fysiske begrensninger, begrensninger av båndbredde, begrensninger på enheten - det kan kreve at vi opplever det samme grensesnittet på forskjellige måter.
Når jeg besøker et nettsted på telefonen min, for eksempel, er jeg visuelt begrenset av skjermoppløsningen min (spesielt hvis jeg bruker en nettleser som oppfordrer til zooming), og jeg er begrenset i min evne til å samhandle med knapper og lenker fordi jeg surfer med fingertuppene mine, som er større og langt mindre nøyaktige enn en musemarkør.
På en berøringsskjerm kan jeg trenge at opplevelsen er litt annerledes, men jeg trenger fortsatt å kunne gjøre hva det er jeg kom til nettstedet for å gjøre. jeg trenger en erfaring, men i tillegg trenger jeg passende erfaring.
Omgjøre virkeligheten at opplevelsen ikke trenger å være bare en ting, vil hjelpe oss med å nå flere mennesker med færre hodepine. Erfaring kan og skal utformes som et kontinuum. Dette er progressiv forbedring: Vi starter med en baseline-opplevelse som fungerer for alle-innhold, ekte linker, førstegenerasjons skjemakontroller og skjemaer som faktisk sender til serveren. Da bygger vi opp opplevelsen derfra.
Nettleseren din støtter HTML5 skjema kontroller? Flott! Du får et bedre virtuelt tastatur når du går for å skrive inn e-postadressen din. Du kan bruke CSS? Awesome, la meg gjøre den leseopplevelsen bedre for deg. Åh, du kan takle medieforespørsler! La meg justere oppsettet slik at de lengdeene er litt mer komfortable. Wow, støtter nettleseren din Ajax ?! Her, la meg laste inn noen teasers for relatert innhold du kan finne interessant.
Tenk deg å sitte ned i en restaurant, bare for å få servitøren umiddelbart ta deg en biff. Men du er vegetarianer. Du spør om de tilbyr noe du kan spise og de svarer høflig: "Å, jeg er lei meg, kjøtt er et krav. Hvorfor spiser du ikke bare kjøtt? Det er enkelt! Du mister virkelig litt smakfull mat." Ingen servitør som faktisk bryr seg om din erfaring ville gjøre det.
Og likevel, vi som en industri, synes ikke å ha noe problem å fortelle noen de trenger for å bytte nettleseren for å imøtekomme oss. Det er bare feil. Vårt arbeid er meningsløst uten brukere. Vi bør bøye seg over bakover for å tiltrekke seg og beholde dem. Dette er kundeservice 101.
Dette kommer tilbake til Postels lov, som Jeremy ofte forteller om:
Vær konservativ i hva du gjør, vær liberal i det du aksepterer fra andre.
Vi må være laks når det gjelder nettleserstøtte og ikke lage for mange (eller bedre enn noen) forutsetninger om hva vi kan sende.
Selvfølgelig er dette ikke en tilnærming som alle i vår bransje er klare til å omfavne, så jeg vil tilby et annet tilbud jeg kommer tilbake til gang på gang ...
Når noe skjer, er det eneste i din makt din holdning til det; Du kan enten godta det eller forstyrre det.
Vi kan ikke kontrollere verden, vi kan bare kontrollere vår reaksjon på den.
Nå er de av dere som har samlet seg for denne siste, Responsive Day Out (eller som følger med hjemme) sikkert forstått dette mer enn de fleste. Vi føler konstant bombardement av nye enheter, skjermstørrelser og evner. Den eneste måten jeg har funnet på å håndtere alt dette er å godta det, omfavne mangfoldet, og se enhets- og nettleserproliferasjon som en funksjon, ikke en feil.
Det er opp til oss å utdanne de rundt oss som har - enten ved et uhell eller en hensikt - ikke akseptert at mangfoldet er den virkeligheten vi lever i, og ting kommer bare til å bli vanligere. Å begrave hodene våre i sanden er ikke et alternativ.
Når jeg prøver å hjelpe folk å forstå og omfavne mangfold, kommer jeg ofte til en av mine favoritt tankeøvelser fra John Rawls.
Rawls var en filosof som pleide å drive et sosialt eksperiment med studenter, kirkegrupper og lignende.
I forsøket fikk deltakerne til å skape sitt ideelle samfunn. Det kan følge noen filosofi: Det kan være et monarki eller demokrati eller anarki. Det kan være kapitalistisk eller sosialistisk. Folket i dette forsøket hadde fri telt til å kontrollere absolutt alle aspekter av samfunnet ... men da ville han legge til vridningen: De kunne ikke kontrollere hvilken stilling de okkuperte i det samfunnet.
Denne vridningen er hva John Harsanyi - en tidlig spillteoretiker - refererer til som "uvitens slør". Det som Rawls igjen og igjen fant var at individer som deltok i forsøket, ville tyngde mot å skape de mest egalitære samfunnene.
Det er fornuftig: hva rasjonelt, selvinteressert menneske ville behandle eldre, syke, personer av et bestemt kjønn, rase, trosbekjennelse eller farge dårlig hvis de kunne finne seg i samme posisjon når sløret ble trukket bort?
De tingene vi gjør for å imøtekomme spesielle behov, betaler nå utbytte i fremtiden. Se på ramper.
De er et klassisk eksempel på en tilgjengelighetsfunksjon for rullestolbrukere som også er til nytte for personer som ikke er i dem: folk som reiser bagasjen, leverer tjenester som transporterer tunge ting på dollies, foreldre som driver barn (eller deres kledde hunder) i barnevogner, en pendler går på sykkelen, og den fyren som bare foretrekker å gå en mild helling for å utnytte innsatsen som kreves for å montere et skritt.
Når vi lager alternative veier for å komme fra punkt A til punkt B, kan folk ta den mest hensiktsmessige for dem, enten ved valg eller nødvendighet. Og alle kan nå sine mål.
Vi har alle spesielle behov. Noen vi er født med. Noen vi utvikler. Noen er midlertidige. Noen har ingenting å gjøre med oss personlig, men er situasjonelle eller rent avhengige av maskinvaren vi bruker, samhandlingsmetodene vi har tilgjengelig for oss, eller til og med hastigheten der vi kan få tilgang til Internett eller behandle data.
Hva er responsivt webdesign om om ikke tilgjengelighet? Ja, dets grunnleggende teneter er opptatt av visuell design, men når det gjelder det store bildet, handler de om å gi best mulig leserfaring.
Som utøvere av responsiv design forstår vi fordelene ved å tilpasse grensesnittene våre. Vi forstår fallbacks. Vi forstår hvordan vi skal designe robuste erfaringer som fungerer under en rekke forhold. Hver dag utvider vi tilgjengeligheten til våre produkter.
Disse ferdighetene vil gjøre oss uvurderlige ettersom teknologien fortsetter å tilby nye måter å konsumere og samhandle med våre nettsteder.
Vi har nettopp begynt å dyppe eller tåse, hendene inn i verden av bevegelsesbaserte gestikulære kontroller. Jo, vi har hatt dem i to dimensjoner på berøringsskjermene en stund nå, men tre-dimensjonale bevegelsesbaserte kontroller begynner bare å vises. Du kan se en demonstrasjon av gestikale kontroller rundt 41-sekundersmerket i følgende video:
Det første store spranget i denne retningen var Kinect på Xbox 360 (og senere, Windows). Med Kinect, samhandler vi med datamaskinen ved hjelp av kroppsbevegelser som å heve en hånd (som får Kinect til å ta hensyn), skyver vår hånd fremover for å klikke / trykke og gripe for å dra lerretet i en bestemt retning.
Kinect inngikk en stor revolusjon når det gjelder grensesnitt med datamaskiner, men fra et interaksjonsperspektiv, presenterer det lignende utfordringer som Wii-kontrolleren og Sony PlayStation Move. Store kroppsbevisninger som å heve hånden din (eller en trollkontroll) kan være slitsomt.
De er heller ikke veldig nøyaktige. Hvis du trodde at berøringsskjermens nøyaktighet var et problem, utgjorde håndbevis som Kinect eller LEAP Motion enda mer utfordring.
For å imøtekomme interaksjoner som dette (som vi for øyeblikket ikke har mulighet til å oppdage), må vi være klar over hvor enkelt det er å klikke på interaktive kontroller. Vi må avgjøre om knappene og linkene våre er store nok, og om det er nok plass mellom dem for å sikre at brukerens hensikt er nøyaktig overført til nettleseren. To spesifikasjoner som kan hjelpe dette er Media Queries Level 4 og Pointer Events.
I Media Queries Level 4 ble vi i stand til å bruke stilregler til bestemte samspillskontekster. For eksempel, når vi har veldig nøyaktig kontroll over markøren vår (som ved en pekepinne eller mus) eller mindre nøyaktig kontroll (som ved berøringsskjerm eller fysisk gest):
@media (peker: grov) / * Mindre koblinger og knapper er ok * / @media (peker: grov) / * Større koblinger og knapper er sannsynligvis en god ide * /
Selvfølgelig ønsker vi å tilby en fornuftig standard når det gjelder størrelse og mellomrom som tilbakebetaling for eldre nettlesere og enheter.
Vi har også muligheten til å avgjøre om enheten er i stand til å svinge over et element og kan justere grensesnittet tilsvarende.
@media (hover: hover) / * hover-relaterte interaksjoner er A-OK * / @media (svever: på forespørsel) / * hover-relaterte interaksjoner er potensielt vanskelige, kanskje gjør noe annet i stedet * / @ media (svever: ingen) / * Ingen svever mulig :-( * /
Vi må fortsatt finne ut hvor godt alt dette ender opp med å jobbe på multimodale enheter som Surface tabletten, men. Vil designet endres ettersom brukeren bytter mellom inngangsmoduser? Burde det? Til det formål gir spesifikasjonen også en hvilken som helst-pekeren og alle-hoverto, slik at du kan spørre om hvorvidt noen støttet samhandlingsmetode oppfyller dine krav, men her er et ord med advarsel fra spesifikasjonen:
Utforming av en side som er avhengig av svever eller nøyaktig peker bare fordi alle-hover eller en hvilken som helst-pekerenindikerer at en inngangsmekanisme med disse funksjonene er tilgjengelig, vil sannsynligvis føre til dårlig erfaring.
Disse spørsmålet om mediesøk begynner å rulle ut i Chrome, Mobile Safari og Microsoft Edge, så det er verdt å ta en titt på dem.
Pointer Events er en annen spec som begynner å få litt trekkraft. Det generaliserer samspillet til en enkelt begivenhet i stedet for å tvinge oss til siloerfaring i musedrevet, berøringsdrevet, penndrevet, (sukk) kraftdrevet og så videre.
Vi kan diskret oppdage støtte for Pointer Events ...
Accentsconagua
hvis (window.PointerEvent) window.addEventListener ("pointerdown", detectType, false); ... og håndter dem så på samme måte eller opprett grener basert på pointerType:
funksjon detectType (event) switch (event.pointerType) case "mouse": / * musinngang oppdaget * / break; saken "penn": / * penn / stylusinngang oppdaget * / pause; case "touch": / * berøringsinngang oppdaget * / break; standard: / * pointerType er tom (kunne ikke oppdages) eller UA-spesifikk egendefinert type * /
Selvfølgelig, i tillegg til å vurdere nøyaktighetsgraden våre brukere har, mens de samhandler med våre skjermer, må vi også vurdere den potensielt økte avstanden som brukerne våre leser innholdet på.
For det formål har jeg eksperimentert med visningsportbredden (vw) -enheten.
I lang tid har jeg brukt ems for layoutets maksimal bredde (slik at linjelengden er proporsjonal med skriftstørrelsen). Jeg bruker også relative skriftstørrelser. Med det som grunnlaget kan jeg bruke et medieforespørsel som samsvarer med maksimal bredde og angi basestørrelsen på vw ekvivalent ved maksimal bredde.
kropp maksimal bredde: 64em; @ media skjerm og (min bredde: 64em) body font-size: 1.5625vw; / * (1em / 64em) * 100 * /
Så hele designet vil ganske enkelt zoome oppsettet når det vises over denne størrelsen.
Hvis du ikke vil slå noe sånn på automatisk, kan du aktivere den til å bli slått av og på med JavaScript.
Ting blir enda mer sprø når du begynner å faktor i enheter som HoloLens. Og nei, jeg har ikke fått spille med en enda, men du kan se en flott demo på 1:27-merket på denne videoen:
Men ideen om å kunne slippe en virtuell skjerm på en hvilken som helst overflate gir noen interessante muligheter som bruker og noen unike utfordringer som designer. HoloLens, selvfølgelig, bringer det også med gestekontroller, så det skal være ganske langt å regne med en rekke innspillstyper..
På en lignende måte bør vi begynne å tenke på hvilke erfaringer som kan og skal se ut når vi blar utelukkende med blikket vårt. Gaze tracking har sin opprinnelse i tilgjengelighetsområdet som et middel til å gi grensesnittkontroll til folk med begrenset eller ingen bruk av hendene. Tradisjonelt har blikksporing maskinvare vært flere tusen dollar, slik at den ikke er tilgjengelig for mange mennesker, men det begynner å forandre seg.
I de siste årene har beregningsmakten til våre enheter økt, ettersom maskinvarekostnadene knyttet til støtte for blikksporing har falt dramatisk. Når du ser rundt, kan du se blikksporing begynne å bevege seg inn i det offentlige sfæren: Mange smarttelefoner og smartwatches kan gjenkjenne når du ser på dem (eller i det minste gjør de noen ganger). Dette er bare et kort skritt unna å vite hvor på skjermen du ser. Og nesten alle high-end smarttelefoner er nå utstyrt med et kamera foran som gjør dem perfekte kandidater til å gi denne samhandlingsmetoden.
Du kan se en flott demonstrasjon av Sesame Phone's ansiktssporingsteknologi fra 18 sekunders merke i denne videoen:
Sesamelefonen ble designet for å tillate folk å bruke en smarttelefon uten å bruke hendene. Det bruker ansiktssporing for å flytte en virtuell markør rundt på skjermen, slik at brukerne kan samhandle med det underliggende operativsystemet, så vel som individuelle applikasjoner. Den støtter trykk, sveip og andre bevegelser (via en kontekstmeny) og er ganske imponerende i min erfaring. Teknologi som dette gjør at folk som lider av MS, leddgikt, muskeldystrofi og mer kan bruke en smarttelefon og - enda viktigere for oss - surfe på nettet.
Øyestammen og Fixational fungerer på samme måte som å bringe øye sporing til smarttelefoner og tabletter. Øyesporing ligner ansiktssporing, men markøren følger fokuset ditt. Mikrobevegelser-blink, blink, etc.-lar deg kommunisere med enheten.
Selv om de fleste blikksporingsprogrammer etterligner en mus og har justerbar følsomhet, er nøyaktigheten av det som en pekerenhet ikke fantastisk. Når jeg har brukt Sesamelefonen, har jeg for eksempel hatt det vanskelig å kontrollere posisjonen til hodet mitt for å holde markøren fortsatt til å sveve og klikke på en knapp. Jeg er sikker på at dette vil bli bedre med praksis, men det er trygt å si at i større blikk vil større, godt fordelte og lettere målrettede koblinger og knapper være en godsend.
Så langt har jeg fokusert på samhandlingsmetoder som letter navigering og forbruker innhold. Men hva med å fylle ut et skjema? Jeg kan fortelle deg at du skriver en e-post brev-for-brev på et virtuelt tastatur, bruker ansiktet ditt, suger ...
Heldigvis er de fleste av disse gesturalgjennomføringene kombinert med en eller annen form for talegjenkjenning. Kinect vil for eksempel akseptere verbale kommandoer for å navigere og utføre oppgaver som å fylle ut skjemaer. Sesamelefonen støtter også talekommandoer for visse grunnleggende handlinger, diktering av e-post og lignende.
Sammen med stemmen fungerer de alternative samhandlingsmetodene til Kinect og Sesame Phone veldig bra. Men taleinteraksjon kan også stå på egen hånd.
De fleste av oss er kjent med Apples Siri, Google Nå, og Microsofts Cortana. Disse digitale assistenter er gode når du henter informasjon fra utvalgte kilder og gjør andre assistent-ting som å beregne et tips og sette inn en påminnelse. Så langt som å samhandle med nettet, gjør de det ikke ... ennå. Vi kan engasjere seg med dem, men de kan ikke (nødvendigvis) engasjere seg med en nettside.
Eksponere informasjonen som er lagret på våre nettsider via semantisk HTML og strukturerte syntakser som mikroformater, mikrodata og RDFa bør til slutt gjør innholdet tilgjengelig for disse assistentene, men vi vet egentlig ikke. Deres ulike beslutningstakere har ikke gitt oss noen anelse om hvordan du gjør det, og som det står akkurat nå, kan ingen av dem se opp en nettside og lese den for deg. For det må du påkalle en skjermleser.
Hvert selskap tilbyr en første-party skjermleser. Og alle er i stand til å hjelpe deg med å samhandle med en side, inkludert å hjelpe deg med å fylle ut skjemaer, uten å måtte se siden. Og likevel har disse teknologiene ikke blitt koblet sammen med deres tilsvarende assistenter. Det er sannsynligvis ikke lenge før vi ser det skje.
Når vi begynner å vurdere hvordan våre nettsteder vil bli opplevd i en stemmeforbindelse, blir lesbarheten av våre nettsider avgjørende. Fjern godt skrevet prosa og en logisk kildeordre vil være en absolutt nødvendighet. Hvis våre sider ikke gir mening når du leser, hva er poenget?
Content strategist Steph Hay visningsgrensesnitt som en mulighet til å snakke med brukerne. Snart blir det bokstavelig talt.
Interessant, har Microsoft gitt oss en titt på hvordan det kan være å designe egendefinerte talekommandoer for våre nettsteder utover hva operativsystemet støtter med Cortana. Med andre ord, la de oss lære deres assistent.
I Windows 10 kan installerbare webapper inkludere en Voice Command Definition (VCD) -fil i hodet på siden for å aktivere egendefinerte kommandoer:
Den refererte VCD-filen er bare en XML-fil som definerer søkeordet for nettappappen og kommandoer som kan utstedes.
Ved hjelp av svært grunnleggende syntaks identifiserer VCD valgfrie biter av en gitt setning og variabler Cortana skal trekke ut:
Gruppepost Gruppepost legg til notat Legg til et notat melding ved hjelp av gruppepost [vær så snill] legg til et notat [at] noteSubject legger til noteSubject til gruppepost
Denne spesielle appen overfører den innfangne informasjonen til JavaScript for behandling. Det stemmer, Cortana har også en JavaScript-API. Temmelig stilig.
Men tradisjonelle datamaskiner og smarte mobile enheter er ikke det eneste stedet vi begynner å se stemmebaserte opplevelser. Vi har også disembodied stemmer som Amazons Echo og Ubi som er helt headless.
Akkurat nå virker de begge rett og slett fokusert på å hjelpe huset ditt til å bli "smartere" -strømmende musikk, justere termostaten etc. - men det er ikke vanskelig å forestille seg at disse enhetene blir kombinert med evnen til å bla gjennom og samhandle med nettet.
I nær fremtid vil talebaserte samspill med nettet være helt mulig. De vil sannsynligvis suge litt først, men de blir bedre.
Jeg skal gjøre en litt dristig prediksjon: mens touch har vært revolusjonerende på mange måter mot å forbedre digital tilgang, vil stemmen bli enda mer signifikant. Stemmebaserte grensesnitt vil skape nye muligheter for folk til å samhandle med og delta i den digitale verden.
Fordi vi har tenkt på hvordan erfaringene vi lager, er forbruksmuligheter på en rekke enheter, har vi hoppet på andre folk som jobber på nettet når det gjelder tale. Vi ser erfaring som et kontinuum, begynner med tekst.
Som stemmen teknologien modnes, vil vi være de menneskene ser til som ekspertene. Vi vil gi den neste generasjonen nettsteder og applikasjoner mulighet til å bli stemmeaktivert, og dermed vil vi forbedre livet til milliarder. Fordi "tilgjengelighet" ikke handler om funksjonshemninger, handler det om tilgang og Det handler om folk.
Visst, vi vil gjøre det enklere å slå opp filmtider og kjøpe billetter for å se det siste transformers debacle, men vi vil også gi de nesten 900 millioner menneskene globalt over 60%, hvorav kvinner er analfabeter. Og det er en befolkning som i stor grad er ignorert på vår dominerende tekstweb.
Vi vil skape nye muligheter for de fattige og ugunstige til å delta i en verden som har ekskludert dem. Du kan ikke være klar, men 80% av Fortune 500-bedriftene tror Target, Walmart-bare godtar jobbsøknader på nettet eller via datamaskiner. Vi vil aktivere folk som har begrensede datakompetanse eller som sliter med å lese for å søke jobb med disse selskapene.
Vi kan bidra til å bygge bro over den digitale skillelinjen og leseferdigheten. Vi kan skape muligheter for at folk skal forbedre livet og familiens liv. Vi har kraft til å skape mer egenkapital i denne verden enn de fleste av oss noen gang har drømt om.
Dette er en utrolig spennende tid, ikke bare for det responsive design fellesskapet, ikke bare på nettet, men for verden! Fremtiden kommer, og jeg kan ikke vente å se hvor fantastisk du gjør det!
Responsive Day Out 3: Den endelige Breakpoint ble avholdt i Brighton, Storbritannia den 19. juni 2015.
Denne artikkelen er en del av webutviklingsserien fra Microsoft tech evangelister på praktisk JavaScript-læring, åpen kildekodeprosjekter, og beste praksis for interoperabilitet, inkludert Microsoft Edge-nettleseren og den nye EdgeHTML-gjengemotoren.
Vi oppfordrer deg til å teste på tvers av nettlesere og enheter, inkludert Microsoft Edge, standardleseren for Windows 10, med gratis verktøy på dev.modern.IE:
Dybde teknisk læring på Microsoft Edge og webplattformen fra våre ingeniører og evangelister:
Flere gratis plattformverktøy og ressurser for webplattformen:
