Jonathan Snook's Blog, page 15

Attempting Deeper Work

I’m in the midst of reading Deep Work. I’m about two-thirds of the way through and while it’s probably a bit hasty to jump into a review, I have been thinking about what it means to how I work and what I want to work on.

The concept behind the book is that for the knowledge worker, success comes from the ability to think and work deeply on something. Basically, to get into a state of flow.

This is extremely difficult for me with my constant need to read Twitter, Facebook, Instagram, Slack, and whatever else I think needs me attention immediately.

Deep Work describes how we need to train our minds to resist shallow distractions. More than that, we need to develop a routine so that these shallow distractions don’t deplete our ability to attend to things deeply.

I’m currently looking at my schedule to see how I can structure my day, to think less about what I should be doing at any given moment, and to think more deeply about the task that I know is at hand.

The temptation is definitely there to just give up on social media altogether—especially with the onslaught of negativity that pervades the platforms right now. I believe I still get value from these platforms and can also provide value back. Thus, I don’t plan to give them up outright.

I do need to restructure my relationship with them, though. And I haven’t determined the best way to do that, yet.

The Schedule

07:00 Day Prep
09:00 Deep Work
10:00 Break
10:30 Deep Work
11:30 Lunch
13:30 Deep Work
15:00 Research
16:30 Disconnect
19:00 Reading

Day Prep attempts to normalize days I do and don’t have my kids with me. I get up, get them ready, and off to school. When I don’t have them, this is time I can use to go get a coffee, chill out, or do whatever. Maybe practice some meditation. I want to avoid using this time to be on my phone because I don’t want to deplete my attention energy at the beginning of the day.

Meditation in some form or another would be ideal. (The book talks about different forms of meditation that can be helpful.)

Although it’s only two hours worth, I’m trying to front load my time for deep work. The intention being that I won’t already be mentally fatigued and thus, more able to get into a state of flow.

The lengthy two hour lunch lets me go out to grab a bite to eat or stay in and prep a meal. If I have extra time, I can deal with email and other social media. This would be the first time of the day in which I would do so.

After lunch, I have my next big block of time to focus on Deep Work. This brings the grand total to 3½ hours. That’s not a lot but hopefully the increased focus during this time will bring greater gains.

Lastly, I cap off the afternoon with some research time. This is shallow activity time. This could include social media time, as well.

After all that, the early evening routine, again, attempts to normalize my days with and without my kids. When I have the kids, we’re doing dinner and homework. When I don’t, maybe I’m getting groceries. Or hanging out with friends. Or just relaxing with a book.

I wasn’t really sure what to do with the end of the day. Do I spend this time back on social media? Is there anything else that might fit in here? Having a routine of daily reading sounds ideal. Basically, finish off the day with something to sleep on, letting the subconscious process things.

Weak Spots

When I first put together my schedule, I noticed I only had an hour and a half of deep work time by the time lunch rolled around. Putting most of my deep work time in the afternoon might mean I’d already be too tired to get into a state of flow. Thus, I switched things around to at least get a bit more time. I could use more but I think it’d mean getting up earlier and I’m not yet sure I want to do that.

How do I deal with identifying and dealing with urgent matters? If I get a text from my ex that I need to pick up a sick kid from school, do I potentially go over an hour before even noticing that I have something to deal with? I’ll need to set things up in a way to let those requests in.

Work to do

This’ll take some time and effort to retrain myself to focus. Just writing this post, I distracted myself three different times. I’ll likely move towards creating more barriers to giving into distraction such as going completely offline or (as the book mentions) doing grand gestures like taking a lengthy flight with no wifi just to get some work done. (I spent 6 hours on a plane yesterday, which I spent reading and left the plane brimming with ideas and things to work on.)

Speaking of grand gestures, one of the stories in the book is of an author who booked a $4000 flight to Japan and back, just to focus on writing. If whatever you’re working on can pay back in spades, then those grand gestures might be worth it.

CSS Concerns

These days, I often find myself hearing people say “we use BEM” or “we use SMACSS” and the question that often comes to mind is “how exactly do you use them?”

Coming up with a catchy name for a development approach is a double-edged sword. On one hand, they are a convenient way to convey a lot of information really quickly. If someone says that they use BEM, I can make some quick assumptions. On the other hand, people are people and often interpret the details differently. The devil is in the details.

Like Ajax and RWD, BEM and SMACSS and OOCSS have, to some degree, become overloaded terms and it’s hard to tease out what someone really means when they say they use these techniques. Long gone are the days when people actually transmit XML in an Ajax call. People create fixed width designs for three viewports under the banner of Responsive Web Design. Likewise, people use atomic classes with a BEM naming convention. (And don’t get me started on naming conventions!)

In reality, what I’ve found is that I have specific concerns that I want to address and that I use particular techniques to address those concerns. People don’t often think consciously about these concerns. I know I often don’t. But it can be useful to understand the priorities on a project and what techniques you choose to address those priorities.

My Concerns (when developing with CSS)

My concerns when it comes to architecting an application often are:

Consistency: How can I maintain consistency in my design and development?
Clarity: How can I make it easier for people to understand what I’ve developed?
Efficiency: How can I speed up development?
Change: How can I make it easier to make changes?
UX: How can I improve the user experience?

The Salesforce Lightning Design System talks about their design principles. Salesforce lists these in order of priority. It’s useful to articulate your priorities as they help you make decisions during the design and development process.

Obviously, when it comes to CSS architecture, I have opinions. The way I chose to solve those problems was by using the concepts I laid out in SMACSS. I’ve never explicitly mapped the concepts to the concerns I’ve listed above but I can see how the concepts address those concerns and why the concepts were important to me.

Consistency

I care about consistency within a given page and I care about consistency across an entire site. I believe that a consistent experience is easier for users to understand, thus creating a better user experience.

Clarity

When I talk of clarity, I mean of how easy is it for other developers (or future me) to understand the work I’ve done. Can a new team member ramp up quickly? Can a developer building out a new interface do so without stumbling their way through it or missing critical steps?

Efficiency

Being able to build new features or redesign existing ones easily in an established system is important. If teams ignore parts of the app or take months to refactor things because of poor design or infrastructure then everything else suffers—users, employees, and employers are sad because it takes longer to get features out the door.

Change

Change ties into both efficiency and consistency.

When it comes to growth within a design system, I believe it important to be able to maintain that consistency as designs change.

It’s also important to be able to roll out design changes quickly. If it takes a large team weeks or months to roll out a new design then this pulls them away from working on new features. In some orgs, I’ve seen global design changes take a back seat to new feature development, further exacerbating the situation. New features either take on new design elements, breaking away from site consistency, or they continue to stay with an old design, increasing the amount of work required to roll out a new design.

User Experience

Lastly, how will the user experience be affected by any of the above? For example, if I improve a widget experience for those using screen readers, I want to be able to easily roll out the change to that widget across the site.

How do I address performance in all the ways that it can affect the user experience? How does a consistent design affect the user experience? Is it worthwhile to replace native controls with custom ones?

The One True Way to Build a Site

You might think I subscribe to the idea that SMACSS is the only way that a site can and should be built. As I mention early on in the book, however, is that when it comes to web development, the answer is almost always “it depends”.

Consider what’s important to you on your project—make sure the team agrees—and then build guidelines on how best to meet your goals.

It’s also important to recognize that these issues aren’t just CSS issues. They are HTML and JavaScript and backend issues, too. They all need to work together to serve these concerns.

Coding CSS for Context

Dave Rupert recently tweeted asking a question that I see quite often:

.some-context .thing { /* special rules and overrides */ }

Does that go in thing.css or some-context.css?

Then, Harry Roberts discussed this concept further in his article of CSS Code Smells Revisited.

Harry uses a practical example of .thing being a .button. (Well, actually, a .btn but whatever. And yes, I just “well, actuallied” myself. It’s preemptive mansplaining.)

You’ll have the standard button that appears throughout your application. And then you have this variation in modal dialogs.

Instinctively, we start writing .modal .button. Hence, Dave’s question of where to put this particular bit of code. It’s interesting to note that the results of Dave’s survey indicated that a slim majority of people prefer that this bit of code live in with the modal CSS and not with the button CSS.

Harry indicated that it should live with the button CSS. And I agree with him. We’re styling a button! It should be in with the buttons.

But then Harry seemed to contradict himself by saying that the button class name should be renamed to .modal__btn, making it a part of the modal component. In doing so, this bit of CSS should now live in with the modal CSS. (And based on naming convention, I would agree with him.)

One thing you have to worry about is components becoming too complex. Yes, the modal has a button. It could also have inputs and headings and all sorts of things. Over my career, I’ve noticed useful boundaries and tend not to create components with deep hierarchies.

Identifying The Thing

Going back to our thing that we’re trying to style: the button. Yes, right now, we’re styling a button in a modal dialog. Is this the only place that this exists? Right now, quite possibly. Will it always be the only place it exists? If your project is constantly in flux, then not likely.

Here’s what’s important:

We want to identify that this is a variation on our button.
We want to indicate the purpose of this button style.
We want to avoid tying the code to a particular context that could change.

Going with .button--modal, for example, now identifies it as a variation. But fails on the other two points: It indicates its context and doesn’t say what it’s trying to do other than be in a particular place on the page.

So, why is the button in the modal different than regular buttons? (If you’re the designer, ask yourself this. If you’re not the designer, ask them this.) You might get something like, “It needs to be green to draw attention to the fact that it’s a primary action.” Or maybe something like, “the button is smaller because we don’t have as much room.”

This helps you come up with a name like .button--primary or .button--compact.

Either of those names satisfy the three points I mentioned above.

It identifies itself as a variation using the BEM double hyphen.
It indicates its purpose through the variation name.
It hasn’t tied itself to a specific context.

That last point, to me, is the most important. As a designer, I might end up using these styles on a new page that hasn’t been thought up yet. I might want to use a primary button style on a form that isn’t in a modal dialog. I might want to use a compact button in a sidebar where I don’t have a lot of room.

And as Harry also mentioned, by keeping all our button styles in one place, we have the ability to see patterns emerge across an entire project.

Three months down the line, do we suddenly find ourselves with 30 button styles and need to reduce the complexity of our UI? That can be harder to do if button styles are strewn throughout the codebase, hidden within other contexts.

Mixed Content and Responsive Images

I ran into a weird issue. Images weren’t loading for some reason on this project I was working on. And yet, on the old site, they loaded just fine. What was different?

After some digging, I noticed that the images that weren’t loading were those defined using the <picture> element. Surely that’s not expected behaviour, is it? Turns out, it is.

There’s a Mixed Content spec. This spec defines the rules in which content should be blocked when they’re served from an unencrypted context within an encrypted one. (That is, an https page trying to load images and other assets over http.)

Images are considered passive content. As a result, browsers will serve them up even though they’re unencrypted. Scripts, on the other hand, are considered active content and, by default, get blocked.

Interestingly, within the spec is this very line: “Return allowed if one or more of the following conditions are met: [...] when request’s type is "image", and initiator is not "imageset".”

The picture element being an imageset, that means that unencrypted images defined in a <picture> or srcset will get blocked.

Solution?

From what I can tell, you have two options: serve the images over https or don’t use responsive images. (I recommend the former.)

On Platform Independence

As I explore running on Windows, I've been thinking about the apps and tools that I use. I went through a similar exercise when I dove into Android.

I definitely felt that one's enjoyment of a platform might come to how much you're willing to embrace that company's entire ecosystem. Using all Apple products for close to 10 years now had meant that moving from device to device was relatively effortless. Many of the recent features like unlocking my MacBook with my watch or having a universal clipboard are pretty handy.

The moment multiple platforms come into play, all this convenience starts to disappear.

As a result, I've started being more conscientious about where I want stuff to live. For example, do I store all my files in iCloud? That doesn't help me on Windows or Android. Then there's music. And photos. And so on.

This also goes for the apps that I choose to use. Even something as simple as a to-do app has been a frustration of mine as I seek to find something that not only meets my needs but can do so on all platforms. Not easy to do. (groan)

As a developer, it makes me think about the experiences I want to create and how I could reach the largest audience but also how I can create a great experience over all those platforms.

The web, of course, is a natural fit. There's a web browser on every platform. I do like standalone apps and I like the experience that native apps can provide. Sometimes those things are subtle. Performance, rendering, scroll or mouse events, and so many other things can often make me feel like I'm in an uncanny valley of applications.

The last version of iTunes, for example, would do this weird thing where it would reset the scroll position every time I selected an item. It ruined iTunes for me. Making a playlist was excruciating.

I'm hoping that Progressive Web Apps will fill this need. With local storage, service workers, notifications, and access to other native resources, we'll be able to build cross platform applications more easily. (Not that testing those applications will be easier, but that's another story.)

On Windows

For to-do apps, Wunderlist and Todoist seem to be the best of the bunch but both frustrate me in different ways.

For things like Twitter and Facebook Messenger, I've just gone with the web. They seem to provide the best experience right now. And Edge has worked just fine. Although I switch over to Chrome to do a few things. (And the lack of 1Password integration in Edge is a bit frustrating.)

Having 1Password available on all platforms has been a huge timesaver. The implementation on Windows, in general, is a bit behind but there have been and continue to be regular updates to improve the integration.

For photos, I've been using Lightroom. I like the mobile implementation but the need to store all the photos locally on desktop is a bit of a frustration. I like having my photos in the cloud and just pulling them down to edit them.

For all my other files, I think I'm going with Dropbox. I already have it and its cross-platform availability works for me. It also has integrations with a number of apps that other platforms don't have.

Hashtag

So, Dave Rupert had #davegoeswindows and now Dan Mall has #dangoeswindows. Do I need to have my own hashtag? I didn't realize this was a thing. I guess I might as well do #snookgoeswindows. (Up next: dev environment!)

Running into Windows

I enjoy exploring an ecosystem. Last year, I spent a month with an Android phone and tablet to see how they compared to iOS.

Now, I'm going to try something similar by switching to Windows as my primary machine. Dave Rupert went through a similar exercise. Microsoft was kind enough to offer up a Surface Book for this experiment.

When the Surface Book was announced, lots of people gave it very positive reviews. I have a Samsung tablet from a few years ago when Microsoft was exploring what it meant for a desktop OS to also be a tablet OS in Windows 7. That Samsung tablet, however, was bulky, ran hot, and the battery ran down quickly. Ick.

Initial Impressions

My first hour or so with the Surface Book created mixed feelings.

On the hardware side, this laptop is quite nice. The detachable screen becomes a tablet and is surprisingly light. The keyboard feels good. The trackpad feels good. This is a really nice laptop.

Having a laptop with a touch screen is nice. For the most part, I use the keyboard where I can but sometimes a button press is easier to just hit with my finger. The trackpad finger gestures are nice and remind me of the handy gestures on the Mac. I enjoy the three-finger swipe to switch applications or to minimize all the apps.

I do find the multiple desktop feature annoying. Mostly because it creates isolated app switching for each desktop. If the app you want to switch to is on the other desktop then you need to switch desktops and then switch apps.

One particular thing that bugs me: the top row of function and media keys. There's plenty of room to have had a separate function key row and media row. Instead, there's a function key that has to be turned on or off to choose between them. I never use the function keys on my Mac but in Windows, I use them all the time. I have to consciously be aware of whether the key is enabled, which is more cognitive load than I would like every time I need to use a function or media key.

Speaking of the media keys, I'd rather the ability to control screen brightness via the keyboard (which I do multiple times a day) than the ability to control the brightness of the keyboard backlighting (which I do almost never).

Also, I find it weird that when the laptop is folded over, it doesn't fold flush. Instead, it looks like a book with a pen stuck in the middle of it. (Hence the name, is my guess.)

On the software side, I'm having a tough time pinpointing the things that really bother me. I think a lot of it comes down to polish, which in a lot of cases, comes down to how well third party apps built their apps.

For example, I'm writing this article in an app called WriteMonkey. It's a fantastic app for writing in Markdown. It runs full screen and gets out of the way. Love it.

The Twitter app, on the other hand, sometimes blanks the screen before reloading messages. The Facebook app seems to have a different scroll sensitivity than the rest of the OS. Edge supports two-finger swipe to go back but nothing else does. And Mail seems to have its own text entry with a custom context menu and the shortcut to paste without formatting (Ctrl-Shift-V) is mapped to something else. Oh, and Messenger locks up quite frequently, requiring a restart.

Of course, I'm sure I could come up with a similar list for the Mac. I've just been on it long enough to get over the annoyances.

When Windows 7 first came out, it felt spartan to the point of feeling unfinished. Windows 10 definitely has a lot more polish. Also, the Cortana voice recognition seems to work really well. I can't tell you how many times I ask Siri for something and she completely gets it wrong. "Play my loved playlist." "Now playing Love Yourself by Justin Bieber." "Goddammit Siri!"

The Cortana integration in the Start menu is really nice, too. I like the speed and design. It feels very natural to just hit the Windows key and start typing for what I want. It finds what I want accurately and quickly.

Living on the Edge

I want to use Edge as my default browser but the biggest hiccup is my password manager, 1password. It doesn't have an extension for Edge. Being able to log in quickly, easily, and securely is important.

The second hiccup I ran into, and this might seem silly but, it's the performance of splix.io. It's a fun little game and it is butter smooth in Chrome. Not so much in Edge.

It looks like Chrome will be my default browser for now but I'll load in my usual plethora of browsers for cross browser testing.

Lots to explore

Of course, I still have lots to explore. I haven't set up my dev environment yet, so we'll see how that goes. (I just typed "terminal" into the Cortana bar and the command prompt app popped up. Nice.)

How do I learn?

I hear this question quite a bit lately. Our industry feels like it’s expanding exponentially with new techniques and technologies. People feel overwhelmed and unsure how to ingest it all.

I’ve found that I have 3 phases to my learning process:

Reading
Building
Writing


Reading — Superficial Learning

I read a lot. I’ll click on links from Hacker News, Facebook, and Twitter. I’ll read about new techniques and new technologies and integrate those learnings into what I already know.

This is very superficial. With this knowledge, I can refer back to things if somebody asks about how to solve a particular problem. I couldn’t necessarily apply the approach myself yet but I have enough to know that a solution exists. That in itself can be quite useful.

Building — Application and Expansion

From there, when I want to learn more about a given thing, I build something with it. Most recently, I wanted to learn about web beacons and took the time to make a beacon to see how it worked. I do this frequently. I’ll build small one-page apps to test out a concept. The exercise may take me anywhere from an hour to a week to build.

Building something expands my knowledge on a topic and now I can speak more authoritatively on the pros and cons of why and when you’d want to use such a technique or technology.

Writing — Explore the Edges

The last step is to write about it. This could be a blog post, a book, or a conference talk. When I write about a topic, I explore the edges of what I know, the edges outside of what I needed to initially implement the idea.

For example, it’s one thing to know that web beacons exist. It’s another thing to know how to implement them. It’s another thing to know the range and other limitations that exist.

In writing a blog post about all:initial, I forced myself to test in every browser and discovered how inconsistent the implementation was.

Reading, Building, Writing, Repeat

It’s not necessary to go through this process for everything. You can stay at the superficial level for many things and only dive deeper when you need to, like implementing an idea on a client project.

Likewise, you don’t need to write about everything you work on. Writing is, for me, how I learn a topic more intimately. Not everything needs to be learned that deeply.

As your career develops, you’ll gain a sense of what things to explore sooner rather than later, or not to explore at all.

I have a list of things I’d like to explore—like progressive web apps, service workers, and web components—and when I do, I’ll go through this same process again and again.

Physical Web Beacons

After hearing about the Physical Web through a second-hand tweet, I decided to look into what it is and why we want it.

The Physical Web is essentially a way to broadcast a URL using Bluetooth (Bluetooth Low Energy or BLE, specifically). Devices can then listen for those beacons.

The beacons can broadcast to a distance from a few centimetres away to possible 450 metres away.

The Physical Web uses Eddystone, an open source beacon specification that Google proposed and is a competitor to Apple’s proprietary iBeacon technology. Google released Eddystone in July 2015.

What’s the Frequency, Kenneth

My initial reaction was “cool!” The practical applications of this could be quite numerous. For example, the web site shows a dog tag or a parking meter broadcasting. Stores could feature sales as you walk into them and have those broadcast directly to your phone.

In Uri† Shaked’s overview of the Physical Web, he talks about being able to broadcast conference slides while doing a talk. Conferences could broadcast the day’s schedule.

I could imagine going by a restaurant and being able to load up their menu via a beacon. Bus stops could broadcast maps and times.

The QR Code of the Future

Sadly, my mind quickly devolved into the annoyance of numerous notifications, like popup windows and other distracting adverts, vying for my attention.

Imagine that same conference with companies pitching their wares or recruiters filling up your notifications. There could quickly be so many notifications as to make them near useless.

Walking into a store, your phone buzzing with dozens of product sales, as companies pay for beacons and shelf space.

It all just feels like QR codes. They’ll be all over the place and most of them won’t be very useful.

Priorities

With the possible onslaught of beacons, some type of filtering or prioritization would seem ideal. Otherwise, I think most people would just rather choose to have beacons turns off, which wouldn’t really be of much use to those who use beacons. (Uri recognizes this issue in the comments of his article.)

Trying them out

Uri’s article does a great job of describing how to set up Beacons on your laptop or Raspberry Pi, and how to configure your iOS or Android devices to listen for them.

Broadcasting a Beacon using Node

On my Mac, I was able to broadcast a beacon with a couple easy lines:

npm install --save eddystone-beacon
node -e "require('eddystone-beacon').advertiseUrl('https://snook.ca/');"

Of note, URLs need to be https. I tried specifying an http URL as a beacon and it couldn’t be found. I tried specifying an http URL that redirects to https and it could be found. I’m not sure if it’s the sender or the receiver that’s doing the double-check on the URL.

(Also, you might have to use sudo to get npm to install everything correctly.)

Listening to Beacons

On iOS, add Chrome to the Today screen. You’ll be prompted to listen to Physical Web beacons. Don’t worry, you can disable it later.

On Android, notifications will come up automatically.

Da Bears

I’m still bearish on beacons but I like the potential. I may try setting up beacons at upcoming conferences and workshops to see how well it works.

† How cool is it to have a name like URI (Uniform Resource Identifier)?!

Working Remotely

I’ve been fortunate over the past decade to have been able to, in various capacities, work from home—or work in place, as some like to call it. First as a freelancer, then Yahoo!, then again when I went to work at Xero, and now back to working for myself.

Shopify has been the exception to the rule in that time and while I tried to instill a culture of remote work, I don’t think I managed to move the needle much within the organization.

So, after all that time, what have I seen that works and doesn’t work? If I were to start my own company, would I allow remote workers? If I were to join another company, how would I foster an environment that encouraged remote work?

What works

With the hindsight that comes from experience, what made it work? For me, it was about being given a discrete task with few or no dependencies. That’s it in a nutshell.

When I was a freelancer, I worked with clients to determine the scope of work, was given the autonomy to do the work, and then delivered the work.

At Yahoo!, especially in the beginning, I had a defined role that didn’t require much communication with the team or teams at large. I would get design work and then build out the front-end based on those. Again, being given the autonomy and trust to build things as I felt they should be built meant that I had very few dependencies. There was very little that would slow down my ability to produce work. (Well, except dealing with my own distractions—something that has become more difficult of late.)

It was fun to hop into a conference call from South Africa. Or to have a co-worker contact me from the passenger seat of a car driving the coast of Italy. I’ve done conference talks from hotel rooms. I’ve done work meetings from coffee shops around the world.

What didn’t work

Not everything was peachy, though. At Yahoo!, I was placed into a managerial role. Managing a team remotely, for example, didn’t go so well. I needed to be in lots of meetings and if people didn’t log into the teleconference, I was left out of the loop. I didn’t really know how to manage a team and that training was never provided, nor was it requested.

In the early days of my time at Shopify, I tried to convince management that supporting remote workers would make us a better company. But I didn’t know how to go about making remote work for the company. As a result, the initiatives that were implemented just fizzled. Instead, each remote office was given tasks that allowed them to work more autonomously.

At Xero, my struggle was mostly in dealing with time zones. Living in a time zone 8 hours away meant that meetings often fell in the evenings when I had family commitments. As a result, I missed countless meetings. While my team never made mention of it, I felt increasingly out of the loop and ineffectual.

Would I Lead a Remote Team?

Given my experience, would I build and lead a remote team?

Yes.

Now that I have some experience behind me, I think I could make it work. To do so, here are some things I would do:

Have discrete tasks

Give people ownership over something and give them the autonomy to build that thing with little initial oversight. There are opportunities through code reviews, design reviews, and other exercises to ensure that people are on the right track. Otherwise, get out of their way.

Communicate in the open

When you have some people in an office and some people out of the office, it’s easy for some communication to be isolated. The team in the office might come to a conclusion and never communicate it outside of the room that decision was made.

For distributed teams, that’s awful. Communicate in the open. Every decision is documented. Find a place, be it Slack, GitHub, Trello, or wherever, and get the word out.

Fostering Remote in a Company

Considering my failures at Shopify, I’ve wondered how, if going into a new company, I could enable remote work. I think I would take a more grassroots approach. I’d implement it for my own team and then teach other teams how to duplicate what works.

Of course, that requires buy-in from the higher-ups to be given that freedom within your team. Basically, you’re the Guinea pig and you’ll need to hit the mark. Establishing trust will be very important.

Assuming you have an in-office team, you can still encourage remote work with baby steps and possibly without needing buy-in. Allow people to work from home or work when they travel. Create a communication process that works whether people are in the office or not. Once you’ve proven that it works on a small scale, you can go to management with a proven track record.

Room for Improvement

I feel that some of the tooling for remote teams could use improvement. I’ve had ideas for apps I’d like to build that could help fill the void. With a remote team, you lose spontaneity. You lose the ability to turn to a co-worker and ask a quick question. You lose the ability to jump up to a whiteboard and gesticulate wildly to explain your point.

Instead, we’re often dealing with poor connections, or laptops awkwardly pointed at half a whiteboard, struggling to read what people are writing through the glare of overhead lights. Or struggling to hear people in a crowded, noisy room.

Despite the downsides, I’m still bullish on remote work. I believe that getting to work from anywhere in the world that has a decent internet connection is one of the great advantages of our wonderful industry.

The future is already here, it’s just not a distributed workforce yet.

How Will Web Components Change CSS Architecture?

With the slow rise of Web Components—the breakdown of interfaces into self-contained chunks of HTML, JavaScript, and CSS—will we see an evolution (or revolution) in how we manage the way we write, build, and bundle the CSS for our web sites?

Currently there are two main approaches to writing CSS: component-based and utility-based. (I’ve also seen this referred to object and functional CSS, respectively.)

Component-based

A component-based approach establishes a 1-to–1 relationship between the HTML and the selectors. It does so by codifying a design pattern and applying it to an HTML element.

For example, a button is codified in the CSS with a .button class and applied to an element.

Since there’s a selector for every design pattern, as the number of design patterns on your site grows, so does the size of your CSS.

Theoretically, there’s a cap to the number of design patterns you will or should have on your site. However, evolving designs and growing sites often continue to add to the codebase without removing old designs. I’ve seen sites with ten years worth of CSS that continued to be cobbled together.

SMACSS falls squarely in this camp.

Utility-based

At the other end of the spectrum is a utility-based approach. It establishes a 1-to–1 relationship between the selectors and the CSS properties.

For example, a button—consisting of a collection of CSS properties—receives a number of classes to style the HTML.

There are only so many CSS properties and only so many values we set with those properties. As a result, the size of the CSS reaches a cap.

Atomic CSS falls squarely in this camp.

In the Middle

Of course, there are people (er, most people, probably) that choose to blend these two styles together. Some use a component-based approach for some things, like buttons and inputs, and then use a utility-based approach for other things, like layout and spacing.

Delivery

How that CSS actually gets delivered to a user is a factor in all this.

Most projects I’ve seen go all in. All of the CSS for a project is bundled together into a single file, minimized, then cached.

When I was working at Yahoo!, the reason for the component-based approach was to be able to bundle only the CSS needed for the page and no more. Only when new pages with new components were loaded was the CSS for those components loaded. This was done through a “combo handler” that could combine the individual CSS files together at request time and cached.

Web Components

If you’ve looked into Web Components, that last bit should feel really familiar.

If a Web Component is only requested when it’s used then the embedded CSS will only be used when the Web Component is requested.

Web Components actually consist of 4 different technologies: custom elements, HTML imports, Templates, and Shadow DOM. When I refer to Web Components in this article, I refer to them as a collective whole. An actual project not using HTML imports, for example, might use a different strategy for bundling and loading components into a project. A project could still bundle the whole app into one fell swoop like many people do today. In which case, none of what I’m talking about here really applies.

That means that a component-based approach allows us to localize CSS to a given component and get the performance benefits of only using that CSS when it’s needed.

Many in the React world using inline CSS are essentially doing the same thing. They’re writing CSS in the component and that CSS only gets used when the component is requested.

As you can probably guess, my approach (with SMACSS, natch) to building a site using Web Components doesn’t really change. Some concerns like using naming convention to namespace CSS fall by the wayside due to the Shadow DOM.

For those using a utility-based approach will still need to go through a bundling process but with the file size being (theoretically) reasonably sized, this isn’t really an issue. Each Web Component just has to say that it wishes to use the same CSS file.

Performance

It remains to be seen whether a micro-delivery approach will create a better user experience than a macro-delivery approach.

Does 240KB of CSS (using a component-based approach) broken down into a dozen requests of 20KB each over multiple pages create a better experience than a single 50KB request (using a utility-based approach)?

I’ve seen pros and cons to both scenarios. The micro-delivery approach currently depends on http2 taking off (which it is and will) and while the performance improvements look good overall, we’re seeing that it’s not necessarily an instant panacea†‡. We’ll continue to see server-side optimizations that can be introduced to improve delivery performance.

† Khan Academy saw a performance drop from serving up too many files over http/2.

‡ Dropbox saw a decrease in performance with POST requests, which has subsequently been fixed.

(I don’t mean to be alarmist over http2. I honestly believe that these are small hiccups and that we should be moving to http2 as soon as we can.)

Conclusion

All that to say that I don’t think the CSS architecture landscape will really change much. We’ll likely see more discussion around what should be defined with a Web Component and what should be defined outside of that. Although, it’s possible that some completely different approach could be introduced.