@txpmag: Onko reagoivalle verkkomainonnalle tulevaisuutta?
EM: On olemassa tarve reagoivasta mainonnasta sanon niin paljon. Päällä Bostonin maapallo, keksimme ratkaisun mainosten reagoivaan reagoimiseen sivuston nesteruudukossa reagoimalla mainokseen sivun hierarkiassa korkeammalle tai pienemmälle, kun näkymäikkuna laajeni tai pieneni. Ja me - ja Maapallo - olivat melko innoissaan toteuttamastamme ratkaisusta.
Mutta huomasimme nopeasti, että asettelu on vähiten ongelmia. Tapa, jolla verkkomainokset suunnitellaan ja myydään, vaatii terveellistä tarkennusta. Sekä Mark Boulton että Roger Black ovat käsitelleet asiaa hyvin yksityiskohtaisesti. Joten muutamia asioita on muutettava. Siihen asti, kun mainosala alkaa ajattelemaan joustavammin, meidän on ehkä aloitettava luovuus ja hahmoteltava vielä muutamia tapoja, joilla mainokset voivat siirtyä työpöydän ulkopuolelle.
@northk: Haluan tietää, mikä on käytännöllisin ja vankka tapa reagoivien kuvien näyttämiseen useilla laitteilla.
EM: No, koko reagoivien kuvien alueella on tällä hetkellä paljon toimintaa. Kaistanleveyden tunnistus on sokea alue kaikki meistä riippumatta siitä, työskentelemme käyttöliittymän tai taustajärjestelmän parissa. Navigator.connection-sovellusta ei ole otettu laajalti käyttöön (tai väitän), että se on tarpeeksi spesifinen, jotta siitä olisi hyötyä, ja me kaikki seuraamme Device APIs -työryhmän mielenkiintoista työskentelyä.
Olen sanonut, että olen todella innoissani kuvakeskustelusta, josta Mat Marquis W3C-yhteisöryhmässä on osannut taitavasti reagoivia kuvia. Ja Scott Jehlin kuvataide tarkoittaa, että voimme alkaa kokeilla sitä tänään.
Meillä ei tietenkään ole edes määrittelyä uudelle merkintämallille, varsinkin toimivalle, alkuperäiselle toteutukselle. Joten ehkä lyhyellä aikavälillä meidän on ehkä luotettava palvelinpuolen sisältöneuvotteluihin - vaikkakin näin on, toivottavasti sillä on enemmän "mobiili ensin" -ajattelutapa, la Brett Jankord's Kategororizr.
Mutta ihmettelen, onko meillä jokin toinen vaihtoehto käytettävissä: miksi emme voi kysyä käyttäjiltämme, mitä kokemusta he haluaisivat? He ovat tottuneet tekemään kosmeettisia käyttöliittymäpäätöksiä aina käydessään Gmailissa tai valitsemaan haluamansa laadukkaan videon YouTubessa. Heck, joka kerta, kun he napsauttavat puhelimessa olevaa "mobiili" - tai "työpöytä" -linkkiä, he valitsevat kokemuksia ja ominaisuuksia, jotka eroavat radikaalisti toisistaan. Joten mietin, onko täällä vivahteikkaampaa ratkaisua: voisimmeko pyytää käyttäjiltämme kertoa millainen kaistanleveyspäätös tehdään?
@christianboyle: Pitäisikö RWD olla valinnainen ja hinnoiteltava erikseen ominaisuutena vai olisiko se oletusarvoinen lähestymistapa ja hinnoiteltava alusta alkaen?
EM: Se riippuu rehellisesti projektista. Kaikkien sivustojen ei tarvitse olla reagoivia, vaikka jotkut eivät hyötyisikään sivustolle optimoidusta lähestymistavasta. Ja yleisösi tarpeiden tutkiminen vastaa siihen paremmin kuin koskaan.
Stevie McKeown: Kirjassasi kannattaa prosenttiosuuksien käyttämistä täytteen ja marginaalin suhteen. Henkilökohtaisella sivustollasi käytät kuitenkin myös pikseleitä ja ems sekä marginaalissa että täytteessä. Mikä on nykyinen neuvosi?
EM: No, sivustoni ei ole reagoiva - se käyttää joustavaa, ruudukkopohjaista asettelua, mutta ei ole kysyttävää mediakyselyistä. Mutta kysymykseesi: Olen suuri fani prosenttipohjaisten vaaka-marginaalien ja täytteiden mittausten ja vertikaalisten vastaavuuksien mittausten puolesta.
Nelson Rodrigues: Mitä puitteita suosittelet suunnittelija- ja kehittäjäduolle, joka alkaa RWD: stä?
EM: Siellä on useita hienoja reagoivia kehyksiä: ZURB: n säätiö, Josh Hopkinsin Fluid Baseline Grid ja Twitterin Bootstrapin 2.0-julkaisu on valinnainen reagoiva ruudukko.
Jokainen näyttää minulle melko pirun lupaavalta, mutta minun on todennäköisesti mainittava, etten käytä CSS-kehyksiä tuotantokoodiin. Minusta ne ovat korvaamattomia prototyyppien luomisessa, ideoiden saamiseksi näytölle mahdollisimman nopeasti ja näkemisestä, kuinka ne ravistuvat reagoivassa ulkoasussa. Lopullisten, asiakasvalmiiden suoritteiden osalta haluan räätälöidä koodin suunnittelun mukaan ja viimeistellä reagoivan suunnittelun, joka on optimoitu oletusarvoisesti pienille näytöille, mutta parantaa asteittain laajempia näyttöjä.
Paul Randall: Mitä laitteita (älypuhelimet / tabletit) ja katkaisupisteitä tyypillisesti kehität ja testaat?
EM: No, olen iso, iso uskovainen, joka pyrkii sovittamaan raja-arvot suunnitteluun, ei yksittäisiin laitteisiin. Jos haluamme tulevaisuuden kannalta paremmin reagoivia malleja, meidän on lopetettava ajattelu '320px', '480px', '768px' tai mitä tahansa muuta - verkko on niin paljon joustavampaa, ja nämä pikselit ovat tilannekuva verkossa, kuten tunnemme sen tänään. Sen sijaan meidän olisi keskityttävä murroskohtiin, jotka on räätälöity työskentelymme mukaan. Ja oletko kyseisten katkaisupisteiden pikselivetoinen vai em-pohjainen, sinä päätät.
Testauksen osalta olen todella onnekas voidessani työskennellä jQuery Mobilen testauslaboratorion vieressä. Mutta jos olet kiinnostunut rakentamaan oman testaussarjan, suosittelen lämpimästi PPK: n ALA-artikkelia mobiiliselaimessa ja Brad Frostin laitteiden ostostrategioita.
