Steve Barnett SteveBarnett

Why write tests?

Have more confidence that the code works. Important since the business depends on it.
Reduces the number of bugs.
Make changes and refactor more easily / at lower cost.
Save time in the long run.
Understand the code and make better design choices.
Gives you a form of documentation.

How to do it with existing code

Summary: in Cape Town we have switched to running one day events, and are going to have mentors pull people through the InstallFest in a much more hands-on way.

We (the RBCPT org team) would like some feedback on this. :)

Aside: Why do one day?

The traditional shape is Friday night InstallFest, Saturday day workshop. A lot of our target audience live in areas with high crime rates and come to our workshops via public transport. This combination means asking them to go home late on a Friday night, with a laptop, is simply not safe. After a lot of discussion, we switched to doing just a Saturday, which meant doing the InstallFest in the morning.

Why do the InstallFest differently?

Activity	Why	Details
Inform the venue clearly	Let’s people arriving know they’re in the right place, and get pointed the right way.	Tell the venue, and ask them to spread the word. Give them one of the stickers / cards / signs.
Name stickers.	Show who’s there for coworkpress and who’s not.	A sticker. With your name on it.
Status indicators	Show who wants to chat and who doesn’t.	“Talk to me!” / “please don’t disturb” or “Ssh! In the zone…” / “Want help? Me too!”. Use a card or a sticker or have tables.
Introduction activity.	Help people get started talking to each other.	1. Start a new channel `#coworkpress` on the WP South Africa Slack and share there. 2. An activity: “Find someone you don’t know, who’s wearing a ‘talk to me’ sticker, and ask them: what are you working on? what’s your favourite thing about WordPress?”

10 Usability Heuristics for User Interface Design (good for a general review)
Four Strategies for Simplicity (good for busy screens)
Design principles for reducing cognitive load (good for complex tasks)
Ten Principles of Inclusive Web Design (good for broader browser support)

Form and error guidelines

what (why)

Forms

Data / Contents

Have as few fields as possible (quicker to complete)
Remove optional field

Here's our custom Angular for an input (admittedly, mine, so not so the best way to Angular)

<app-label-input-pair labelText="Your name" inputId="your-name"></app-label-input-pair>

Here's the HTML output (which we write ourselves, following Bootstrap conventions)

<div class="form-group">

How to make your team FED up

Making software for the web is tricky. The more directly everyone on the team works with the materials of the web (HTML, CSS, and JavaScript), the more informed our design and development decisions can be. One of the best ways to do this is to have a team of T-shaped people (deep knowledge in one area, shallow knowledge in many others). Does that mean designers should learn to code? Nope. 🙅‍♀️ Does it help if they know a little about code? Yes! 🎉

We’ll look at a couple of tiny case studies of a Front-End Developer (me. Hi there! 👋) working with UI designers, UX designers, and Back-End Developers across different teams. We’ll see how sharing the FED love led to more accessible designs, more realistic prototypes, and cleaner front-end code. And since “front-end developer” can mean a lot of things these days, we’ll also look at various flavours of FEDs and why they are all delicious.

Keybase proof

I hereby claim:

I am stevebarnett on github.
I am stevebarnett (https://keybase.io/stevebarnett) on keybase.
I have a public key ASDrGc9Di9id_mzJFCpGdTPEs41CYd5K9O8elJRaPxrTCwo

To claim this, I am signing this object:

	{
	"remove-empty-rulesets": true,
	"always-semicolon": true,
	"color-case": "lower",
	"block-indent": " ",
	"color-shorthand": true,
	"element-case": "lower",
	"eof-newline": true,
	"leading-zero": true,
	"quotes": "double",

	<!doctype html>
	<html lang="en">

	<head>
	<title>Testing</title>
	</head>

	<body>

	</body>