Screenshot of my 24ways article

I was asked to write an article for 24ways.org, the well known web advent calendar, this year. It was published today! Hop over and read about The Accessibility Mindset. Thanks for all the good work behind the scene, Drew, Brian, Anna, and Owen!

If you prefer to read the article in German, don’t shy away and see Accessibility im Sinn, published on the Webkrauts Adventskalender. Thanks to Matthias, Jens, Nicolai, Kerstin, and Nils for their continuous efforts to bring those articles to the German speaking audience.

  • Open data
  • Big data buzzwords
  • 90% of the world’s data was created in the last 2 years
  • Several ways to use data in your work
  • Tea tracker for personal tea consumption
  • Data is often restricted
    • Only certain data is displayed
    • Can’t use data freely
    • restricted
  • You sometimes can’t get your hand on the data that you want
  • Data sharing
    • Restrictive data sharing to restricted set of people
  • Open data means to not be confined to the data provider’s conditions
  • Opendefinition.org
  • Open data and content can be freely used, modified, and shared by anyone for any purpose.
  • Data spectrum: http://theodi.org/data-spectrum
  • Re-publish
  • Derive new content or data
  • make money by selling products
  • charge a fee for access
  • data needs to be open, but the delivery access (API) can be restricted
  • Licensing similar to the known content licence, not just Creative comments, for example Open Government Licence or OS Open Licence ect.
  • Dbpedia – Wikipedia data in RDF
  • Data.gov.uk
  • MusicBrainz
  • plaidplug.com
  • awesome-public-datasets
  • Consuming open data is pretty easy
    • data is not special
    • download periodically or via API
  • Sometimes data is released as PDF, “openly”
  • d3js.org – Data-Driven Documents
  • Example: Mark up fire hydrant violations in NY, top grossing hydrant was actually very confusing for parkers, almost a trap. Reaction from administration: Make clear where not to park.
  • open data -> may generate 3 million dollars
  • Transparency
    • Not only access
    • but also analyze and visualize
    • combine with other data
    • freely to use
    • open by default would save so much time
  • Data and User Experience
    • mapumental.com answers the time to work in minutes instead of miles.
    • How accessible is our nearest school, post office or hospital?
    • How quickly could fire engines reach a given postcode?
    • Improved efficientcy, effectiveness, measure impact
    • Improved products
  • Not just digital, also in the real world, for example as art
    • Internet of things
    • opensensors.io
    • dougmccune.com – Artistic projects based on open data
    • stevanie posavec
  • Linked data
    • timbl doesn’t only want us to share documents but also the data
    • new knowledge from combined data sources and patterns
    • Misinterpretation:
      • Some sites don’t allow it because they don’t want to have their data in the wrong context
      • spurious-corelations
    • Combining data sets & licenses
  • Publishing open data
    • People use it in ways you never dreamt of
    • Step one: Identification & planning
    • Clear licensing & usage information
    • Structure & quality
    • A plan for support – data needs to be maintained
    • Accuracy
    • Step two: transform and clean data
      • data privacy & the individul
      • openrefine
      • cleansheet
    • Step three: Sharing
      • http://5stardata.info/en/
      • think about your data from the beginning
      • https://certificates.theodi.org
  • In conclusion:
    • We collect and share data and it is a component to the web, just like documents.
  • Slides: http://www.slideshare.net/sallyjenkinson/an-introduction-to-open-data-53732088

  • Lets compare tooling to plumbing
  • new type of fitting: Sharkbite
    • Lego for plumbing
    • snaps together instantly
    • can connect any material to copper
    • can be redone
    • less prone to leaks
    • more expensive
    • less error prone
    • plumbers: too expensive, too new
    • changes the industry competely.
  • Some people write off tooling as over-engeneering, others see the benefits
  • Fine line between tooling for tooling’s sake and tooling to get work done
  • Let’s be smart about the tools that we’re using
    • Investments need to pay beck
  • Overwhelmed? Crying? 😭
  • This talk: 😭-> 😃
  • Build tools:
    • biggest barrier to entry
    • a lot
    • what are they for
    • compiling + converting styles
    • concatenation
    • test running
    • deployment
    • anything, really
    • two big: grunt, gulp
    • npm as a built system by using the CLI commands directly using scripts in the package.js, takes bash
      • But probably best used with simple sites
      • hard to maintain
    • Webpack
      • javascript modules focused – gulp meets browserfy
      • bit of a hard to learn api
      • react community likes it
    • What should I use?
      • Pick one. Whatever is best for you.
      • Personally like gulp
        • built speed
        • packages available
        • easy to understand and author
        • overall industry acceptance
        • 47% use gulp, 20% don’t use anything
      • Sass brought people to the built train
  • Performance
    • Critical: First paint is important
    • Purify: Removes unused CSS
      • Looks at JS and CSS and finds unused CSS
      • Much smaller CSS files
    • ImageMin: common interface to 17 different image compression libraries
      • Recommendation: MOZJPEG
    • Uglify.js: Minifies, compresses and mangles code
  • Dependency + Module Management
    • We’re seeing a huge shift on how we manage frontend dependencies
    • Problem: Many scripts, duplicated, different versions of the same file
    • The solution: Modules for javascript
    • How does it work
      1. Install your libraries, ex. npm/bower install jquery
      2. Write your code, ex. var$ = require(‘jquery’); or in IE6: import $ from jquery
      3. Compile into a single or multiple bundles
        • Browsify – simple, quickest setup
        • WebPack – handles css
        • JSPM – client side, close to JS spec
      4. Stop?! What about Gulp/Grunt?
        • They are task runners, one of the tasks will be “bundle javascript”, they can call those bundlers.
    • Small modules that do one thing, and one thing well
    • Only need ajax, npm install fetch
    • Pick and chose from lodash
      • Is coded in a way that you can access all methods individually, exports only that module to use
    • NPM or Bower?
      • Libraries, similar
      • NPM for everything!
      • Ecosystems coming soon to NPM, helps categorize the modules
  • The Future
    • JS + CSS evolve rapidly
    • Don’t need to wait with future code today
    • Wasn’t possible before
    • JavaScipt
      • ES6/7/Next
      • Arrow functions
      • let and const for variable declarations
      • template strings
      • many more
      • Babel
        • Allows you to write IE6 code but will then compile it to code that will work today.
        • gulp-babel
        • What about new language features?
          • polyfillable require babel/polyfill
    • CSS4
      • Everyone 😍 SASS, comes to browser
        • Nesting
        • Scoping
        • Variables
      • CSSnext allows to write in CSS4 and compiles to CSS3
      • part of postCSS ecosystem
      • quantityQueries helps to work with those, also a postCSS plugin
  • Workflow treats
    • Browsersync – like live reload but actually works
      • Instant reload
      • Includes server with cert for easy local HTTPS
      • Proxies existing applications/servers: Wordpess, ruby, python
      • Exposes server via local IP, can test on multiple devices
      • Syncs clicks, submits, scrolls
      • MAGIC
    • Sourcemaps
      • Code goes through several transforms before it is in the browser
      • If there is an error that needs to be traced back
      • Sourcemaps is standardized
      • Can be used with a lot of plugins
  • Tooling is extremely important
  • Everyone should have  built process
  • Sky is the limit
  • Better code

  • Simplicity is not dumbing down.
  • There is room for creativity even in relatively simple things.
  • Let’s focus on what matters.
  • Helps to provide the right optimizations for users.
  • Benefits about static sites
    • cheaper, simpler hosting
    • fewer points of failure
    • fewer vulnerabilities
    • easier compliance
    • greater portability
    • sandboxed environments
    • attrition avoidance
  • Credibility of static sites
    • Just for simple things? That’s not the case
    • Campaign for Obama – $250 million dollars donated
      • Static sites perfect for large audiences
      • baked with jekyll
      • large audience
      • rapid iterations
      • hosted statically
    • Google project
      • Content on Github
      • baked with jekyll
      • served staticly by google
      • Reduced risk
    • Google year in search
      • Annual retrospective
      • large audience
      • infrequently updated
      • long life
      • 40 stories, 52 languages
      • 2.6B social impressions
      • content abstracted
      • baked with “goro”
      • served staticly by google
    • Static sites are already mainstream
    • Enablers:
      • Front end tooling is a key part
      • Generators and templating -> staticsitegenerators.net
      • Style guides as a side effect… as an artifact… as a process
        • Styleguide driven development
        • How to have a style gide as a secondary output for your site
        • Modules + Templates + Content built site through generator
        • Style guide also built there
        • Unless a style guide is part of your built, it is just more documentation to maintain
      • Automation
        • Gulp grunt, brunch, belch, burp, cough, sneeze ;-)
        • deploy faster, safer
        • update faster
        • feels dynamic
        • surge is good tool to do this deploy
    • We need a developer mindset and people want to manage content themselves.
      • traditional web development is very complex with dev, staging and live stages
      • also server side logic
    • Static sites are simpler
      • Dev environment: Site generator & build tool -> Production -> User
      • Content as a service that cares about the admin interface.
      • Additionally you could use deployment as a service
      • Is that simplifying?!
        • It’s about shifting/outsourcing complexity. Distance between user and complecity.
        • Source content at build time, not execution time
      • Jekyll data
      • contentful is Content Management as a Service
        • Hosted CMS interface
        • Exposes content via an api
        • Supports translations
        • user roles & management
        • Environments & versions
        • Decouples content administration from the production invironment
        • integrates into jekyll: jekyll-contentfull
      • roots.cx
      • netlify for deployment
        • commit hooks
        • command line interface
        • portable configruration, can be in a config file in the repo
        • notification
        • control of headers
        • basic auth
      • A lot of control
    • Limitations:
      • personalization
      • very very large sites
      • user generated content
    • Need to find the best fit for the project
    • It depends
    • http://bit.ly/ssg-hollywood

  • SASS well received although it is built in Ruby. But it is slow and no-one uses it for something else, also it loses to nodejs.
  • libSass developed, a C/C++ port of Sass engine but not with all features.
  • Most other languages can use the libSass binaries.
  • Big bet on libSass, has now 98% compatibility – mostly edge cases missing.
  • Worth it? – libSass is very fast
  • Downsides:
    • Binary files – OS/HW dependent
    • C++ not known by many webdevs
    • slow to develop new features
    • Ecosystem fragmentation
  • Focus on the JS portion
    • libSass to node.
    • Don’t want people to have tools with less features.
    • C++ <-> Node.js bridge
  • Compass not ported to libSass
    • Best parts of compass regenerated in JavaScript.
    • Stop development of compass.
  • Sass modules as npm modules instead of ruby gems.
  • New open source project with support from linkedIn
    • Eyeglass takes compass features to JS
    • Distribute Sass modules via npm
    • Import Sass from modules
    • Define Sass functions in JS
    • Global resolution of shared dependencies
    • Deliver assets with the right URLs.
    • Node-like importing
    • Filesystem API
    • http://eyeglass.rocks
    • 30 modules on npm under eyglass-module
    • Install: npm install –save-dev module_name
    • Use: @use module_name.sass(?)
    • Eyeglass is not an asset pipeline.
    • Motivation is to make it easier to contribute to eyeglass
    • Module: Sprite maps for Sass files
      • Advantage: Works with multiple file formats
      • Files can be in several directories
      • No “Magic Import” that was confusing to people
  • Use libSass. It’s ready
  • Use eyeglass to distribute Sass.
  • node-sass-utils for writing Sass functions in JS.
  • But the Ruby Sass is not dead.