Should a company do trial employment?

Trek Glowacki — Wed, 10 Mar 2021 18:06:46 +0000

There are many benefits to trial employment – hiring someone for less than a month to decide if you want to hire them full time.

You get to see the candidate work in a real-world scenario. You get to spend a real amount of time with them. You get to verify claims made in the interview. You have a clear check-in point where you can back out.

However, trial employment can exclude certain groups of candidates from your hiring pool. Assuming you want a diverse hiring pool, this could be problematic.

For example, candidates who are:

parents: won't relocate for only a potential job, disrupting their family life.
new to your tech/tools: will spend time learning instead of performing, making the trial period not representative of their work.
managing chronic health issues: need continuous health coverage, which would be broken by one or more trial periods
without savings: need income stability.

In a country with strong social safety nets and worker protections, trial employment could be a really great way to form a longer-term working relationship. This is sadly not the case in many countries.

UI Kits and Open Design

Trek Glowacki — Wed, 31 Jul 2013 00:00:00 +0000

UI Kits and Open Design.

The last few years has seen the wonderful proliferation of UI kits for the web. These libraries offer non-designers a way to create designed interfaces without needing to involve a dedicated designer. They function much like the libraries that save every developer the time of mastering the diverse range of technologies (file IO, networking, application structure, etc) that go into making a technology product.

Like open source software, these projects also have the goal of open sharing so anyone can take the project and augment it, use it without charge, change and redistribute it, or commit changes back for everyone to share.

A UI kit means a trained professional has done the complicated and time consuming task of crafting a reusable set of elements that can be combined in many ways and still retain the cohesion and unity that come from good design. Some kits also ship with HTML and CSS, saving you the time of taking a design and converting it from pixels to the powerful but quirky DSL we have for web interfaces.

On the surface this looks like an equivalent to open source software: "open design" if you will. But these projects aren't as open as I suspect the authors intend. That's a bold statement, so bear with me: releasing images and/or HTML and CSS, even accompanied by permissive licenses governing their free use, doesn't constitute "open". They're certainly free-as-in-beer, but I'd argue they fall short of the loftier free-as-in-speach.

The problem with PSDs, dribble shots, even HTML and CSS is that no matter how much freedom we have for use, none of these things are the design. They are artifacts of the design. They're an encoding, visually and in a DSL (HTML/CSS), of the design but they are not, themselves, the design.

The actual design – the information I wish the authors of these frameworks opened – is the decision making process behind the values they've selected for sizes, proportions, colors, line, textures, and all the other primitives that make a design.

Let's use Topcoat as an example. Here's a button from their kit:

I can know from the CSS that the button's color is a light gray (#e5e9e8), the text inside is 1.167em in size, that it has 1.16em of padding accomplished with padding for the right and left and with line-height for the top and bottom. It has 1px border of solid #a5a8a8 with a 3px radius. The text is Source Sans with a weight of 200 in dark but not pure black (#454545) with a slight #fff shadow.

Even if Topcoat was like other UI kits and only made images available, I could use tools like xScope and ColorSchemer Studio to derive the values. Having the CSS is awesome because it saves this step and encapsulates best practice solutions for getting these values into a format parseable by a browser. Still, those specific values are the "what" of the design but they aren't the most important part, the part that makes a design truly open and reusable: the "why".

Why a 3px radius and instead of 5px or 1px? How does 3px relate to the size of the button as a whole or the size and weight of the text? Why is the button #e5e9e8 and the border #a5a8a8? How were these colors selected?

Expanding outwards from the button we can continue our line of questioning. How do the values that create space between the button and other elements near it relate to each other? How were colors in Topcoat selected and how do they relate to each other? The colored buttons have various blues to indicate state. How were these blues picked from all the possible combinations of hue, saturation, and brightness? How do the blues and grays and near blacks compare to each other?

The answers to those questions (and more) is the actual "source" of design. If you think the "why" isn't the single most important aspect of a design, open one of these UI kits (or even a favorite web app!) in a browser's inspector tool and start changing values. You won't need to change many values and you won't need need to change them by much before the design will look "off" or "broken" to you. Change them back with a reload and the design will appear to snap into place, rich with its original cohesion.

Go, give it a try. Isn't it amazing? What's more amazing is that you'll see it even if you aren't a designer[1]. You live in a designed world. You've been trained by constant exposure to see design. And, while you probably haven't been trained to make new designs from scratch you're perfectly capable of distinguishing between good and poor design. If you don't believe me, go play with the games at method.ac.

Every design is like a little language with its own correct grammar and syntax nearly as specific as a programming language. It contains primitives but instead of concepts like maps, arrays, integers, and functions the primitives include size, weight, color, proportion, and texture.

Without first understanding that language it's impossible to correctly express anything new. And that's where the problems start for most people using these libraries. If they stay safely within the provided components they can make an application that looks designed (because it is) but no UI kit provides every possible component or even has guidance about all the ways existing components can be combined.

Inevitably these kits will fail to help. You'll need something new – it might be as large as a new component or as small as a new highlight color – and it will look wrong somehow. This is the #1 complaint you'll here from developers trying their hand at design. Not that they don't know what makes good design, but that when they try it comes out all wrong.

It's tempting to think the HTML and CSS are design source and that reading through it will explain everything you need. Let's examine this idea a bit by returning to the button example from above and adding another button into the mix:

Large button

Small button

Let's say our applications needs three hierarchies of button to properly draw attention. The large button for actions on data they are currently interaction with, the small button for actions elsewhere, and small_er_ buttons for global but infrequently used actions.

How much vertical space should the smaller button should use?

Implicit in the design artifacts that FlatUI, Bootstrap, Foundation, and Topcoat expose is the actual design. A skilled designer can extract it in the same way that a skilled programmer can look at an application and reverse engineer with surprising accuracy.

Once a designer has uncovered the underlying primitives, it's trivial to create new elements that fit into the overall design.

Most programmers lack this skill. So do many novice designers. For an expert designer, and especially for the ones who make UI kits, the design is so obvious from the artifact that they can't understand why we throw up hands up and say "These are beautiful examples, but how do I actually make a damn thing."

The good news is programmers are highly trained at working within a set of constraints and rules. You just need to tell them what those rules are and how to use them. A design isn't random. A design is the accumulation of intentional choices about size, proportions, colors, textures, line, etc. Values are selected for specific reasons and the relationships between these values is what becomes the language of the design.

For all the popular UI kits someone knows the reasons behind the values, but that knowledge isn't open. With enough skill you can derive a good guess at the answers, but that's no more open than any exercise in reverse engineering.

I'm extremely grateful for work people put into making these frameworks. I just wish they'd share the right parts.

Footnotes

I've tried this exercise with some design friends, too. They're often able to notice the breaking when a single value is changed by a small amount. It's impressive.

This post originally appeared as a gist

Some resources that informed my thinking

Android's style guide
Windows Phone UI design language
BBCs style guide
Apple's Human Interface Guidelines (HIG)
Tim Brown - More Perfect Typography and the great Modular Scale tool for selecting cohesive size values
Content out design
Infinite Grid

DEV Community: Trek Glowacki

Should a company do trial employment?

UI Kits and Open Design

UI Kits and Open Design.

Footnotes

Some resources that informed my thinking