This week (in August of 2024), silverorange turned 25 years old. While we didn’t throw a big party like we did for our 20th anniversary, we did gather together on Prince Edward Island to enjoy each other's company (get it?), as we do every summer. Seeing most of us together like this highlights how we’ve grown and changed over the years.

When we got started in 1999, we were 7 people in Charlottetown, Prince Edward Island.

In 2024 we are 38 people spread across 8 provinces (and one Canadian working abroad in the US):

• 12 on Prince Edward Island
• 9 in British Columbia
• 7 in Ontario
• 3 in Alberta
• 2 in Quebec
• 2 in Nova Scotia
• 1 in New Brunswick
• 1 in Manitoba
• and one Canadian working in the US

The completionists among us are glaringly aware of our absence in Newfoundland and Labrador, Saskatchewan, and the territories.

While our numbers have grown from 7 to 38 over the years, we’ve also become a much more diverse group.

• We hail from over 10 different countries around the world.
• As a group, we speak at least 16 languages fluently (not including programming languages).

As we note in our job ads:

“People with different backgrounds and experiences make us stronger, and we’re always looking for ways to improve. Our team is getting more diverse across many dimensions of diversity, but we’re still missing perspectives that could make our work better.”

My own 25 years

While most of our original founders remain involved in the company in some capacity, I’m the only founding member that is still working full-time for the company 25 years later.

I’ve been asked how it feels to be the “last” founder still working full-time with the company. My answer is: it feels great because the company is a vibrant place with all kinds of great new people. There is a healthy respect for our long history, but the culture isn’t overly focused on the past or the founders.

I’m much happier to be part of a vital company than one that remains unchanged from the “old days.” This very change is why I’ve been happy to spend 25 years here (and am happy to keep going): the company is always changing, the technology is always changing, and the job is always changing.

At this point, a quarter century into the life of our company, we’re a stronger and more extraordinary group of people than we’ve ever been. Here’s to the next 25 years.

I was very excited to see Matthias Ott speak about Web Design Engineering and had a few others on my can’t-miss list. But my favourite talk ended up being one I didn’t even plan to watch.

Elika Etemad’s Standardization Stories was fascinating. I came away with an even greater appreciation for all the thought and consideration that goes into the specification process (I will never look at border-radius the same again). It’s invaluable work that allows us to avoid vendor lock-in and maintain the interoperable foundations of the Web. And I love a bit of a “how did we get here” narrative, so was hooked from the opening lines:

Imagine a world where each browser company implemented the coolest technology that you could imagine as fast as they could and shipped it in their next release for everyone to use immediately. So fast. So shiny. So exciting! This was the Nineties.

I don’t want to give too much away. But if you only watch one talk from this year’s CSS Day, let this be the one.

The purpose of GAAD is to get everyone talking, thinking and learning about digital access and inclusion, and the more than One Billion people with disabilities/impairments.

Practically speaking, this means taking an hour out of your usual schedule to dedicate to accessibility in some way: adding captions to video content, fixing inaccessible names in code, learning about the assistive technology browsing experience, reading about touch targets… The list goes on and on. It’s a bit overwhelming. Where do you start?

Start anywhere

At a company meeting, raise the topic of marking Global Accessibility Awareness Day in some way. People will start having ideas about what you can do. Write them down. You will have too many ideas. This is a good problem. Look at those ideas later and decide what makes the most sense for your situation.

This year, we decided to focus on education. To avoid placing too much pressure on volunteer speakers and to cover a wide range of subjects in an hour, we chose a “lightning talk” format. 5 minutes. No waiting.

Our line-up for 2024:

• Accessibility in our hiring process
• Web Content Accessibility Guidelines (WCAG)
• Design Accessibility Tools
• Android Accessibility Tools
• Web Accessibility Tools
• Readability
• Alt text best practices
• HyperText Markup Language (HTML)
• Accessible Rich Internet Applications (ARIA)

On the day, with introduction and questions and wrap-up included, we had to cut the last three talks for time. They were recorded later and shared in Slack.

The entire line-up of talks was saved in a Notion Meeting page for the day.

Share what you did

You know, write a blog post or something. Seriously, there are two major benefits to this step:

1. Accountability: Trying to explain a topic to others often helps clarify your own thinking. What did we want to get out of this hour? How did we prepare? These are questions we had to answer for ourselves before we could write this post. Also, it’s a public commitment: if we’re going to talk about accessibility, we have to build accessible products and maintain an accessible work environment.

2. Amplification: We all heard about Global Accessibility Awareness Day from someone. This is our chance to be that someone! We hope purposefully marking this day inspires more questions about what it means to make an accessible digital product, both internally and externally.

Start again

Accessibility is never “done”. We can check off all the automated and manual tests as successes, but the real tests are with our actual users. We need to be open to feedback. We need to have processes in place to ensure that feedback results in action.

Global Accessibility Awareness Day is every year on the 3rd Thursday in May. We’ll be celebrating it again in 2025.

Any ideas on what we should do?

Everything is a feature; nothing is a bug.

On my latest hobby site, I wanted to play around with some of the incredible CSS that has been landing in the last few years.

Here’s an overview of my impressions so far:

Top 3

Cascade Layers

I want to use cascade layers everywhere, immediately. For backwards-compatibility, I would need a polyfill or careful consideration of how to support older browsers before incorporating this into professional work. But holy smokes, this is my new favourite thing!

Cascade layers allow you to organize your style architecture in new ways, wiping out concerns about specificity and order of appearance for rules in different layers. Those criteria only apply within the same layer.

@layer component, state;

/* by order of appearance rules, I would be overruled */
/* by cascade layer rules, I am applied! */
@layer state {
  button[aria-disabled='true']:hover {
    filter: none;
  }
}

@layer component {
  .button[data-variant='primary']:hover {
    filter: saturate(200%);
  }
}

You can even import a stylesheet into a layer, which means notoriously fickle vendor styles can be neatly slotted into a “vendor” layer, where you don’t have to worry about the fact Vendor X decided to select everything by ID.

@layer vendor, author;

@import url(vendor.css) layer(vendor);

@layer author {
  // everything in here beats vendor specificity
}

Styles can also be appended to layers, so you don’t have to define them all in the same place at the same time. I broke up my “variant” layer into specific variant blocks, which made it really easy to focus on the one I was working on at the time.

Cascade layers are wonderful but also intimidating. How do you choose what layers to define? In what order?

These are difficult questions to answer at the beginning of a project when you have no experience to draw from. But it’s impossible to gain experience if you never try anything new. I changed my approach several times along the way and ended up with a much better understanding of how I would answer those questions for my next project.

Learn more about cascade layers with Bramus Van Damme

Subgrid

This long-awaited feature finally became available in all evergreen browsers as of September 2023. Thanks, CSS Interop!

For me, the exciting thing about subgrid is its “breakout” possibilities. You can create a grid and position most everything in a column of that grid, but then use subgrid to push an element outside the bounds of that column.

A common use case for this is moving from container to full-bleed width.

A less common use case is what I wanted to do: create a two column layout, with the second column containing a sticky element that used to be embedded in the first column on smaller screens.

It’s a fun feature to play with and I’m looking forward to seeing what kind of designs this inspires.

Learn more about subgrid with Rachel Andrew

Container Queries

The first thing you’re going to want to do with container queries is make style changes to the container itself and you can’t do that. The implementation may seem quirky at first, but there’s good reason for it (see Miriam Suzanne’s CSS day talk for details).

I knew early on I wanted to use container queries as much as possible because I wasn’t working from a planned design. Re-adjusting media queries every time I moved things around in the browser was not a pleasant prospect. A lot of component layout has nothing to do with page width but how much space the component happens to take within a particular context. The idea I could set up components with container queries and then toss them into whatever context struck my fancy was very appealing.

In practice, I wasn’t as enamoured with container queries as I thought I would be. I spent a lot of time debugging. But it was very satisfying to finally see that little “container” badge show up in the dev tools and have a new tool in my responsive web toolkit.

Learn more about container queries with Ahmad Shadeed

Honorable Mentions:

• :has()
• :is()
• :where()
• color-mix()
• CIE LAB color space
• Variable Fonts
• Image Masking

TL;DR

There’s a lot of new CSS out there and hobby sites make great playgrounds. Filling in your mental model of a new specification is a side benefit. Coding for fun and curiousity is a worthwhile end in itself.

Eight years ago when silverorange’s first CEO Dan James stepped away to focus on his family and his family business, he pointed out that he had donned the title of CEO almost as a matter of course. The founders of silverorange were committed to as flat and open an organizational structure as possible. Internally, the role required consensus building, team building, communication, and odd jobbing to make sure everything ran smoothly. It’s a definition of the role which, at the time, ran counter to many of the ideas of what a CEO should be–firebrands, iconoclasts, near-messianic figures, but tracks pretty well to the notion of “servant leadership” that’s gaining traction. It’s how the role of CEO at silverorange still operates. And that’s how we like it.

As a company we’ve hit another transition point. Isa Grant, who took over the role from Dan, is stepping away and we’re happy and excited to welcome Clare Raspopow as our new CEO! To be honest, technically the transition actually happened in January of this year. Which perhaps begs the question: why so long with the announcement? To which we will respond, a good succession takes time.

Isa has been with silverorange since the beginning and has been our CEO, friend, coworker, and so much more for the last eight years. During their tenure we’ve grown and changed tremendously as a company. Succession is normal and inevitable. It can feel scary, but it’s a chance for the company to do some self-reflection, acknowledge transformation, and reaffirm the principles on which the company operates. We chose Clare because she is smart, competent, kind, and possesses a host of skills and qualities that we know can continue to steer the current version of silverorange to maintain the legacy of excellent work and offering a people-focused humane working environment.

No one can lead forever. No one should lead forever. If you start from that truth and strip out the egos and dramatics, it is very possible to plan a transition grounded in care and support and a shared vision for the thing that everyone - and that does mean everyone - at a company works every day to build. Which is what Isa has given us and what Dan James gave us eight years ago.

While we’re sad we won’t get to keep working with Isa day to day, they remain actively involved with our Board of Directors. They will always be a part of what makes silverorange who we are. As the CFO of silverorange and as representative of both the Board of Directors and the silverorange Executive, I know that we’re excited to welcome Clare as our new CEO. Welcome!

Here’s what we learned:

Sometimes a logo is just a logo

SVG is a great fit for logos. Logos are not necessarily a great fit for headings. Before diving into how we could associate SVG headings with accessible names, we had to step back and examine why we chose the SVG as heading in the first place. This allowed us to identify a few pages where we could use a more descriptive text option. A visible text heading is always preferable to an SVG heading.

Test your assumptions

For SVG headings that definitely needed to stay headings, we wanted to find a reliable approach to giving that SVG an accessible name. A developer Slack thread revealed that we had various approaches to consider:

1. Visually hidden styling on text
2. SVG <title> element
3. aria-label attribute
4. alt attribute

Our test case was a simple page scaffolded with create-react-app, using SVGR:

import { ReactComponent as Logo } from './logo.svg';
import './App.css';

function App() {
  return (
    <div className="App">
      <header className="App-header">
        <h1>Testing SVG labels</h1>
        <h2 data-testid="1">
          <span className="visually-hidden">Pattern 1</span>
          <Logo aria-hidden="true" />
        </h2>
        <h2 data-testid="2">
          <Logo role="img" title="Pattern 2" />
        </h2>
        <h2 data-testid="3">
          <Logo role="img" aria-label="Pattern 3" />
        </h2>
        <h2 data-testid="4">
          <Logo role="img" alt="Pattern 4" />
        </h2>
      </header>
    </div>
  );
}

export default App;

We checked the page against several browsers and MacOS's VoiceOver screenreader. We also tested WebAIM's WAVE extension and jest-dom's .toHaveAccessibleName() test assertion. Results were as follows:

Visually hidden styling:

• Firefox Voiceover: Pass
• Chrome Voiceover: Pass
• Safari Voiceover: Pass
• WAVE: Pass
• Jest Accessible Name Assertion: Pass

<title/> tag:

• Firefox Voiceover: Pass (but not recognized as heading title in accessibility dev tools)
• Chrome Voiceover: Pass
• Safari Voiceover: Pass
• WAVE: Pass
• Jest Accessible Name Assertion: Fail

aria-label attribute:

• Firefox Voiceover: Pass (heading title shown with warning icon in accessibility dev tools)
• Chrome Voiceover: Pass
• Safari Voiceover: Pass
• WAVE: Fail
• Jest Accessible Name Assertion: Pass

alt attribute

• Firefox Voiceover: Fail
• Chrome Voiceover: Fail
• Safari Voiceover: Pass
• WAVE: Fail
• Jest Accessible Name Assertion: Fail

We discussed the findings at our next developer meeting. The alt attribute was quickly discarded as it often wasn’t identified as a heading name. The <title/> element and aria-label attribute introduced just enough doubt that we decided to err on the side of caution and use visually hidden styling, which offered the most consistent results.

Do something about it

Honestly, we could have debated this for a week. But we wanted to come out of the developer meeting with an actionable standard, so we’ve placed the .visually-hidden rule on a Notion page to document our current approach to SVG headings (with a reminder to confirm you really, truly, 100% need an SVG heading). It’s not carved in stone and it’s certainly not perfect. But it’s better than what we were doing before and it’s important to celebrate small wins.

The comic includes the (good) advice to use memorable-but-nonsensical passphrases rather than passwords, with the delightful example: correct horse battery staple.

This developer ended up reading some password guidance from the Canadian government. We were delighted to discover that the Canadian government’s own official password guidance includes the XKCD example verbatim, including a Canadian bilingual twist:

“Passphrases are easier to remember and can be as secure as shorter, more complex passwords.

• Choose 4 or 5 randomly selected words (for example, correct horse battery staple).
• Include words from another language (for example, correct cheval battery staple).”

They also had this great follow-up advice: “Don’t use any of the password examples given above.”

👏 🇨🇦

It’s ultimately very satisfying when the problem is solved with a better understanding of CSS specifications. You figure it out; you bank the knowledge for next time; you move on with your day. But that day’s going to get a whole lot worse if the problem is browser implementation. You can’t move that mountain. You have to hack your way around it or retreat to something that works cross-browser.

To anticipate “doesn’t look right in [insert browser name here]” feedback, one of the first sites I bookmarked when learning front-end development was caniuse.com. It’s like a Google search specific to browser support for a feature. Consider the results for CSS Subgrid:

The feature works in some stable browsers, but not all. Can I use this feature in production? Not really. If there’s a decorative enhancement possible for Safari and Firefox users, sure. But if fundamental layout positioning will create a poor experience for all Chrome and Edge users, forget about it.

I can’t force people who want to visit my site to do so with a specific browser. Aside from being something they may not have control over (if they’re on a library computer, for example), it goes against the ethical principle that the Web is multi-browser, multi-OS and multi-device. Generally speaking, websites need to work for everyone, on everything.

That makes cross-browser inconsistencies a huge headache for website developers, leaving us a limited toolset to work with. Browser vendors are well aware of this. As of 2021, they decided to publicly work together to do something about it. Compat 2021 involved 5 focus areas and was successful enough that Interop 2022 expanded to 15 focus areas. Last week saw the announcement of Interop 2023, which combined a few carry-overs and several new additions to make a total of 26 focus areas.

What does this mean for browser developers?

Well, it undoubtedly makes their job harder. They have agreed to spend time discussing with their competitors what features would most benefit users and pursuing shared priorities in developing those features to a reliable standard. These decisions are time-consuming and inevitably involve compromise. But, the hope is this collaboration will make their work more effective. Providing support for features no one uses is depressing. This alignment should encourage greater application of new features.

What does this mean for website developers?

Let’s take another look at that Subgrid support.

Firefox was the first to release support in December 2019. Then nothing much happened for two years. Two years! When Interop 2022 named Subgrid as a focus area, Safari released support in September of that same year. The Chromium bug is now very active and Edge announced it would be shipping support early 2023. This is fantastic progress and far from an isolated example.

Quite frankly, I’ve been amazed at how often I’ve looked at caniuse.com over the past year and seen uniform support across the major browsers*. Can I use aspect-ratio? Yes. Dynamic viewport units? Yes. Cascade layers? Yes.

Combining user-first thinking with public collaboration for impactful results makes CSS Interop truly awesome**. A huge thanks to all those who develop browsers and participate in these discussions. The Web is a better place because of you.

Can I help?

If you are a developer, like myself, wondering how you might contribute to the awesomeness, here are a few thoughts:

• Participate in the next State of CSS survey to help identify pain points
• File browser bugs (and star existing ones) to record implementation issues
• Write web compat tests to measure the focus area progress
• Use the new stuff to show it matters! (Providing sensible fallbacks where appropriate, of course)

Official Interop 2023 Announcements:

• Apple
• Bocoup
• Google
• Igalia
• Microsoft
• Mozilla

Notes

* IE, officially out-of-support as of June 15, 2022, is no longer a safe browser option. It should still receive basic consideration as there will be a long tail of people using this browser (or IE Mode on Edge) for a variety of reasons, but newer builds can focus on the actively developing browsers.

** To be completely accurate, Interop extends beyond CSS. It considers HTML, JS, and Web APIs as well.

Like anyone aiming to build great Web systems, we’re concerned with the performance of the systems we build. We want to craft experiences that feel fast and responsive. I’ve even trumpetted the performance of this very site.

On the Web, ‘performance’ tends to refer to fast server response times, optimized assets for fast downloads, and generally limiting size and complexity of code that needs to be transferred to and executed on client devices.

Instead of this focus on performance, we’re better served by focusing on efficiency.

The term ‘performance’ brings to mind exotic super-cars suitable only for impractical demonstrations (or ‘performances’). ‘Efficiency’ brings to mind an electric car (or even better, a bicycle), making effective use of limited resources.

Computing power is the most obvious resource at play in the world of Web and mobile app development. The time and attention of those using our systems are also a resource that should be treated with respect.

Much like an electric car can be a better driving experience than an internal-combustion vehicle, an efficient Web system feels lighter and faster. It uses less power on the server and the client device (including your precious laptop and phone battery).

To push the automotive metaphor even further, efficiently designed Web and app systems can also have a real impact on carbon output. After all, we’re working on bicycles for the mind, not SUVs.

This ushered in my stream-of-consciousness commits phase, where I would commit everything, all the time:

• Missed a typo? Add a “fix typo” commit.
• Not finished a task but have to stop working? Add a “WIP” commit.
• Forgot to save file? Save it. Then add an “actually save file” commit.

I was the only one who had to deal with the consequences of these commits in freelance days. I was the developer, reviewer, and debugger. Quite frankly, I only thought of myself as the developer. I appreciate the roles of reviewer and debugger more when part of a team.

Seeing a descriptive commit message history on a pull request or finding a well-defined set of changes in a main branch commit makes those jobs easier.

My unfocused, unfiltered commits would be useless to folks trying to understand the logic and context of my changes. In addition, they would be a tangled mess to roll back if a problem occurred after merging to the main branch.

Recognizing a good commit is one thing. Getting in the habit of writing them yourself is a whole other thing. I’m still learning here. If you’re just getting started, feel free to skip the years I spent writing terrible commits without knowing it and help git help you.

What is a good commit

A good commit is a logical chunk of work with a concise and consistent explanatory message. A good commit message follows your team’s style standards (i.e. line length limit, active voice) and adds context via the message body when needed.

How to write good commits

The what of a good git commit is a team decision, but the how is an individual one.

Here’s the thing: I still miss typos, finish my workday in the middle of a task, and forget to save files. I still get excited about a feature and code for hours without a thought of version control.

The difference now is that I have a bit more git knowledge, and I benefit from the example of more experienced teammates. With many thanks to those who shared their tips at a silverorange developer meeting on this topic, here are a few commands you can use to clean up your commits.

If you have too much uncommitted code:

git add -p or git reset -p

The -p flag allows you to review the difference of your modified code and select the chunks you want added or reset. This allows you to organize your commits into smaller, logical bundles of work. It is particularly useful if you want to select parts of a file to commit, but keep working on other parts.

Changes to be committed:
  (use "git restore --staged <file>..." to unstage)
	modified:   README.md

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	modified:   README.md

If you need to change already committed code:

git commit --amend (optional --no-edit)

The --amend flag replaces the incorrect or incomplete commit with a new commit that includes your latest changes. By default, you will be asked to enter a commit message for the amended commit. If you don’t need to change the commit message, include the --no-edit flag. This one’s a personal favourite for all those missed typos.

A message I want to change

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date:      Fri Oct 14 16:24:19 2022 +0100
#
# On branch main
# Changes to be committed:
#       modified:   README.md

git rebase -i HEAD~3

Git rebase is kind of like the swiss army knife of git commit fixing. You can remove commits, change commit messages, edit commit content… for multiple commits at once! HEAD~3 is an example of how you can select the commits you want to alter.

pick b14b68e Complete commit
reword 669afb8 A message I want to change
drop a6d958c Testing, do not commit for real

# Rebase dbff38c..a6d958c onto dbff38c (3 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
#                    commit's log message, unless -C is used, in which case
#                    keep only this commit's message; -c is same as -C but
#                    opens the editor
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified); use -c <commit> to reword the commit message
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.

Important: --amend and rebase commands alter git history and require force pushes to update remote repos. They should not be used on shared branches (like your main branch). They work best for pull request branches before review begins.

Bonus: git stash is a great helper for things you’re happy with but not ready to commit. Stashes are bundled away to leave your working tree clean (allowing you to switch branches and do something else if needed).git stash apply will restore the code to your working tree.

I was hyper-aware of being the most junior member of the team and the only female developer. I knew I would struggle for ages over a task someone else could complete in five minutes but I was determined to out-work this deficiency. I exhausted myself reading articles and doing tutorials outside of office hours. When I was actually on the clock (but delirious after my extra-curricular study and lost sleep), I would frantically copy/paste code, hacking away until I got something fit for review. I did this for months.

Eventually, I had a task that involved working directly with a colleague. I was terrified, imagining my ignorance would be on full display and I’d be fired and they’d think twice before hiring another female developer. Fears that look ridiculous written down but were all too real in my head at the time.

Almost immediately, we hit a bug and I didn’t have a clue what was going on. But funnily enough, my colleague didn’t either. He started talking about what he expected to happen and why he expected it to happen and I realized I could follow his logic. I could read it myself, in the code. We traced the bug back to a pre-existing issue, did a bit of research to understand the roots of the problem, filed a fix and went on with our main task.

Redefining productivity

It was a small detour but it made a massive difference for me. I stopped asking myself, “Why can’t I get this to work?” and started asking, “Why isn’t this working the way I expect?” Answering the first question was anxiety-inducing and gave me no sense of accomplishment when I stumbled upon the solution. Answering the second question could lead me down unexpected paths and often took longer but was more satisfying. I inevitably learned something that helped me multiple times in the future.

My productivity was still important to me, but no longer easily quantified. Having a productive day meant feeling good about the work I did that day. Instead of churning through a bunch of low-priority, low-impact tasks, I wrote higher quality code with a greater sense of purpose.

Documenting how we learn

When I joined silverorange, it was clear this view of productivity was generally understood. It’s a natural extension of our Be Kind philosophy. But the learning part wasn’t formally written down.

This was a topic of discussion at our last retreat and turned into an internal document with the following three distinctions:

• Everyday Learning occurs daily in the course of completing a task. Individuals should be comfortable self-directing this type of learning.
• Dedicated Learning is subject-specific, requiring more time than can be reasonably applied during a regular work day. This type of learning needs to be planned in advance with Project Managers.
• Shared Learning is an opportunity to disseminate knowledge gained from recent work or dedicated learning through bi-weekly design and developer meetings and weekly Show and Tell meetings. This could also be extended to cover conferences or group courses.

Vague and aspirational as it was, this document became the basis of a hiring exercise for our new Director of People (shout-out to the new slice, Nikki Mifflen-Mitchell!). In the process of introducing herself to everyone on the team, Nikki has been asking some great questions to inform the creation of an effective and inclusive personal development policy. It’s exciting to see the steady evolution of this work and I’m proud to be part of a company that puts action behind words.

Learning is part of the job

If there’s one thing I wish I had known from the start of my career, it’s this: learning is part of the job; it should be done during work hours. If your company already has a policy in place, use it! If they don’t have a policy, start the discussion. It may lead to results sooner than you think.

Here at silverorange our team has been growing faster than ever. Getting things done for a deadline can sometimes require letting go of trying to do things perfectly. However when a team has chemistry, even the most stressful timelines can be tackled collaboratively and it’s a beautiful thing. As a consequence of tight timelines and client expectations, a process that developed organically here at silverorange is the concept of “roughing things in”.

Get 80% done by the time the project is halfway through the timeline

One common problem is the illusion that a project is going at a good pace. Then, a few weeks before launch, everyone is panicked because the project is clearly behind. When we start a project, we add a bunch of tasks and as the project continues, a backlog accumulates and gets bigger as the project goes on. Tiny tasks add up and more are created as we uncover all the edge cases once we start testing. But you can’t really start testing until you have something that you can test!

“Commit code that is going to make a difference, but not necessarily be 100% polished. This means a change may not be 100% accurate to the designs or 100% accurate to the functionality. This does not mean merging broken code.”

This isn’t exactly new, as the concept of commit early and commit often has been preached for years. I’m sure we’ve all read about this and nodded along agreeing. Doing this in a team requires a certain understanding and trust. When we “rough things in” there is flexibility to merge code with minor non-blocking issues, but one must ensure there is a task logged to come back for a second pass for more careful code-review.

Say what? Are we saying we commit code that does not match the exact request, and has not gone through extensive review, nitpicked and commented to the point where reviewing becomes an eight hour ordeal?

The process of “roughing things in” starts when a set of code changes (a pull request) is proposed but has something missing or needs polishing. At that point we make it a habit of noting in the pull request what is missing and make it clear to the reviewer what will be completed separately. Essentially more responsibility goes to the developer to communicate this and keep track of these additional tasks. The reviewer also has to feel comfortable knowing that some unfinished work will get done later.

“Why would we want to make pull requests that don’t address the assigned task?”

One would argue it’s a waste of time to divide tasks into separate pull requests, because it requires more overhead writing descriptions and adding the task into project management tools which require even more descriptions. And yes, this does require more upfront time and effort. However, the time spent doing this allows the flow of work to keep moving forward.

The philosophy of only committing working code seems pretty logical. An extensive review process has also been a good way to make sure clean and unobtrusive code is merged to the project. It’s also an opportunity to work more closely with team members and learn from each other during this process. But is this practical when it comes to meeting deadlines?

When we split things up into smaller tasks, there are no hidden massive features hijacked in one PR going back and forth between two people. Some developers may not realize a massive incoming PR may very well change the ways they may be solving their own tasks.

Git commits are fast and easy to recover from if things need to change

“Roughing things in” does indeed expand the project since we are essentially committing “prototypes” and going back to fix or improve things later on. We are doing second or even third passes instead of trying to get one thing done perfectly the first time. But in doing so, we are able to test and uncover problems sooner. Major problems are found out earlier, and the smaller ones are prioritized for later. Once we have bigger problems sorted out at the beginning it’s easier to visualize and estimate how much more is left in the project.

Project Managers become more in tune with the state of the project, understanding how far into development the project truly is. Their role is more involved, understanding what changed and sharing these details with clients in a way that matters to them. There is no longer a reliance on a lead developer simply telling them where things are at. They can see progress. By constantly pushing code, the staging site is incrementally changing and viewable by clients because the project is always evolving in small chunks. Clients are more involved with the evolution of projects.

Evolving ways of software development

At first this may seem counterintuitive, but this method has been working well in projects where we are starting from scratch or is a completely new page or feature. It has worked well in teams with a shared understanding of the concept. This method isn’t the answer to all software development logistical problems, but it’s a start and we have certainly had smoother project launches thanks to the process of “roughing things in.”

The outpouring of corporate Pride Month good vibes and high fives is in full swing. Instead of just extolling our virtue as a queer-supportive company, I reached out to the team to get their feedback.

I wanted them to answer a question: What have you noticed or learned working in a company that embraces queer culture?

The answers are as varied as the people. For some, like me, there’s a focus on missteps and learning to do better. For others, they describe finding connection in the vulnerable space of sharing, honesty, and learning.

Our company isn’t just focused on Pride for a month - it’s a core value of the company and something we work on together. My coworker Clare sums up my thoughts on this well:

We’re not perfect. But perfect is the enemy of the good. And when I see the conversations people are having and articles people are posting and the space people are trying to make, not just for celebrations like Pride, but moments of sadness and anger and frustration, I take comfort in the fact that we are all trying to be good.

Clare Raspopow

I spent half a decade of my life working at a large, sprawling, often labyrinthine institution. Like many institutions, as the norms of society began to shift, they made a point of publicizing the efforts they were making towards Diversity, Equity, and Inclusion. Training sessions were available and in some cases mandatory. Banners were printed. Policy emails were sent. But talk is only a small part of the equation.

Training sessions aren’t very effective if it’s the same 10 people showing up or, in the case of those mandatory sessions, the audience views the facilitator as an opponent, not an educator. (It’s telling that in my entire tenure there, I never once saw a member of management at one of these sessions) A “preferred pronoun policy” loses its meaning if someone rolls their eyes as they use someone’s pronouns. A banner is pointless unless your management and HR teams don’t try to gaslight you into believing that the “joke” that Patty said at the meeting wasn’t really a big deal.

Which brings me to silverorange. I’m relatively new here, but the difference is palpable. The education sessions feel different, because everyone actually wants to be there (and I do mean everyone - our management is as actively engaged as the rest). Conversations about 2SLGBTQ+ issues are commonplace and everyday, like they should be. My coworkers are proud of their places in the 2SLGBTQ+ community. We all still mess up, but when you do it’s acknowledged, you move forward, and you try to improve.

We’re not perfect. But perfect is the enemy of the good. And when I see the conversations people are having and articles people are posting and the space people are trying to make, not just for celebrations like Pride, but moments of sadness and anger and frustration, I take comfort in the fact that we are all trying to be good.

Kristen Ford

It’s really easy to be jaded nowadays. Coming out in 2008, a lot of the heavy lifting had already been done and I naively assumed it would only get better from there. But time and time again, I’ve been reminded that society’s acceptance of queer people is tenuous at best. The mariage pour tous protests in my wife’s home country. Bathroom bills. The Pulse nightclub shooting. The endless number of murdered black transwomen that don’t even garner a news article.

When I was younger, Pride was a joyous event with chosen family. But as I started to look outside my bubble and heard more stories, it took on a different tone. I told myself I needed to be better, to do better. So Pride started having caveats. Pride was less joyful. And Pride was just another event on an endless checklist. I focused so much on how much better things could be, that I forgot to slow down and appreciate what’s already there.

Getting opportunities to share such an important side of myself at work has helped me reconnect with Pride. By seeing my coworkers learn, I’m remembering how mind-blowing it was to discover these things for the first time. I’m passing along the resources that I wish I had when I was younger. My posts and comments are met with curiosity and appreciation and the labour isn’t taken for granted! I can also be honest with them about the evolving language and politics that I struggle with too. Especially in years like this one, where it’s hard to find reasons to celebrate, I’m pretty grateful that I get to look at Pride with fresh eyes instead of jaded ones.

Kelly Burke

Silverorange has evolved into a workplace whose guiding principles encompass diversity and inclusion. This intentional shift a few years back has improved so many things in subtle and larger ways for everyone.

My teenagers have stated that they point out silverorange to their friends as an example of companies that DO exist that welcome inclusivity. They have said to me how great they think it is that we are explicitly respectful of people’s pronouns. The kids lead by example themselves as their friends shift names and pronouns they just accept each other as they are. They at times are exasperated when teachers deadname their pals and say, “jeez, it’s not so hard! He goes by “he” and his name is Tom.”

And they are correct. Using the correct pronouns is not difficult, neither is respecting fluidity in their gender expression. Sure, I screw up correct pronouns sometimes, but we talked about this as a company and chose guidance on how to do better (correct yourself, keep going, make it automatic for next time). It validates our 2SLGBTQ+ community members and expresses that they are surrounded by people who respect them and care about getting it right. If I could share anything with folks unfamiliar with these adjustments, it’s that it is way more important for the person to feel comfortable than your own comfort level with the change. It’s an easy step forward to demonstrate respect. I had very limited understanding or connection to the 2SLGBTQ+ community for the first 40 years of my life, and I have much to learn. Pride month for me is a time to recommit to a personal pledge I’ve made to do my own work, and hopefully continue to foster an environment of empathy for all current and future team members.

Kendra Kohler

I grew up in a small town during the 90s and early 2000s. Queer culture wasn’t something we really discussed except for when we casually dropped in homophobic language/slangs to regular conversation. I didn’t know that some of the things I said were harmful to others and I was missing out on a really special community.

Since then, I’ve seen friends and members of our town come out. I’ve moved to the city, made queer friends and experienced a lot more of their culture.

However, it wasn’t until I started working at silverorange that I realized how sheltered I had been. There’ve been so many discussions that have opened my eyes to the struggles that queer people are still dealing with today. I’ve barely scratched the surface and want to learn as much as I can to be a better ally.

To all the queer people out there, thank you! The world is so much richer and beautiful because you’re in it.

Jayme Fall

Growing up on PEI, between my family and circle of friends I never really had much exposure to the queer community. Sure, we knew one or two people who were “different”, but never thought much about it and never truly understood the struggles. I went on to spend a majority of my adult life working at small companies dominated by straight males where the subject matter was rarely introduced, and if it were it was in a toxic light.

When I started at silverorange, it was really the first time in my life that I had any significant exposure to the queer community, ideas, and working directly with queer co-workers. The supportive nature of the work environment made it very easy for me to learn and discuss some of these difficult topics, and, while I still have much to learn about the community I feel like I have come a very long way, and have silverorange to thank for that.

Nick Burka

I’m the type of person who really wants to support people. I often do so by launching myself into problem solving mode to help them “fix” things. An eye opening thing for me were all of the nuances of queer culture that kept making me stick my foot in my mouth or hurt the person I was trying to support.

For instance, my friend (and silverorange CEO) Isa asked me what I thought of them participating in a conference. I immediately lept in and said “OF COURSE! Why are you even worrying about it?” meaning to push them forward. In reality, I wasn’t taking into consideration the minefield that a trans person is potentially walking into in a situation like that. It’s been extremely humbling and fulfilling to work to change that gung-ho attitude. Now I try to pause, ask questions, check-in, and do my best to slow down, learn, and empathize with my colleagues before offering support.

Nikita Campbell

While growing up, I’ve had quite a few friends that are members of the queer community. It has always just been a normal part of life. However as I got older, I quickly realized that it was not the same for other people, and it wasn’t part of their normalcy.

In past employment, I have had coworkers make rude comments or ask outrageously innapproperiate questions when I’ve talked about stories involving my queer friends. I always chalked it up as them simply being uneducated about the subject. However, it really made me feel uncomfortable that they would ask these ridiculous questions, and made it feel like it was not a safe place to talk about everyday life that involved loved ones who were members of the LGBTQ community. I felt defensive and offended over the questions I would receive about people I care about, which really put it into perspective about how members of the LGBTQ community must feel in many day to day interactions with some people.

Then I started working at silverorange, and it has been SUCH a breath of fresh air. Everyone is accepting of everyone, no one judges anyone, and no one asks inappropriate questions. Silverorange is a safe and respectful space for anyone and everyone, and I truly feel like the world needs more companies like ours. When I think of silverorange, this quote always comes to mind, because I feel like it is so fitting to our company. “Be the change you wish to see in the world.”

Camila Rivera

I just started working at silverorange a couple of months ago. Since I applied, I realized how the company encourages inclusivity. From the first email that I got from our CEO, I noticed that all members were introduced by their pronouns. English is my second language and I was afraid of making a mistake that could hurt someone. Fortunately, I realized that being a company that supports the LGBTQ community, means also that they are willing to teach you and happy to help you in case you have any doubts.

Today I feel that I belong to a company that not just says that it supports LGBTQ people but also is reflected in its actions and its team members. I’m happy to belong to a company with a diverse workforce, which is driven by respect and is patient to include and teach anyone eager to learn to be more inclusive. Silverorange is an example of awareness of something that is still urgent to address in our society, the basic right to be true to our true self, without judgments, should be recognized at every level of our society.

Rob Campbell

I’m new to silverorange and I’m still getting acquainted with everyone. Being fully remote, during the aft-end of a global pandemic, I haven’t had the luxury of meeting everyone in person yet. Online, everyone’s been great, welcoming and frankly, delightful. It’s so refreshing being among a diverse team of excellent individuals.

I’ve always considered myself an ally for 2SLGBTQIA+ people. It’s a tough road and I recognize that, even if I don’t count myself within those abbreviations, I have a number of queer friends and acquaintances.

I know how that sounds: “White cisgendered straight guy has gay friend.” It could be a story from The Onion and I would read it and make fun of the person who said that. Except it’s true.

I enjoy learning from and supporting everyone if I can, where I can. I’m not always good at it and have made mistakes, gaffes and embarrassing missteps along the way and try my best to learn from them.

So, for Pride Month, I’m trying to be more open, more understanding and a better ally to my queer friends and colleagues. I appreciate you. The world is a better place because of you. Thank you for all that you do and for just being you. Happy Pride!

Steven Garrity

What I’ve appreciated most about the changes toward inclusiveness in our company over the past few years is the conversations.

While it’s most important that we work to create a safe and comfortable environment for everyone, I feel like the queer members of our team have actually created a safe space for me, a cisgender straight man, to learn and ask questions.

Should we update our logo with a pride-flag variation, or does that just look like an empty corporate gesture? What more concrete actions can we take? Beyond the answers to these questions, these conversations and even the discussions and feedback around this blog post have been rewarding.

I’ve also learned that there aren’t single right answers for many of my questions. As the acronym implies, the Two-Spirit/LGBTQ+ community is rich and diverse. No one person or group can be expected to be the arbiter of which terms and symbols are right for everyone.

To my friends who have helped me along when they’re already shouldering a lot — thank you.

Isa Grant

When I sat down to write a post about Pride for silverorange I quickly became overwhelmed. Like many a queer person, I have very complicated feelings about how corporations embrace Pride each year, as well as how it affects and represents me personally. As a visibly queer person who also happens to be CEO of a mid-sized business, I want to be able to both celebrate the ways in which silverorange cares, and be open and honest about how it isn’t enough. And I’m not nearly a good enough writer to do that.

So when Nick and Steven cautiously sent me early drafts of their contributions to this post, asking if it was fair for them to speak about queerness at silverorange, I teared up.

Often the work of trying to weave more queer awareness into a company that is predominately cis and straight seems to be the work of making a better space for myself, as well as other current and future queer team members. The fact that it’s also created a safer space for the rest of the team to not only support, but actively engage in an ongoing process of asking questions, learning, and understanding aspects of 2SLGBT+ perspective in the world is incredibly heart-warming.

Thank you, to those who wrote entries above, but also to everyone else at silverorange, for truly caring enough to want to learn and do better on social issues, including queerness.

A few years ago I wrote that queerness is joyous. I stand by that whole-heartedly. Happy Pride everyone, this June, and every day of the year.

Medium worked well for us, and its design constraints let us focus on writing. By using the blog.silverorange.com subdomain, we’re able to switch out our blog platform without disrupting the site.

The time to migrate off of Medium has come. The cross-promotions and sign-up prompts were getting to be a bit much (it was free, fair enough).

We opted to migrate our blog to a simple self-hosted system we built using Next.js. We were drawn to Next.js by the quick setup, the component-based development approach from React, and the simplicity and performance of static-site generation on the server side.

The result is light, simple, and fast. It’s so fast that we discovered Google’s Lighthouse performance auditing tool gives you fireworks if you hit 100% in all four of their measured categories:

We’ve also used the opportunity to exercise some newer front-end web practices, including CSS Grid for layout and much more visually prominent focused links for better keyboard navigation accessibility.

It’s nice to have the blog back in our own hands and not rely on the business whims, however good or bad they may be, of a platform like Medium. We’re looking forward to writing more and improving the site in other ways.

What does this mean for you? Nothing! You can keep reading at the same blog.silverorange.com address and keep subscribing to the RSS feed at blog.silverorange.com/feed.

Every August for the last five years, we’ve flown the remote folks at silverorange into Prince Edward Island for a week of work with the rest of the team in the office. We call it “Remote Week.” People come from various locations, including British Columbia, Montreal, Halifax and Ecuador (since this writing we’ve now added Calgary to that mix). It’s something we value at silverorange because in-person meetings can break the digital barrier and allow remote folks to connect at a more intimate human level that Zoom and Slack messages sometimes lack.

This year at silverorange, our Remote Week was different than most years. COVID-19 has shifted the way people work and although half of our team was already working remotely, the rest of the in-office team began now working from home too. Hence the birth of our first ever Remote Remote Week.

In the past we used this week as an opportunity to share the same working space and have some real life “watercooler” moments as we wait for coffee or prepare a bite in the kitchen. Many of us would choose to sit together on the third floor of our Charlottetown office. This space has a large table and couches along the walls, providing a relaxed environment where one can work while also engaging in side conversations. We usually plan lunches and dinners together and generally hang out after work for a few drinks too.

Given the circumstances of 2020, our main goal was to connect with each other in fun ways that were not directly work-related, either during or after work hours, through some required and optional activities. Although we didn’t quite hammer down the “working together” as much as we would have liked, we did manage to create a work week that was uplifting in these uncertain times of COVID-19.

So we hope the following activities will inspire other workplaces to come up with their own ways to uplift morale, provide ways for people to express themselves, and ultimately have fun with each other.

1. Zoom backgrounds with a twist!

We started off our Remote Remote Week with a light activity to slowly wind people into the week of planned activities. Everyone was asked to download or create a fun background for our weekly standup Zoom meeting. Five minutes before the meeting we reminded people to prepare their backgrounds but told everyone to refrain from using them until they were told during the call.

Once on the call, we gave everyone the surprise that those backgrounds were actually meant to be used by someone else. Each of us were assigned a random person to send our background to, and then were told to go ahead and activate the Zoom background each person had received. Some funny moments occurred, as some had naturally customized their backgrounds thinking it was for themselves. Each person was then given a moment to talk about their background and this resulted in some of us learning a few things about each other and overall got everyone smiling!

2. Team Collage with theme of “Music”

At silverorange we have a Slack channel called #out-and-about where we post a theme every week which encourages us to go out for a walk to take a picture with a goal in mind. For this activity we put everyone in groups of 4–5 people and instructed each team to create a “collage” borrowing from the #out-and-about theme. Since we have a few designers/photoshopers, we made sure there was at least one per team to digitally put together their team ideas into one composed image.

The theme for that week was “Music”, so lo and behold, we had some pretty amazing outcomes and truly memorable results.

For our Queen photoshoot, we had to take photos in dark rooms/closets. Jenn noticed everything was shoved out of the way in our closet yesterday and asked: “What were you doing in the closet!?” I told her I was taking a picture for work. — Steven Garrity

3. Game Night with Jackbox

We used Jackbox for our games night because there are a variety of interactive games you can choose from as a group, and the games are usually simple and silly with light competition which allows everyone to feel comfortable enough to participate. The games we chose to play included Drawful, QuickPlash and Fibbage. As seen in the screenshot above when playing Drawful, we had some pretty silly answers.

4. “Back to the Future” movie night

A movie night is a classic activity that can be done remotely quite easily with the help of Netflix Party! Each participant is asked to download and add the Netflix Party plugin to their browser. The person sharing the movie sends over the movie link and each person can see the movie on the left side of the screen and a chat box on the right. The movie can be controlled by anybody in the party, which does lead to accidental pauses.

As an experienced roast-host, it’s better to watch a dumb movie together so you can make fun of it. — Jacky Gilbertson

The best advice is to pick a movie that is either a classic, or intentionally bad to get some juicy commentary. The final choice was between “The Predator” and “Back to the Future”. After some fun slack polls and banter , we ended up choosing “Back to the Future” which honestly made us think twice about some norms in the 80's.

Thanks for the movie night organizing- it was fun to pick apart Back to the Future with you all. — Isa Grant

5. Learn-to-make-tortillas cooking night

I volunteered to teach the group how to make tortillas, a simple dish that can be made with minimal ingredients found at home, and participants can easily follow along in their own kitchens. This turned out to be a fun family event as Steven’s children joined in to learn how to create this timeless wrap that you can eat with a variety of things. Others joined just for the entertainment of watching and commenting as we cooked together.

6. Bop 🥁, banger 🤟, 🎷groove, 🎸jam

For this activity we split into teams of 3–4 people. We then jumped into a Zoom call where the organizer created Zoom breakout rooms for each team. Each team then collectively decided what makes a song a “bop”, a “banger”, a “groove”, or a “jam”, essentially deciding what characteristic each category has versus the others. Once each team had their criteria set, the activity began.

We had prepared a list of 10 songs chosen from our #jams Slack channel (where we share music) to categorize according to each team’s criteria. The organizer sent everyone off into their breakout rooms meanwhile the song was posted in our remote week channel. Each team then had a chance to react to the song with the appropriate emoji- 🥁, 🤟, 🎷, 🎸.

Each breakout room was set with a countdown of 3 minutes, allowing people to listen to a bit of the song, apply the criteria, share their opinions, and try to make a group decision. Once the time was up, the breakout room would end and everyone would regroup into one Zoom call to discuss, debate, and proceed to the next song. This resulted in some good spirited debate and fun GIFs while listening to some music.

7. Fancy dinner and happy hour

To finish off the week our last activity was a Fancy Happy Hour where the requirements were to order-in some delicious food, wear a fancy top and/or bring a fancy-looking drink. This made it easy to break the ice and by talking about our drinks and clothing choices we all learned a bit about each other in a more casual setting.

I put my food on a square plate because square plates are fancy! — Clara Campos

Normally during our remote week, silverorange pays for a nice group dinner out at the end of the week. This time around each team member was provided with a stipend to encourage participation and to allow flexibility for partners to join as well. This activity was voted number one by the team after we made a survey for which activity people enjoyed the most.

Lessons from our Remote Remote Week

Having a dedicated Slack channel for the week allowed for a casual space for people to share GIFs, funny comments and general praise for all the activities happening during the week. Using Slack surveys to choose games and movies made it a collaborative process that allowed for some friendly competitive banter.

Who came up with that game of categorizing music? It was super neat! — Kendra Kohler

We also did a survey to get some feedback and the responses were all very positive. Many had mentioned their interest in more team activities during the year and were generally feeling happy that this was planned out. We learned that connecting with teammates in a casual setting is truly important in creating a culture of creative expression, compassion, kindness, and trust. Overall this was a rewarding experience despite the slight challenges of being entirely remote.

That was great, @malena and @charles! Thanks for organizing our remote remote week! — Keith Burgoyne

Here at silverorange, we rely on a mix of our own hosting infrastructure and a variety of cloud-based services. In our on-premise server-room, oVirt has become an increasingly important component of our infrastructure. We’ve been using oVirt for a number of years, and have since moved many of our physical servers to virtual machines. Along with using Ansible as the source of truth for configuration management, we perform file-level backups with Borg.

While we could technically rebuild any of our servers using these tools, it can be a time consuming process, especially with many VMs involved. The last thing we want to be doing in a disaster situation is piecing back together dozens of VMs in the middle of the night. That said, it’s also important for us to perform full VM image backups for greater flexibility in disaster recovery scenarios.

What’s out there already?

One would think that backing up a VM on a modern virtualization platform such as oVirt would be a simple task. Unfortunately, that’s not the case. The oVirt API provides the means to perform backups but there’s actually no official tool provided to back up multiple running VMs automatically on a schedule. We came across a few open-source options, but they were either abandoned, their dependencies were too complex, or in some cases, required a VM as a proxy to attach cloned snapshots in order to back them up (which is resource intensive).

By far the best option we tried was vProtect by Storware. It did a great job handling oVirt backups and included robust features like incremental backup support, the ability to exclude certain VM disks from the backup, and scheduling policies. Storeware graciously offers the product for free for up to 10 VMs. Unfortunately, once you hit the limit you have to move to their paid license. Being a software development company, we support paying for software and understand the amount of work and costs involved in shipping and maintaining a product. The issue is that many of these backup vendors target enterprise-level businesses and often offer nothing for personal or small-business use. For example, a vProtect license for just three oVirt hosts costs $3,000 USD per year. They also license per-VM, but even with just 10 VMs you’re looking at a cost of $1,200 USD, minimum. For a large business these costs may seem like a drop in the bucket, but many oVirt users do not fall within that category (if they did, they’d more than likely be paying for Redhat Virtualization instead of oVirt).

Another drawback to vProtect is their lack of support for CentOS/RHEL 8x, although we’ve been informed that it is on their development roadmap.

Our homemade solution

After researching and testing some of the available options for oVirt backups we wondered if we could roll our own no-frills solution that would easily allow anyone to perform full-image backups of running oVirt VMs. We originally started by looking at the oVirt REST API, but later discovered we could do what we needed with Ansible.

What we ended up with is a set of simple Ansible playbooks that performs authentication to oVirt, exports a given list of VMs as OVA format, then performs a basic cleanup task to keep backups from getting out of hand. The OVA format is essentially a single file with the entire VM configuration and all data included. It’s a portable file that can be easily imported back into oVirt or any other platform that supports the format.

We found that the “ovirt_vm” Ansible module could be used to start an OVA export task on the oVirt hosted engine, which can export to a local or remote path attached to a specified oVirt host. For example, you can export a VM to /backup on oVirt host0, which could be a local partition/device or network attached storage like an NFS mount. The main hurdle we faced when using the ovirt_vm Ansible module is that Ansible is satisfied the task is complete once the export task is successfully submitted. This means that if we fed it multiple VMs, an export task would be started for all VMs at the same time which is far too resource intensive. We needed to find a way to loop over a list of VMs but wait for the export to finish before moving on to the next. We ended up looping the VMs over an includetask and adding a _wait within that included task using the wait_for module. The wait simply waits for the filename to be present in storage before moving on. The export process writes a temporary file first and is only renamed once the entire export operation is completed. It would be possible to implement a more sophisticated wait_for task which doesn’t need to watch the storage location, but this was the easiest option since we had local access to the backup mount.

Another hurdle we faced were timeouts, especially when dealing with large VMs (we have some over 500GB in size). The first timeout had to do with the wait_for Ansible module. wait_for has a default timeout of 300 seconds, which was easily overcome by specifying a higher timeout value in the task.

The second timeout we had to consider was the Ansible playbook timeouts on the oVirt hosted engine itself. Under the hood, oVirt is actually running Ansible plays to perform the OVA export (Ansible inception!). The oVirt engine has timeout values set for playbook execution which we found can be overridden by defining a custom value for “ANSIBLE_PLAYBOOK_EXEC_DEFAULT_TIMEOUT”. We did this by creating a new file and included in /etc/ovirt-engine/engine.conf.d/99-ansible-playbook-timeout.conf on the hosted engine VM. Note that the hosted-engine service requires restarting after this change has been made.

Once we had a working playbook that could export a list of VMs (including very large VMs) one at a time successfully, the last thing we needed was a simple way to control backup retention. We ended up adding a cleanup task that loops over the VM list the same way the export task does. This cleanup task is comprised of a couple basic shell commands using the Ansible shell module. The first task identifies the most recent backup of the given VM and stores it in a variable while the second task finds all backups of the given VM older than the retain_days var, excluding the most recent backup found by the first task. It then deletes them. This way we can retain X amount of days while also ensuring that at least one copy of any given VM is always retained.

To automate backups we simply run the playbook with a crontab entry.

Resources

We’ve set up a GitHub repo containing our playbooks: https://github.com/silverorange/ovirt_ansible_backup

Ideas for improvement

Some ideas that could be implemented in the next revision:

1. Instead of specifying a list of VMs, we could get a list of them using the ovirt_vm_info Ansible module If this route was taken, it’d likely be necessary to also include some logic to exclude VMs from backups say, for example,stopped VMs.
2. Implement a better wait_for solution, one which does not require access to the storage system. We think that it may be possible to use the “ovirt_event_info” Ansible module to determine when the export completes instead of relying on a file check.
3. Implement a more robust backup retention schema. What we’ve implemented in the first revision does the job, but there is room for improvement.

We have now used the playbook to perform several full backups of our oVirt VMs, including VMs larger than 500 GB with no issues to report. We plan to continue working on improving the process, and hope that this information will be useful to the oVirt community.

• Be kind.
• The 20th anniversary silverorange art project
• 20 Years of silverorange party!
• silverorange & Pride
• My Mother’s Mentorship
• silverorange at 20: How silverorange was almost called Net Prophet
• Being Charitable

Being kind isn’t new advice. In fact, we all learned the importance of kindness as kids. Whether it was showing appreciation with a thank you or playing with the new kid, it was the childhood golden rule. However, as we’ve grown up, trading play money for pay cheques, the instruction seems relegated to our personal lives and included as an afterthought in our careers.

Let’s face it, kindness doesn’t neatly track to an OKR and it’s much harder to codify “be kind” than “maximize profits” when making a business model.

Since our beginning 20 years ago, silverorange has been more about the personal than the professional. Given that we were started by a group of teens living at home, becoming super rich at breakneck speeds didn’t have to factor into the founder story. Instead, the company scaled up slowly, finding ways to grow the business while simultaneously figuring out what type of adults the founders wanted to be. Early on, we drafted our core message: “be a platform from which we can live interesting and fulfilling lives,” and it still holds up. Being kind factors heavily into that, and it’s the first lesson new slices read in our HR handbook.

Be Kind: The Short Version

Silverorange is an inclusive company, based on treating all individuals respectfully, regardless of gender or gender identity, sexual orientation, age, disability, nationality, ethnicity, religion (or lack thereof), or career path. We value respectful behaviour above individual opinions. Our team is an intentionally supportive group that recognizes and celebrates the creativity and collaboration of independent members and the diversity of skills, talents, experiences, cultures, and opinions that they bring to our company. Everyone at silverorange has the right to be treated fairly and with respect by everyone, and has a responsibility to treat others with the same consideration. Being kind toward your colleagues is key, but we also extend this to our clients and other external contacts, even (or especially) when we’re annoyed or stressed out by them.

The message sounds warm and fuzzy, but being kind isn’t all sunshine and rainbows. It means we have to test and challenge whether we are doing right by the people we are, the people we once were, and the people we want to become. It’s focusing on the lessons learned instead of fixating on the mistakes. It’s re-evaluating our humour and checking if everyone’s still laughing. It’s retiring well-meaning processes like board room video calls since remote workers find it hard to speak up and participate. Or anxiety parties that are supposed to alleviate stress but can trigger other issues. It’s making room for respectful debate so team members are empowered to express dissenting opinions and not feel singled out.

Silverorange isn’t a monolith, nor do we want to be. What was once a group of cis-white males from the same hometown has been transformed by the past three years of hiring. Now we proudly represent a diverse team including members of varying genders and gender expressions, sexual orientations, religious affiliations, ages, and ethnic backgrounds. Each member contributes their unique personality and life experience in a way that strengthens our company as a whole. Which is not to say our diversity work is done. The real work is educating ourselves on the ways we will still differ and ensuring people with those voices are set up to succeed. Inviting people to join a group where they aren’t already represented is a monumental (and sometimes dangerous) ask, and it’s doing a disservice to them if they’re just expected to trust us. We can’t promise we’ll do it perfectly, but we can promise we’ll do it kindly.

Throughout the past year we’ve learned how leaders in tech can champion one practice in public, but do another in private. At silverorange, we’ve found these simple practices have made us stay true to our word.

Be Kinder to Each Other

Express gratitude. It’s easy to take things for granted when we’re caught up in our individual work. Highlighting the wins each week, both as individuals and a company, helps remind us what we’re achieving as a team. It reminds us that even small or boring tasks are still valuable. Our clients contribute those compliments as well, which helps keep us motivated.

Focus on the positive. We all have struggles at work from time to time, whether that’s stress, struggling with something new, or our own personal issues. While there’s always a negative take to a situation, there’s usually a lesson to be learned. Even though trying to stay positive can initially feel contrived or inaccurate, the main point is to not dwell on the negative. Ruminating on how bad things are or could be is rarely useful… unless you’re doing risk analysis.

Give each other the benefit of the doubt. When deadlines loom and stress runs high, it’s tempting to attribute mistakes to malice or incompetence. Take a moment to cool down before you talk to your colleagues. Give each other the opportunity to change those assumptions.

Just listen. Receiving feedback is inherently uncomfortable, but critiquing can be just as hard, if not harder than receiving it. It’s emotional labour to identify the issue, plan a solution and deliver it in a way that will not risk the relationship. So if someone is working to help you improve, resist the urge to defend and actually hear them out.

Make room for new opinions. It’s naive to imagine we’ll always agree. As our team grows, we will hear other opinions rooted in personality, cultural or social differences. Sometimes that leads to conflict where someone feels they’re misunderstood or disempowered. In these moments, it’s important for both sides of that conversation to be human rather than be right.

Be allies and adapt for those that can’t ask for it. I enjoy introducing my coworkers to queerness and making silverorange adopt simple, inclusive practices like asking for pronouns and avoiding unnecessarily gendered language. However, there are a lot of lessons I can’t teach because they’re not my story to tell and education isn’t my job. As we continue growing, we’ll be able to add previously unrepresented voices to the mix, but we all need to speak up for those empty seats so they don’t have to do the heavy lifting.

Be Kinder to Others

Choose projects and clients that align with your values. Finding work personally or emotionally fulfilling can motivate you to get that project shipped. Given the chance, we would always choose work all twenty of us could get behind. That isn’t realistic, so our sales process invites any slice to speak up if the work would compromise personal or company values.

Stay on your client’s side. It’s easier to collaborate if you see your client as a teammate instead of an opponent. Avoid speaking negatively about them, and try to show empathy to their situation. Remember that you’re working towards the same goal. When issues arise, ask what both of you can do together to improve the situation instead of treating it like their problem.

Challenge clients to do more for their customers. We had a client challenge us to adopt broader accessibility practices and give us the opportunity to learn about inclusion. Because of that success, our team has chosen to incorporate low hanging fruit like colour contrast, semantic hierarchy and ARIA attributes into our best practices. We also advise our clients to simplify text in their privacy policies, terms of use, and other legal writing so they can collect informed consent. On a basic level, it’s the right thing to do. But if your clients still need convincing, it means their products can reach a wider audience.

Challenge our peers to do the same. As a bunch of introverts, networking has never been our forte. But as we’ve passed twenty years, we realize we actually have valuable insight to share. We’re active in the PEI dev and design community and try to teach others the benefits of diversity and inclusion. We participate in UPEI’s co-op program, by hiring summer students and sitting on hiring panels so students can practice their interview skills. We’ve been attending Montreal events for women and queers in tech, and have been inviting other agencies along.

Be Kinder to Yourself

Strive to do the best you can within reason. It’s admirable to have high standards, but make sure they are achievable. Talk to your managers and your coworkers to ensure that your expectations align with theirs.

Forgive yourself. We all inevitably slip. Planning and estimation isn’t a science, so sometimes you overpromise and underdeliver. Don’t beat yourself up over past mistakes. As long as you learned something from the experience, that lesson was worth it.

These suggestions will inevitably change with time. The way we express kindness evolves from day to day, from project to project, from person to person. We make missteps and we need to readjust with each new challenge. It’s a continuous process and a complicated equation to keep iterating on ourselves, but centring kindness as our guiding principle has been a fulfilling way to find community within our company and our industry.

About half of the silverorange team is now based in Prince Edward Island, and the rest distributed across Quebec, British Columbia, and Ecuador. This year we decided to keep our retreat on PEI, as a few of the Charlottetown team have new babies at home.

We spent our week at the Centre Goeland, a retreat centre in Cape Egmont, on the south shore in western Prince Edward Island.

We enjoyed some great meals, including a vegetarian feast prepared by Green Isle Catering.

The site of the retreat centre includes a handy altar for ritual sacrifice, and is just up the shore from the Cape Egmont lighthouse, which could use a coat of paint.

We had fun, but our discussions were productive and intense.

We enjoyed a fireside reading of iOS app release notes (really!), some virtual reality, and some actual reality. A few enthusiastic early risers swam in the chilly Northumberland Straight.

We each got a nice new pair of slippers. We voted for our Employee of the Year, where employees and family members are not eligible.

We enjoyed some bowling in Summerside and are still sore from an amazing evening at a trampoline park.

We had an extraordinary week. Thanks for all who worked so hard on food, logistics, sessions, and for those who travelled and spent time away from home, pets, and family.

Let’s do it again next year!

At silverorange we encourage our team to share the real aspects of their life—but only what they’re comfortable sharing, of course!—to normalize the struggles we all face. As 50% of our company is remote, we often share these things on Slack and use Reactji to show support with a growing set of custom emoji.

The hug emoji 🤗 makes a regular appearance. But sometimes its little cheery face feels off when we’re reacting to something a little more serious.

And so, we present, :serious-hug:.

It may seem like a little thing but so is making an appropriate emoji. Feel free to download a copy for your own use!

Halifax

Photos by Isa

Charlottetown

photos by Stephen

Montreal

Photos by Kristen

Check out his thoughts on Leaking Presence on the Acts of Volition blog.

We asked some of our friends and members of our team to create pieces of visual art to help celebrate the 20th anniversary of silverorange. The response was delightful. We first showed these pieces at the 20th anniversary party and we will be framing them for permanent display at the silverorange offices in Charlottetown. Thanks to all who participated.

Daniel Burka

NEW YORK/LONDON — Daniel is one of the original founders of silverorange and helped lead our design efforts for years. While he went on to work at Digg, TinySpeck, Milk, GV (née Google Ventures), and now Resolve to Save Lives, Daniel is still a co-owner and active advisor to silverorange. While Daniel has lived in San Francisco, New York, Bangalore, and is now setting up in London, he always makes it back to Atlantic Canada for our annual company retreat.

This glassy 3D slice sketch was from a set of experiments Daniel kicked off a few years ago, exploring how we could evolve the visual identity and logo of silverorange. We’ve opted to stick with our classic slice logo for now—it too was a Daniel Burka creation—drawn in Corel Draw back in 1999.

Geoff Gibson

OTTAWA, ONTARIO — Geoff Gibson is a close friend to many of us at silverorange. He worked with us for a little over a year, joining when the company was only a few months old. Geoff now works as a designer for the Canada Mortgage and Housing Corporation in Ottawa and creates visual art of his own. Geoff started with a list of memories and ideas he associates with silverorange. His list includes: Weekly BBQ, hikes all over the world (primarily California sequoias), , building (houses, crafts, websites, etc), healthcare, music, awards, frisbee golf, coffee, PEI, family, among many others. The border around the outside is a nod to the intricate wooden gingerbread decoration on our Charlottetown office.

Tom Hughes

SCITUATE, MASSACHUSETTS — Tom Hughes is a close friend and something of a company godfather. Tom served as the creative director at Apple, Polaroid, and idealLab! and has been a generous friend and mentor to many of us at silverorange. Tom created this remarkable oil painting with an actual orange posing as a model. It will hang in our office as a reminder of Tom’s friendship and kindness.

Tom also took a series of photos of Boston transit system and composed them into this mythical meeting of the silver and orange lines. If you look closely, there’s a slice in there.

Kendra Kohler

GIBSONS, BRITISH COLUMBIA — Kendra joined silverorange as a developer in 2018 and works from her home in Gibsons, British Columbia (the Beachcombers town!). She designed and crafted this custom cross-stitch for our 20th anniversary, but it’s not her first cross stitch for silverorange. During her first month, she made this beautiful cross-stitch slice that hangs in our office kitchen in Charlottetown.

Steven Garrity

CHARLOTTETOWN, PRINCE EDWARD ISLAND — I’m one of the original founders of silverorange and the company’s Creative Director. While I’ve got 20 years of experience with visual design, I don’t have strong illustration skills. I’m happy to dive into help a client improve the visual design and experience of a website, but give me a blank canvas and I freeze up.

I worked around these limitations by deconstructing our slice logo. I broke it down into simple geometric shapes and reconstituted them as a sun setting over a mountain horizon. The mountains are the two tips of the slice logo, the objects in the sky, and the sun itself, are from the dots on the peel of the slice logo.

Nikki Babaii

_CHARLOTTETOWN, PRINCE EDWARD ISLAND _ — Nikki Babaii spent the summer of 2019 with us as part of the UPEI co-op program. Nikki recast the iconic Scotch VHS cassette design with silverorange themes and impressive fidelity.

Stephen DesRoches

CHARLOTTETOWN, PRINCE EDWARD ISLAND — Stephen DesRoches joined as one of our earliest employees when the company was three-years old back in 2002. He works from our Charlottetown office as one of our lead designers and is also a talented photographer with a book coming out this year.

Stephen ambitiously took an actual slice of a real fresh orange and painted it in the style of our logo. While he shared this with us as an experiment, it was an immediate favourite given the rich effect of the mixture of paint and actual orange juice.

Stephen also created this minimal slice silhouette. It was created as a possible sticker for the back of Apple laptops back when the Apple logo was back-lit. It may crop up in our branding again as it’s such an effective rendering of the shape of the slice with so few visual elements.

Sean Martell

_NOVA SCOTIA _ — Sean Martell is the creative lead at Mozilla who worked for years in Toronto before returning to work from his home province of Nova Scotia. We had the pleasure of working with Sean during our collaboration on early Firefox branding and went on to refine the Firefox logo over several generations. Sean was generous with his talents and responded to our request within hours with his combination of the Firefox and silverorange logos.

Nick Burka

MONTREAL, QUEBEC — Nick is a founding partner at silverorange and works as one of our lead developers from his home in Montreal, Quebec. With masters in art history, Nick brings a unique background to this project. He was inspired by the collage works of the German artist Hannah Höch and created this collage as a physical piece, before capturing it with a digital camera and finishing it off in Photoshop. It’s full of visual easter-eggs and company history, but we suspect it was mostly an elaborate ruse to be able to put his own face on the canvas.

Nick also used this project as the impetus to update this set of avatars of the team at silverorange based on Pablo Stanley’s delightful avataaars library. You can create your own with the web editor.

Thank you all!

Thanks to all of the artists who participated in our project. It was fun to reconnect and I’m looking forward to having the pieces framed to hang in our office as we begin our third decade.

Thanks to Daniel Burka and Stephen Desroches for the wonderful photos! And thank you to everyone who joined us and for those who sent well wishes.

Pride month may be over, but Pride events are just starting in the cities we at silverorange live in. I’m writing this in Halifax which kicked off its Pride celebrations yesterday. Pride PEI celebrations started today. Montréal and Vancouver both have Pride in early August.

And this year, silverorange has been celebrating.

Silverorange started as an apparent monoculture. We were seven Canadian white middle-class male teenagers when we started the company in 1999.

I was lucky enough to be one of those founding teenagers. My entire adult life has been spent as part of silverorange. On August 1st, just a few days ahead of the company’s 20th birthday, I’ll celebrate four years in the role of CEO.

Today we are 19 people with a far more varied mix of background, gender, and sexuality.I have a direct and personal role in that expansion of identity and representation within the company.

The same four years I’ve spent as the CEO has been a period of immense professional growth as I’m constantly learning how to do the job. It has also been a period of intense personal growth and the start of a lifelong project of living openly as a more genuine version of self. I am proudly and visibly trans and queer.

It’s no mistake that these things are intertwined. There has been a positive feedback loop of support from the silverorange team, and trust in my leadership, feeding back into the confidence and comfort in myself.

With all of this I’m personally feeling the desire to both mark and celebrate Pride more with each passing year.

A year ago I very publicly claimed my trans identity.

One year on I’m still figuring out exactly what that means.

What I am certain of is that it includes being very visible and a very proud version of being trans. I won’t have it any other way.

Happy #TransDayOfVisbility all pic.twitter.com/oTLKln5oHH

— Isa Grant (they⚡️them) (@isa__grant) April 1, 2019

I’ve been thinking about marking Pride as an organization for a while. We started kicking around rainbow versions of our logo many months ago. I knew I wanted silverorange to celebrate Pride this year, although at first I wanted to understand why it felt important.

I wasn’t sure that it wasn’t just the excitement of being a newly out queer. I wanted to make sure we weren’t just wrapping ourselves in a rainbow and participating in pink-washing with our company. Most importantly I wanted to make sure our team—especially the LGBTQ+ members, thought it was important and justified as well.

In the end I came up with the following important reasons:

• Silverorange is far more than the founders and more queer than just me. We have a growing LGBTQ+ group inside our company spanning lesbian, bi-and-pansexual, and trans identities. Some of us in that group make this a foundational part of our public selves, and for some of the team it is a more private aspect of self. Overall it’s a facet of who we are as a group and we all want to celebrate that.
• Our whole team has been genuinely interested and engaged in better understanding LGBTQ+ issues.
• For a small group we’ve done a lot of hiring in the past four years, and are likely to do more in the future. Being loudly, clearly, and proudly queer is part of who we are now. Job candidates knowing this is a safe and welcoming environment is incredibly important for both them and us.
• As an agency, we work with lots of teams and people. There are queer identities within that pool and bound to be more in the future. It’s just as important to extend the same sense of welcome to everyone we work with that we do for those within silverorange.

Seeing the silverorange of today, both more welcoming but also more willing to do the work of improving, is something I feel immensely proud of us all in. It is a credit to everyone who works here on the never-ending task of changing our culture for the better.

In the end, I think it’s important to celebrate how we have all grown and who we have become. Queer identity is wrapped up in struggle, but it is also joyous and worth celebrating.

In many ways this is 20 years overdue.

Queerness is joyous. Happy Pride Everyone.

I’m writing this as part of silverorange’s “20 years of silverorange” series because I’ve been thinking lately about how my mom inspired and mentored many of us when we launched our company. She also had a major impact on the lives of many people beyond me, my siblings, and my co-founders. She was a force of change and an inspiration for the large group of people who encountered her.

My mom died of cancer in 2006. She was 51 years old, and saw silverorange through its first seven years. She knew we were doing well and had been successful, but I wish she’d been able to see how far we’ve come as people and as a company. Much of what we’ve become is due to her.

My mom had four kids by the time she was 23. She quit her degree in biology at the University of Guelph to raise us. She was an active parent who took us on outings, participated in school, and encouraged and supported us to try new ventures. As siblings, we sold pussy-willows around the neighborhood, fresh bread (that she baked) at our local campground, and flowers and melons that we grew ourselves. We always felt like we were the ones to run the project, but it was her who guided us throughout the process.

When I was in elementary school, my mom went back to university and earned a degree in history. She parented full time, took classes at night, and won the Governor General’s Medal for top marks in UPEI’s entire graduating class. Sometimes I would sit with her in the back of her university class and work on my homework while she took notes. It was hard not to be influenced by her work ethic and determination.

My family wasn’t the only one that was influenced by her. She also earned a teaching degree and taught special-needs classes to kids with family problems, behavioral issues, or both. The parent of one of her students was so affected by her work with her young son that she named her next child Martha. When my mom later said it was important to find meaning in work as well as enjoyment, her example hit home to me.

When I was about 12 years old, my mom asked me if I wanted to go camping with her—just the two of us. With four kids in the family this was extremely rare, it had never happened before. I said yes. We didn’t go far, up the road 25 minutes to Strathgartney Provincial Park. It was a simple evening: we went for a short hike, cooked something on our old Coleman stove, sat and talked during a sunset, and slept in the tent. It was one night, but it’s so extremely memorable to me. I don’t remember what we said to each other, but I felt special, and supported, and connected with her. When I came home I knew I could do anything and that she’d be there to support me.

In high school, my brother Daniel and I became friends with Nathan Fredrickson, Isa Grant, and Jevon MacDonald. Together we printed off the HTML 2.0 Spec and made a simple website in the Mosaic browser. My mom picked up on our interest and helped us create Whitelands Inc, a little company to make websites. We worked out of the attic of our farmhouse outside Charlottetown. She incorporated the company, opened a bank account for it, and helped us get set up. On our behalf she applied and won an Industry Canada grant to make a website about the Charlottetown Conference of 1864—our first big contract. Instead of the usual process where an institution would apply for funding and hire students to do it, my mom took the initiative to go for it herself. Her attitude to make an opportunity happen (and not wait for something to fall in your lap or do calls-for-submissions for contracts) would become a core principle for our later business decisions.

After the success of the Charlottetown Conference site, we got more grants and more contracts to do more sites about war photos, potatoes, and later client sites for conferences, dog breeders, and more.

Her hand was in everything. She helped write grants, line up meetings, make connections, and do all of the paperwork. She was essentially the CEO, CFO, and COO, but let us reap the rewards and recognition. She also made us dinner. As a young person, it was hard to give her all the credit I now wish I could.

In 1999, the Whitelands team met up with Steven Garrity and Dan James who ran a little company called Meta Media. That summer we combined our teams to form silverorange. Again, my mom was there to offer support, advice, moral guidance, a boardroom table, and more.

My mom’s energy to help others and the power of her personality reached deep into her community. She volunteered for many charities and served on the international board of Ten Thousand Villages. She also touched the lives of coworkers, friends, and neighbors. Every few months, I’ll get a note out of the blue from someone who asks me if I knew how much she had helped them. She was a mentor to many others and supported people with their issues of love, kids, divorce, illness—essentially the big issues in life. She fiercely advocated for acting morally, and was also there to give a long, supportive hug when it was most needed.

The legacy of her guidance can’t be overstated. My sister is an active mother of two and a pastry chef. My older brother is an expert programmer at TwoSigma in Manhattan. Daniel, my twin brother, who is still an active co-owner of silverorange, joined Digg, then GV, and now Resolve to Save Lives. I’ve been proudly helping run silverorange for 20 years. Us kids, my cofounders, and so many other people who my mother met have all been shaped by her.

The goal

The project involved coming up with an entire system to help low-income families get discounted internet access and for participating ISPs in Canada to securely validate who qualified. We worked with Computer for Success Canada (CFSC), who oversaw the entire project, and with the Innovation, Science and Economic Development Canada to design a framework that made it as easy as possible for qualified households to get notified, find a participating ISP, and to get them online with the program.

Focus on accessibility

CFSC pushed hard for a focus on traditionally overlooked communities. We wanted the program to be as easy to access as possible for everyone, especially those with low literacy, people who aren’t comfortable using computers (low digital literacy), and people with disabilities who use special browsers or aids to complete tasks online.

We got to work with literacy expert Gillian Mason and learned a lot from her about the unique ways those with low literacy approach content online. Her advice and contributions really improved the reach of the program and changed how we wrote notifications and messages, and also the design of the interface and access codes. We also got to run tests with Inclusive Media Design whose expertise on how blind and vision-impaired users navigate websites greatly improved the site. Their testing with screen readers and assistive devices made the site much easier for vision impaired users to navigate.

We think of web-accessibility as using good semantic markup, accessible interface elements and a clear way to navigate content. For this project, we took it further by developing the entire process from the ground up to be as inclusive as possible. I published an article on how to make the most accessible access codes. We worked with CFSC, Gillian, and IMD to make sure the wording for all content was as easy to understand as possible. We made sure the site worked with screen readers, zoomed-in viewing mode, high-contrast displays, and other assistive devices. All decisions, whether design, policy, or implementation, were always grounded in making the program as accessible to as many people as possible.

Usability for Promotion Codes and Access Codes

Testing to prove our concept

One of the most rewarding parts of the process was doing prototype testing with a group of participants with low literacy and low digital literacy at our office in Charlottetown. It’s always humbling to see your assumptions put to the test in a real world scenario, but even more so in this case when our testers revealed things we took for granted, like whether or not the system was a “test” with right and wrong answers, how to communicate that something that seemed “too good to be true” wasn’t a scam, or how challenging it is to write instructions on what to do next when each word needs to be carefully considered.

We came out of the testing experience with a much stronger design that would have been almost impossible to accomplish without testing. It’s often hard to take the time to validate that a design accomplishes your goals, especially with a fast moving project with ambitious timelines, but without this step the whole program would have been significantly less effective. Skipping the testing process and having to address these issues later in the process would have been much more costly and time-consuming in the long term.

Full system design

I’m most proud of the way silverorange tackled the project with our design philosophy in all aspects of the project. That means more than creating a highly usable and “simple” web interface. We really designed an entire system that focuses on usability at the core. This type of design encompasses program policy, database design, system architecture choices, API design, writing, support, and end-to-end user experience. With so many stakeholders involved and a large target population, all of these things need to work in tandem to make the experience as easy as possible.

We ended up with one of the simplest looking websites we’ve developed in years. While there’s a complicated API behind the scenes, ISP-facing tools, and a significant codebase behind it, the simplicity of the experience is a testament to user-advocacy throughout the project. Both CFSC and silverorange kept focused throughout the process on the easiest to use system despite many pressures to add text, steps, or options to the process that would have pulled us away from that goal.

At one point, about halfway through the project, it became clear to me that a big choice we had made early on was no longer relevant and by removing it we could make the system simpler. We already had documentation written, API designs in place, and had confirmed the current path in many meetings. Plus we were tight on timelines and moving fast. I was worried it would look bad to re-question the earlier choice, but I became convinced it was important enough to re-open the discussion. We called a meeting, hashed out a solution, and implemented it. And the end result was much better. To me, that’s as important a design decision as any in the project.

Launched!

We’re very proud of the Connecting Families project. Through it, hundreds of thousands of low income Canadian families can save a significant portion of their budget by reducing their internet bill and spending that money on things like food, housing, and their children. Families who couldn’t afford home internet before will also be able to get online and have access to education, public services, and employment.

It was a true collaborative effort across the public, private, and not-for-profit sectors and really pushed us at silverorange to use all of our design skills to make a highly usable and smooth web system. We’ll also be involved in the project over the next three years as they try to reach as many low income Canadians as possible.

Go Connecting Families!

On August 11, 2019, silverorange will turn 20 years old. We were formed in 1999 when two small businesses joined together—MetaMedia and Whitelands Studios.

We obviously needed a name for our new venture and started throwing around ideas. You know how there are no bad ideas? We had some bad ideas. I’m not sure who actually thought of it, but I remember liking the idea of naming the company Net Prophet. Get it? There are at least two puns in there. Thankfully, greater wisdom prevailed.

Our goals for the name included:

• The name shouldn’t be tied to any particular technology—we were building our websites in ColdFusion at the time, something we knew even then wouldn’t last.
• Something abstract, that we could imbue with meaning rather than carrying too much meaning itself. While IBM may stand for International Business Machines, it has long since become a new word of its own.
• The .com domain name must be available. There was no .io in 1999. It was dot-com or nothing.
• Something we could say to people without having to explain or spell out (the opposite of slashdot.org.

Someone suggested “silver systems”, which we liked, but wasn’t quite unique enough to ensure a domain name. Someone else suggested something orange related. We threw around the number 47—the atomic number of the element silver—which was a bit too close to 37 Signals, a company we admired.

Eventually, someone suggested we merge the silver and orange ideas. “silverorange” sounded pretty good. It didn’t really have any baggage or meaning that we didn’t like and the silverorange.com domain name was available.

I don’t remember who in particular ultimately suggested the name silverorange. As soon as we settled on it, Dan James shouted “I call dan at silverorange dot com!” and Dan(iel) Burka followed up with “gah!”

silverorange as a name has aged well—if we do say so ourselves

Our original goals of having a more abstract name have served us well. While it may be a touch goofy, we managed to pick a name for a company when many of us were twenty years old that we’re still happy with twenty years later.

We took a similar approach to how we presented ourselves beyond just our name. Our tagline “building powerful web-based systems” has also aged well. That’s still what we do today. Our website today has only evolved slightly to: “silverorange designs and develops simple and powerful web and mobile applications.”

If I were to time-travel and give our twenty-years-ago selves any advice on naming and branding, it would be that cleverness is seldom timeless, and that the real meaning comes from what you do with the company, not from what it’s called.

The success of a new standard like this will depend on it being easily usable by people of all different levels of experience with the Web. So, instead of focusing on the technology here, I want to take a look at how it works in practice.

So what browsers even implement WebAuthn?

CanIUse has a good rundown of browser support for WebAuthn at the moment:

You’ll notice a few major gaps there—Safari, basically no browser on iOS (Mobile Safari, Firefox, and Chrome aren’t supported), and only the latest version of Edge. The bright spots are on desktop and Android where Chrome and Firefox both have support, though as you’ll see below, supporting the standard and having it actually work in practice are two different things.

Update: it looks like Safari is getting WebAuthn very soon. Thanks for the heads-up Stuart

Update 2: And they’ve done it in the Tech Preview release (May 29)

While support is growing, WebAuthn is still difficult to use

Despite the spotty browser support, I wanted to see how it worked in the browsers that it’s implemented in. I used this demo site at WebAuthN.org for testing.

Firefox Developer Edition: Scary text and misleading icon

• The wording is really confusing. Phrases like “extended information about your security key, which may affect your privacy”, “the website may decline this key”, “Anonymize anyway” are scary technical terms. I’m a programmer with 20+ years experience and it’s not even clear to me why there’s a security risk. I know this is bleeding-edge technology, but surely Firefox can do better to hold the user’s hand through the process.
• Crossing my fingers, I click “Proceed”.
• Despite the “fingerprint” icon, I guess I have to use a USB key? The touch sensor doesn’t work in Firefox on macOS yet. It’d be nice to test the whole flow, but the wording of the message and having to agree to a security warning every time you want to save your identity on a site is a bit of an impediment.

Chrome on macOS: Very technical feeling

• Pop-up 1: Pretty decent start really. I chose “Built-in sensor” to use my MacBook Pro touch sensor.
• Pop-up 2: “Google Chrome is trying to verify your identity.” This is the standard screen I get on macOS whenever I use my touch sensor.
• Pop-up 3: “WebAuthn wants to / see the make and model of your Security Key”: Hmmm… now I have to authorize the website to use it? Even though I’ve chosen twice already to proceed. And I didn’t choose to use a “Security Key”, I’m using Touch ID. Confusing.
• And… it fails. Maybe the WebAuthn.org demo is out of date? Maybe it just doesn’t work yet? Chrome Developers?

Chrome on Android: Better wording, but so many steps

• Get Started: This is the best permission screen yet. Here you’re encouraged to proceed which is good, but then I also wonder why you even need to be asked. I’m also not sure anyone will know (or care) what a “Security Key” is in this case. The description could also be more clear and helpful about what you’re actually doing. I’ve offered an example in the “The wording should be way less technical” section below.
• Using your fingerprint must be the main use-case here, but they still make you choose. Maybe it would make more sense to just assume the fingerprint and then have a “other verification options” to the next screen?
• “Verify your identity” is a really nice screen. But “Use screen lock” is not a clear button label—and why is this a manual action after I’ve already put my finger to the fingerprint reader?
• And… not sure why it fails. But I’ll leave that to the WebAuthN.org programmers to figure out.

The initial implementation shows promise, but there will need to be more focus on usability

I realize these are the first implementations of WebAuthn and that there’s a lot of work going on right now to improve things. With that said, here are some initial thoughts on the user-experience for WebAuthn.

The wording should be way less technical

The way insecure messages are shown for security in browsers is a good model to follow for WebAuthn. Most warnings for SSL just talk about “Secure Connections” or “Your connection is not private” or warnings about “trust”. There’s little mention of the underlying technology. At the moment, WebAuthn feels like it’s only for developers and experts. The wording in the authentication and the information around it talks about USB authenticators, “security keys”, etc. Instead of talking about all of this technical jargon, the person should just be reassured with something like:

Use your fingerprint to verify your identity

You’ll be able to sign into webauthn.org using your fingerprint. This information is sent securely and is unique for each website so there’s no risk of your information being shared.

Or use a different verification method…

Authorizing WebAuthn per site should be easier

It’s unfortunate that I’m asked multiple times whether I really (really) want to use WebAuthn on each domain I visit. When you consider the current state of passwords in browsers, anything is an improvement. Currently, passwords are implemented with <input type="password"> that sends the password in plain text and I have to hope that the developers who implemented on that particular site use decent encryption on their end to store it. I shouldn’t have to jump through hoops to use something that’s so much better than that out of the box.

Ideally, it would just jump straight to a fingerprint validation step without having to ask for my permission to first allow for the use of WebAuthn. If the “permission” step and the “auth” step could be combined, it would be more in line with how apps like 1Password use fingerprint authentication. Ideally it wouldn’t need to be authenticated in the same way that Geolocation API does due to privacy. It seems that the most the website could get would be a unique identifier for me, so I wonder if Webauthn could just be enabled by default. That said, there may be valid reasons to first have to give permission.

At the very least, the number of pop-ups and permission steps could be reduced. Having to be given info, then agree, then choose a method, then input your fingerprint, then receive confirmation, is too many steps.

Choosing an authentication method should have a default

The options to choose a USB-key, NFC, or Bluetooth are confusing. I realize that there’s a good chance that the Firefox, Chrome, and other developers are starting with the use-case that’s the most prevalent for them internally and will circle back later to address the rollout of WebAuthn for everyone. Hopefully the next iteration will start to make those authentication options less in your face.

USB keys for authentication will almost certainly never be used by home users where authentication (at least for now) will be via fingerprint sensors on laptops or phones. Having to choose an authenticator is confusing for the vast majority of people who don’t even know what that is, and the default should be obvious—those with USB keys or other auth methods can be made to do a bit more work to go to a preference (or subtle link) to enable that option.

Can’t wait until it’s ready for us to use!

I really love that the Web Authentication API is coming alive, but I worry that it will fail to be used widely if a few simple user experience improvements aren’t made. Better copywriting, fewer technical questions for users, and streamlined flows would go a long way to making the API a truly wonderful experience.

Thanks to Daniel Burka and Steven Garrity for their input and editing on this article!

What follows began as a brief presentation I made internally at silverorange.

I’ve never been great at taking feedback or criticism. Few people are. I’m trying to get better at it. These are some thoughts that have helped me.

I’m not an expert on this. On the contrary—that’s why I’m talking about it, because I’m bad at it and want to get better.

When you get critical feedback:

• Don’t get defensive. That’s often our first instinct.
• Maybe don’t react at all, initially. Just don’t respond right away—give your emotional reaction a moment to pass.
• They might be wrong. Maybe your thing is perfect.
• They’re probably not wrong.

I give you The Depression of Defensiveness. The left axis is a scale of how you feel (good is up, bad is down). The bottom axis is the inexorable and relentless march of time.

1. First, you’re oblivious. You’re just existing in a blissful state of self-assured ignorance (or maybe low-grade anxiety).

2. Bam! There it is: feedback!

3. PFFT! They don’t get it.

4. Wait a sec … that might not be a bad point.

5. Oooh! I totally missed that.

6. Respond only now that you are enlightened.

This entire process could take two days, but in my experience, it often takes 30 seconds or less. A short enough time that in the span of a conversation, you can say “Hmm …” or, “Ok, let me think about it for a minute.”

In summary, shut up for a minute (or a day) and think about it before you react.

As our small company has grown beyond the number that can participate in a single hug, we’ve inevitably drifted into the area where many of us are unaware of the process that went into most decisions we weren’t directly involved in.

It’s important at this stage that everyone remain informed enough to have a sense of trust. People should know they can have some agency and influence, but not necessarily a vote.

In his great book on the creative collaboration process at Apple during the development of the original iPhone, Ken Kocienda shares an anecdote about an engineer being rebuffed when offering feedback.

In Ken’s story (loosely paraphrased here), an engineer reported that the new button styles in iOS 7 didn’t look “clickable.” This engineer was told that the Human Interface group was in charge of this and they have their reasons.

Now, if this engineer is at a party months later and someone asks why the new buttons are so bad, they may respond with frustration (“I know—it’s dumb! I tried to tell them”).

Instead, if this engineer had been given some insight into the rationale behind the decision, they may have become an ally (or at least not a critic) of the choice and been able to comfortably defend the decision to friends and family.

The key here isn’t how the friend at the party sees Apple—it’s how the engineer feels about their own agency within the company. It feels pretty lousy to be putting your effort into a project when the motivations of those at the helm are inscrutable to you.

So, when asked why a thing is like it is, don’t respond with:

“Someone already thought about it. Trust me.”

Instead, take a few minutes and use the opportunity to turn a bystander into an ally:

“It’s a long story. Do you have a minute?”

I like to let people know when to clap.

The first installment of our “20 years of silverorange” series.

At silverorange we try to take a caring approach to work and the world. We make an effort to tackle meaningful projects (for instance, we recently helped launch the amazing Connecting Families initiative that helps low income Canadians get $10/month internet), our work culture is built on compassion, we make time for families and friends, and we encourage community activism. What I’d like to highlight here is how we also use charitable giving as way to support causes that are important to different members of our team and to educate each other about issues that are important to us as individuals.

We’ve previously taken a quiet approach to charitable giving in order to avoid patting ourselves on the back for just giving away money. I’m making an exception here because I’ve been struck by how well these ideas have worked as an addition to our company culture, and because I hope one of the ideas might prompt another group to try something similar.

Kiva Loans

Most years at our retreat we give each employee some sort of gift. This year, we did a combination of money for self-care (to be used for anything from yoga, to massage, to psychological healthcare) and $500 to give out as microloans through the amazing Kiva platform:

Kiva is an international nonprofit, founded in 2005 and based in San Francisco, with a mission to connect people through lending to alleviate poverty. We celebrate and support people looking to create a better future for themselves, their families and their communities.

By lending as little as $25 on Kiva, anyone can help a borrower start or grow a business, go to school, access clean energy or realize their potential. For some, it’s a matter of survival, for others it’s the fuel for a life-long ambition.

100% of every dollar you lend on Kiva goes to funding loans. Kiva covers costs primarily through optional donations, as well as through support from grants and sponsors.

Kiva lets you search for the types of projects you’d like to support such as women-run, single-parents, sanitation, eco-friendly, etc. They also have some really nice features where you can see what types of projects other people on your team have donated to and where they’re located:

So far we’ve made a total of 95 loans (and counting) to help small businesses who otherwise would be denied credit by traditional lenders in their countries. We’ve funded a farmer in Kenya so she can purchase high-quality seeds and good fertilizers, a family in Jordan who plans to start a home products store after restarting their life there after the war in Syria, and a man in Armenia to install solar panels to save money on energy costs, among many other worthy projects. It’s great to be able to share these stories with each other as we choose projects to support and to see people across the world who are improving their lives and their communities.

Monthly Donations

Since 2014 we’ve been giving back to our communities through company-funded donations. Every month, two employees get to each choose any registered charity to give $1,000 to. Over the years, we’ve given to over 35 amazing charities with a huge variety of interests such as the environment, social causes, health, poverty, and literacy. It’s a great way for us to teach each other about the causes that matter to us. For instance, our CEO Isa, who’s a genderqueer trans person, made an example of this by donating to Trans Lifeline —a gesture of support for an important cause, as well as a chance for us all to reflect on the struggles trans people face in our society on a daily basis.

Some of the charities we’ve donated to include:

• PEI Family Violence Prevention: “providing a place of safety for women and children who are victims of abuse, educating the public about the issues of violence against women and family violence, and advocating for the needs of abused women and children.”
• Diabetes Canada: “leading the fight against diabetes by helping those affected by diabetes live healthy lives, preventing the onset and consequences of diabetes, and discovering a cure.”
• Rainforest Alliance: “building an alliance to create a better future for people and nature by making responsible business the new normal.”
• Dans La Rue: “the only organization in Montreal which takes a multifaceted approach to respond to the needs of homeless youth and youth at risk.”
• EM:RAP GO: “while access to expert emergency medicine has developed rapidly across high resource nations, in many lower resource communities it is still in its infancy. EM:RAP GO plans to change that.” EM:RAP is also a client of ours.

Good Feels

Our experience with charitable giving as a group has been extremely positive in so many ways. Personally, I keep a watchful eye on our donation calendar and look forward to my month so that I can choose an interesting organization to donate to and share the reason I chose them with my friends at work. When my Kiva loans are repaid, I give a little fist-pump for the entrepreneur who completed their project and then I get the joy of looking for a new person to fund.

I’ve written an article about the value of using difficult data when designing for the Web (placeholder text, media, etc.). I’m honoured to have the article published on the venerable A List Apart site:

Design with Difficult Data by Steven Garrity

My first article for A List Apart was published a remarkable 17 years ago in 2001! Given this cadence, I look forward to submitting my next article in the year 2035.

Thanks!

• Thanks to Nick Burka, Daniel Burka, Malena Andrade, Jacky Gilbertson, Stephen DesRoches and the others at silverorange who helped with the conception and editing.
• Thanks to Ste Grainer who was my ALA editor for this article. Ste offered great feedback and encouragement.
• Thanks to A List Apart taking the submission and for helping so many of us learn and grow.

A few interesting patterns have emerged in our use of Slack at silverorange.

THE WAVE 👋

As a company distributed across Canada (and Ecuador), we span four time zones. This makes the morning “hello” and evening “see you later” something asynchronous.

Our remote team members gradually began starting their day with a 👋 emoji in our #office Slack channel. This serves as a friendly greeting, and also a light reminder that “Hey, I’m here!”

It’s the digital equivalent of seeing someone walk into the office and nodding on their way by.

At the end of the day, another wave serves the same purpose: a friendly goodbye, and a gentle notice that “Hey, I’m out!”

I’M BACK! 🔙

Another interesting pattern came from our resident emoji artisan. When they would post a message about a brief absence (“Running out to get a coffee”), instead of following up with another message (“I’m back”), they add the 🔙 emoji as a reaction to their original message.

It’s a handy way to indicate when you’re back without interrupting people. It also shows an updated status if someone is catching up and reads your message later.

While neither of these patterns were mandated or documented, they’ve both been widely adopted by the team. It’s fun to see how our group works out our own little communication patterns.

THE #TROPHY-CHEST 🏆

Some of these light usage patterns are worth formalizing (we’re paving the cow paths). As we started to use the trophy 🏆 emoji to acknowledge achievements, we’ve gone on to gather these items each Monday into a Highlights of the Week presentation. Read our other post on how we 🏆 to celebrate.

I 👀 YOUR 👍

There are a few other emoji reactions (reacji, in Slack parlance) that we’ve imbued with a bit of extra meaning.

• The 👀 emoji indicates that you’ve seen or read a message.
• The 👍 emoji indicates agreement or approval (it’s not 🚀 science).

OUR OWN EMOJI DIALECT

We’ve also added a few of our own custom emoji to Slack:

• For each of our team members, we have a custom emoji for their name, so you can drop :nick: into a sentence (without necessarily using their full username). We also use these to identify who pushed code to a production website with one of our Slack bots.
• We have a custom:merged: emoji to indicate when a GitHub pull request has been merged and a :github: octocat to indicate that there’s a GitHub pull request associated with a message.
• When a discussion wanders off-topic in a channel, we try to push it back to our #watercooler channel (where there is no topic and people can safely ignore it if they so choose). We use the :watercooler: emoji to (maybe a bit passive-aggressively) nudge conversations out of the wrong channel.

👋 BYE

We recently started a project at silverorange with the non-profit Computers for Success Canada. A consideration of the project is to generate a unique code that can be read off paper, typed into a web-form, and spoken over the phone. Simple enough, right?

We’ve always focused on highly-usable UX and UIs, so designing a simple code is right in our wheelhouse. But when we started researching usability best practices for promotion/access codes, it was surprisingly difficult to find any. There are tomes written about designing for security, but what does it matter if your users can’t use them? So we put our brains together and worked with literacy and essential skills consultant Gillian Mason to design our own access code best practices.

Main Goals

Keep in mind that the use-cases for the codes are to be read, temporarily memorized, and then typed or spoken. With this in mind, the most usable codes should be:

As short as possible: Short codes are easier to memorize, quicker to type or say, and offer less chance of making mistakes. Imagine if you (presumably an English speaker) were asked to type 8 characters in hiragana: ぎまひせお. It’d take you a long time per character to type. That’s what the Latin alphabet is like for many people.

Easy to read: Remember that a significant portion of the population has low literacy skills or speak another language than the one of your site. Use characters that are as easy to recognize as you can.

As error-proof as possible: Keep the barrier to entering the code as low as possible and avoid the frustration of error messages.

Hard to guess: Balance a short, easy to read code against the security concerns of your application. A four character numeric code is simple to type but far too easy to guess.

The Edge is Your Focus

For most programmers and designers who make websites, inputting a code involves a quick copy/paste or touch-typing while you read it from a piece of paper. For someone with literacy, eyesight, language, or other impediments, doing that same task can be a frustrating experience and may result in them giving up on the process.

In govt we have a moral responsibility to design for the edge cases > "Edge cases define the boundaries of who [and] what you care about. They demarcate the border between the people you're willing to help and the ones you're comfortable marginalising" https://t.co/1OMNeQN0Fz

— Kylie Havelock 🏳️‍🌈 (@kyliehavelock) April 10, 2018

Any code should, at the minimum, account for people who are affected by:

Visual impairment: A screen-reader, magnifying device, or other aid may be necessary to read the code.

Physical impairment: An assistive device or voice-input may be necessary to input the code.

Different languages: The Latin alphabet is not familiar to literally billions of people worldwide.

Low literacy: According to the NAAL, approximately 14% of Americans have a “below-basic” reading level and 29% have a only a basic reading level. The numbers are roughly the same in Canada.

Low digital proficiency: Many users are intimidated by web forms and technical language found in error messages or form submission.

Making it “accessible” for everyone also makes it better for everyone, regardless of your abilities or proficiencies.

Even if you don’t have a disability, but are reading your own messy handwriting, in a low-light situation, or distracted and tired, the same “accessible” features designed to accommodate the “edge” are suddenly relevant to you.

Techniques

So how do we make a code that works for everyone? Some best practices to follow are:

Avoid similar characters: Some characters look very similar such as 0 and O, 1 and I. For a base to start from, we suggest an alphabet of 0123456789ABCDEFGHJKLMNPRTVWXYZ which notably excludes IOQSU. When validating the code, the similar characters should be automatically substituted for their visually similar match (e.g. replace I with 1).

Homophone considerations: Let’s say you’re making a code for people who speak two languages—in Canada, often French and English. Amazingly, when spoken, the letters G and J sound reversed in those two languages. I is pronounced as a long ē in French. You may need to remove these characters from your alphabet.

Format code in groups (chunks): The NN Group has a great article all about chunking and why it’s cognitively easier to remember and recite chunks. For an 8 character code, you might want to format it A1 P3 8C N9 or A1P 38 CN9.

Generous kerning and spacing: Characters that are too close together can be hard to read for people with dyslexia or people not adept with the Latin alphabet.

Uppercase, sans-serif font: This eliminates interpretation/guessing associated with some lowercase letters. You could even consider using the OpenDyslexic font.

High contrast black and white: For people with some visual impairments it’s best to avoid colours. It also makes printing the code more consistent with the digital display of the code.

Code Validation Usability

When validating the code, try to solve problems automatically for the user. This is one of the most important parts often overlooked by developers. Your application should allow input of the code with either upper or lower case (and use CSS to auto-format it uppercase), auto-format the “chunks” both visually and for verification, and automatically replace incorrect “similar” characters with the matching correct character. If there’s any way to avoid showing a variation on the “Your code is formatted incorrectly” message, you should do it.

If you can’t solve the problem automatically, don’t just say “Your code is formatted incorrectly” when the person submits an invalid code. Use informative and easy to understand messages. Tell them “Your code is too short. A correct code looks like: A1 P3 8C N9.” Is it too long? Tell them. Whatever you can do to inform the person about the issue in as easy to understand, non-technical language as possible, the better.

Security

One of the main goals is to have the code “as short as possible,” but in most cases you also want the code to be hard to guess, random, and non-sequential. The length of the code will depend on the number of codes you distribute and how critical code-guessing issues are to your system. The point of including this security info is to help you choose the shortest code possible for your application.

The math: To figure out the number of possible codes, just take the size of the alphabet you’re using and raise it to the length of the code. So for a 31 character alphabet:

• 31⁶ = 887,503,681 unique codes
• 31⁷ = 27,512,614,111 unique codes
• 31⁸ = 852,891,037,441 unique codes
• 31⁹ = 26,439,622,160,671 unique codes

Rate limiting: The number of codes you need will also depend on how quickly a malicious person can guess codes. Your API or form validation should keep this in mind. If you limit the validation mechanism to ten validations per second, and you give out 100,000 codes, it would take about 14 minutes to guess one correct 6-character code. For 8 characters, this increases to 14,215 minutes. If you’re using a second validation criteria such as email, guessing the correct code becomes much harder again. (I realize botnets could guess faster, but you’ll have to figure out your own risk tolerance for such scenarios)

Brute-force and timing-attacks: In case someone gets access to your codes in the database, you can protect them in much the same way you protect passwords. AES or Blowfish encryption make it programmatically slower to guess codes. For validation code (such as an API) you should use a comparison function that always takes the same amount of time to verify will protect against timing attacks.

Interesting Examples

Our simple implementation

Authy

The Two Factor Authentication application Authy uses chunking and bold text to format the code:

1Password

The popular password manager 1Password uses colour to differentiate numbers from letters and symbols. We recommend using black and white for most cases, but it’s interesting what 1P does. Their use-case is a little different than ours in that they don’t restrict the alphabet so differentiation is even more important for them.

Next Steps

The next phase of our project is to do additional research with other accessibility consultants and real-world testing with a wide variety of differently abled people. When we’re done, I’ll post an update here with the results.

More advice or examples?

Due to the lack of information out there, our team at silverorange has mostly developed these ideas on our own and with the help of Gillian Mason. I’m sure there are lots of other people out there who have thought long and hard about these issues and have more recommendations or ideas. I’d love to hear about them.

Our web agency silverorange does amazing work, but historically, we haven’t been great at celebrating our achievements. We’ve always focused on what we can do better rather than what we’ve actually done. Even in the midst of our retreat reflecting on our best year ever, I still found myself focusing on a missed goal instead.

We’ve recently made it a team goal to stop and recognize our achievements together. This is partly a cultural change, but also something we’re tackling with better processes. And what better way to do that than to combine Slack + Reacjis + Slackbot? Seriously—that’s part of our solution and it’s been great!

Whenever someone talks about something on Slack that feels like an achievement, people will react with an emoji (aka “reacji”) of a 🏆. This triggers the Reacji Channeler to automatically highlight the post in our #trophy-chest channel for the admiration of the whole team.

An achievement can be anything from launching a major new site, to bringing in fresh baked cookies from home.

It sounds like a tiny thing (and it is), but it’s a small thing that allows us to:

• Recap the achievements from the previous week at our Monday team stand-up.
• Allow anyone to highlight an achievement. It doesn’t require a team leader to take special notice of it. Even our clients can highlight achievements using shared channels.
• Notify everyone, whether or not they’re a member of a specific channel, when an achievement takes place.
• Give credit to the team who helped make the achievement happen.

It’s a fun and meaningful way to recognize our achievements, and it’s another small piece of supporting our wonderful team.

We held our annual winter retreat near Wolfville, Nova Scotia this year in a beautiful and tranquil old farmhouse complete with cats, horses, and an alpaca. Besides the nuts and bolts of our usual retreat meetings and reflections, we also threw axes at Timber Lounge, and tossed rocks at Windsor Curling Club.

Our highly anticipated “Employee of the Year” (employees are ineligible) went to our “Team Growth Spurt” which reshaped our team in wonderful ways in 2017.

“Employee of the Year 2017” for @silverorangeinc is “The Team Growth Spurt” (as per tradition, actual employees are ineligible)! 6 new FT and 2 PT team members have helped make our team the best it’s ever been.@slackHQ was a graceful runner-up for the 3rd year in a row.

— silverorange (@silverorangeinc) February 6, 2018

The retreat is always a great kickoff to the year ahead. 2018, here we come!

Photos mostly by Stephen DesRoches, with a few by Nick and Daniel Burka.

We bought the beautiful century-old Victorian G.A.W. Robertson House from architect David Bergmark in 2003 to use as silverorange HQ. In the time since, it’s been painstakingly restored and granted a Heritage Award in 2016.

David dropped by last month with a gift. He had an original architectural sketch and specification document that he had found in the walls of the building decades earlier.

After having the document framed in his office for years, David thought it should stay with the building. The document presumably dates to around 1900, when the building was built.

It is now hanging proudly in the main foyer. Thanks David!

Thanks to Stephen DesRoches for the photos.

Kelly’s Garfield

When Dan left, I decided I wanted to use his Garfield mug and have become attached to it—I use it on the days I’m sluggish and NEED my coffee, because on the inside rim it is written : “Face It....” to which it reminds me to drink that damn coffee and face whatever large tasks I have to do that day! Kick in the Pants Coffee Mug! It also doesn’t turn into a scalding hot vessel when microwaved (I’m looking at you, plain white mugs).

Steven’s Reusable Roll-up

With only a minor customization to this otherwise understated mug, I can enjoy the thrill of Tim Hortons’ Roll-Up-The-Rim-To-Win™ season all year round.

Nick’s Heath Ceramics

It’s a good, solid mug. Solid heft, but not too heavy. A lip that’s thin, but not too thin. I guess I like a goldilocks mug. But not with goldilocks on it or in the shape of a bear or something. That breaks my “no novelty mugs in my kitchen” rule (in your kitchen it’s fine).

Kristen’s Shark Friends

I have a soft spot for all things grey, sharky and handmade. So of course I bought mini Chomp, brazenly assuming I could be an espresso person. As it turns out, Aeropresses are daunting when you’re uncaffeinated! Who knew? Enter mega mug, the perfect-sized shark to hold large volumes of hastily-brewed, comparatively-dilute caffeine.

Jacky’s Glam Breakfast

Who doesn’t want to start the day with a little Bowie? Especially a Bowie drawn by Canadian Hero™ Kate Beaton! A cup of black in this miraculous mug will raise you like Lazarus, transforming you from a Space Oddity to a Pretty Thing who’s thinking “Let’s Dance!” (Okay, I’ll stop.)

Mike’s Double-shot Espresso

This is a cheap, mass-produced espresso mug. Do you like coffee but don’t like the time it takes to make a latte? Espresso may be for you. Also pictured: vintage 1999 veneer desk surface.

Jacob’s Bob Ross

Dropped the production database? With Bob Ross by your side that’s just another happy little accident.

Isa’s Receiver Coffee

Have to represent Receiver Coffee Co, best local roaster and coffee shop. You know you spend too much time at your local when they know your birthday and hand you a mug.

Keith’s Moe Vember

This mug was handmade by Michael Stanley, a pal of mine who produces some really beautiful pottery in his Victoria, Prince Edward Island studio. I was growing a gnarly mustache for Movember a few years back when my girlfriend spotted this mug at Michael’s studio and promptly bought it for me.

I love that we look like we all go to the same hairdresser (there are about 8 hairstyles to choose from). It was a super fun little project to play with. Thanks Pablo!

And, if you’re into the whole avatar aesthetic, don’t forget about the wonderful “Slice of the Month” caricatures that Daniel made back in the day for silverorange.

One of our founders, @dburka, drew 51 Slice-of-the-Month illustrations between 2000 & 2004. From Amelie to @zeldman: silverorange.com/a/slices/

— silverorange (@silverorangeinc) September 19, 2017

In the beginning

silverorange was founded 18 years ago by a group of seven young men with a fairly homogeneous set of backgrounds and life experiences. We were all white, all male, and all middle-class—and though I expect we didn’t understand it at the time, we enjoyed the privilege that comes from this type of situation. We had time to spare, access to technology at home and at school, and were encouraged to be technical and entrepreneurial at every turn.

This shared life experience afforded us an automatic set of cultural touch points. Music, movies, games—these were tastes and interests likely to be shared across the whole group.

We considered ourselves to be fairly liberal and progressive. We thought of ourselves as “good guys”. We decided early on that the purpose of the company was to serve as a platform from which we could live interesting and fulfilling lives. The company was not an end in of itself.

The circumstances of our lives were also quite similar. We were all in our late teens, most still living with our parents and attending high school or university. There were no kids, no partners, and no mortgages.

Our commonalities allowed us to make assumptions: You probably won’t be offended by this joke; You can probably stay at the office playing games until 11pm (and you probably want to).

The slow descent into regressive humour

I recall an interview with the Beastie Boys where they talked about how their style and behaviour was originally based on a parody of the dumb party-animal lifestyle. After living this parody for long enough, they lost sight of whether they were even joking anymore.

We fell into a similar trap. We developed a stupid “ironic” (questionable quotation marks used intentionally) insider joke culture. When I made a sexist or racist comment, I was making a social commentary! I felt it was obvious that I was mocking people who make those types of comments earnestly. I would never say something in front of someone who didn’t know me well enough to know I was obviously being sarcastic. I didn’t understand that Obvious to You is Not the Same as Obvious.

Eventually though, if you make a sexist or racist joke, even if you think you’re being sarcastic, you’re still a person being sexist or racist by making an offensive joke.

“Irony doesn’t scale...” — Paul Ford

To be fair, this behaviour wasn’t shared by everyone on the team, nor was it spread evenly among those who did participate. As a key participant, I’m mostly criticizing myself.

Baby steps

As our company grew, we inched toward a slightly less uniform team. Among the founders, we also diverged in our own places in our lives at different rates and in different directions. People began to travel, complete different levels of post-secondary education, establish homes, and form significant relationships with spouses and partners.

We even hired a woman!

With a woman joining a team of well-intentioned, but immature young men, the opportunity for failure (on the part of the young men) was obvious and we failed many times. One glaring example arose when our only female employee needed to take maternity leave.

What was our parental leave policy? We didn’t need policies! If you need time, take it. If you find yourself in uncharted territory, chart it! Never mind that you may be an employee and not an owner, unclear of the boundaries.

We thought we were being generous and even “progressive” with our unlimited vacation policy. We didn’t realize at the time that when we said to “take as much vacation time as you like”, what we were really saying was “figure out what unspoken amount of vacation time we consider reasonable”. What we thought was a benefit was at best a burden, and at worst a minefield.

A few years after our first female employee was left to sort out her own parental leave, the founders started to have kids of their own. Only then, as we granted ourselves ample (and ill-defined) parental leave, did we learn that our unfortunate trailblazer ended up back to work much sooner that she would have liked.

The unfortunate issue of ill-defined parental leave may seem like an obvious issue in hindsight (there’s that word again—obvious). It wasn’t obvious to a bunch of twenty-year-old single guys with no management experience (and limited life experience). Almost twenty years later, I have to wonder what obvious issues we’re missing today.

Good news: change is easy!

We’ve discovered that it’s both hard and easy to change the culture of a company. At one of our annual company retreats, we were discussing ways to improve our team over the coming year and one of our employees made a revolutionary suggestion:

We should be nicer to each other!

He was referring mostly to a culture of sarcastic insults we had grown accustomed to, but we all agreed that treating each other with more respect was worth a shot. It seemed like a good opportunity to shed our ironically ugly humour. As one of the key culprits, I can safely say that in addition to being unnecessarily negative, it just wasn’t funny. We don’t miss it.

This small initial change was surprisingly abrupt and surprisingly easy. It seemed like only a matter of days before what had been totally normalized started to stick out as inappropriate. We even came to refer to the echoes of our former vulgarity as “old office humour”—a phrase we still use as a reminder/warning to ourselves.

If we hadn’t addressed this glaring surface-level ugly tone in our humour, making our team more diverse would have been much more difficult.

Bad news: change is hard

These relatively easy changes had a surprising impact on our company. Still, they weren’t enough to make us into a more diverse and empathetic team.

The primary way we’ve been trying to address our blind spots is, first, by becoming a more diverse team. If we’re not all the same age, gender, sexual identity, or ethnicity, the number of blind spots that will be visible to at least some of us drops off.

The second way of reducing such potential blind spots is to build systems. When we fall down, we try to put systems in place that will keep us from relying solely on being attentive and empathetic in order to avoid such mistakes. Regular check-ins and better-documented practices are two simple examples of such systems.

We’ll always make mistakes, but endlessly repeating easily avoidable mistakes is inexcusable.

That example of parental leave is one we’re quite familiar with now (there are 13 kids-of-silveroranges as of this writing). That said, there are other key life experiences that we don’t yet have experience with. Deaths, major illnesses, and on a more positive note, retirement, are all examples of inevitable milestones we have yet to experience. More concerning still are the issues that I couldn’t name that we’ll surely come to confront.

Taking stock and looking forward

We’re coming up on our twenty-year anniversary. It took us more than a decade to really get started, but we’re now working hard to become a more welcoming environment to more people. In our hiring, we’re trying to carefully craft the language in our job postings to convey this progress (or at least intended progress). We’re also trying to get our job postings into places more likely to be seen by those in traditionally underrepresented groups.

While our progress has been slow and late to get started, the good news is that being more diverse can make it easier to become more diverse. Pessimistically, this may seem like a catch-22, but if you can get things started, progress can compound and accelerate.

That first female employee is now part of our executive team and is our CFO. Though she worked as the only woman on the team for years, she is now part of a team that has become more inclusive and diverse, one that dropped from being 80% to 60% men in the last 12 months while growing from 10 to 15 people. It’s not enough, but we hope that our changing demographics will help attract talent and continue to improve the diversity of our team.

You don’t need to be part of a marginalized group to enjoy the benefits of a more welcoming environment. A friend of mine noted a pride flag sticker on the window of local Catholic Family Services Bureau office. Even a small symbol like this is a reminder that seeing anyone feel welcome can make everyone feel more welcome.

The work continues.

Thanks to everyone at silverorange who helped with editing, feedback, and guidance, especially Kristen, Isa, & Nick.

At the 18th anniversary of the founding of silverorange, we've been looking back at how our silverorange.com website has changed with our business.

We’ve always kept our silverorange website intentionally simple. First, it exemplifies how we value simple, fast, and effective websites over heavier and fancier alternatives. Second, we wanted to avoid the usual “tell the world what great work you do” and to instead let our work and reputation tell the story.

Here’s a quick look at our silverorange.com website through the ages.

v1.0: The Beginning (1999—2000)

The first iteration of our website was build in ColdFusion on the back-end, with a few simple pages. The layout fit nicely into a 640×480 screen, but floated comfortably in the middle of a luxurious 1024×768 display (thanks to the powerful HTML <table> ). Internet Explorer 5 was the state-of-the art web browser.

v1.1: Frames! (2000—2002)

While we were apparently still happy with the original style of our site, we needed room to showcase our news and special projects. With the astounding but controversial power of HTML Frames, we kept our existing simple site, but added a sidebar. Here, we showcased our in-house web-based team communication tool, the silverorange intranet (think Slack, but with the tech of 1999).

v2.0: Pixel-sharp (2002—2008)

In 2002, we significantly redesigned our site, with a crisp, pixel-sharp style and flexible layout (still <table>-based). This style is a personal favourite of mine and served us for six years with only minor updates. The site also transitioned from ColdFusion to PHP on the back-end—a good move, in hindsight.

v3.0: The Darkness (2008—2014)

In 2008, the global financial system collapsed, which we unintentionally reflected in the dark tone of our website redesign. This design showcased clients of the time including Feist, Sloan, Bebo, Digg, Mozilla, and Duolingo.

v3.5: Cards (2014—2016)

In 2014, we kept the dark tone (and subtle, but internally controversial, pin-striped background) and redesigned with our first mobile-friendly responsive version of the silverorange site. This version was intended to show our core set of long-term clients, and implicitly suggest that we weren’t looking for new clients at the time.

v4.0: Single Page App (2016-PRESENT)

In 2016, we redesigned with the simplest version of our site since it’s launch in 1999. Unlike the more elaborate single-page applications (SPA) we’ve built for clients with tools like Ember and React, this site is literally just a single page of static HTML.

With this redesign, we limited ourselves to a result that would be quick to implement and easy to maintain. The two key use-cases I had in mind during this redesign were:

1. A potential client looking to contact us.
2. Me, looking up our postal code.

I can confirm that the design has at least addressed that second use-case.

We’ve since added a few pages to highlight when we’re hiring, but the basic main page still serves us well. We rely on our @silverorangeinc Twitter account and blog.silverorange.com (hosted via Medium) to share more about our company.

v4.1, 5.0, & Beyond (the glorious future)

Our current brutally simple site continues to serve us well enough, but I’m sure we’ll look to update and expand it at some point. Maybe we’ll use WebVR.

As web designers and developers, we love a good set of standards. In working with our friends at the IWK Health Centre in Nova Scotia, we’ve learned of an interesting health issue and a much different set of standards than we’re used to.

Almost a decade ago, researchers with the IWK Health Centre noticed that Aboriginal children had higher rates of pain and pain-related health issues, yet are less likely to be treated. The members of the Aboriginal Children’s Hurt & Healing (ACHH) Initiative have been working to understand and improve the way the health care system addresses pain in Aboriginal children.

In learning about the ACHH, we’ve also learned of a set of standards around research involving First Nations. The First Nations Principles of OCAP® (Ownership, Control, Access & Possession) are “a set of standards that establish how First Nations data should be collected, protected, used, or shared.”

The First Nations Information Governance Centre describes why the OCAP standards were created:

“There is no law or concept in Western society that recognizes community rights and interests in their information, which is in large part why OCAP® was created. OCAP® ensures that First Nations own their information and respects the fact that they are stewards of their information, much in the same way that they are stewards over their own lands.” [source]

There are generations of work to do to improve the way Aboriginal communities are treated in Canada, and our country is only beginning to learn about and discuss the ways these communities have been mistreated in the past.

We were pleasantly surprised to learn about the OCAP standards and are glad to adhere to the standards in any relevant work we do.

Beyond OCAP

The OCAP standards are just the start. John R Sylliboy, the Community Research Project Coordinator for ACHH writes:

The OCAP established a baseline for standards across Canada, but there are specific protocols, ethics and review boards that must be considered in health research that individual First Nations may also require.

The IWK Health Centre acknowledges and adheres to tribal or regional ethics processes. This includes working directly with each First Nations community as well as tribal and/or regional organizations. All ACHH research is generated in coordination with First Nations, which will then go through a community protocol process. In Nova Scotia, this is followed by approval by Miꞌkmaw Ethics Watch (MEW). MEW was created “to establish a set of principles and protocols that will protect the integrity and cultural knowledge of the Miꞌkmaw people.” ACHH research conducted in PEI requires the approval from the Miꞌkmaq Confederacy of PEI (MCPEI).

Similar processes and protocols are being developed across the region and in other Canadian First Nations communities. Therefore, ACHH or any health research must adhere to the OCAP and territorial practices from other First Nations and Indigenous groups altogether. Success to any research with Indigenous community is through continuous community engagement and relationship building between all parties involved in health research, but most importantly when First Nations are equal partners and leaders of health research from their perspectives.

ACHH represents IWK Health Centre in leading this mandate and building on to that capacity for knowledge sharing for Indigenous health research in coordination with First Nations.

Thanks to John for this additional context.

Web Developer (Node/React)

Accepting applications until July 16, 2017.

Designer (Web & Mobile App)

Accepting applications until July 31, 2017.

Remote working is just as good as local. Complete details and information on how to apply are all available at: silverorange.com/job

People from a range of backgrounds and experiences make us stronger, and we’re always looking for ways to improve. Our team is getting more diverse, but we’re still missing voices from different backgrounds and experiences who could make our work better. Why not help us with that? We highly encourage people from traditionally underrepresented groups to apply—we’d love to hear from you.

UPDATE: THIS POSITION HAS BEEN FILLED Future job openings will be posted here on our blog and via @silverorangeinc on Twitter.

silverorange is a small design and development agency based in Canada. We’re looking to hire another back-end web developer.

Remote working is a possibility. Complete details and information on how to apply are all available at: silverorange.com/job

People with different backgrounds and experiences make us stronger, and we’re always looking for ways to improve. Our team is getting more diverse, but we’re still missing voices from different backgrounds and experiences who could make our work better. Why not help us with that? We highly encourage people from traditionally underrepresented groups to apply—we’d love to hear from you.

UPDATE: THIS APPLICATIONS FOR THIS POSITION ARE CLOSED
Future job openings will be posted here on our blog and via @silverorangeinc on Twitter.

silverorange is a small design and development agency based in Canada. We’re looking for a project manager who will help get the most out of our team by enabling our developers, designers, and management to focus on their strengths.

Remote working is a possibility. Complete details and information on how to apply are all available at: silverorange.com/job

People with different backgrounds and experiences make us stronger, and we’re always looking for ways to improve. Why not help us with that? We’d love to hear from you.

We at silverorange have been working on new product we call Neon.

Update: The neon.io domain has a new owner. We had fun building Neon and used it as a platform to learn and experiment. It served its purpose well but we have since decided to shut it down.

The goal of Neon is to allow you to quickly review stuff and share the reviews with your friends.

With this prototype, we’re trying to learn if people can create compelling reviews quickly—usually from a mobile device.

You can already post elaborate reviews on dedicated review sites, or even Medium, but these take a significant amount of time to craft. On the other end of the spectrum, you can make a Facebook, Twitter, or Instagram post that says “love it”. We wanted something in between.

Our initial vision combines a photo, a simple rating (out of 10), an emoji, and a few other quick fields. From this input, we build a simple and fun review that’s easily shared on Twitter, Facebook, or wherever else you like.

Here are a few example reviews:

Creating reviews with Neon is limited to a group of early testers for now. If you’re interested in trying it out or learning when it becomes more widely available, ~~sign up and we’ll let you know~~.

Read about some of the lessons we learned running design sprints and working with clients in the world of healthcare:

Sprint Stories: Running a design sprint in a healthcare organization

UPDATE: THIS POSITION HAS BEEN FILLED Future job openings will be posted here on our blog and via @silverorangeinc on Twitter.

silverorange is a small design and development agency based in Canada. We’re looking for an excellent back-end web developer to help us build new features for an awesome client in the medical education field.

Remote working is a possibility. Complete details and information on how to apply are all available at: silverorange.com/job

People with different backgrounds and experiences make us stronger, and we’re always looking for ways to improve. Why not help us with that? We’d love to hear from you.

The credit card industry is about to require security practices that will preclude support for Internet Explorer 10 and older. The story of how and why is RWA (riddled with acronyms).

My friend and colleague at silverorange, Mike Gauthier, gave a talk at a recent local developer meeting about Web Security with TLS (slides). In his well-researched overview of SSL and TLS encryption on the web, he explained how a boring industry organization (my words, not his) is helping to accelerate the transformation of the web browser landscape.

We build web sites and applications for clients that process credit card transactions. We’ve been working with our clients to ensure that they are compliant with the Payment Card Industry Data Security Standard (boring PDF warning), or PCI DSS.

PCI DSS is a standard to ensure data security in the world of credit card processing. It was developed by a consortium of major card backers including Visa, MasterCard, American Express. The standard dictates procedural and technical measures that those dealing with credit cards must implement to maintain a basic level of security.

Among the many prescriptions of the standard is support for TLS (Transport Layer Security). Here’s where the world of web browsers gets involved. The PCI DSS mandates that all new applications support a minimum of TLSv1.1 by June of 2016. All applications, old or new must support TLSv1.1 by June of 2018.

The PCI DSS also includes all web browsers in the “new applications” category, meaning they have to hit the June 2016 compliance date.

Old friend Internet Explorer didn’t get support for TLS until Windows 7 and it wasn’t enabled by default until IE v11. The Microsoft Edge browser does fine, as do all of the other major browsers.

This means that as of June 2016, our clients’ sites can no longer support IE6 through IE10 or Windows XP/Vista. If they did continue to allow connections with the older encryption protocols that older IE version require, they would be subject to fines and/or suspension of card processing abilities.

That’s right. If you are accepting credit card payments, you can be fined for supporting old versions of Internet Explorer.

It’s not clear how soon and how strictly the standard will be enforced by the credit card providers, if at all. Even if it ends up being treated more as a suggestion than a requirement, any acceleration of the adoption of more standards-compliant browsers is welcome.

Older versions of Android are also affected. Given the way Android updates are handled on many phones and carriers, out-of-date versions of Android are quite common.

The side-effects of this are clear. Out-of-date web browsers that have been holding back the adoption of modern web standards, including CSS 3, are getting an extra push into obsolescence.

Using global statistics from Net Market Share, the Internet Explorer users affected by this account for just over 15% of web users as of March, 2016. For most of our clients, whose customers skew toward the US, the number is closer to 5%. Either way, it’s a significant percentage of people using the web.

I’ve long been a supporter of standards. They allow us to build the web and to use a broom-handle with a paint roller. It’s nice to see the unintended consequences from the financial industry make our jobs as web developers a little bit easier.

Thanks to Mike Gauthier for his research and presentation on the topic. For more detail see the slides from his presentation, Web Security with TLS.

silverorange held our 14th annual company retreat this year, spending four days (plus about 1½ days for travel) at a beautiful home in Saint Andrews, New Brunswick. We used the time to look back at the past year while making plans for the next year coming.

In the hope that it may be useful to others who may be learning, as we are, how to better run their company, we’d like to share a bit about how we operate our annual company retreats. For more about the purpose and rationale behind our retreats, see the first part in this series, Why we retreat.

At the time of this writing, we are a team of 13 people, including developers, designers, systems, and support/administration roles. Two of our team members work remotely. Here’s how we managed to get everyone together.

Location. Location. Location.

We like to find a location for our retreat where the living, meeting, and relaxing can all happen at a single site. It’s also important that the retreat happen close enough to home to not be an ordeal to get to, but be far enough away that that temptation to step out and take care of the responsibilities of everyday life isn’t too strong.

Finding a location is getting more difficult. Though 13 people is still a small business, there aren’t a lot of houses available for rent with 13 rooms (let alone 13 beds). Hotels or inns are an option, but many smaller inns in our area are closed in the winter and hotels don’t afford us the shared living space that makes us feel like we’ve retreated together. If we grow much beyond our current size, houses (even giant houses) may cease to be an option.

Most of our previous retreats were held within a one-hour drive of our Charlottetown office. Last year though, we ventured further, allowing ourselves the expanded scope of “anywhere with a direct flight from Charlottetown”. This year we drove 5 hours (and one Irving Big Stop diner lunch) to a rental house in Saint Andrews, New Brunswick, and the year before we flew to Montreal.

Timing is important too

We now do the retreats early in the year (January or February, schedules allowing). This reduces the pre-holiday madness of a December retreat, and it means we start the year with a clear collective head. We have considered other times in the year to avoid traveling during the Canadian winter, but so far we continue to retreat in January or February.

Our retreats started off as a long-weekend. This eventually grew to include a full-day Thursday, Friday, Saturday, and part of Sunday. This year was the first we didn’t use a weekend, traveling/starting on Monday, and traveling back home on Friday. This allowed us the weekend to recover from the intense week, and preserve the weekend with families. This timing is a trade-off between disrupting our personal lives, and the work-week we would usually spend dedicated to particular clients.

Who’s invited?

Our retreat is for everyone in the company. This obviously includes everyone who is actively working for silverorange, but we also include a few others. Everything is discussed openly with the entire company, including financial status and plans and general strategy.

Discussing everything in the open with everyone can be counter-intuitive (maybe we should fire all the designers and replace them with robots!). That said, the benefit of everyone having had the opportunity to understand how we came to make our decisions is worth it.

Two of the seven founding partners work elsewhere, but retain a financial and advisory stake and still attend our retreats. Having the two founders who work elsewhere come back each year is particularly helpful. They return with new experiences and contacts. With their long history with the company, they can also be counted on to bring praise and criticism that we might be too close to provide ourselves.

Family members and significant others are not invited along to the retreat. This was easy when most of us were single, but asking people to leave young families behind for four or five days has gotten difficult. This could change in the future, but the logistics and tone of the retreat would change significantly.

We’d be interested to hear how other companies address the issue of isolation versus inclusion of family.

What do we do all day?

Our first day is focused around the business (a year-in-review, a state-of-the-union, some self-reflection, etc.), the second day on clients, and future plans, and the third day on technical matters.

In our opening year-in-review session, we look back at the work we did. We consider the changes in lives and families. We look at where our money came from, and where it went. We look at the technology we’ve used and built, and what we hope to build in the coming year.

Some of the more traditional sessions involve a review of the technologies we’re using, financial updates, and discussion on how we can better serve our clients. We have also developed some of our own sessions:

1. Scoring Goals —  we run through the goals we created for ourselves at the previous retreat and score our progress on a scale of 1-to-10. This process helps to remind us what we wanted from the year, highlight where we fell short, and recognize where we succeeded.
2. Personal Best/Worst — we ask everyone to share the worst thing about their work-life from the past year, then go back around asking about the best. This brings up themes that we may need to address later in the retreat. The ‘bests’ help to celebrate personal success and direct future planning toward work the people find most rewarding.
3. Sacred Cows — a new and experimental session this year, Sacred Cows was an opportunity to challenge long-held beliefs or practices at our company. The intent is not to solve large, difficult problems in a few minutes. Rather, we hope to discover if some of the things we’ve grown to do without much thought are still valuable, or need reconsidering. We use strict time-limits to encourage controversial topics without getting mired in endless discussion. While not a complete success, we managed to discuss a lot of difficult topics without conflict, and in doing so learned a lot about how this could be better structured next year.

While we do have a lot of fun at the retreats, most of our days are taken up with fairly intensive meetings. In the past, we’ve had two or three long days (9am-7pm) of solid meetings. This year we improved the balance to keep from burning out. Still, our retreat isn’t a vacation. It’s a time to reflect and plan.

Don’t monopolize

While some of our sessions start with a structured presentation from an individual, they also involve a lot of time for discussion. We’ve been plagued by the tendency for a few of us (myself included) to monopolize the conversation. This was an issue again this year, as a small group of us did a lot of the talking.

Some basic techniques to avoid this did help. The most basic of which was to go around the room and asking for input from each individual. This brought out valuable input from some, but just put others on the spot. This is something we still need to improve.

Eat well and eat together

Our meals are a key part of the retreat. We have lots of snacks and coffee/tea to keep us going through the day, but the meals offer a time to sit around a table, much like a big family.

Sometimes a few of us will prepare a meal and bring it to share. We prepare a few meals together, making a good large kitchen a requirement. Preparing and sharing meals together is a nice way to talk about whatever is on our minds without the formality of a meeting. A few of our developers also happen to be pretty great amateur chefs.

Mandatory fun

While the main purpose of the retreat is to retreat from routine as a group, it’s also nice to get out of our venue once or twice. Last year we were in Mont-Tremblant, Quebec and we went on a rope-climbing and zip-line course. It sounds like a team-building cliche, but it was awesome (and freezing).

This year we rented a gym, where I was picked last for the dodgeball teams. Dodgeball turned out to be a great activity with simple rules and a forgiving learning curve. It also worked well for those in great shape, and for those like myself who could use more exercise. A short game of pickup basketball afterward highlighted how dodgeball was a much more inclusive sport.

Inside jokes for 100 please, Alex

Two of our team members secretly planned a game of silverorange Jeopardy. Clues included company specific topics (like some choice quotes from our Slack instance), and general trivia. This type of activity has to be carefully balanced and not too forced. This one was a hit, even though I was robbed in Final Jeopardy by the CEO.

Some other evening activities included a (very) late night winter bonfire, cards, karaoke, soaking in a hot tub, and a Yankee gift swap.

Build traditions

When you have an annual event for 14 years in a row, it becomes a tradition. It’s also filled with smaller traditions that have grown over the years.

Every year at our retreat, we vote on an Employee of the Year. However, at silverorange, employees are ineligible for Employee of the Year. Abstract concepts and inanimate objects are eligible. Previous winners have included a (very nice) coffee machine, the code-review process we use on GitHub, and the beautiful new deck on our office.

Promising nominees for Employee of the Year this year included Slack, our new office kitchen, and an extraordinary afternoon of shoveling. The winner ended up being the retreat itself. Each nominee is championed in sometimes impassioned speeches (one speech made us cry once—for real). It can be dumb, and it can be awesome. It’s a tradition we look forward to.

The eight-year-old wounds are still fresh from the year that our office drink-fridge beat out Firebug for Employee of the Year in a hotly-contested final round. I’m not saying there was voter fraud that year, but the electorate was ill-informed at best.

What’s the damage?

Taking time away from work isn’t free. For our company, with 13 people, the retreat tends to cost between $8,000 and $15,000. This covers travel, food, and a venue, but doesn’t include salaries or tens of thousands in lost potential billable time. If we were to expand our travel range to include air-travel again, the budget would have to expand.

We try to keep the cost of the retreat at a level where it feels like a bit of an extravagance, but not so much so that we’re left feeling like we need austerity measures to fund it.

This budget doesn’t include the cost of our own time in planning and time spent at the actual retreat. Some accommodation also needs to be made to ensure our clients are taken care of during our retreat time.

Would retreat again A+++

The time, effort, and money that goes into our retreats has paid off many times over in the sense of shared history and direction. We leave with a solid footing for the following year. Many major decisions in the history of our company have been made at our retreats. This year’s may have been our best retreat yet.

We’re already scoping out venues for next year.

In 2003, silverorange moved our offices to a beautiful heritage building in Charlottetown, Prince Edward Island called the G.A.W. Robertson House.

The century-old Victorian building hadn’t been well maintained for many years and had been crudely subdivided into two units before our arrival. One of our lead programmers, Nathan Fredrickson, happened to also be a master woodworker and builder and in 2010 took on the ambitious project of renovating and restoring the building back to its former glory.

After six years of major interior and exterior renovations, the project was completed. Nathan and his team of craftspeople (including our former CEO, Dan James) took great care in restoring and preserving architectural elements in their original form in every aspect from the faux-grain painting technique on the interior woodwork to the Wallace stone foundation.

This week, the PEI Museum and Heritage Foundation recognized the work Nathan and silverorange did in preserving the home and presented us with a 2016 Heritage Award which Nathan received at a ceremony in Summerside last Tuesday. An epic job well recognized.

The description of the project for the PEI Museum and Heritage Foundation:

The Robertson House at 84 Fitzroy became the office of silverorange, a software company, in 2003. Over a six year period from April 2010 to October 2015 we completed a comprehensive heritage renovation of both the exterior and interior of the building.

Previous additions were removed and the front porch roof line was changed to be more complementary to the original structure. All windows were replaced with new custom wood windows. Rotten siding was removed and all paint was removed from trim work being preserved. Great care was taken to create exact matches of siding and molding profiles. The original gingerbread work in the front gables was carefully removed to be restored and then re-installed. Much of the sheathing was removed with the siding which allowed for rewiring and repair of framing in the exterior walls. Old insulation was removed and replaced with spray foam insulation and modern house wrap. Everything was painted with exterior solid stains that will avoid peeling paint in the future. Porches and decks were rebuilt with custom railings and balusters to complement the building.

Inside, the original plaster, trim, and floors were saved where possible. Earlier renovations that divided the main staircase were removed and the original servant stairs were rebuilt. Hardwood floors were uncovered, repaired, and refinished. New hardwood was installed in other areas to match. Where new trim was required, exact matches were made and much of it was faux-grained in a style to match original graining. All plumbing and electrical was replaced throughout. Lighting was greatly improved with LED pot lights and reproduction brass fixtures. Three bathrooms and a kitchenette were rebuilt in styles that complemented the existing interior.

We held our first annual silverorange company retreat three years after our founding, in the winter of 2002. We gathered in a basement of the Kindred Spirits Country Inn & Cottages, in Cavendish, Prince Edward Island. At the time, the inn was owned by the parents of our then-CEO. Now he owns the inn and we have a new CEO, but that’s another story.

Over those few days in 2002, we played video games (4-player Mario Kart on a GameCube, projected on a wall), ate, and planned our coming year as a company. None of us were married and none of us had kids. Now, fourteen years later, we have 18 kids between all of us (you know, respectively).

This month marked our 14th annual company retreat. Since that first winter, we have changed venue a few times, added a few extra days/nights to the schedule, and increased the budget. However, the basic purpose of the retreats hasn’t changed. It’s an opportunity to retreat from our regular routine, enjoy ourselves, and revisit what kind of company we want to be.

It’s not a vacation

While we do have a lot of fun at the retreats, most of our days are taken up with fairly intensive meetings. This year we improved the balance to keep from burning out. Still, our retreat isn’t a vacation. It’s a time for everyone to participate in shaping the direction and day-to-day working of the company.

When we only had one real meeting a year, it was a big one.

In the first few years of our retreats, we weren’t a well-run company. We shied-away from structure, authority, and even responsibility. We weren’t a mature company, nor were we particularly mature individuals. We survived because we were a small, tight-knit group, but I’m sure this lack of organization held us back.

Years into our company, this beautiful chaos started to become more chaotic and less beautiful. In response, we invented what we thought at the time was a bold and innovative solution. We called it the “board of directors”. While the day-to-day operations and management of the company remain fairly flat, this group of six people in the company met monthly to review and direct the state of the company. In hindsight, we’re alarmed at how we managed to fare at all without this level of oversight.

Before we had this board of directors our annual retreats were a frenzy of planning. We were packing an entire year of management, financial oversight, client and process review, all into a few days. It was exhilarating, but it was also ridiculous.

Even a well-run company can stand to retreat now and then

Now that we’ve matured as a company (and hopefully as individuals), we have more structure in place. We aren’t surprised at the end of the year by how much money we made (or lost). We have regular oversight of financial, management, and other business issues. It’s far from perfect, but it’s much better.

With better machinery for managing the company throughout the year, we no longer have to fill our retreat days with the basics of figuring out where our money came from and where it went. We have more freedom to think about bigger issues. We can look further ahead with more accuracy. We can work through what kind of company we are, and what kind of company we’d like to become.

There are several goals for the retreats. First, we reflect on the year that was. We celebrate our achievements and reflect on our failures. A secondary, but perhaps equally important goal is to spend time together as a team in one place, outside of our regular work environment. We prepare and enjoy meals together. We play games. We catch up with the remote employees.

We try to leave our retreat with an appreciation for, and understanding of, the previous year. We leave with a list of specific and general goals, but perhaps more importantly, we aim to leave with a shared understanding of the direction we’re all pushing in.

It’s still worth it

This year we asked each employee (one-on-one) if the company retreat was still worthwhile. The answer was unanimous and enthusiastic (and it was ‘yes’). I leave the retreat feeling great about the year that was, the year to come, and most importantly, about my friends and co-workers at silverorange.

Now, I’m off to unpack my snow pants and bathing suit.