Rocking #respond16 for the home town over the next couple of days. Spoiler: an excellent show to come!
Archives: Notes
-
-
RT @Independent: ‘What I discovered about homophobia by holding hands with another man in public’ http://www.clickhole.com/video/eye-opening-these-guys-lived-15-minutes-homeless-s-2415
-
I can’t say this better, come along if you’re in Melbourne
https://twitter.com/xzyfer/status/718650280275881984 -
My plans tonight are to watch the latest Survivor & fall asleep on the couch reading Dalton Ross. Good to be home.
-
- The web is its own medium; a medium defined by its fluidity.
- It’s available on any device, one web. As long as we don’t break it.
- One web is:
- One content
- One url
- One team
- One release schedule
- One codebase
- One web sounds a lot like responsive.
- The phrase adaptive is magic.
- No one seems know what adaptive means.
- An m-dot site is dedicated site served to mobile users, but it’s easy to server the wrong content.
- Adaptive is often used to means: serves something different to different devices. It may mean
- A limited of media queries where the width jumps rather than fluidly grows
- Serving something different, the url remains the same but the content is served differently
- Karen McGrane prefers the latter definition.
- Adaptive content is server side, the server detects the device and serves something different.
- Google is the one company most invested in your site serving the same content at the same url all the time.
- If the home page is political, serve a different home page and keep the rest of the site responsive. Do it, go adaptive on the home page.
- Adaptive doesn’t need to be per page, it can be per component. Fidelity used two versions of markup for adaptive tables based on the screen site.
- Don’t get the server involved with content when it’s a client side problem.
- Karen McGrane has spoken about adaptive for five years, since discussing COPE.
- There is a great value in storing chunks of granular content rather than massive blobs.
- It makes it easy for people to conclude they should be targeting different users with different content.
- One way of targeting is based on the users device.
- There are other ways. Context: information that can be gleaned from the devices sensors, the time, location, velocity, barometer, temperature.
- Think about this, when does it make sense to serve different content based on the device vs different content based on the users context?
- Device: support pages based on the users operating system.
- Even based on device selection, prioritise the content rather than exclude the content. An iOS user may be helping their Android using friend.
- Often people make assumption to adapt on device that are stretching it’s suitability, to assume the input mechanism, for example.
- Microsoft think there is no difference between what mobile & desktop users desires.
- Karen’s definition of context (device sensors) are the closest we can get to guess the users context.
- Modern hearing aids can switch to car mode when travelling over 10mph. This is a good but imperfect solution (could be a human canon ball).
- Restaurants can be displayed according to the user’s location, this is a good contextual cue.
- Language may not be a good contextual cue for language, this can be flawed – visitors arriving in a foreign country.
- Device detection is flawed, there is no correlation between being away from home and using a mobile device.
- Device type will always be the least reliable form of estimating context.
- Expedia found that responsive was better than context targeting. A travel company.
- Adaptive and responsive are not in competition, they work together. RWD will solve 95% of your problems, adaptive may cover the remaining 5%.
-
- 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.
-
<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:
https://twitter.com/brad_frost/status/599676745176997889
-
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.