• Share
  • Email
  • Embed
  • Like
  • Private Content
Is everything we used to do wrong?
 

Is everything we used to do wrong?

on

  • 2,364 views

Many developers used to believe that class-free, lean markup and descendant selectors were the answer. Many developers still build websites for a single resolution, or a small range of devices. ...

Many developers used to believe that class-free, lean markup and descendant selectors were the answer. Many developers still build websites for a single resolution, or a small range of devices. However, these practices are now being questioned. Where do we stand? What is best practice web development today? Russ Weakley will explore these topics and more... or possibly less...

Statistics

Views

Total Views
2,364
Views on SlideShare
2,362
Embed Views
2

Actions

Likes
2
Downloads
111
Comments
1

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel

11 of 1 previous next

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • With my Nexus 10 I have a higher resolution screen than either of my dual 24' screens for my Power Mac workstation. It would be a shame to feed the Nexus lower resolution imagery.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Is everything we used to do wrong? Is everything we used to do wrong? Presentation Transcript

    • is everything we used to dowrong
    • This presentation is going to look at some of our best practices from the past, and what are considered best practices today.
    • First of all, an admission…
    • I’m not a fan of the term“best practice” any more.
    • Best practices:right vs w rong
    • If we define one method as the “right way” it oftenimplies that other methods are wrong.
    • While there are definitely“bad practices”, there are many situations where there are no clear right or wrong solutions.
    • “Today, anything that’s fixed and unresponsive isn’t web design, it’s something else. If you don’t embracethe inherent fluidity of the web, you’renot a web designer, you’re something else.”http://stuffandnonsense.co.uk/blog/about/i_dont_care_about_responsive_web_ design/
    • Best practices:things change
    • If history has taught usanything it’s that everything changes over time.
    • Tables vs CSS
    • “My rule of thumb is Consistency, Consistency, Consistency... If CSSworks for a project, then I use it. If itdoesn’t look like it will, I use tables.” http://www.raizlabs.com/blog/148/ten-reasons-why-css-sucks
    • Microformats
    • “The blog is neglected, thereve been no new formats promoted … none of uswork actively on it, … the mailing lists are deserted. It is an entirely legitimate impression that the effort has folded into irrelevance.” http://microformats.org/wiki/events/2011-03-sxsw
    • The <i> element
    • The i element now represents a span of text in an alternate voice or mood, orotherwise offset from the normal prose ina manner indicating a different quality of text, such as a taxonomic designation, atechnical term, an idiomatic phrase from another language, a thought, or a ship name in Western texts. http://www.w3.org/TR/html5-diff/
    • Um.. then there is myRemix07 presentation…
    • “Why separate your CSS? It’s easier tofind rules. More than one developer ata time. Files can be turned on or off as needed.” http://www.slideshare.net/maxdesign/modular-css
    • Best practices: pend on skillsde
    • Best practices may be quitedifferent depending on the skill area.
    • For example, best practicesin front end development may be different from best practices in UX, SEO and Social media…
    • Best practices: e pend on te amsd
    • Best practices may be quitedifferent depending on the team you work with.
    • As an individual, you mayhave specific best practices.However, these may have tochange when working in a team environment.
    • outcomes not techniques
    • Instead of talking about bestpractices as techniques, we should probably focus on outcomes.
    • Let’s take front enddevelopment (HTML, CSS,JavaScript) as an example:
    • What are some of ourdesired outcomes?
    • Outcome 1:u sers come first
    • We should not do anything that makes the user experience harder.
    • We should make sure our sites are accessible to all users.
    • We should make sure our sites are accessible to all devices.
    • We should make sure our sites are accessibleregardless of bandwidth.
    • Outcome 2: elop efficientlydev
    • We should aim to develop using efficient methods, to reduce overall development time.
    • We should aim to developusing methods that avoid repetition.
    • Outcome 3:m ain taina ble, s cal able
    • We should aim to developusing practices that allow easy maintenance.
    • We should aim to developusing practices that allow our sites to scale well over time.
    • Outcome 4:fast page load
    • We should aim to developsites so that pages load asquickly and efficiently as possible.
    • Outcome 5:backawar d and comp atibleforward
    • Does anyone else hate the term “future proof”?
    • XHTML 1.0 was supposed to be a future-proof language
    • We have to be careful notto leave our users behind in the rush towards the future.
    • For example, JavaScriptbased solutions should be built so that they fail gracefully.
    • We should be careful about abandoning users witholder devices because wedon’t want to support them.
    • Some techniquesthat aid our outcomes
    • So, here are some strategies and techniquesthat are currently considered “best practices”.
    • Be warned, these may not be considered“best practices” in the future!
    • More importantly, these best practice techniques aredesigned to help us achieve some key outcomes.
    • Reducingrepetition
    • 1:CSS resets
    • CSS resets aim to removebrowser-specific styles, andthen build up from scratch - so that each element will appear the same in all browsers
    • html,body,div,span,applet,object,iframe,h1,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,address,big,cite,code,del,dfn,em,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dl,dt,dd,ol,ul,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,article,aside,canvas,details,embed,figure,figcaption,footer,header,hgroup,menu,nav,output,ruby,section,summary,time,mark,audio,video{ margin:0; padding:0; border:0; font-size:100%; font: inherit; vertical-align: baseline;}
    • Strengths:Efficient developmentConsistency for teamsWeaknesses:lots of additional rewriting
    • 2:CSS frameworks
    • CSS frameworks are pre-prepared libraries thatallow for easier, standards- compliant styling of web page components.
    • Many frameworks focus on layout grids, allowingdevelopers to pull in libraryclasses to build complex layouts.
    • .column, .span-1, .span-2,.span-3, .span-4, .span-5,.span-6, .span-7, .span-8,.span-9, .span-10, .span-11,.span-12, .span-13, .span-14,.span-15, .span-16, .span-17,.span-18, .span-19, .span-20,.span-21, .span-22, .span-23,.span-24 {float:left;margin-right:10px;}
    • Keep in mind you canalways roll your own framework.
    • StrengthEfficient developmentLean, abstracted CSSWeaknessesDesigns that don’t fitBloated frameworksPresentational class names
    • Maintainableand scalable
    • 3:Object-oriented CSS
    • How many timesdoes your CSS file mention H2 or “float: left”?
    • Do you ever findyourself stylingusing Firebug?
    • Object-oriented CSS styles HTML “objects” or “modules” with cleaner, more efficient CSS.
    • For all the hardcoredevelopers… yes, it’s not really object-oriented. It’s just a name!
    • There is a strong chance that you may be “doing itwrong”, or could at least be “doing it better”.
    • How do we useObject Oriented CSS
    • Before starting your CSS, look at your layouts and try to find patterns.
    • Are there aspects of the layout that could beabstracted into library items?
    • Strengthslean, robust CSSeasier site maintenanceavoid repetitive CSSavoid specificity warsWeaknessesadditional HTML classesnew mindset
    • Efficiency
    • 4:Pre-processors
    • Pre-processors allow us touse variables in CSS files and then parse them to regular stylesheets.
    • There are many different frameworks available: • LESS • SASS • Turbine • Switch CSS • DtCSS • CSS Crush
    • Variables
    • @color1: red;@color2: green;@color3: blue;@color4: orange;@color5: brown;#a { background: @color1; }
    • Minification
    • div{width:200px;height:200px;-webkit-border-radius:10px;-moz-border-radius:10px;border-radius:10px;}#one{background:red;-webkit-border-radius:20px;-moz-border-radius:20px;border-radius:20px;}#onea{color:green;}#two{background:green;-
    • Mixins
    • .border-radius(@radius: 5px){-webkit-border-radius: @radius;-moz-border-radius: @radius;border-radius: @radius;}div { .border-radius(); }
    • PackingGzippingCompiling
    • Strengthfaster developmentvariables!Weaknessesdeep nestinginefficient CSSentirely new syntax
    • Deviceindependence
    • 5:Responsive design
    • Until recently, people builtsites for desktop and/or mobile only.
    • Responsive design isabout creating sites that adapt to any device.
    • Problem 1:solving screen size
    • Ideally, we want to start with a single linear layout that can be viewed by any device.
    • Then we gradually build a series of advanced fluidlayouts on top, controlled by media queries or JavaScript.
    • @media only screen and(min-width: 800px) and(max-width: 999px){}@media only screen and(min-width: 1000px){}
    • This means we can deliver entirely different layouts based on the viewport.
    • Problem 2:Solving bandwidth issues
    • But what aboutimages and other rich media?
    • Ideally, we should deliverlow end images and media as the default.
    • Then we deliver larger,richer media for thosedevices with suitable bandwidth.
    • Problem 3:content and context
    • Another problem we face is determining what types ofcontent should be delivered to devices, and in what context are people are using the site.
    • It is not as simple as delivering stripped back content for mobile devices andrich content for desktops.
    • The reality is that these lasttwo problems are not solved yet. But a change is coming.
    • I think we are at a tipping point. Very soon, a major site is going to crack thesethree problems and change the way we build sites.
    • Final words?
    • A solution that seems ideal today may beoutdated tomorrow.
    • Focus on outcomes rather than using the latest technique.
    • But most of allwe should have fun!
    • So, what are yourbest practices?