- How do we adapt the things we make to different spaces?
- We used to think about the web in pages, back when RWD became first defined.
- We now think about components.
- On average a large site may have 200+ media queries.
- We are trapped, media queries are defined by pages.
- We think about components, and less frequently about pages.
- The element query would allow us to adapt content to the size of the content.
- The element query is great for how we think now.
- The element query is great for circular dependancies.
- It’s the circular dependency that killed the element query.
- The element query became the container query, it’s a problem that needs to be solved.
- It’s possible to use “element flow” to hack container queries.
- Flex-grow can change how content displays as element grows and shrinks, regardless of the page.
- display: container can be used to allow use to use flex-box order to content based on the containers size.
- Nesting the picture element as foreign object in an SVG give the picture element a container query.
- The best thing to do to get a container query is to get involved in the RICG.
Archives: Notes
-
-
<picture> perfect: designing with responsive images
- about half the room is using responsive images
- smashing magazine twitter survey found 58% of people didn’t use them
- responsive images allow us to support a range of devices, the best image for a device is delivered
- img[srcset] takes a definition of image sources, the browser selects the best image to use
- img[sizes] allows us to define when sizes at which the image is displayed, provide hints to the browser
- srcset is pretty well supported in browsers
- the picture element is designed for art directions
- picture element is used as a wrapper around existing image fallback
- picture element gives the author a lot more control over the image displayed
- the author can modify the crop to be appropriate for the users’s device
- picture element can be used to select image types based on images format: eg webp, jp2
- image type selection allows the browser to use less bandwidth in possible
- picturefill provides a great polyfill
- Coding the picture element can get complicated:
I never want to make anything that even remotely resembles this. pic.twitter.com/QsfusOtxkI
— Brad Frost (@brad_frost) May 16, 2015
-
Building accessible web components without tears
- Four painful questions
- have you tried to navigate your site with only keyboard?
- could you perform every action on that site? (everyone put there hand down)
- did the tab order make sense?
- did you always see the element in focus?
- “full stack” devs seems to have forgotten some of the fundamentals of the web
- paragraphs, headings are terminal block elements: they can’t contain other block elements
- accessibility: enables hearing impaired, vision impaired, motor impaired users and more to access the web.
- accessibility: allows your users to use their input device of choice. More than keyboards, mouses and screen-readers
- WAI ARIA: Web accessibility initiative, accessible rich internet applications
- We can use roles and states to describe the elements to assistive technologies
- Screen readers require notification when content changes within the document using aria-live
- aria-live can be used for anything is intended to be used for important information: error alerts, resorting tables
- aria-live has three values: off, polite and assertive
- off: will wait until the screen reader loops over the content
- polite: will notify the user after the current action finishes
- assertive: is poorly supported but in theory will interupt the current action
- role=alert is used to tell a user of really important
- Two main modes screen readers use:
- read mode, standard mode can navigate the page
- forms mode, can interact with form elements… but there is a catch… content that is not directly related to the form (eg p tags with alert messages) will not be read-aloud.
- Form control error messages can be inaccessible, if it is not programatically related to the field (again, in a p-tag)
- we can not use colour alone to define a form field is invalid
- the error message needs to be programatically linked to the form
- including the error message inside the label is a simple method of associating
- when submitting forms, if an error occurs the user should be focused to the top of the form where there will be a description of the form
- A good wrapper for errors prepares the page for the error while keeping them invisible to users
- models have problems
- keyboard users can tab outside the model, the model is active and it can be confusing
- screen readers may not be notified of the model
- screen readers may not be made aware of the purpose of the model
- closing the model may move the user away from the locations in which they navigated to the model
- fixing models
- hide the model from assistive technologies, once they open hide the pages remaining content
- set focus to the model itself, not content within the model
- limit the tab key to the model for keyboard navigation
- explain to the user what each element will do when they close a model, submit a form in the model, etc.
- make a smart decision about where to position the user once the model closees
Models are shit but we can make them less shit
- in page tabs
- relationship between tabs and each panels content may not be clear
- keyboard only navigation may not work on tabs
- tab and arrow navigation (arrow to choose tab to display) is preferred
- define the tabs as role=tabpanel, links as role=tab
- define tab as aria-selelected=true/false, panel as aria-hidden
- there is a lot to do around accessibility, but there are quick wins available to make the application accessible.
- don’t be overwhelmed
- this to do
- test with keyboard only
- test with one or more screen-readers
- test screen-readers in different browsers, different bugs appear in diff browsers
- get specialists in to help you
- the ideal time to focus on accessibility is when you’re building the individual components, when you’re building pattern libraries.
- Four painful questions
-
My @webdirections #respond16 slides are available at http://pwcc.cc/respond/slides
-
- It’s often said users are the weakest link in the security chain
- How true is this, who are *we* designing for?
- Human factors influence security
- Passwords are broken, each accounts requires a human remembers
- username
- password
- was the password reset recently
- what are the rules are the password
- For things for an account is easy to remember
- Each email is associated with, on average, 130 accounts.
- These four things are not easy to remember, 130 times.
- Users make it easy to remember
- This makes it easy for users to hack accounts.
- Hackers will cycle email addresses against common passwords (this also gets around lock-outs from excessive attempts)
- Two factor auth improves security for user, smart-phones make it 2FA easier than other physical tokens
- Security needs to be easier to deal with but not too easy
- SSL locks (or triangles or warnings) are not helping, users have tunnel vision and block the URL bar from the page.
- The security information should be timely, clear and relevant
- Chrome 36 and back had a timely and relevant SSL certificate warning that 63% of users would ignore and proceed to the untrusted sites, against the advice.
- Chrome’s team decided they needed to redesign the page, hide the option to proceed to the warning page
- The redesigned warning page reduced the number of people proceeding to 37%.
- The redesign made the secure course of action clear.
- 11% of people click through to 419 scams, they don’t know what they don’t know
- People don’t look for what they are not expecting.
- Some FT users fell for a phishing attempt
- The IT dept sent a link to users requesting they reset passwords.
- The emails were seen by the phishers, who sent their own version.
- The FT now uses 2FA globally. Savvy users fall for phishing too.
- Phishing can include paper, urgent invoices.
- Warnings aren’t a great help, people don’t notice the absence of warning.
-
Lunch with the fine folk at @canva, thanks for having me down @web_goddess
-
Kogan.com are going through a responsive web design.
- Version three of their site (K3) has been around for ten years.
- Kogan had a really good, really light weight m-dot.
- The devs hated developing in two code bases
- Wanted:
- Feature parity
- Responsive design
- Speeeeeeeed
- They started with the aim of a complete refresh.
- It became apparent that a full refresh was not the right approach
- After throwing out the full refresh, they took a step back and considered their site.
- The new approach: responsive, keep it working
- Coding is like Jenga: you change one thing a completley different Jenga tower collapses.
- Started small, bring in people once it gets big enough that they’ll notice
- On a narrow screen, you couldn’t see the add to cart button. <- important!
- Add code to be deleted once the site is switched to responsive (add a min-width and max-width, remove min-width later)
- Pick random breakpoints, they will change as the site develops.
- Add a test mode while working on the css but before the site goes responsive.
- Just because someone on the net says something is a hack doesn’t mean you shouldn’t use it. Floats Vs Flex-box for layout. Everyone on a team knows how the floats works
CSS is a hack
- Don’t make an overriding class, you’ll just need to add be twice as specific as you want to change things, eg body.k4
- Avoid nesting, use classes.
- Put Sass variables in the same file in which you use them.
- Know when to steal, eg steal @snookca’s accessible visibility code.
- In the early dev stage, don’t worry about poor performing selectors. Fix them later, they’re more performant than the 5 meg of ads on every page!
- Hide code, make it hard to change CSS file that are only intended to be deleted from.
- Use component media queries, nest the media queries within the component.
- Choose a naming convention, it doesn’t matter which one.
- Needed to build a theme for a new brand, we needed to change colours.
- Turns out $red was not a great variable name
- Went a themify mixin
- m-dot site was turned off a few weeks ago, no change to conversions.
-
- Fairfax have learnt a lot about iterative design since starting the redesign of their site
- Responsive redesign of SMH is a massive project with many contributors: designers, developers, engineers, everyone at fairfax.
- SMH was founded in 1931, committed to honest accountable journalism
- SMH went online in 1995, a trial blazer of getting online in the news world.
- Before getting too excited, it did look a bit shit (my words, not theirs).
- For many people smh.com.au is the SMH, the paper may not be picked up
- The site is made up of partner sites, video, etc
- The site is used on a number of devices, mobiles on public transport, tablets in the evening
- Fairfax wanted to people to be able to reach the content regardless of devices
- They put together a dream team to work on the RWD site.
- For the new site, they needed designers to be able to design an element and put it in the CMS. Not currently possible
- There were five defining mantras they referred back to often, even now.
- Fairfax wanted to move away from multiple dev streams: m-dot, desktop, etc to a single dev stream: rwd.
- SMH went with an adaptive layout
- SMH had fallen behind the a-game. Ganiad already had a RWD site.
- Mobile geddon had arrived. SMH did not have a “tablet” site.
- SMH’s RWD team take performance very seriously, faster, faster, faster.
- They made hard calls about what was in and out. No way to redesign entire site in 18 months, too complex.
- they new they needed to change their process: iterative design over waterfall
- Mandates:
- No wireframes (initially), 60 minute design sessions to get a live prototype
- Quick’n’dirty: quality kept with design principles, style guides.
- Screen agnostics: impacted the design approach by going tablet first after a false start. Tablet is where RWD lives or dies.
- Lean user testing: less users more often.
- Sharing is caring: content (article) is the new home page, people visit news sites via social media
- Decide with data: testing gets feedback, beta site allows further testing.
- They gave the project the code name project lego. Building blocks not pages.
- Using building blocks, they can build and trial a site quickly
- Using A/B testing to discover the difference between what people wanted and what people thought they wanted.
- At Fairfax they are still learning about RWD,
- never test on yourself, test on the user
- don’t hide what you are doing
- rules will change, design for today
- Features will always be improving, this is not a design that will finish.
- Fairfax found they needed freedom to fail
-
Scroll magazine has been relaunched by @webdirections, features some excellent writers and your’s truely. https://twitter.com/webdirections/status/717879688375324672
-
- We’re no longer building pages, we’re building systems and complex networks.
- RWD is not about individual device classes
- Devices have become more complex, multiple input methods, various screen sizes
- New interactions models are been created all the time
- I’d like to tell you I have perfectly formed solution, I do not.
- Laziness is bad. Well, maybe it’s more complex than that; maybe it’s a virtue.
- We have a lot of tools available to allow us to be lazy.
- eg: nth-child for grids rather than including the grid in the html
- Modern frameworks come with baggage.
- They work of a predefined grid
- Stock breakpoints
- It’s hard to know if they’re useful for the expanding device market.
- Think about content, context rather than devices you can design for products that don’t yet exist.
- Disney made animation beautiful, it made it real and life like.
- Disney defied language to describe their work, allowing to them to keep high standards.
- If we think about the characteristics of design rather than of the page, columns, roles, it allows you to support the design.
- Describe the challenges of a site, this allows the break points to be defined.
- Rather than CSS frameworks, define vocab frameworks to make our sites fit.e
- RWD navigation is not a solved problem, they rely on the content.
- As an industry, we have a problem with the hamburger.
- It’s not working as well as we think it is.
- Time magazine added about a thousand items of help text to their hamburger. This suggests it didn’t test well.
- Disney added a hamburger icon to use the same off-screen navigation pattern
- Behind the hamburger, we put all the shit we couldn’t be bothered to deal with. We avoided the ard discussions.
- Other, arguably better, design patterns exist for navigation
- The BBC shows/hides nav items as they fit on their screen
- The Guaniad scrolls their navigation
- The Filament Group changes their nav on content driven pages to a more subtle version than their home page.
- If we look for opportunities to be lazy with nav, we can focus on other parts of the page, other features. For example animation.
- We can design of the basic elements and enhance with animation
- This does mean we need to build up from the basics, add enhancements. Design two, three or more interfaces. This doesn’t appear lazy.
- The laziness comes from designing defensively for the web. Designs will work for multiple devices.
- The BBC have done this with the cutting the mustard test.
- They track two broad responsive experiences. It’s lazy and Ethan lves it.
- Approach a site with questions, even if you have solved the problems before. Like a beginner.
- Doing a little less will allow us to do a little bit more.