Archives: Notes

• 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.

I deny this. https://twitter.com/developerjack/status/717653909683109888

Playing seat selection offence has worked again, the neighbouring seat is vacant, again. MEL ✈️ SYD

Nice to see the council getting in on the @batlabels joke.