Share
Denne siste delen av Google Maps API for Designers-serien runder opp ting ved å se på responsive design, retinabilder og en rekke test- og feilsøkingsverktøy som gjør livet enklere. Det gir en fløyte-stopp tur gjennom en rekke områder, som du kan utforske videre i dine egne prosjekter.
Responsive hjemmesiden. Venstre - mobil stil. Høyre - laptop / desktop / tablett stil. Med mindre du har snoozing under en busk de siste årene, vet du at responsiv design handler om å gjøre en nettsideendring og tilpasse seg etter enheten den er sett på.
Hjemmesiden til denne demoen (over) bruker også responsivt design for å presentere folk med en endret versjon av kartet, avhengig av enheten, eller mer spesifikt skjermbredden de bruker.
Det første skrittet før vi gjør noe annet er å sørge for at meta-taggen for visningsport er satt i hode av siden din.
Merk: Nøyaktig hvilke viewportattributter du bruker til å sette opp ting, er opp til deg. Les vår guide for flere detaljer.
Den populære tilnærmingen til å håndtere responsiv design som vi skal bruke her, er å søke media spørringer innenfor CSS. Medieforespørsler er en måte å segmentere opp CSS og bruke forskjellige stiler avhengig av for eksempel bredden på visningsporten nettstedet blir vist på.
Koden oppføringen nedenfor er ganske lang, men det er nyttig å se hva som skjer. For å se denne koden i bruk, ta en titt på hjemmesiden. Hvis du ser den på en større skjerm, drar du siden av nettleseren for å gjøre den smalere. Når nettleserens bredde når under 640px, bør designet endres.
Medien spørringen i dette tilfellet er @media (min bredde: 641px) kode på linje 101, og den påfølgende CSS innenfor de krøllete parentesene. Denne medien spørringen kontrollerer enhetens bredde.
Det er godt å bruke en mobil første tilnærming; Dette er ideen om at standardstilen er rettet mot mobile enheter, og da blir unntak gradvis lagt til ved hjelp av medieforespørsler som visningsportene blir større. Denne tilnærmingen hjelper nettsteder med å laste raskere på mobile enheter. For eksempel, ting som det store bakgrunnsbildeet vi har brukt, er bare lastet for større skjerm enheter.
Så i koden ovenfor, den første delen av koden (det vil si over media spørringen - @media (min bredde: 641px) ) vil som standard bli lastet på hver enhet. Og så @media (min bredde: 641px) media spørring laster stilene i de krøllete parentesene for enheter som har bredde over 641px bred.
Et vanlig spørsmål er:
"Hvor skal brytpunktene i designet være?"
Punktet i dette eksemplet er 641px. Denne demoen bruker bare ett bruddpunkt, men ofte vil du ha mer enn en. Dette kan avhenge veldig mye av innholdet ditt, og også på rekke enheter du målretter mot og de populære skjermoppløsningene på markedet.
I dette eksemplet vil iPhone (bredde 640px) vise standard mobil stil, mens iPad2 (bredde er 768) vil vise skrivebordet versjonen. Vårt valgte bruddpunkt er passende for dette kartet, fordi grafikken er for stor til telefonen. Imidlertid kan andre mer tekstbaserte nettsteder finne ut at det bare er når du kommer ned til mye mindre skjermstørrelser at stilen må endres vesentlig, slik at bruddpunktene kan være lavere.
Merk: Når du velger breakpoints, er det ofte klokeste å bare vurdere designen, observere hvor den er pauser, heller enn å sikte på bestemte enhetsoppløsninger. Skjermstørrelsene er så brede og varierte, pluss de endrer seg etter hvert som tiden går, at det ikke er noen måte å nøye følge med på dem.
Det er noen ganger hensiktsmessig å presentere brukere med helt forskjellige versjoner av innhold, avhengig av deres visningsforhold.
I vårt tilfelle gjøres dette med to div koder (dvs.. button_to_map_mobile og button_to_map_standard), som hver inneholder en annen lenke og en litt annen grønn "besøkskart" -knapp. Hvis du er på en bærbar datamaskin eller en stasjonær datamaskin, kan du se hjemmesiden og dra siden av nettleseren din inntil designet endres til mobiloppsettet. Du bør legge merke til at den grønne "besøkskart" -knappen endres litt for å inkludere ordet "mobil". Hvis du klikker denne knappen nå, får du en mobilversjon av kartet.
Medieforespørselen brukes til å alternere som div er for øyeblikket synlig. Dvs. Hvis du ser på koden oversikten ovenfor, kan du se at button_to_map_standard har display: none; brukes til det når standard mobilstil er i bruk, men når medieforespørselen oppdager skjermen er over 641 piksler bred, gjelder den display: block; til button_to_map_standard. (Medieforespørselen gjør det motsatte til button_to_map_mobile div).
Hvis du følger denne opplæringen, lage din egen nettside, ta en titt på kildekoden som er tilgjengelig fra linken øverst på denne siden. Jeg personlig fant det lettere å få noe som begynte å jobbe med "mobile first" tilnærming og ett bruddpunkt, før du utvidet det til en mer komplisert design.
Det er verdt å merke seg at valget mellom alternativ innhold og mottakelig innhold er noe du bør gi reell oppmerksomhet på når du utvikler nettsteder for flere enheter.
Forhåpentligvis har du nettopp tatt et glimt på den nye mobile versjonen av kartet. Vi kommer tilbake til det om et minutt. Men først er det verdt å ta en titt på hvordan hjemmesiden bruker bilder designet for retina skjermbilder.
Retina (og andre hei-pixel tetthet) skjermer har så mange piksler, så nært sammen at det er nesten umulig for netthinnen i et menneskelig øye for å skille mellom enkelte piksler. Retina skjermer anses å være den neste generasjonen av skjermer, og et økende antall enheter har dem allerede, for eksempel iPhones 4 og 5 og noen high-spec MacBook Pros. Ulempen er imidlertid at grafikk som ikke er forberedt med disse skjermene i tankene, faktisk vil se litt uklart ut.
Heldigvis er det noen måter rundt dette. Tilnærmingen du går for, avhenger av selve bildet av selve bildet. Denne demoen bruker to tilnærminger; retina.js bibliotek og SVG grafikk.
Retina.js er et lett JavaScript-bibliotek, som er gratis å laste ned. Du trenger bare å lagre JavaScript-filen ved siden av nettstedet ditt på serveren din, og legg til følgende kodelinje like før avslutningen kropp stikkord.
Du lagrer deretter to versjoner av hvert bilde; en to ganger størrelsen du vil vise bildet på på en standard skjerm, og den andre i normal størrelse. Trikset for å få dette biblioteket til å fungere er at du må lagre bildene dine i samme mappe på serveren din og følge strenge navnekonvensjonen -
Du legger deretter til bildet ditt til sidemarkeringen som vanlig, bare ved å legge til standardoppløsningsversjonen -
Når noen ser på nettstedet ditt på en netthinnen, forteller tilstedeværelsen av retina.js-skriptet nettstedet ditt for å sjekke om det er en høyoppløselig versjon tilgjengelig.
Selv om retina.js har begrensningen av tiden det tar å lagre to versjoner for hvert bilde, kan det være veldig nyttig for fotografiske eller ikke-vektor type bilder.
Den grønne "besøkskart" -knappen på hjemmesiden bruker retina.js-plugin. For å se dette i aksjon, prøv å se på nettstedet på en netthinnenhet, f.eks. iPhone 4 eller 5, og se på hvor skarp teksten på den grønne knappen er. Hvis du har lastet ned din egen kopi av koden, fjerner du retina.js-plugin-modulen og ser på nettstedet på netthinnenheten igjen. Du bør legge merke til at kvaliteten på knappen (for eksempel de hvite linjene i teksten) er dårligere.
Jeg vil anbefale å bruke retina.js for viktige fotografiske eller ikke-vektor type bilder som ikke endres ofte, på hjemmesiden din eller innebygd i malen. Men hvis du for eksempel driver en blogg med flere forfattere, er det sannsynligvis urealistisk å forvente at de skal lage to versjoner for hvert bilde.
En annen tilnærming til å skape skarp grafikk for retina skjermer er å bruke SVG bilder. SVG står faktisk for skalerbar vektorgrafik. Som navnet antyder, er SVG-bilder egnet for vektortypebilder (det vil si ikke bilder!)
Som vektorgrafik forstørres, beholder de sin skarphet. For å se et eksempel, ta en titt på hjemmesiden. Gears og spanner ikonet er en SVG grafikk. Bredden er satt til 50%. Når du endrer størrelsen på nettleseren din, bør du kunne se at den alltid holder seg perfekt skarp. Den forblir også perfekt skarp hvis du zoomer nettleseren din (for eksempel på en telefon).
SVG-grafikk er faktisk et XML-basert vektorformat. Dette betyr at du kan redigere dem direkte, hvis du ønsker det, ved å bruke et grunnleggende tekstredigeringsprogram. Koden ovenfor lager et bilde av den gule sirkelen nedenfor.
Enkel SVG demo (skjermbilde). Du kan sette inn SVG-bilder i websidene dine på samme måte som du vil sette inn et jpg eller et annet bilde.
SVG støttes av alle moderne nettlesere, inkludert de som brukes på netthinnenheter som iPhones 4 og 5. Det er imidlertid fortsatt viktig å gi tilbakebetaling for eldre nettlesere som ikke støtter dem, for eksempel IE 8. Hvis du er bruker Modernizr (se nedenfor) allerede for resten av nettstedet ditt, så er dette en fornuftig tilnærming. Det er imidlertid også en dedikert JavaScript-plugin tilgjengelig, SVGeezy, som vil håndtere dette.
For å bruke dette pluginet, last ned skriptet og lagre det ved siden av nettstedet ditt på serveren din. Deretter legger du til følgende linje kode før lukkekroppen.
På samme måte som netthinnen plugin diskutert ovenfor, vil du faktisk gi to bilder hver gang; SVG-filen og jpeg- eller png-filen. Disse begge må lagres på samme sted på serveren din. Når SVGeezy plugin merker at nettleseren din ikke støtter SVG-filer, vil den bruke den alternative versjonen av bildet.
Hvis du har lastet ned kildefilene for demoen fra koblingen øverst på denne siden, kan du se på SVG-filen refresh.svg og hvordan tutorial4_index.html filen bruker dette bildet.
Når det gjelder å lage SVG-filer, er ideen om å manuelt kode en bildefil nok til å gjøre selv den geekeste geeken kjørt en mil! Heldigvis kan du lagre bilder som SVG-filer fra Adobe Illustrator (Klikk Fil> Lagre> SVG) eller åpen kildekode vektorredigeringsprogramvare, Inkscape. Å si at jeg vil anbefale å gjøre noen prøveversjoner på dette for å sikre at designene dine vises som forventet i nettleseren.
Det er også mange nettsteder rundt som tilbyr gratis SVG ikoner for nedlasting. Gears-ikonet som brukes i denne demoen, er fra spillikoner. Et annet godt nettsted er Icon Finder, som viser tilgjengelige formater sammen med alle søkeresultatene. Ikon Finder er også ganske nyttig for å få en følelse for hva slags bilder som kan produseres som SVG-filer.
Selv om SVG-filer kun vil fungere for enkelte typer bilder, kan de utnyttes nøye med en kraftig måte å levere skarp grafikk på alle enheter på. Før du går videre, er det verdt å nevne at det finnes andre måter å implementere retinabilder på, ikke implementert i denne demoen, for eksempel å bruke en PHP-løsning på server side som bruker informasjonskapsler og endret .htacces-fil, eller ved hjelp av ikonfonter.
Denne demoen har to versjoner av kartet; en bærbar PC / desktop / tablet versjon og en mobil versjon.
Både mobil og skrivebordskort bruker de samme dataene (dvs. bilder) som er lagret på Flickr. Å lage to versjoner kan virke som en snill å snyte. Og for de aller fleste nettsteder ville jeg ikke anbefale separate mobile og desktop versjoner på grunn av det åpenbare vedlikeholdskostnader. Den nye typen Google-kart vi har bygd på er imidlertid et tilfelle når det er fornuftig å ha to versjoner.
Avgjørende, selv om vi ikke skal duplisere dataene. I stedet, begge versjoner av kartet tegner seg fra samme sett med data på Flickr. Dette betyr at overhead for å ha to versjoner er minimal, og vi har fleksibilitet til å tilpasse utseendet på kartet, avhengig av enheten.
Jeg har utvidet eksemplet fra den siste opplæringen. Opplæringen trekker data fra denne nye Flickr-kontoen (bruker id: 99915664 @ N08). (Påminnelse - hver Flickr har en enkel (ish) å huske brukernavn, i dette tilfellet bennett1671, og et bruker ID nummer, i dette tilfellet 99915664 @ N08.) Så hvis du følger med å bygge på hva du gjorde i den siste opplæringen, må du peke kartet til denne nye Flickr-kontoen.
Denne nye Flickr-kontoen inneholder bilder for alle festivaler, inkludert både de mindre og viktigste hendelsene. Flickr-kontoen som ble brukt i den forrige opplæringen, inkluderte bare bilder for de mindre festivaler. Bildene til hovedhendelsene ble ikke lagret på Flickr.
Merking av bildene dine i Flickr er nøkkelen til å få dette til å fungere. Hvert bilde i Flickr er merket for å indikere om de er en hovedseremoni eller a smallevent (disse kodene er nødvendige for bærbar PC / desktop / tablett versjon) og om de er en englandevent, scotlandevent, walesevent eller irelandevent (disse kodene er nødvendige for mobilversjonen).
Når knappen oransje mindre hendelser klikkes på den bærbare / desktop / tablet-versjonen, blir følgende Flickr API-anrop gjort. Dette kaller 99915664 @ N08 Flickr-kontoen og filtrerer resultatene med taggen smallevent.
http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=f7095d157adfd78715344ed893a9554b&user_id=99915664@N08&tags=smallevent&has_geo=1&extras=geo&format=json&jsoncallback=?
På mobilversjonen har jeg gruppert markørene i henhold til land og farget ikonene tilsvarende. Så, for eksempel når du klikker på den hvite engelske markøren, blir følgende Flickr API-anrop gjort. Denne API-anropet er det samme som det forrige, bortsett fra at det filtrerer resultatene basert på taggen englandevent.
http://api.flickr.com/services/rest/?method=flickr.photos.search&api_key=f7095d157adfd78715344ed893a9554b&user_id=99915664@N08&tags=englandevent&has_geo=1&extras=geo&format=json&json&jsoncallback=?
Vennligst se den forrige veiledningen for en fullstendig beskrivelse av hvordan resultatene av disse Flickr API-anropene behandles. De bruker begge flickr.photos.search-metoden fra Flickr API.
Alle kartmarkørene på mobilversjonen er SVG-filer (se ovenfor). Derfor, selv om de er litt enklere enn ikonene på laptop / desktop / tablet-versjonen, forblir de alltid skarpe når de vises på netthinnen, for eksempel iPhone 4 eller 5.
For å avslutte denne opplæringsserien, vil jeg bare fremheve noen få verktøy som jeg finner nyttige når du utvikler kart, eller noe annet online for den saks skyld. Jeg vet at det er tusenvis av verktøy rundt, og det er derfor ikke ment å være en uttømmende liste på noen måte. I stedet er det verktøysettet som jeg bruker til å teste ting, og finne ut hvorfor noe ikke har gått å planlegge.
Disse verktøyene er nyttige, kanskje viktige, for å unngå marerittet for å få et nettsted til å fungere perfekt på din egen maskin, bare for å oppdage at det gjør noe uventet på en klient eller kundes maskin.
For å få tilgang til Chrome-utviklerens verktøy, åpne Chrome og klikk på Menyknapp øverst til høyre og deretter Verktøy, deretter Utviklerverktøy.
Elementer-fanen i Google Chrome Utviklerverktøy lar deg klikke på deler av nettsiden din for å avsløre informasjon om hvordan den har blitt gjort av nettleseren. Dette gjør en enorm mengde ting; nok til å fylle en hel opplæring på egen hånd! Noen få biter jeg bruker ofte er:-
Nettverk-fanen forteller deg hvor lang tid hver del av en nettside tar for å laste. Ikke alle nettlesere støtter alle HTML- og CSS-funksjoner. Dette kan være problematisk når du vil dra nytte av de mer interessante funksjonene i HTML5 og CSS3, samtidig som du sørger for at folk med den eldste kopien av IE også kan få tilgang til nettstedet ditt.
Men med mindre du har et ekstraordinært minne (jeg har ikke!), Er det nesten umulig å huske hvilke nettlesere som protesterer mot hvilke funksjoner. Dette er hvor caniuse nettstedet kommer veldig bra. Dette nettstedet gir et sammendrag av hvilke HTML, CSS, SVG etc. funksjoner er kompatible med hvilke versjoner av hvilke nettlesere.
Også, hvis du vil bruke en ny funksjon, men eldre nettlesere ikke støtter det, kan du bruke Modernizr JavaScript-biblioteket. Som de forklarer på deres hjemmeside:
"Å dra nytte av kule nye webteknologier er gøy, til du må støtte nettlesere som går bak. Modernizr gjør det enkelt for deg å skrive betinget JavaScript og CSS for å håndtere hver situasjon, enten en nettleser støtter en funksjon eller ikke. "
Hvis en brukeres nettleser ikke støtter en bestemt funksjon, lar Modernizr deg også spesifisere en tilbakekallingsfunksjon. Dette ligner veldig SVGeezy-plugin-modulen beskrevet ovenfor.
I tillegg til å planlegge nettleserstøtte og tilbakekallinger mens du bygger nettstedet ditt, er det også viktig å teste det på forskjellige nettlesere. Browserstack er en effektiv måte å gjøre dette på. Den lar deg sende inn en nettadresse og deretter se på hvordan nettstedet fungerer i forskjellige nettlesere. Den eneste ulempen er at det innebærer et abonnementsavgift. Selv om dette er uten tvil billigere enn å ha en bank med ekte maskiner og enheter tilgjengelig for testing. En gratis prøveversjon er også tilgjengelig, så du kan ta en titt og se hva du synes.
Et annet nyttig nettlesertestingsverktøy når det gjelder mysterier for å få ting som fungerer i IE, er Modern.IE nettsiden. Som navnet antyder, er det bare for IE. Men det er gratis og er fortsatt en svært nyttig ressurs.
Før du tar en titt på nettstedet ditt i Browserstack eller ModernIE, er det viktig å validere koden din for å stryke ut eventuelle syntaksfeil.
En validator er en gratis web-app som sjekker koden din mot gjeldende standarder. Standarder er viktige for å sikre at nettstedet ditt fungerer på en forutsigbar måte over ulike nettlesere og enheter.
Det finnes også en rekke verktøy rundt som vil hjelpe deg å sjekke JavaScript-syntaksen din. Closure Compiler er faktisk et verktøy for å komprimere JavaScript (som du kanskje også vil gjøre hvis filstørrelsen er enorm), men det er også nyttig for å sjekke syntaksfeil. f.eks pesky savner halvkolonner som fanger oss alle! Hvis du kopierer og limer inn i koden din og klikker på Kompil, vil eventuelle feil bli uthevet under kategorien Feil. Et annet nyttig nettsted for å sjekke koden er JSHint.
Sidens hastighet er viktig fordi ikke bare besøkende vil bli drevet bort hvis det tar lang tid før nettstedet ditt lastes inn, kan Google ta hensyn til dette når du bestiller søkeresultater.
Det finnes en rekke verktøy som lar deg teste dette, inkludert -
Disse verktøyene kommer også med forslag til forbedringer du kan gjøre. For eksempel, en vanlig forbedring du kan gjøre er å komprimere bildene dine ytterligere. Du kan bruke disse verktøyene i forbindelse med Nettverk-fanen på Google Chrome Utviklerverktøy (ovenfor) for å undersøke potensielle problemer.
OK - det er det! Som jeg sa i begynnelsen av denne opplæringen, ville det være en fløyte-stopp tur! Forhåpentligvis etter denne opplæringsserien er du nå rustet til å lage dine egne Google Maps-kreasjoner. Ha det gøy!
Kredittene for de fleste bildene (for eksempel festivalens bilder) finnes på slutten av de tidligere opplæringsprogrammene 1 og 3. Dette er de nye brikkene for denne opplæringen:
Accentsconagua