And with the strongest typhoon in 25 years about to make landfall in Osaka, I needed to figure something out. Like, now.

Let me start from the beginning. A few months back, I took a trip to Japan. I was going to be there for three weeks, and for the first week I was all on my own. My flight into Tokyo landed on August 31, 2018. This is going to be important later.

When I landed, one of the first things I did was go to an ATM in the airport and pull out about $400 in yen. I took that money and travelled to a bunch of different cities over the next few days: Tokyo, Nikko, Kurobe, Toyama. Four days into my trip, I found myself in Takayama, Japan, in the center of rural Gifu prefecture. It was beautiful.

By then, I was running a little low on cash. I had around ¥5000, or $50, and I definitely needed more. In Japan, cash is king, and in rural Takayama, restaurants, hostels, and busses are all cash only. I knew this from my previous trips, and so I went to the only international ATM in town, at the 7–11 on the corner. I stuck in my debit card, and punched in my pin.

Transaction declined.

No problem, I thought, I probably mistyped my pin. I put my debit card back in the ATM, and re-typed my pin.

Declined again. This time I read the paper slip more carefully:

Transaction Declined: This card has expired.

I looked down at my debit card, and sure enough, my debit card had expired as of September 1st, 2018, the day after my flight landed in Tokyo.

In the corner of the 7–11, a newscaster ominously reminded everyone that there was a typhoon headed for Japan. Typhoon Jebi, the strongest typhoon to hit Japan in 25 years, was on collision course for Osaka and due to make landfall tomorrow.

Everything was going to be fine.

Let’s take a look inside my wallet.

Whenever I travel, I carry a four cards with me in my wallet:

1. Charles Schwab Investor Checking Debit Card
2. Chase Sapphire Reserve Credit Card
3. Chase Freedom Unlimited Credit Card
4. Google Corporate Credit Card

My debit card was expired, so I called Schwab with lots of questions. Why didn’t I get any advance warning that my debit card was about to expire? Couldn’t they re-activate my card, or something? I was out of luck. You can’t use an expired debit card, no exceptions.

Problem #1: Schwab didn’t notify me that my debit card was going to expire. They claimed to have mailed me a new one weeks ago, but I never received it.

The customer service agent offered to overnight the card to me from the U.S., but it would take a few days to get through Japanese customs. They asked me where I’d be staying for the next few days. I had planned to stay in a different town each night for the rest of the week, so it didn’t seem like a good option. I told them to ship it to my hotel in Tokyo, and I’d pick it up at the end of the week. But what was I going to do until then?

Chase Credit Cards + ATMs = no luck

I started sticking my credit cards into the ATM, starting with my Chase Sapphire Reserve (which has no foreign transaction fees), and following up with the Chase Freedom Unlimited. I figured they’d probably stiff me on the cash advance fees, but I’d live.

I typed in every pin I could think of, and they all got declined with an “incorrect pin” message. That’s when I realized: Did I even have a pin?

Problem 2: My Chase credit cards were both chip + signature cards that don’t support pins for purchases.

Because my Chase cards were both chip + signature, I didn’t have a pin configured on them. Confused, I called Chase. It turns out these cards can be used for a cash advance at an ATM, but to do so you have to call Chase and specifically ask to setup an ATM pin. If you call and ask just to “setup a pin,” they’ll tell you that the card is chip and signature. (It took me three customer service agents at Chase to figure that out.)

Meanwhile, the winds of Typhoon Jebi just hit 130 mph.

So now on my fourth call to Chase, I get to the pin creation automated phone system. After painstakingly typing in my social security number and credit card number, I get to the end of the pin process and realize that while you can easily change your ATM pin if you already have one, you can’t actually create an ATM pin over the phone. Instead, they will mail you a randomly generated pin to your home address, in 2–3 weeks. Then, you can call in and change your pin to whatever you want. I hang up.

Problem #3: There’s no way for me to create an ATM pin over the phone.

I called Chase back, now for the fifth time, and grilled them. Why was this so broken? By this time, I was on the phone with the ultra-elite-emergency-super-customer-support person from Chase. The woman told me that they didn’t allow ATM pin creation over the phone for security reasons, unless the card is less than 90 days old (not true for me).

I had a flash of hope when she said “Wait a minute, I swear there used to be some emergency pin process, but I haven’t heard about it for years… let me go look that up.” She put me on hold to, as I can only imagine, take the elevator to the basement of the Chase customer support center, open up some filing cabinet, and blow years of dust off some ancient manual in search for this “emergency pin” procedure.

It turned out she was right, they used to have an “emergency pin” process for situations like mine, but they stopped the process several years ago. This woman, who tried so hard to help me with all of this, had to say “I’m sorry, good luck with all of this” and hang up.

No luck on my company card, either

I tried my Google corporate card in the ATM as well, to no avail. I had a pin on the card, but it got declined, with the error message “feature not available.” Apparently, my corporate card didn’t support cash advances.

Problem #4: No cash access on my Google corporate card.

Time to call in the cavalry: Google Security team

One of the many perks of working for Google is that employees have 24/7/365 access to the Google Security Team, the Google security team. No matter where you are in the world, you can call Google Security when you’re in trouble and they’ll help you figure it out. Even if you’re not on a work trip. (I was, at least sort of.)

I explained my situation: cash-only rural Japan, no cards that work, incoming typhoon. They told me I could apply to get cash access on my corporate card, but it would require manager approval.

Problem #5: I needed manager approval for cash on my corporate card.

The Google Security team filed a ticket, but it was the middle of the night back home in the U.S. I could call back if things got really dire.

So there I was, in the middle of the street in Takayama, Japan, when it really hit me: I didn’t have enough money to afford my hostel reservation that night. Or a bus ticket back to the city. I wasn’t even sure if I could afford dinner. With the strongest typhoon in 25 years about to make landfall in Osaka, I needed to figure something out. Like, now.

I started to get creative. In the US, you can get cash back at a grocery store, like Stop & Shop. So I walk up the counter at the 7–11 and whip out Google Translate, trying to explain to the 19-year-old working behind the counter what a cash advance is.

“I want to buy something using my credit card, and have you give me Yen.”
私はクレジットカードを使って何かを買って、円を貸してもらいたい」

She shook her head, clearly confused and weirded out. She gave me the look that said “yeah… we don’t do whatever that is.” I had to try something else.

My solution? Begging strangers to help me use an ATM.

I’m actually pretty surprised it took me this long to think of, but it finally popped into my head. Could Venmo be my answer? Well, not Venmo because I was in Japan and no one there had Venmo, but some peer-to-peer payments app. I tried to sign up for one of the many Japanese P2P payments apps, but they all required Japanese bank accounts. No dice.

I did have one app that could work, though: PayPal. Boring, corporate, ubiquitous, PayPal. It could work. Someone with a working debit card takes out Yen for me, and I send them money on PayPal.

What came next wasn’t pretty. I went to the most touristy area of Takayama and started profiling tourists that seemed the most likely to trust me. I approached them, like a shark.

“Excuse me, sir, I’m so sorry to bother you, but you see, my debit card–here take a look at it–you see it expired the day after I arrived here in Takayama, and see I have these credit cards…so my question is, do you have a PayPal account?”

I was literally that scammer that walks up to you on the street and asks if you can help him get his hands on some cash. I probably approached 10 different couples, all from Europe or Australia or India or the U.S. in search of someone who would trust me enough to take out ¥50,000 from an ATM for me, in exchange for that amount, rounded up, on PayPal.

I begged.

Time and time again, I got roughly the same answer. “Sorry.. yeah.. you see, we don’t really have any cash… No, no, we’re just using our cards… yeah sorry I can’t help you.” It was brutal. To them, I was just your average tourist scammer.

After an hour of trying, finally, finally, I found a willing tourist. Manuel, de Barcelona. Manuel and his wife listened empathetically to my sob story (I was an expert at this point), and after considering it for a moment, agreed. We went together back to the 7–11, he got me the cash, and I paid him on PayPal. There are good people in the world.

With cash in hand, I could finally afford my bus ticket to my next destination, and I could afford to check into my hostel. I asked if I could buy him and his wife a drink. They said they were headed to check into their hostel, but maybe later that night. “Where are you staying?” I asked.

Of course: They were staying in the same hostel as me. Not only that, but, as we found out later, we had rented neighboring rooms in the hostel. I’m not sure I could have made up something that coincidental. Of the hundreds of tourists visiting Takayama that day, it was Manuel that trusted me enough to take a risk, and do the PayPal for cash exchange.

Epilogue

The next day, I called back the Google Security team, and even though my manager hadn’t approved the ticket yet, they skipped the approval and put some cash access onto my corporate card. This got me through the rest of the week (Manuel’s ¥50,000 only went so far) until I arrived in Tokyo and picked up my new debit card.

I still carry these four cards with me whenever I travel. But now, I make sure to check my expiration dates, well before my trips start.

Disclaimer: I’m not a designer. I’m an engineer and product manager but I’ve picked up a few tricks from my colleagues that have helped me hold my own in design reviews and projects.

My perspective is that becoming an advanced designer requires years of practice but that the basics of design is like learning guitar: You only need to learn four simple chords to play a lot of the music from the past 50 years. I’ve collected a few equivalent design fundamentals that have served me well. Most of the examples I’ll use here are from web design (my wheelhouse), but my hope is that you’ll find them broadly applicable.

1. What is design, and how do I learn it?

I know the question sounds a little academic, but bear with me. After years of being corrected for my assumptions about the field, I’ve learned that everybody (including most designers) has a slightly different definition of design. Here’s the definition that makes the most sense to me as a starting point:

Design is the intersection between art, engineering, and people.

The field of design could be understood as the process of using art and engineering to impact people’s lives.

• Design without art is dull. (Think of a stuffy office building.)
• Design without engineering is impractical. (Think of flying cars.)
• Design without people is devoid of purpose. (Think of an Olympic village, several years later.)

Different fields of design use each of these skills in different proportions, but they all leverage some combination of all three:

If the art-engineering-people triangle is an academic definition of design, here’s a more practical one:

Design is a tool to direct attention, create understanding, and motivate action.

When we want to achieve a goal, we need to first understand the world around us and act accordingly. When we interact with the world, we rely on core assumptions about how objects and elements will function. These assumptions are created and reinforced by design.

Take a very simple goal: walking into a building. A well designed door can be easily identified from the exterior of a building, and a properly shaped door handle can only be turned one way to unlatch it.

It’s design’s job to help people understand objects in their world, and make their interactions with those objects intuitive. This flow — attention to understanding to action — is core to design. We can evaluate design by examining how effectively it directs attention, communicates meaning, and enables people to take action when needed.

Artists steal, engineers cheat, designers do both.

There is lots of hard work required to become a designer: understanding art, engineering, and human psychology requires years of study. But when you’re just starting out? Cheating and stealing are perfectly acceptable as well. (Aside from complete and utter plagiarism.)

Becoming an artist is hard, but any teacher will tell you that imitation builds a strong foundation. A jazz musician might transcribe solos by Miles Davis, learning to play each note and phrase to better understand rhythm, harmony, and phrasing. Likewise, imitating your favorite designers can be a great starting place, especially when it comes to the more subjective choices like color and typography.

On the other hand, when it comes to engineering, copying others’ work isn’t very helpful. Instead, a few key tricks and cheats can get you a long way. In calculus, L’Hôpital’s rule, factoring, and completing the square are all useful techniques for parceling out a complex problem into solvable chunks.

In design, these tricks take the form of best practices for layout, spacing.

2. How do I layout my design?

Space facilitates understanding.

In design, space is an extremely powerful tool for controlling attention, and conveying meaning.

Some designers use space well:

Others don’t:

So how can we use space effectively in design? To explore that question, let’s try an experiment. I’ll show you a few paragraphs of text and a captioned image, and you find the caption:

Can’t find it? How about here:

OK, you might have figured it out. But it took a second, and we can’t necessarily be sure. How about here:

OK, pretty doable, but I think we can do better:

Finding the caption in that last example is easy, especially in comparison with the first version. Why?

Proximity creates associations, and separation creates distinctions.

The problem with the first Calvin image was that it wasn’t clear which of the many sentences is associated with the image. Said differently, it wasn’t clear which sentence was meant to be distinct from the rest of the paragraphs.

In the revisions, space is added between distinct elements (the image and the text, the caption and the paragraphs). We can visualize this process by drawing boxes around visually grouped elements:

This final version is quite easily parsable and therefore it’s easy to draw boxes around the intended grouping of elements. If we apply this evaluation technique to our earlier examples, we can see that the same principle holds.

In Alphabet’s site, the “G is for Google” text is closely associated with the beginning of the note “As Sergey and I wrote.” Additionally, the signature and signature label are grouped, with ample space above them, as to make clear that the signature is one unit that is distinct from the note.

Looking at Columbia’s website, we find quite the opposite. It’s hard to draw meaningful boxes, and when we do, they’re very tight to each other, often overlapping.

Space should be used to make several elements distinct: the search box from “Email” and “Quick Links”, the dark blue bar at the top from the light blue sidebar and the content, and the image gallery from University news and events. See my simple mockup below as an example:

These general principles of space can help sketch out a basic layout, but when it comes to the details of precise positioning, things can get tricky.

Grids can help you place elements precisely.

The word grid here can be a bit misleading. In the context of web design, a grid is a set of columns that can be overlaid on top of a page. Elements on the page are typically sized to take up one or more columns. In between columns, we can place a “gutter,” or space, so that adjacent items are not overlapping.

Take a look at the Airbnb homepage (circa a few months back) to see how grids helped organize their design:

The principle here is consistency, consistency, consistency. Our brains are wired to notice things that are unexpected or outside normal (like a painting on a wall that’s not quite straight), and so as designers, we shouldn’t give them anything to squint at. On a grid, elements on a page make logical sense.

Notice how each image and piece of text on the page aligns with one of the grids. For example, while each row of images is a different height, they align on the grid. In the first row, each image is four columns wide, then two, then three.

Airbnb’s use of grids is unrelenting. Notice how they aligned the elements of the footer on the same 3-column groupings as the last row of images. Even the language and currency selectors (in the bottom left) are two columns wide!

By aligning the majority of our design on a grid and breaking the trend for some elements, we can subconsciously draw a user’s eye. Take the top of the page: Can you spot the elements that break the grid system?

You might have noticed that the Airbnb logo and the four links (Become a host, Help, Sign Up, Log In) are all off-the-grid. This is because the navigation is meant to be made visually distinct from the rest of the page.

Notice anything else, though? This might be a stretch, but hang with me for a second. Take a look at the booking form with the grid overlay:

It’s off! Is it an error? A lazy web developer? I doubt it. Maybe I’m giving Airbnb too much credit here, but I would bet that the positioning of the lines between the “Where,” “When,” and “Guests” inputs is intentionally off-grid, shifting your eye to the right towards that lovely “Search” button. With the rest of the site being positioned meticulously on a grid, I can’t imagine that the designers and developers overlooked the search box on the homepage.

Whether you buy that or not, I stand by that there shouldn’t be a strict formula when it comes to grids. Careful bending of the rules for visual balance or emphasis can be a powerful tool.

Grids emphasize a more general principle of design:

Whenever possible, reduce mental strain.

Many designers frame good design as reducing the amount of work that a user has to do to understand your product and take the next action. This can take several forms:

Keep copy concise (versus jargony or text-heavy):

Opinionated design (versus asking users to make decisions):

Or, taking one huge step forwards:

Whatever form mental strain takes in your design, aim to reduce it wherever possible.

3. What about color, typography, and illustrations?

While layout and organization may seem like more of a science, many elements of design are very clearly artistic. As an amateur designer, I’ve felt that developing opinions about these visual components to design comes with experience. That said, there are a few tricks that I’ve used to squeeze by:

When it comes to color, think subliminal.

Picking the right color or colors for your design can be hard. As a place to start, think about how color can subliminally affect how your user views your design.

Contrasting colors can be used to emphasize important components:

Commitment to a single color can help build a brand:

Or try to change one:

Finally, if you’re looking to pick actual hex codes, I’d recommend Jeff Hilnbrand’s article Picking Colors:

Picking Colors

Personally, I don’t trust myself to pick colors quite yet. Often times, I just steal colors I like from other brands or websites. Great artists, yada yada.

Typography can be confusing. Don’t get overwhelmed.

Often picking the right font can feel like an impossible chore:

While I tend to pick fonts and font pairs that I like from other designs, there are a few properties to keep in mind:

Contrast is your friend:

Tone is also crucial. What vibe do your fonts give off?

Don’t get too fancy. Clear, legible fonts get your point across:

Again, with typography, don’t stress. Start by noticing what you like, and move from there.

When it comes to illustration, there aren’t any shortcuts.

To me, all explanations of illustration feel like this:

I know there are some brands that use illustration to their advantage, but it can be hard to pin down exactly how it works.

While I don’t have a great answer here (no, stealing other people’s illustrations is not an option), I would recommend reading Scott McCloud’s book, Understanding Comics, which has a lot of interesting theories about how comics work.

scottmccloud.com - Understanding Comics

I particularly enjoyed his discussion on level-of-detail. McCloud explains how choice of style can make an illustration more relatable and emotional or more informative.

Design is complex. But that doesn’t mean it has to be hard.

I’m still a design-toddler, but I manage to get by with a few tools in my belt:

1. Appreciating design as the intersection of art, engineering, and people is the first step. Bad design forgoes one of these elements for the other two.
2. Clever use of space and grid systems can help you layout elements of your design. Important pieces should be made distinct.
3. Once the rest is done, you can worry about picking the right colors, fonts, and imagery for your design. Learn from other designers and find what you like best.

Hopefully, with these tools, you’ll be able to generate a first draft of whatever design you’re working on. Once you do, share it! There’s no better way to learn than friendly critique; working with others will keep you honest and refine your design.

Good luck!

In 2015, I decided to take a picture of everything I ate. Every sandwich, every chip, and every square of chocolate. For 365 days, if I ate it, I took a picture of it. When December rolled around, I had over 1,800 pictures with nowhere to put them. I couldn’t upload that many photos to Facebook or Instagram, and I hadn’t found a photo service that I liked enough to put my food photos on.

So I built a website.

It turns out, in the course of making a website for viewing 1,800 photos I ran into a bunch of interesting technical challenges, and walked away from the whole thing with a JavaScript library called pig.js, an image grid that is faster, more responsive, and easier to use than any other solution I could find. Here’s how I built it.

First: Why the easy solutions don’t work

The most straightforward way to display a collection of images on the web is to show the images in pages of rows and columns, with 3–5 images per row and 20–50 images to a page. It’s tried and true, but not a great solution for my purposes. If I post 1,800 photos in 36 pages, you can be sure that very few people are going to make it past page two or three.

You might think “A-ha! This is what infinite scrolling is for!” Most websites with lots of content use a simple tactic for simulating an infinitely long page: They display 10–20 entries in a vertical array, and when you scroll to the bottom of the screen they load in 20 more and inject them at the bottom of the screen and let you keep scrolling. Problem solved.

Well, not quite. I tried this, and it turns out no matter how you load them, two thousand reasonably-sized images on the same website will crash your web browser. The site works great as you scroll for the first minute or two, but as you keep going it will eventually get bloated and freeze. Bummer.

Finding an elegant solution

I wanted to design an image grid that displays all two thousand images on one page, without showing more than 50 or so images at a time. To do this, I would need to both load and unload images onto the page, to ensure that a reasonable number of images were on screen at once.

To accomplish this, I came up with an idea: wherever you are on the page, we should have all images within the viewport loaded, as well as some images immediately above and below the viewport, so they are visible when you scroll.

For a better user experience, it is helpful to know what direction the user is scrolling and make that buffer larger. If we are scrolling down, for example, we don’t need that many images loaded above the viewport, because they are only needed if the user changes scroll direction. If the user is scrolling down the page, the primary image buffer is below the viewport, and the secondary image buffer is above the viewport.

Images outside the viewport and outside the buffers do not need to be loaded into the page. As the user scrolls down the page, images above the viewport are removed as more are loaded below. This ensures that we have a relatively constant number of images on screen and a time.

It’s a clever solution, but not one that comes naturally in HTML and CSS. If we use a traditional “rows and columns” grid, removing a row of images from the DOM would cause the images below to jerk upwards. I thought about a way to cleverly put the right amount of padding above the upper buffer to avoid this problem, but that ended up being a huge headache. To make matters worse, alongside managing loading and unloading I also wanted the image grid to be responsive.

Enter Google Photos

I figured out a solution to this problem while scrolling through my food pictures on Google Photos. The web app choreographs a similar infinite-scroll that I wanted to build, while also allowing images to shift around smartly as you resize the page.

To figure out how they did it, I spent ten or twenty minutes fooling around in the Chrome inspector, watching as images were loaded and unloaded, and noticing how they did layout. The secret: CSS transform-based positioning.

Using translate3d for layout

The basic layout consists of a bunch of <figure class=”pig-figure”> elements inside a container, with the following CSS:

Then, once the library has injected and laid out all the images, the HTML ends up looking like this:

The entire grid is computed in JavaScript, and executed by taking <figure> elements and positioning them within their container exactly using height, width, and translate3d.

OK, so what’s so cool about this solution?

1. Loading and unloading: Because each <figure> element is absolutely positioned, we can safely remove and add new elements without affecting the position of the others.
2. Responsive sizing and layout: When you resize the window, you can update the width, height, and translate3d properties in the inline styles, and shift images around using CSS transforms.

So this much I completely ripped from Google Photos (through the Chrome Inspector). I had an idea how the whole thing worked, but the implementation proved tricky.

How it works

Reverse engineering the Google Photos image grid proved complicated. The grid consists of many rows of images, where each row has the same spacing between images and is perfectly sized to fill the container, but each row might have a different number of images, or a different height. Importantly, within each row, all of the images are the same height.

In order to size each row perfectly, we build up the row image by image, with a maximum desired row height. Because all of our images will share the same height, we can treat them as one combined shape.

While this would work as-is, it’s actually easier to use a minimum aspect ratio rather than a maximum height. Here’s how:

Let’s say the desired maximum row height is 200px. If the row is 1000px wide, that’s a total aspect ratio of 5:1. If we had just one 16:9 image at 100% width, the row would be 1000px * 562.5px. Too tall.

If we add another image to the row, each would be 500px * 281px. Still too tall.

We continue adding images onto our row until the aspect ratio of the combined shape exceeds our minimum, 5:1. In the illustrated example, it takes two landscape images, a portrait image, and a final landscape image to create a row with a large enough aspect ratio.

Then, using the aspect ratio of each image, we can compute each image’s width from its fixed height: For landscape images, their width is 169.5px * (16/9) = 301.3px. For our portrait image: 169.5px * (9/16) = 95.3px.

Now all that’s left is to update the style attributes on each of our <figure> elements and we’re done.

Making it fast

My original implementation involved running this entire algorithm every time a scroll event fired, which left me with some serious lag. In order to achieve smooth scroll behavior, I removed as much work from the scroll handler as I could.

While the selection of photos in view could change on every scroll event, the actual layout of the grid is fixed. Taking advantage of this, I separated the computation of each image size and position and the load/unload logic into two different functions:

1. _computeLayout is responsible for creating a huge list of objects, one per image, where each object contains a reference to a DOM element, as well as it’s desired height, width, translateX, and translateY values. I only call this on load and resize, when the layout needs updating.
2. _doLayout takes the latest scroll position and direction, determines the primary and secondary image buffers, and then uses the data structure created in _computeLayout to appropriately hide, show, and position the DOM elements.

In doing so, I saw a big uptick in scroll performance. This separation of concerns ensures that we’re not computing our layout many times a second.

Making it (even) faster

The next step was to make sure that the grid ran well on mobile devices as well as desktops. To do this, I looked at how Medium loads images in their articles, and brought that to my grid.

Have you ever noticed on a slow internet connection how Medium’s images load in a blurred state and then appear to come into focus? It’s not just a cool effect; it’s also a tactic for reducing page load times.

They start by loading in a ~20px tall version of the image, blown up to the actual size of the image. Then, they blur that thumbnail, creating the blurred image effect. At the same time, they load the full image, and when it’s ready, they replace one with the other by animating the thumbnail’s opacity to zero. This tactic: loading a placeholder and then loading in the full asset afterwards is called progressive loading.

José M. Pérez wrote a great blog post detailing the entire process, and wrote a super useful Codepen that both shows off the effect and demonstrates how to use filter:blur() in CSS rather than a <canvas>-based solution.

Medium’s progressive image loading tactic has an extra added benefit: Because the full image is loaded in JavaScript, I can decide what size image to load on-the-fly. On small devices, load a 240p image, and on tablets load a 480p image, etc. This ensures that the images both looks good and loads quickly on all devices. This is especially important for my grid, where I’m loading lots of images all at once. Every speed increase matters when it’s multiplied 2000 times.

Recap: Performance-first design

I believe that on the web, performance can be one of the biggest components of good design and storytelling. With pig.js, I put speed as my one and only concern for the library. It was a lengthly process, but I ended up with four core tactics for making the grid smooth:

1. Dynamically load and unload images above and below the viewport to reduce the number of elements on the page at once.
2. Make the primary and secondary image buffer different sizes, because we are more likely to load images in the direction we were already scrolling.
3. Separating out layout computation and DOM manipulation into two different functions: _computeLayout and _doLayout, only running the former on load and resize, drastically reducing the work we have to do on scroll.
4. Implement a responsive version of Medium’s progressive image loading, making on-the-fly decisions for what size image to load.

The end result? It’s pretty freaking fast

If you don’t believe me, head over to my demo page. If you want to take it for a spin, fork or clone me on GitHub.

I’ve also over-commented the JavaScript source if you’re interested in diving into the details of how it works. There‘s a lot in the source that I wasn’t able to include here: organizing the scroll & resize handlers, doing aspect ratio math while accounting for the space between images, managing CSS transitions that probably won’t complete when they’re supposed to, and the best in-source diagram I could muster. Fun stuff :)

My final result was a library with no dependencies and no feature-bloat. For a pure display of images, it’s the fastest thing I’ve used. I hope you enjoy it!

Have a question or comment? Can you think of anything that might make this run even faster? I’d love to hear from you! Leave a response here, or even better: an issue/PR on GitHub.

It’s amazing how far the hackathon community has come in just a few years. Back in February 2014, when Hackcon first kicked off in the cramped but homey AlleyNYC, the hackathon world looked very different than now. Major League Hacking had been founded just a few months prior, and the hackathon organizer community was still in its infancy.

Hackathons were popping up all across the country. Attendees were returning from larger hackathons and were starting to organize similar events at their own school for their own communities. Passionate organizers from all over worked to improve their own events, but were unable share with each other or differentiate their events. Enter: Hackcon.

The First Hackcon

The first Hackcon flipped our community upside-down. The Hackcon team realized that if they put 100 organizers in a room together, then the stories, discussions, and debates that would arise would completely change those organizers and the events they run.

With the help of my co-organizers Chris Yan and Dina Lamdany, I wrote a talk about DevFest, its values, and why ADI, the club behind DevFest, structured our event around learning, community, and creating a welcoming experience for first-time hackers. In sharing the mission of ADI at Hackcon, I found myself more strongly connected with the organizer community. For many speakers (myself included), Hackcon was their first real public speaking experience. There was a raw energy standing up in front of the room, an energy created by a group of 100 students all excited about the same thing. It’s fun to go back and watch how excited we all were to be talking on stage, finally able to share our enthusiasm with people who knew exactly how we felt.

Hackcon provided a space for organizers to share stories and work to improve hackathons. It was a platform for first-time organizers to learn about the nuances of running a successful event and gave veterans a new way of looking at their own events.

Hackcon II, III, & EU

After the first Hackcon, the inter-hackathon community exploded. The Hackcon Facebook group became a resource for organizers, and MLH curated and packaged content from Hackcon, making it accessible to future organizers. The Hackathon Hackers Facebook page was founded in June 2014, with the mission of bringing the entire hackathon community closer together. I remember being inspired by how Hackcon and the organizers I met there had changed how I thought about DevFest, and gladly accepted an invitation to join the planning team for Hackcon II.

If the first Hackcon was about creating a network of student organizers, then Hackcon II was about sustaining it. Set in Livestream Public in Brooklyn, NY, this Hackcon embraced a more discussion-focused format, with selected talks and a continued focus on community events. Talks focused more on how we can work on the problems hackathon organizers face. Discussions dove deep into unsolved issues, like how to make events more inclusive, how to deal with crisis situations, and how to build hacker communities.

As hackathons spread internationally, so did Hackcon. That August, Hackcon EU was the first Hackcon outside the United States. It brought organizers from across Europe and the world together to discuss how running a hackathon is a unique challenge outside of North America.

As the team behind Hackcon, we knew that our most important job was to create spaces that would stir conversation between attendees. That focus on conversation and community building became the entire thesis of Hackcon III, which had unconference-style discussion groups that were formed on the spot, led by attendees and organizers alike. Held in July at GitHub HQ in San Francisco, Hackcon III established Hackcon as an annual summer event.

Hackcon III was in many ways a changing of the guard. Most of the speakers at the first Hackcon were seniors or recent grads, and it was clear that a new wave of organizers was growing. It was amazing to meet so many new and first-time organizers last summer, and hear about how they saw their events in a different light than the organizers just a year or two older than them. With Hackcon IV, our team wants to put the spotlight directly on them.

Hackcon IV: Campground Edition

Hackcon IV will be radically different from the Hackcons of years past. First and most noticeably, it’s being held in Estes Park, CO, on a beautiful campground, with plenty of natural beauty all around. By removing attendees from the normal rush of a city setting, we will give them space to engage more meaningfully with each other, and hold even more impromptu conversations.

We’re also looking to empower even more first-time speakers at Hackcon IV. For everyone who applied to speak, we’ll be offering consulting on how to structure and deliver their talks. I hope that all of Hackcon IV’s speakers have the same experience I had in 2014. Speaking is both incredibly scary and tremendously empowering. It both gave me confidence in my work at Columbia and started conversations I could never have had otherwise.

Finally, because we won’t be hosting Hackcon IV in a city anymore, we’re upping our game when it comes to community bonding events. While we don’t want to spoil the surprise, it’s safe to say we’ll be taking full advantage of our time out in nature.

It has been a huge honor to help think about how the next generation of hackathon organizers will change our community and the events we all know and love. I can’t wait for everyone to share in what the team has come up with this year. It’s going to be great!

All photos courtesy of MLH.

Hackcon: The Story So Far was originally published in Major League Hacking on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s not hard to tell a good website from a great website. You can feel it. While most designers consider proper word choice, typography, and spacing, there are some details that are often forgotten. This is a list of tweaks to consider whenever you build a website. Put together, these tips can go a long way towards making a website feel polished.

I. Use Color to Extend Your Brand

When used correctly, color can make your site more immersive and help you better communicate your brand.

Text selection styling

Read more on CSS Tricks.

One easy way to add a little extra punch to your website is setting a custom selection color, changing the stock default semi-opaque blue background when you highlight text to something more exciting. Here’s how:

::selection {
    background-color: #FFDD33;
    color: #222222;
}

::-moz-selection {
    background-color: #FFDD33;
    color: #222222;
}

Chrome Theme Color

Read more on Google Developers.

Chrome for Android allows developers to change the color of the URL box and status bar to fit our website, by changing the theme color. It can be set to any hex value using one simple meta tag:

<meta name="theme-color" content="#000000">

For colorful or dark-themed websites in particular, changing the theme color of a site can make it more immersive.

Overscroll Color

On some web browsers, like Chrome and Safari for Mac, users can use inertial scrolling to scroll beyond the top of the page and below the bottom of the page, a behavior called overscrolling. This behavior is not a web standard, rather it is defined independently by each browser that implements it. Most browsers do now allow developers to customize this behavior at all but some do (Chrome and Safari for Mac, for example). To control the overscroll color of your page, simply set the background color of the body tag:

body {
    background-color: #3399FF;
}

Especially for simple designs, with large blocks of solid color, the correct overflow color can help emphasize the hero content on your site.

Another option would be to disable overscrolling entirely using CSS or JavaScript. I wouldn’t recommend it because it can be confusing, but it isn’t a bad option.

II. Rewarding Interaction

On a web page, interaction is dialogue with your users. Here are some simple ways to make your site more conversational:

Hover, focus, active, and tap states

Read more on Google Developers.

There are many ways to interact with an element, and you may want to react to these interactions differently. Elements can be hovered over (using a mouse), focused (using the tab key on your keyboard or a screenreader), made active (when pressed), or tapped (on a touch device). You can use pseudo-class selectors to style these states:

.btn {
  background-color: #0087F7
}
.btn:hover {
  background-color: #006DDE
}
.btn:focus {
  background-color: #0053C4
}
.btn:active {
  background-color: #0039AA
}

On devices that allow this to be overridden, there is a highlight color that appears when you tap the element. Many choose to hide it entirely:

.btn {
    -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
}

Transitions

Read more on Mozilla Developer Network.

Once you have created different visual states for hover, focus, and active elements, it’s important to consider transitioning between these states. The most basic CSS transition syntax is as follows:

transition: [delay] [easing] [property];

For example, to put a subtle transition on all properties, you would include:

transition: 0.3s ease all;

FastClick

Read more on FastClick.

Making your website fast and reactive on mobile devices is extremely important. One way to make every part of your site feel a little faster is to use FastClick, a JavaScript library that removes a 300ms delay between the physical touch of the screen and a click event being registered. Many touch browsers insert this delay in order to determine whether or not a touch is a tap, drag, or long press. For most of your site however, this won’t matter, and you can safely remove it.

Implementing FastClick is quick and easy:

<script src='/path/to/fastclick.js'></script>
<script>
    window.addEventListener('load', function() {
        new FastClick(document.body);
    }, false);
</script>

Edit:
On some browsers, it is also possible to remove this delay by disabling zooming using meta tags, although this behavior is new and may not be reliable.

<meta name=”viewport” content=”width=device-width, ..."> 
<!-- OR -->
<meta name=”viewport” content=”user-scalable=no, ...">

Both using FastClick and meta tags disable double-tap to zoom, which may be an accessibility concern. Another option is to use the currently not well-supported touch-action property:

.btn {
    touch-action: none;
}

Thanks to Chen Ye for this note!

III. Keeping Consistent

There’s nothing more embarrassing than having your site look different on different devices. Here are some tips to make sure your design is consistent across browsers and screen sizes:

CSS Resets

Read more on Meyerweb.

Most browsers include a set of default styles (font size, margins, input appearance, etc) that are applied to web pages that don’t override them. With a CSS reset, you can override these default styles, giving you the same base set of element styles to work from, no matter the browser.

The most popular CSS reset is Eric Meyer’s Reset CSS. It’s short and sweet, and will handle the vast majority of browser defaults.

Edit:
Another great option is to use Normalize.css, which aims to “Preserve useful browser defaults” and make them the same in all browsers, rather than unsetting all styles like CSS resets do. Read more about the difference here.

Thanks Stefano Contiero for the suggestion!

Form Styles

Read more on Google Developers.

Eric Meyer’s Reset CSS doesn’t cover everything however. There’s a wide variety of default styles that web browsers add to form inputs and buttons, which can be challenging to compensate for.

For example, it’s pretty rough when you think your form looks good and then iOS’s idiosyncratic default stylesheet messes that up:

There are a few ways to deal with these form issues. Some developers use yet another CSS reset, like this one, or this one, or this one. Others feel that these resets are too broad, and aren’t a good idea, opting to test their website on different devices and do one-off bug fixes. Either way, the goal is the same: your forms should look the same on all devices.

Conclusion

Hope you found something new to think about for your next site! For your reference, here’s the TL;DR:

Use Color to Extend Your Brand

• Text selection styling
• Chrome theme color
• Overscroll color

Rewarding Interaction

• Hover, focus, active, and tap
• Transitions
• FastClick

Keeping Consistent

• CSS resets
• Reset form styles

Did I miss anything? Have a good resource to share? Post a response here or let me know at @danrschlosser on Twitter.

Making websites just got a lot easier.

When it comes to web development, there’s a lot to learn.

Maybe someone has told you to use vendor prefixes for cross-browser compatibility, to minify your code to decrease load time, or to use a linter so that your CSS and JavaScript follows best practices. Maybe someone has ranted about how using SCSS is better than using CSS, or about why templating engines are all the rage right now. Or maybe this is the first you’re hearing of it, and you have no idea what setup to use.

Trying to figure out “the right way” can be intimidating. Respect your sanity and your time: Gulp will save both.

Gulp is a program that you can use to automate everything about developing on your project. It’s called a build system, build tool, or task runner. Instead of having to memorize eight obscure commands to get your project running, Gulp lets you use one. Gulp’s philosophy is that it should be easy to combine a bunch of programs together into one unified task.

Gulp does everything short of writing your code for you.

It’s amazing! Since I’ve learned to use it my productivity has skyrocketed, and so has my code quality.

So how does it work? The trick with Gulp is that it does very little on its own. All its power comes from the massive library of plugins that can be chained together with relative ease, using configurations in a file called “Gulpfile.js”. Let me give you an example:

When Jeff Hilnbrand and I started Minimill together I knew that we’d need a solid web workflow to be efficient and consistent, and so I built an open source project template that uses Gulp. Our Gulpfile allows us to:

• Install the project in just three commands.
• Use Handlebars.js to keep our HTML organized into templates and partials.
• Use SCSS to keep our CSS organized into logical pieces.
• Use Autoprefixer to automatically insert browser prefixes where necessary to handle cross browser compatibility.
• Use Browsersync to automatically launch a development version of our website, reload the page whenever we change the HTML, and inject changes to CSS, JavaScript, and images with needing to reload.
• Use HTML Minifier, CSSNano, UglifyJS, and ImageMin to compress and optimize our HTML, CSS, JavaScript, and images, respectively.
• Use SCSS-Lint, JSHint, and JSCS to perform linting and style checking on our SCSS and JavaScript files.

All with one command from terminal:

gulp serve

It’s hard to describe how empowering Gulp can be to those who haven’t tried it. It takes all of the hassle, stress and confusion away from web development, letting you harness the power of its plugin library without worrying about how to use each individual program. With a streamlined build process and more logical Gulpfile syntax, it gives build tools a major usability facelift.

Get started now!

Sold? Drop what you’re doing and try out Gulp. You’ll thank yourself later for all the time you’ve saved. Here’s how:

• Clone my project template, and mess around with it! Follow the installation instructions in the README file and see what it’s like. If you have any problems, feel free to tweet at me or file an issue.
• Try this tutorial to get started with Gulp. It’s easy to follow and doesn’t skip any steps.
• Start from scratch using Gulp’s 4-step installation guide and then install whatever plugins catch your fancy.

Alternatives to Gulp

There have been plenty of build tools before Gulp that may be better suited to your project’s needs. Here are two popular alternatives (and why you might choose Gulp instead):

Make

The oldest build tool that’s still in active use today is Make, a program that comes preinstalled on Linux and Mac OSX. Make is built for projects that compile in pieces, especially C and C++ projects. In your Makefile, you create a tree of dependencies and write out bash commands to build each file from its parts. If any of a file’s dependencies are modified, Make knows to run only the commands necessary to rebuild the final product from the changed files.

Make has no concept of a “Make plugin” because all it does is run bash commands, so anything you could do from your terminal you can do from Make.

It’s a popular choice for many developers and an important tool to learn. But if you’re working on a web project, Gulp makes it easier to perform web development-specific tasks.

Grunt

The closer relative to Gulp is Grunt, a build tool that popularized a plugin-based system. Unlike Gulp, Grunt’s plugins are designed around commonly-used tasks, each one configured in the Gruntfile.

Gulp was designed to alleviate many of the aggravations associated with Grunt. For starters, Gulp uses Node.js streams to connect each plugin to the next. This means that tasks run faster on Gulp because streams remove the need to create temporary files at each step of the build process. Gulp’s “code over configuration” philosophy makes Gulpfiles more intuitive than Gruntfiles. Instead of writing lines and lines of configurations (as is the standard for Gruntfiles), Gulp will have you creating tasks using the plugins as building blocks, streaming one plugin into the next. For many, it’s a matter of preference, but if you’re picking your first build tool, Gulp is the way to go.

I spent last weekend at Hackcon, the hackathon organizers conference. On Sunday, I was tasked with taking notes for a workshop entitled “Being Different,” which spun out from Jeff Hilnbrand’s talk on the same subject. Instead of publishing my messy notes, I’m publishing a summary of our discussion, and some points I didn’t get to make day of.

Dan Schlosser on Twitter

"We're just changing the metadata of our hackathons: title, location" @jhilmd of @bitcmp #hackcon

The general zeitgeist going into the “Being Different” Hackcon workshop was that hackathons are all pretty similar: 24–48 hours, sponsors, prizes, apps, food, caffeine, and probably a midnight surprise. Each event might have it’s own little spin, but for the most part we were all working off the same model. This model, while tried and true, has several problems in it, which prompted our group to think about how to change it. The core of our discussion centered around two questions:

1. Why are hackathons so similar?

At first, the answer seemed to be simple: The model works.

Hackathons haven’t changed drastically since the first generation of student hackathons (hackNY and PennApps) largely because these events were so successful. In our discussion, many organizers recalled experiences of attending a hackathon early on in college, and seeking to bring the event back to their schools. Hackathons have an inspirational quality that makes attendees want to throw hackathons at their own schools. The answer is simple: organizers think hackathons are pretty much fine as they are. Problem solved, right?

Not quite. Hackathon organizers aren’t blind. They see room for improvement and growth in the hackathon model, but there are other factors at play that make organizers resistant to change. Here are a few justifications that were made for the similarities between hackathons:

• Drastically different events might make hackers from other schools less likely to attend.
• Changing your event can backfire. (One organizer told a story about how hackers complained when they threw a hackathon and didn’t invite sponsor representatives into the hacking space.)
• There’s no reason to differentiate because our local communities have not been exposed to hackathons, so they don’t realize that the event is the same as one from another school.

While these concerns may seem justified at first, they have the same logical flaw. They assume differentiation for the sake of differentiation, rather than differentiation for some larger purpose. Finding that larger purpose became the second question.

2. Why should hackathons differentiate?

In my opinion, this was really the wrong question to ask. For the hackathon community, differentiation shouldn’t be a goal. We shouldn’t be fighting over attendees; there are way too many students eager to attend hackathons for events to feel the need to compete. No organizers should elect to arbitrarily change their event to stand out in the crowd.

In our discussion, we discovered that many of us hadn’t thought carefully about why we were organizing hackathons in the first place. Without thinking through some basic motivations, the events become nothing more than copies of each other with slight variations. Throwing a good hackathon doesn’t mean looking for ways to differentiate, it means taking a step back an evaluating what the community needs.

First, find your audience and get to know them.

Are you hosting a hackathon for first timers? For burnt out veterans? For entrepreneurs? For designers? Depending on your audience, you should make different decisions about how long your event is, whether or not you have prizes, etc. In our discussion, many of our disagreements stemmed from the fact that we were organizing events for different kinds of people.

Make sure you know your scope.

Hackathons change lives. They create Computer Science majors, they make software engineers, and they can also do the reverse. A single bad experience at a hackathon can color someone’s view hackathons and the tech industry as a whole.

Many organizers had the attitude that by bringing the traditional hackathon model to their school, they were making an exclusively positive impact on their community. However, without addressing issues of inclusivity, health, and intimidation that come with that model, an organizer could unknowingly do great harm as well.

Finally, have a vision and a value proposition.

What will attendees get out of your event? What will keep thing there for the duration? What do you want to achieve? Way too often hackathon organizers get so caught up in planning that they lose track of any vision grander than hosting a hackathon. By solidifying a value proposition for your attendees, you can ensure that they leave the event satisfied.

Some examples

Here are examples that were brought up of events that differentiate for the right reasons.

hackNY

As Shy Ruparel will proudly tell you, hackNY has remained relatively the same for the past five years. Despite this, hackNY remains one of best hackathons out there. It doesn’t have the best prizes, or food, or anything really. The hackNY team has crafted the right event for those that attend it. It goes to show that being different isn’t always the solution. Execution on the basics goes a long way, especially at a time where hackathons gimmicks are all too common.

DevFest

Three years ago, DevFest was a week long hackathon that intended to give participants the time they needed to build high quality products rather than basic hacks. Not a bad idea at all, but it was a bad fit for the Columbia community. With the Computer Science major ballooning in size, there was an influx of inexperienced programmers on Columbia’s campus. In 2014, ADI pivoted DevFest to focus purely on education, moving the hackathon to the last day of the week, allowing for the rest to be spent on workshops. This refocus made the event take off, allowing ADI to reach hundreds of students that would have otherwise felt unqualified to attend.

Building a better hackathon

My biggest realization in this discussion was that when we talk about improving hackathons, “different” is a red herring. So was Jeff wrong to say that we need more differentiation in hackathons? No. We shouldn’t aim to be the best in some category, rather we should aim to be the best event for our attendees. There are too many ways to do “different” wrong to allow that to stand as a goal strive for. Instead, lets focus on a more straightforward approach: finding an audience and serving them. We need hackathons to change, but we definitely need them to change for the right reasons.

Too often, I realized, we argue about how hackathons should change or what they should be, without realizing, that not all hackathons serve the same purpose. Computer Science communities differ greatly between schools, and so it’s only natural that hackathons should bend to accommodate them. If organizers are upfront and transparent about their values when organizing an event, we can hold them accountable for not taking the hackathon model for granted.

Have a Hackcon story?

Did you have a memorable experience at Hackcon? Write about it in a response to this post, I’d love to hear stories from conversations I missed out on.

I thought it might be nice to also explain how to check if LinkedIn has your contacts on it’s service, and how to remove them if they do. While we go, why don’t we count the dark patterns?

Step 1

Go to LinkedIn.

(Dark patterns: 0)

Step 2

Hover on the person with a plus next to their head, and click the “Add Connection” header. Note that clicking other links in the dropdown may take you to the same place.

(Dark patterns: 1)

Step 3

Click the small, hard to find “Manage imported contacts” link in the top right of the new page.

(Dark patterns: 2)

Step 4

Scroll all the way to the bottom this next page. Note that the list of contacts itself is scrollable, so it’s very possible that you wouldn’t even figure out that it was possible to scroll past it.

(Dark patterns: 3)

Step 5

Click the “Delete selected contacts” button hidden at the bottom of the page, instead of the “Invite selected contacts” button which has been visible the whole time.

(Dark patterns: 4)

Step 6

Click “Delete” in the popup window.

(Dark patterns: 4)

Step 7

Wait for the deletion to complete. If you close the browser tab, it may not complete.

(Dark patterns: 4)

Step 8

Celebrate!

(Dark patterns: 4)

Congratulations, you’re done! Let’s see how we did:

Number of Steps: 8
Number of Dark Patterns: 4

This process is far more difficult than it should be. When I first found it, it took me several hours of digging. Hopefully this helped you!

If you’re interested in how these contacts got there in the first place, and haven’t read my other piece yet, check it out below!

LinkedIn Dark Patterns

In December of 2013, I closed my LinkedIn account. As I retold in an emotional post Facebook post, I had discovered that I had been sending those annoying “Dan Schlosser has invited you to join LinkedIn” emails to my friends. Confused, I spent several hours digging around in LinkedIn settings and menus to figure out why.

It turned out that when I made my account years earlier, LinkedIn had tricked me into importing my address book. If they had used the contents of my address book just to suggest contacts on LinkedIn, I might not have minded, but they went further. On the “People You May Know” page, LinkedIn had inserted a few buttons to invite email addresses from my address book to LinkedIn, and made those buttons look a lot like people already on LinkedIn that I could connect to. The difference between these two kinds of buttons was negligible, and as a result I had been sending spammy emails when I thought I had been sending connection requests.

This feature has since been refactored (why I felt comfortable joining the service again recently) and these two buttons do not show up next to each other anymore. Instead, they make it one-click to invite every one of your contacts unknown to LinkedIn to the service.

It also shows up in the contacts manager, where it only takes one click to both connect with every person in your contacts who is on LinkedIn, and to send a “Join LinkedIn” email to every person in your contacts who isn’t.

This system, setup to trick me into inviting people in my contacts to LinkedIn, is called a dark pattern. In UX design, a dark pattern is design that works against users. It might trick them into doing the wrong thing, or just confuse them to the point where they can’t figure out how to do something that the designers don’t want them to do. This could be making it hard to delete a user account, or in LinkedIn’s case, making it really hard to use the service without importing your entire address book.

In order to bring LinkedIn’s spammy practices to light, I’ve walked through all the steps needed in order to sign up for and use LinkedIn without importing your address book. Check it out, it’s near impossible. Along the way, I’ll take a look at how LinkedIn uses design to trick its users.

Account Creation

For most people, this is where they get you. The big offense throughout this whole process is conflating OAuth with address book importing. Take a look:

The Landing Page

This page is pretty simple. There aren’t any dark patterns at play here, unless you count the User Agreement, Privacy Policy, and Cookie Policy that joining the service entails. This page is clean.

Basic Profile Info

This page is also clean. LinkedIn uses this info to connect you with other people that work at your company, or went to your school, and that’s to be expected. They give a nice explainer in the box on the right side. Simple and straightforward.

The First Dark Pattern

Here’s where things get messy. After filling out basic profile information, LinkedIn asks you to “Get started by adding your email address.” There is a note explaining what this button does, but because it is put in light gray text next to a bold blue “Continue” button, they get most people to blindly click ahead. This is definitely a dark pattern. In fact, it’s really a lie. This page is not for “adding your email address,” it’s for linking address books.

OAuth Dialogue

After clicking the blue continue button on the previous page, the Google OAuth popup appears. Note that one of the permissions being granted is “Manage your contacts.” Google hasn’t done an amazing job highlighting this fact, but it’s pretty good. If someone were to click “Accept” at this stage, the user’s entire address book would be imported into LinkedIn. This is where I went wrong the first time. Here, LinkedIn is taking advantage of the fact that Google uses the same OAuth popup for address book import as they do for the “Log in with Google+” dialogue. LinkedIn knows that most users just click through these windows without reading the permissions.

The Failure Screen

If the OAuth flow is cancelled, an error appears. It reads “We are unable to import your email contacts. Please try again later.” The continue button brings the OAuth window open again; you need to find the tiny “Skip this step” link at the bottom right to proceed. Moreover, the link is placed outside of the blue box which ostensibly contains all relevant info or controls. This page is excellently designed, but it’s designed to trick users.

Are You Sure?

Just in case you found the hidden link by accident, LinkedIn asks you to confirm that you do indeed want to skip the address book import. Notice that “address book” or “contacts” show up nowhere in this popup window. Instead, you’re prompted to “Find now.” Wouldn’t it be nice if LinkedIn gave this kind of warning dialogue when you click the button that gives them your entire address book?

Confirm Your Google Account

This next page is pretty insulting. The text asks the user to “confirm” their Google account, and “verify” their email address, but what LinkedIn is not saying is that clicking “Confirm my Google account” will sync the user’s address book with LinkedIn. The user has already indicated on the previous page that they do not want to sync their address book with LinkedIn, but they try again anyways.

We Could Not Confirm Your Email Address

If we cancel out of the OAuth dialogue on the confirmation page, a warning appears indicating that a confirmation email has been sent instead. For once, the blue button on the page doesn’t import all your contacts, and instead links to Gmail.

Confirmation Email

This is the email that LinkedIn sends to confirm your email address. If you click the yellow button, it links to the next page shown.

Add Your Email Address… Again?

Following the link in the email shows a success message which reads “Thanks for confirming your email address…” right next to a box asking you to “Get started by adding your email address.” Recognize this screen? It’s the same one as before. Once you confirm your email address, they try a third time to get you to “add” it. After the first two times that the user explicitly skipped adding their address book, it is overwhelmingly clear that they don’t want to. This page is included just in case it happens to trick users into clicking “Continue.”

Are You Sure… Again?

Just like before, if you click “skip this step” at the bottom of the page, a warning popup appears making sure you didn’t skip accidentally.

Get the App

On the next screen, they offer to send you a link to download the LinkedIn mobile app. If they don’t get your address book on the web, maybe they’ll get it through your phone.

Finally done

There we have it, finally signed up and signed in to LinkedIn. The next part of the new user experience is filling out your profile. Depending on how you count, LinkedIn tries to import the user’s address book three to eight times. It shouldn’t be this hard to sign up for a product without giving away any unnecessary information.

The New User Experience

In software design, a new user experience, or NUX, is content that is driven to make the service valuable for new users who likely don’t have any connections or friendships on the service. For my experience with LinkedIn, this started with a welcome email. Let’s take a look at how they use dark patterns to get you to sync your address book, even if you made it this far without doing so already.

The Welcome Email

It turns out that the “Get Started” link and the “Stay Connected” link both go to two different screens that both do the same thing. First, let’s follow the big yellow “Get Started” button, as I’m sure that’s what most people clicked.

Every Career Needs A Strong Network

Big surprise. Yet another way to import our address book. In fairness, this is the page where the copy is most descriptive of what’s happening. The sub-header reads “Build yours by looking for your email contacts” and there isn’t any mention of “adding your email address,” which would have been very confusing. Again, we see a big blue “Continue” button that just begs to be clicked.

Also, LinkedIn is using traditional NUX designs to trick users into thinking that this is more of a tutorial than an attempt to get the user’s address book. Notice the dots up in the far right, and the solid blue background? This is different from every other screen we’ve seen before. It feels different than every other part of LinkedIn we’ve experienced so far. For users of other web or mobile applications, this might feel like a first-time tutorial screen, where you click through the six screens that teach you what the app is, and then you get to actually use it at the end. Most users are trained to click through these tutorial screens, and LinkedIn is counting on that. In case you hadn’t guessed it, the “Continue” button launches the Google OAuth popup again.

You Don’t Want A Strong Career?

If you managed to find the skip link, LinkedIn asks you to confirm that you want to skip importing your address book. Once again, the blue “Continue” button in the popup is actually the “No never mind, I do want to give you all my contacts” button. We’re looking for the “Skip” link. This is a textbook dark pattern. In the last screen, the skip link was hidden on the right, and the continue button was highlighted on the left, where it’s more noticeable. Here, that positioning is flipped, so if you happen to find the skip button, you have to reverse your thinking, and notice that this time the skip button is on the left. To add insult to injury, the wording of the question is such that “Continue” seems like the answer we want. The word “Continue” has an affirmative connotation for most people, so when being asked “Are you sure you want to skip this step?” it seems unnatural that “Continue” doesn’t get us what we want.

Lets review everything this popup does.

1. The big blue button is the “give us all your contacts” button.
2. The skip link we’re looking for (and have already clicked once) has been moved to the other side of the button, which confuses the left-right association that was subconsciously built in the previous screen.
3. The popup essentially asks “Are you sure?” and “Continue” here means “No,” which feels unnatrual.

Pretty clever.

The Rest of the NUX

The rest of this flow is harmless. If you happen to make it through the previous screen without getting fooled, the rest of the new user experience screens serve to connect you with more companies or interests, or to get you to download the mobile app.

Done with the NUX?

So we’ve finally finished, and we’re on the LinkedIn homepage. Now this page is a total mess design wise, but I’d like to draw attention to the “Welcome, Dan!” card that shows up, which has a big yellow “Continue” button. By now, I’m sure you know where that goes.

The only solace I can find here is that the page is so cluttered that I doubt that most people would end up finding this link on the first time. Thankfully this card sticks around for a while…

What About That Other Link in the Welcome Email?

Remember the “Stay connected” link? Turns out that takes you to a completely different screen that also gets you to import your address book.

Yet Another Way to Add Your Email Address

This page is no longer new user experience, rather it’s the permanent home for the “add your email address” flow. We see a return of the original copy which hides the true function of the “Continue” button.

A Final Word

I hope you understand now that when you get spammy emails from friends inviting you to LinkedIn, it’s LinkedIn’s fault, not your friends’.

Many smart people have written about how dark patterns damage brands, and are harmful to user trust. I can unequivocally say that LinkedIn’s address book import design is harmful to their brand, even if it’s better for business in the short term. They make money when their network is more strongly connected, and so it is in their best interest that users connect their address books.

LinkedIn isn’t the only social network that uses dark patterns to grow their social graph, far from it. However, LinkedIn is an example of doing this to the extreme. It made me quit the service for two years, and has harmed my image of the company. Dark patterns are bad design, and bad design is bad business. I guess I’m disappointed that LinkedIn doesn’t agree.

PSA: If you’re wondering if LinkedIn has your address book imported, I wrote a short tutorial on how to find out, and how to remove it. Check it out here.

A few days ago, I migrated my personal blog to Medium. From now on, I’ll be publishing here instead of on my website. I had some good reasons to stay off it for so long, but I’m glad that I switched.

I’m a big believer in personal websites, especially self-hosted ones. My website is where I first started messing around with web development, and working on it has taught me a lot of what I know. I’ve learned basic system administrator skills, Flask, HTML, CSS, and JavaScript. Part of hosting my own website was making a blog, which meant setting up a content management system (in this case, a folder full of markdown files), and building the blog from scratch. I learned a lot doing this, I would whole-heartedly recommend the process to anyone who is considering it. When things broke, I was the only person to fix it, and they weren’t always easy problems to solve. Self-hosting taught me self-reliance as a web developer.

Over time, however, managing my blog has become less of an adventure, and more of a task. I’m busy maintaining one CMS, I’d rather not maintain two.

When I considered switching to Medium, however, the site’s branding turned me away pretty quickly. Medium wants to be a service that “connects people, stories, and ideas that matter to you.” It’s a place for bright minds to share brighter ideas, and it’s a space where people talk about serious topics, and I’m not sure I fit in.

The Medium about page demonstrates this pretty clearly, where the word “stories” is almost always accompanied by “ideas”. This branding decision is very conscious, from the article layout to the typography. On Medium, people are judged for the quality of their ideas, rather than what they look like or how fun their summer vacation was. For this reason, it has a leg up over many social networks. The problem is that a community of thinkers can be intimidating.

I’m hesitant to put my writing onto a service where everything is taken so seriously. I believe that I have valuable thoughts to offer the world (if I didn’t, I wouldn’t publish my writing at all), but for me, publishing on Medium feels presumptuous.

Medium’s sell to writers is audience. By publishing on Medium, I can get access to new readers that would never have gone to my personal blog. But then the question becomes: Is my writing worth discovering?

My blog posts don’t necessarily fit in next to other articles about technology, never mind articles tagged with “BlackLivesMatter”, “Women In Tech”, or “Education Reform.” These topics are serious; they demand respectful discussion and Medium facilitates that. The problem is that I’m not sure if my writing falls into that category. I blog seriously about technology and design, yes, but I can also be a little silly, and that’s important to me. I am serious about my writing, but my writing isn’t always serious. Because of this, I can’t help feeling a little out of place.

This branding problem has kept me off Medium for over an year, but recently I’ve reconsidered. For me, writing on Medium means being taken a bit more seriously, and I think I’m okay with that. I’m still not sure my writing fits in here, but I’ll have to wait and see.

Most of all, moving to Medium means putting pressure on myself to do more writing. I’ve realized that publishing on a personal blog doesn’t mean much if your blog doesn’t have followers, and most people don’t follow blogs these days. My writing is more discoverable now, and I’m okay with that.

It makes sense to switch to Medium and voice my concerns instead of yelling them into a self-hosted void. There’s a lot to love over here. While the Medium editor is far from perfect, I appreciate that it’s a hard problem and that they’ve done a pretty good job. I prefer tools with more customizability, but good design has constraints, so I’ll concede. Yes, I’ll miss syntax highlighting and underlining and picking my own fonts, but I won’t miss worrying about uptime or cross-browser compatibility.