tommorris.org

Discussing software, the web, politics, sexuality and the unending supply of human stupidity.


notes


LWS talk: Break down the barriers - Self taught developers today

The following is contemporaneous notes from a talk at London Web Standards by Matt Bee (@mattbee) from futureLearn. There may be errors or material I missed.

Auto-didacticism: the act of self learning or self-education without the guidance of masters (such as teachers and professors) or institutions. (Audience member: “Just Stack Overflow!”)

Wholly self-taught front end developer. Two things happened when I first started developer: “The Facebook” and Firefox.

If you are self-taught, you are in good company: Leonard Da Vinci, Charles Darwin, Quentin Tarantino, David Bowie, Jimi Hendrix.

Our industry is amazing - the support/encouragement available is unbelievable. We are excluding new people though.

“I followed an unconventional route to being a web developer”. But that’s a lot of people.

Source for first website - table based layout, a lot of view source, a lot of Notepad, a lot of IE 6. Used to work mostly in HTML and CSS. With the help from books like “HTML for the World Wide Web - Visual Quickstart Guide”, learned a lot as a tinkerer.

Two years in: good with HTML (table layouts) and moderate CSS (fairly new), basic PHP, could use FTP and do basic web config. Could get a site up and running from scratch. This was enough to get my first developer job. This was without any computer science background.

Now: front end developer with 10 years experience, not an engineer, or a code ninja. I don’t know Angular, React, WebPack. I don’t even know JavaScript inside out. I am valuable to my team. Need more: empathy, honesty, being able to see stuff from a user’s perspective.

I worry for the future. Not in a political sense either. The openness is being removed. A lot harder for someone who is intrigued to learn. 69.1% of developers are self-taught according to Stack Overflow.

3 key areas that have made it harder for new people:

  1. Harnessing the power of devices.
  2. Exposure to the inner workings
  3. Mass adoption of complex tools and technologies

My first computer: ZX Spectrum 48K. Had to load programs off a tape. Instruction manual contained programs you could write and run, could produce beautiful graphics (if you had a colour TV). You could buy magazines to copy commands.

Compare the ZX Spectrum keyboard (with “str$”, “rnd”, “peek”, “poke”) keys with the PS2 controller. UX won out - but blackbox devices don’t enable developers.

Terminal and command line are hidden away. Accessible hardware is around, but you need to know about it and have surplus cash for it. Simulated environments aren’t always great experiences.

It used to be easy. View source was enough to get inspiration and troubleshoot. A lot of code was not dependent on anything else. Generally you saw exactly what people write. Didn’t depend on a node package that the author of the code you are looking at didn’t understand. The was true even for big production sites.

JavaScript is an example of how it used to be. In my early development days, a website like Dynamic Drive.1 You could copy, paste and tinker. The modern day equivalent is include some file then type $('.datepickerclass').datepicker();

Today: a new developer can create with no exposure to real code. View source is now potentially useless. Everything output is transformed from what is written. HTML and CSS sometimes feel like second class citizens.

Tweet from @paulcuth: “Just starting to use Web Components & Shadow DOM. Great fun, but going to raise the barrier to entry massively. View source is practically useless.”

Complex tools and mass adoption: “I first thought of learning AngularJS through their official documentation, but this turned out to be a terrible idea.” (source)

Ashley Nolan’s front end tooling survey: “the adoption rate of front-end tools shows no signs of letting up, with tools such as Webpack and JavaScript transpilers becoming ever more essential in our workflows” (source)

Try to install a Node.js library. Thousands of C++ compilation errors. Answer is to download a few gigabytes of Xcode that you probably won’t ever use. Why?2

We are exposing thousands of developers to this every day, and potentially putting them off a career in tech.

I am not saying do not use frameworks. They are valuable and save time and effort. I am saying provide a pathway to learn them.

In summary: I don’t think I’d cut it today. I’m not a great developer, I have huge gaps in my knowledge. I do have other attributes that make me valuable.

“The rapidness of getting the information doesn’t really correlate with the pace of the actual learning. This frustrates us” - Gavin Strange

What can we do? Consider the future developers. Run a code club. Run a Homebrew Website Club. Help teach people. Promote diversity on teams.

People learn at different rates and in different ways. Empathy is important. Provide pathways for great people to become great developers.

(All pictures from Wikimedia Commons!)

  1. Oh my. It still exists.

  2. “Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?” (Brian Kernighan)


LWS talk: Designing for the Web - Healthy practices for developers and designers

The following is contemporaneous notes from talk at London Web Standards by Matteo Pescarin (@ilPeach), development lead at Sainsbury’s (for now). There may be errors or material I missed.

“I’ve seen things you people wouldn’t believe”. I’ve seen developers and designers who didn’t want to touch a single line of HTML and CSS. I’ve seen fantastic designs that would work on paper. I’ve seen code that shouldn’t work in browsers.

There’s a lot to take in: learning the ever increasing complexity of front-end technologies.

At the beginning, we were very happy. Using tables to display data. Paginating millions of records. Then UX.

Then we started looking into content-first approaches. Personas, user journeys, interactions and behaviours, usability, cross-device compatibility, and many other aspects. A lot to take in.

Let’s say you don’t know web design. What is web design? Everything? Multi-faceted set of practices and doctrines that surround websites. Maybe it is more similar to product design. Quite difficult to grasp everything.

Semantic markup. Do you know?

  • What’s the difference between article and section?
  • How do you vertically align with CSS?

If developers have too much to take in, what should designers do? Learn to code?

The developers are masters in their field. Developers know the limits of the technologies. Designers know colour theory, typography, grid systems, use of whitespace etc. “Don’t expect to find the unicorn” - there are developers who learn design, and designers who learn to become developers, but they are rare.

Don’t expect tools to solve your problems: tools exist to help developers do design better. Things like SketchUp (and earlier Dreamweaver) enable designers to turn ideas into web pages. Developers have the same: CSS grid systems taught us indirectly how design work. Methodologies like Atomic Design too. But don’t let anybody decide which tools you should be using. Allow yourself to be flexible enough to experiment, try new things.

A better world is possible. We cannot shift responsibility.

1-10-100 rule: if you have to fix a problem during design time, cost is 1. Fix a problem during development time, cost is 10. Fix after delivery, cost is 100. Data-based analysis showed the 100 is more like 1m.

Iterate and validate: as developers and designers, we are biased. Involve your users. Design in the browser. Rapid prototyping. Use Design Sprints. Use style guides and pattern libraries - save thousands of hours in the long run.

Designers must sit with developers, to promote knowledge sharing. Work bottom-up, understand each other, elevate developers to work on front-end design.


LWS talk: Building a dementia friendly website

The following is contemporaneous notes from a talk given at London Web Standards by Imogen Levy (@teppie). There may be errors or material I missed.

Dementia: memory loss, mood changes, changes in reasoning. Caused by a number of diseases - most common is Alzheimer’s. Over 850,000 people in the United Kingdom with dementia. By 2021, over 1m people will live with dementia. Getting worse with ageing population.

Designing websites for people with dementia is an unexplored space. Redesigning the Alzheimer’s Society website, it was key that it worked for people with dementia, so they were included them at all stages in the design process.

Challenge 1: how to design for dementia

First step was to develop a series of personas. Personas help guide decisions in design. What are their needs? Used focus groups, interviews, help line call logs, surveys and quantitative data from existing website. Focus groups included both people with dementia and carers. Focus groups run through local branches of Alzheimer’s Society as well as local charitable groups included singing groups, “Alzheimer’s Cafés” etc.

Seven personas:

  1. Person with dementia
  2. Carer
  3. Volunteer
  4. Researcher
  5. Mature supporter
  6. ??
  7. Authority?

Research findings:

  1. Goal-oriented content emerged as key need. Content needed to be structured around stages of dementia.
  2. Increasing importance of mobile and tablet usage. Smartphones are equally accessible in the home to computers. Lots of users relying on smartphones and tablets alone.
  3. Content must be visual and interactive: more video and audio content.

Challenge 2

Challenge: “website is informative scary”. Contained 10,000 pages of content, but was added to without review. Overgrown, unclear structure. “Time to do some weeding”.

Google rankings were excellent, but navigating via the website wasn’t good. Old site started with four items on the left-hand navigation panel, but this grew. Had to start again, but didn’t want to lose out on Google rankings for key content.

New IA/site structure to make it easy for people to find stuff easily and quickly. Worked with consultants.

Digital team owned website, but dementia content was produced mostly by team responsible for print content including fact sheets and material handed out in doctors surgery. Printed material must meet NHS Information Standard.

Had to restructure content but not break compliance with NHS information standard.

The goal of the website is to help users find information and complete tasks.

Structure tested using online tool called TreeJack.

Set of tasks given to user, then user is asked to navigate through website. No design, just structure. Gives you a “spider graph”. The cleaner the graph, the easier the navigation.

Example task: find out more information about vascular dementia. 90% found information easily. Each click stage broken down.

Unsuccessful task: “how can you best look after yourself while caring for a relative?” Content was contained within the “About dementia” section, but most users went to the “Get Support” section, though that did not contain the relevant information. Result was moving the information.

Lessons:

  1. Don’t let the organisation dictate the website structure - this required tricky conversations internally
  2. Clear signposted entry points on website - “
  3. Needs and abilities are unique

Challenge 3: brand strategy

Wanted a new brand strategy as part of a wider goal to change societal perceptions of dementia - “I have dementia, and I’m OK.”

Use of logo across multiple devices. Square logos on a mobile phone was hard.

Colour palette: web use was limited. Lots of testing required. Two prototypes tested - one wireframe - to test out IA hierarchy. Testers liked the design and layout, gave positive impression

Challenge 4: in trouble with the law

ICO enforcement notice against AS. Data breaches including website hack. Great deal of scrutiny followed. Complete restructure necessitated a new environment. Involvement of lawyers, penetration testers and security companies. A great deal of security scrutiny was performed.

CMS limitations: 10,000 to 2,000 pages meant a lot of redirects. Significant number of spreadsheets sent for 301 redirects.

New site enabled “friendly URLs”. Not perfect, but better.

Lessons:

  1. “Love your testing team!”
  2. More time for managing redirects
  3. Use a CMS that supports SEO friendly URLs.

Challenge 5: The Future

AS wants to reach every person who has a dementia diagnosis, and “build stuff people want”. Team wanted to show how to be user focussed.

New stuff:

  • Implementing a new CMS
  • Extensive research into people at point of diagnosis
  • Partner project with NHS Digital - “we are the authority” on dementia content, so want to align with what NHS are doing
  • Continued website improvements

Towards an Evernote replacement

Since the recent announcements by Evernote that they really, really will be able to poke around inside your notebooks without issue, and they’ll also apply the same sort of machine learning technology to your data that people have convinced themselves that paying for a product will help them avoid, lots of people have been looking at alternatives to Evernote. I’ve been evaluating a few of them.

Here’s some of the open source alternatives I’ve seen people talk about:

  • Laverna, a client-side only JavaScript app that uses localStorage for your notes. No syncing, sadly.
  • Paperwork, PHP serverside app
  • Standard Notes, which aims to be an encrypted protocol for storing Evernote-style notes

These all handle the plain text (or Markdown or whatever) case reasonably well, but there’s a few things Evernote provides which we should be aware of if we’re trying to find replacements.

  1. text/plain or RTF storage. A lot of people store a lot of simple text notes in Evernote.
  2. OCRed PDF storage. Evernote has an app called Scannable that makes it ludicrously easy to scan a lot of documents and store them in Evernote.
  3. Web Clipper: I don’t use this, but a lot of people use Evernote as a kind of bookmarking service using the Web Clipper plugin that they provide. If they see a news article or recipe or whatever on the web, they clip it out and store it in Evernote and use that almost like a reading list, like what people use Instapaper/Pocket for etc.

The solutions people have been building generally solve problem (1) but do little to address problems (2) and (3).

My own preferred solutions are basically this: for (1), I’m leaning towards just storing and syncing together plain text Markdown files of some description.

Solving (2) is a harder problem. My current plan is to try and create a way to store all these in email. Email is a pretty reliable, well-tested and widely implemented Everything Bucket. The process would be relatively simple: scan document, run it through an OCR process, then provide the relevant title and tags which could be stored in the subject line and body of the email. The OCR result would also be stored in the body of the email to make it more easily searchable. Then you just stick it all in an email folder (or Gmail label). You’ve got a security layer (whatever your email provides, and if you are storing lots of important data in there, you should probably ensure it is 2FA). You’ve got sync (IMAP). You’ve got universal capture (email it to yourself). And you have already made either the financial bargain (with, say, Fastmail) or the give-away-all-your-personal-information bargain (Gmail). Backing up IMAP is relatively trivial compared to backing up whatever weird binary blob format people come up with.

Solving (3) is somebody else’s problem because I don’t understand why anyone wants to stick all the websites they’ve ever visited into Evernote.

That said, let’s not promise users replacement for software if we are only replicating the features from that software that we actually use. If anyone has great suggestions for how they are going to sort out problem (2), I’m all ears.