Responsive Web Design Retrospective
•Descargar como PPTX, PDF•
1 recomendación•1,532 vistas
On the first anniversary of the Be Responsive meetup let’s take a look back at the year of responsive web design and how it's fast become just best practice. The accomplishments, the hurdles, the battles still being fought and sharing some of the lessons the team at Isobar have learned along the way.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Responsive Web Design Retrospective
Similar a Responsive Web Design Retrospective (20)
Último
Último (20)
Responsive Web Design Retrospective
- 1. Be Responsive Meet Up 13May2014 ResponsiveWebDesignRetrospective
- 2. Front End Lead @ Isobar Australia dave.sharpe@isobar.com DaveSharpe
- 3. It’s been a massive year
- 6. The way we collaborate Delivering quality Tackling performance Thinking differently Run through
- 11. Brief together Sitting together* Involved earlier and for longer Communication Tools Co-location Broaden your knowledge Clients share the journey
- 12. Deliveryquality
- 14. Lots of tools
- 15. Gotchas
- 16. No easy answer Test early and frequently – milestone showcases Test on real devices, even if only a few Hopefully online tools will mature
- 17. Performance
- 21. Performance As Design “It’s time for us to treat performance as an essential design feature, not just as a technical best practice.” Performance As Design Brad Frost http://bradfrostweb.com/blog/post/performance-as-design
- 22. What tools are you using? Frameworks, libraries, plugins etc? What do you really need? Consider your legacy Sidenote
- 23. ThinkDifferently
- 24. Responsive Web Design Ethan Marcotte http://alistapart.com/article/responsive-web-design/
- 27. Talk more, in person Take interest in other disciplines Test early and often on real devices Focus on performance Continue to think differently
- 28. Front End Lead @ Isobar Australia dave.sharpe@isobar.com DaveSharpe Thanks,
Notas del editor
- Largest full service digital agenciesin AustraliaWith connected offices around the worldIn Australia some of you might remember us as Visual JazzHere we’re a team of 200 or soCreate end to end solutions in the digital space include websites, mobile apps, integrated solutions, games, social and video productionWorking with a diverse set of clients ranging from commercial brands, government, tourism and not for profitWith our FED team currently sitting around 20.I’ve been at Isobar for almost 4 years nowLucky enough to work with a bunch of really smart front end devshelping to hone and refine the way we do thingsWhether streamlining our existing techniques or trying new approachesPlus I get to work closely with other disciplines to help create solutions and solve problems for clientsWhat gets me out of bed in the morning, I’m very much someone who likes to solve problems, and the agency landscape provides a real diverse landscape for that.There’s always different challenges to tackle everyday.
- Less that a year ago we had the first Be Responsive MeetupRan through a timeline of key events around the RWD movement: Articles, Books, Case Studies and Site LaunchesIt was easy then to pretty much wrap everything that was going nowBut over the past year it’s snowballed
- So, Ikinda hate these images now, they were everywhere a year or more ago.2013 was definitely the year of RWDWe saw industry awareness and acceptanceThere was a ton of hard work, and an immense amount of discussion and problem solving that occurredA really massive challenge for us allClients now ‘know’ what it is and that they ‘need’ it be don’t necessarily get itCost, performance and quality are all still hotLost track of the number of responsive sites that have launched.
- We’ve crossed a point where it’s no longer responsive web design, it’s now just web design.From here we now face existing or new challenges in web development.
- So today I wanted to run through 4 of the big ages of changeAnd share some of the experience I’ve seen along the way
- The way we work together has changed significantly
- We’re no longer working in silo’d teams and a waterfall approach no longer works for usEverything is much more dynamic nowWe’re not able to handover and say our part is complete anymore and move onNor does development occur sequentially
- There’s a lot more cross overWhen I started my web career – front end didn’t existThere were designers who worked in Photoshop who then jumped into programs like Adobe GoLive which generated crude HTML and CSS, and they tweaked a littleThen back end developers came along and hacked that into shape as best the could, tables after allI was interested in both design and programming so front end was a beautiful land in between which I fell in love withLike lots people who started out in front end and eventually it became a thing in it’s own right Then a lot of people that have followed have just learnt that discipline, an there’s nothing wrong with thatWhich worked well when we were in silos and more isolatedBut things are changing now with this cross discipline change
- Run through some of the key changes we’re seen at IsobarBriefed together= buy in, opinion, ownership, catch issues earlySit together – open plan office of pods, we shuffle our seating per project, identifying small conversations make all the difference and often lead to bigger important onesComm Tools – Issue Management, Wiki, Chat, Video Conf, less email – these are a must, esp if teams are located separatelyCo-location – be prepare to consider this, may not always be possible but makes a significant differenceTennis AustraliaNetwork 10 our design and development team co-locatedJB Hi-Fi we undertook periods of FED/BED co-location to help with integration supportInvolved earlier and longer – be prepared to stay across a project even when you’re not directly working on itBroaden your knowledge – now more than ever you need to understand the basics of other disciplinesUX and Designers should understand FED basics – HTML, CSS and how web pages flow.Break out of Photoshop, Design/FED prototyping, thinking mobile first is hardFEDs should have appreciation for design aesthetic and user experience – sometimes there are gaps to fill, continuityClient joins the journey – They need to change their expectations too, the easiest way is to take them on the journeyDetail explanation up frontInvolve them closely through the developmentRegular showcases, even when not complete
- How do I test across the ever growing gamut of devices?I assume the situations many of you are different but for a lot access is difficultAnd it’s a challenges to get access to a lot of devicesBut you can get by with a small subset of iOS and Android ones.Remember to get some cheap Android devicesOur experience is you need to be testing on real devices – there’s no substituteAnd you need to test earlyWhile our devs leverage browser developer tools and resizers, weird quirks only show on actual devices.To help facilitate this for large projects we built to sprints or milestones with showcases at the endQA occurs on each milestone to not only track development but raise issues early
- BrowserStack – we use it, our devs don’t like it – too slow; our QA preserve with it, helpful for oldie which we use VMs for anyway. uses emulatorsDeviceAnywhere – we’ve had a play with it, requires more setup with a tightly controlled network such as ours and costs more – still we found it slow but they are real devicesOpenDeviceLab – interesting idea, one in Sydney but a bit of effort to setup and manage
- Touch Dependence– on on of our first large responsive sites we made bad assumption, that if a device supports touch it was a touch device.This caused much brief when Windows 8 came out and touch laptops appearedAlways question the assumptions you make, this is hard on a fast paced project with an aggressive client when we didn’t full understand the implicationsBrowser resizing: In the early days it was quite common for our own QA team and clients to ‘test responsive’ in <= IE8 by resizing the browser.We had the respond jspolyfil running for Media Queries to work.Seemingly small but wasted time an energy before we settled on remove support for media queries on IE8So we separated breakpoints into separate stylesheets and then served all of them to <= IE8Educating clients that they should test websites in IE by resizing the browserOf course there’s an overhead of multiple stylesheet calls for each breakpoint and oldIE gets all of themWe’ve been exploring using SASS for a way to compile two different versions
- Really it’s an old topic which is hot again because of impact of RWDOur laziness with bandwidth has caught upSo it’s hot again because user drop off on slow loading sitesBut interesting side note – we also see clients with secondary concerns around their CDN costsFor example image a with monthly traffic of 4 millions users you can see page weight importance as it goes up in size when they’re charged by the gigabyte
- So there’s a whole bunch we’re been doing for ages on improving performanceMinification, aggregation to lower http request, Icon fonts, SVGs etcBut there are three interesting that have popped upThe firstFocus on Javascript optimization. For the devs out there with Computer Science backgrounds this is all good.The challenge comes in for the many who don’t have this knowledgeThe secondWhich ties into the above is understanding how http delivers the goodsLooking closely at the network requests going outIdentifying problem patterns and making adjustments accordinglyPaul Irish has been talking on this – search for ‘Delivering the goods’
- And the thirdSo this isn’t a new concept, it was thrown around at the start of last year by Brad FrostAnd Tim Kadlec followed up with the idea of setting up a performance budgetBut like with a lot of new ideas, it takes some time for them to growThe idea centres around performance being the entire team is responsibility not just the devsKey focus around UX and designers don’t necessary know the performance implications of their ideasSo this ties back to my earlier point on collaborationWith all disciplines being involved early these can be picked up early and shaped accordinglyHowever documenting a budget or metric is an interesting idea which we’re started to play withWe actually now have clients putting forth their KPI’s too.But it’s not without challengesDepending on where you work it’s likely to be the devs to sell it in, expect some resistance from other disciplinesNot unlike, what we saw with RWDBut it’s our job to push each other, just as the push us to further what’s possible in browser
- Some are bloatedSome are overkill for what you needSome included features you won’t useSome are badly written too and affect page load – social pluginsConsider your legacy tooAre you choosing something because it’s hot right nowAre you choosing a complex route to try something?Consider how will you or someone else go with it 6-12 + months from nowWe’ve had a couple of case where this has gone badBrick walks get hit, people get sick or move on or even knowledge gets forgotten later to cause other people painChoose wiselyWe’re all for tinkering and trial new tech, but assess if it’s right for a project or it’s for playtime
- We’re seeing mobile and content first help us and clients re-evaluate what is really important on large screens.The idea being we start with the essential content and progressively enhance.Sure we can enhance and add more but do we need to?
- Originally sprouted on mobile appsThen found it’s way into solve navigation issues on small screen devicesNow we’re seeing it remain on large screens
- Touch requiring larger hit areas is also filtering through with larger hit areas, and greater spacing leading to cleaner uncluttered large screen designsWork in SwedenBusiness VictoriaHuge Inc