Knowing the right way to export an SVG (scalable vector graphics) file can be tricky, especially if your goal is to animate it later. When doing my own research on the subject, I quickly realized there weren’t a lot of resources to pull information from.

Cue the process of trial and error that totally doesn’t make you want to throw your laptop out the window.

After several attempts at getting Illustrator to generate the most optimally structured code for custom CSS animations, I finally found the settings that work best. Since information on this topic is scarce, I’m sharing what I’ve learned via a handy 13-step guide.

Heads Up!

This step-by-step guide is current with Adobe Illustrator Version 23.

To view which version of Illustrator you have, open your program and click the ‘Illustrator CC’ tab located in the top navigation menu. Then, click the ‘About Illustrator…’ option.

A window with some information should pop up. I’ve included a screenshot of what is displayed on mine and have circled the version number in red.

If you’re running the same version as me, great — you should be able to follow these steps with no problems! Going forward, this method should be compatible with most versions of Illustrator (unless Adobe releases changes that alter settings used here). If you’re running an older version and this guide works, let us know in the response section below.

Alright, now that we’ve got that squared away, let’s take a look at the steps!

The Step-By-Step Roadmap

When following this guide, pay extra attention to Step 8. There are two options available that are dependent on your preferences.

Step 1: Select all graphics on the artboard [shortcut keys: command ⌘ + a on Mac/ctrl + a on a PC]. To achieve this without using shortcut keys, find the ‘Select’ tab in the top navigation and choose the ‘All’ option.

Step 2: Click the ‘Object’ tab in the top navigation menu.

Step 3: Click ‘Expand Appearance’. This converts design elements like paths, lines, etc. into editable vector shapes. If this step is skipped, you may see some transparent gray lines or shapes in your image that are caused by a number of design elements that were made in Illustrator.

Step 4: Click the ‘File’ tab in the top navigation menu.

Step 5: Hover over the ‘Export’ option and click the ‘Export As’ option.

The following window will be displayed. Steps 6 through 9 are to be done in this window.

Step 6: Name your file and choose where you’d like to export the file.

Step 7: Find the ‘Format’ dropdown menu at the bottom of the window and select SVG (svg).

*Step 8: Check the ‘Use Artboard’ option below the Format dropdown menu if you wish to include only the graphics inside your artboard. If you wish to include graphics that extend outside of the artboard, leave this unchecked.

Step 9: Click the ‘Export’ button to continue.

The following window will be displayed. Steps 11 and 12 are to be done in this window.

Step 10: Adjust the settings as follows:

• Styling: Internal CSS
• Font: SVG
• Images: Embed
• Object IDs: Layer Names
• Decimal: 2
• Leave the ‘Minify’ and ‘Responsive’ checkboxes unchecked.
  If checked, Illustrator would compress your code by removing any unnecessary characters like white spaces or new lines. This is not an ideal code structure to work with as you would have to separate the code yourself.

Step 11: Click the ‘OK’ button at the bottom right of the window.

Step 12: Locate the file from wherever you saved it. This was done in step 6. In my example screenshot you can see that my awesome.svg file was saved to my desktop.

Step 13: Right click the file and open it in your text editor.

And BAM, you now have the most optimal SVG code ready for custom CSS animations!

Achievement Unlocked

Now you can begin sifting through the code blocks to identify what is what.

To bring this article full circle, here are three workflow options for finding which part of the graphic belongs to which particular block of code:

Option 1

If your designer named their layers, then this process will be easy. With the file opened up in your editor, search for the layer name and then write a comment above it to label what it is for future reference.

Option 2

If your designer didn’t name their layers, you can name them yourself in Illustrator, save the file and then export. From here, you can follow through with the above paragraph’s comment/label workflow.

Option 3

If for whatever reason you’re working with unnamed layers, the labelling process will be a bit longer, but still doable. You can begin by commenting out code blocks and seeing which element was removed from the image. Once identified, uncomment the code block and label it with a comment above it. Do this for the rest of the file until everything is labeled.

After all of the code is labelled, identify which graphics you want to animate. Then, remove the commented labels for graphics that you will not be animating to reduce file size.

From there, you can start to write the custom CSS animations in between the style tags and add their respective class to the code as you test the animation and move along to the other graphics you want to animate.

Finished Animated SVG Example

Below I’ve included an example of a finished animated SVG that I did for a recent project at Envy Labs. Feel free to look at how it’s structured and play around with the different animated elements!

Did this article help solve a problem you were experiencing? Did you create a really awesome animated SVG? Let me know in the response section below!

Also, if you have any questions about something mentioned in this article that you want me to go more in-depth on, share them below! There may be other readers who have the same question and would benefit from having that dialogue documented here.

About the Author

Casey Ocampo is a Front-end Developer at Envy Labs, a data-driven web application consultancy with a focus on interactive training and visualization.

If you’re interested in hiring us or want to have a chat about your project, you can reach us by email at hello@envylabs.com. We’re happy to get acquainted and talk about your idea!

SVG Export Settings for Custom CSS Animations | Adobe Illustrator was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

2018 was a great year for us at Envy Labs! We hired some talented people, worked with clients new and old, traveled all across the country to attend conferences, got new office plants (and they’re still alive), wrote things on our blog, and, of course, had some fun along the way!

Here’s a quick video we put together to commemorate our year:

Thanks for watching!

Envy Labs: 2018 in Review was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

When I was in college, studying User Interface (UI) Design wasn’t an option (or at least not one that I was aware of), and that was only 7 years ago. I went to school for Studio Art and Graphic Design, which is a fancy way of saying print design. We only had one web design class available, and it consisted of W3Schools tutorials. I’ve forgotten everything covered except <> and </> (if my professor happens to read this… sorry).

Now, UI design in all its various forms (UX design, interactive design, product design, etc.) seems to be the “it” design job. It’s safe to say the Internet and all devices that use it are here to stay, which means that companies are increasingly interested in hiring people who can design for an optimal digital experience. Graphic designers have found the transition to marketing site design relatively straightforward, but styling for an application is a different beast.

Here’s a collection of pain points and helpful resources I’ve collected during my (short) journey from print to interface.

Back to Basics

Examples of graphic design:

Examples of UI design:

Design is design, right? I was confident the transition would be pretty straightforward (spoiler: it wasn’t). Having a solid foundation of typography, color, and composition (basically the seven elements and principles of design), is important, but not enough to make it a perfectly seamless switch. Though both disciplines start from a place of visual appeal, the intent of graphic design is to cause an action or feeling, while UI focuses more on the intuitiveness of a design and efficiently completing a task. Even the way you choose fonts is different (oh hey, web font licensing and delivery).

Understanding this has been the biggest challenge for me. Where once I judged websites based on how they looked, I now have to think about how they work, too — buttons, transitions, animations, icons, navigation, etc. It’s honestly a bit overwhelming at first.

Where to start?

Sketch It Out

Sketch is an industry favorite in UI design, and a great place to start. Think Adobe Illustrator, but tailored for web interfaces.

The biggest hurdle is mastering symbol creation and nested symbols. Fortunately, we’ve got you covered: Ayana, Envy’s Creative Director, wrote an article on precisely that.

Efficiency is key in design software, and Sketch definitely isn’t lacking: shortcuts, shared styles, and text styles are all invaluable for a foray into interface design. Knowing how to use them will smooth out common problems during the design process and design-to-developer handoff.

Wireframes

Initial design sketches are handy in the print realm, but my introduction to wireframes revealed how much weight they carry in the interface and experience process. Styling an entire application is a time-consuming process, and providing the means to solidify functionality and content is very helpful. Getting the team’s input in this stage is also important, as they’ll be able to steer you away from any ideas that are too time-consuming, fall short of goals, and/or are generally unnecessary.

Wireframes should be kept simple — big changes are easier to make with low fidelity compositions. Being a very detail-oriented person that isn’t used to designing in phases, this has been difficult for me because I want to design everything all in one go.

Style Guides

Brand books are a relatively standard asset in the world of graphic design, and applications have a similar concept in style guides. Style guides should be started early on in the design process and continued as you go. Teams that collaboratively work on a style guide begin on the same page with stylistic choices, and have a proper base to build on as the application and brand mature.

Before creating the style guide, it’s a good idea to design 3–4 of the website’s pages: the homepage, a page that includes forms, and an interior page (at least). By the time you’re done with those, you should have a decent idea of where the overall design is heading and what’s working vs. not working. Additionally, the start of your style guide is a good point to begin creating those Sketch symbols I was talking about earlier.

Learning is Hard

Functionality

Functionality is the chasm between graphic and interface design. Print takes something with a fixed size, focuses on appealing visuals, and seeks to compel the viewer towards a specific goal. Interfaces need the same sort of attractiveness, but provide users with the means to fulfill a number of (potentially complex) goals. Why is this button here and how is the user going to interact with it? Are there any new insights on hamburger menus, or should we stick with a traditional horizontal navigation? Where is the user taken when they click this link?

Application functionality is a series of patterns — and building your own personal library of preferred patterns through research, trial-and-error, and exploration is a time-consuming process. No, you can’t learn all of this in one day no matter how hard you try. It helps to find someone who’s willing to teach you in-person (like co-workers in my case), and there are plenty of online options, too, like Designlab, General Assembly (with a UX lean), good ol’ YouTube, and here on Medium, too.

Responsive Design

Interface design lacks any guarantees around the device size users will use to interact with your finished product. Considering all shapes and sizes (and environments — hello direct sunlight) is another fundamental shift that carries throughout your efforts. Sketch has some great tools to help with this, like the resizing constraints feature.

Perseverance

Failure happens. You’re probably not going to get it right on the first, second, or maybe even third try. This hit me right in the ego; I’m a perfectionist and used to being good at my job and knowing (mostly) what I’m doing. Feeling relatively comfortable and jumping back in the deep end is a tough transition.

I have to keep reminding myself that this is normal when learning something new and, with time and perseverance, that feeling will pass. It’s important to ask for feedback from teammates or mentors as much as possible in the learning phase in order to continue fine-tuning your new skills and knowledge.

Remember that no one on the team has all the answers, so feedback isn’t necessarily a matter of being wrong, just a way to explore different perspectives and approaches.

Final Thoughts

Transitioning from print to interfaces was much trickier than I expected, but bridging the gap is totally doable and rewarding with time and dedication. UI design is a valuable skill to explore at least once, even if you don’t plan on trading in ink and paper.

Had I known about UI from the get-go would it have changed my career path? Possibly, but I’m glad I have the foundation that I do. And I love print design way too much to give it up. That being said, I definitely plan on continuing to learn UI moving forward and am thankful for teammates who are patient and willing to help.

UI Design for the Graphic Designer was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

You’ve spent all week gathering ingredients. Testing combinations, cooking techniques, and presentations. Satisfied with the result, you shuffle your new roommate into the kitchen, stick a spoon in their mouth, and… stare until they give a response.

Reactions range from shrug to “mmm” plus a nod. Not helpful, (typically) not genuine, and not what you’re looking for to drive the recipe forward — but the fault lies with the chef.

Asking for live feedback from a deliverable is the same as shoving a spoon in someone’s face. The right sort of critique takes consideration, and it should start in an environment separate from the creator.

The delivery is a bit of process that’s remained largely unchanged since Envy Labs began its foray into software consulting. We follow four steps:

• Start with a screencast.
• Follow up with a call, especially for the first delivery.
• Provide a means for in-place comments.
• Transfer to the source of truth.

Start With a Screencast

Crab is pretty great, but handing someone a crab leg for the first time may not leave them with your appreciation (or knowledge) of the meat inside.

While images can tell a story, we anchor our deliveries with a screencast — whether it’s for wireframes, design, or code, the format conveys reasoning without the creator being present. The first line of decision-making defense.

If you’re aiming for the client to actually watch the video, commit to a set of guidelines and a base level of production value. Our tenets include:

• Length: it shouldn’t rival an episode of a television show in length. At the very least, keep it information dense.
• Script: varies by the individual — it should sound natural, but with as few tangents, corrections, and ums as possible. I usually skip a script and record the second take.
• Streaming: upload the video somewhere that makes it easy to consume.
• Walkthrough: provide a quick demonstration of any applications you’ll be asking the client to use in the review process. Don’t assume they’ve used InVision, Marvel, or something similar in the past.

Bonuses

Screencasts bring a few handy bonuses in the software world. Many development tasks — tests, performance, refactoring — aren’t immediately visible in a staging environment, but can be highlighted as part of a video.

For longer projects, they serve as a library of decisions, checkpoints, and visualization of effort.

For designers, screencasts are a good way to reveal bits of unused or outdated work. Clients can be walked through the process, without offering up reviewable versions of old designs.

Best Paired With

Sending a video on its own can be counterproductive. We aim to include:

• Linked project documentation for decisions referenced.
• A separate list of all questions asked in the video.
• Expectation for review deadlines.

Follow With a Call

Assuming everyone taking part in the follow-up has seen the video (which is a useful check to kick the meeting off), we’ve shifted from a presentation to a discussion. Instead of taking time to introduce a solution and the inevitable pause for processing that follows, the focus is on clarification and feedback.

Timing the call after delivery will vary from client to client — everyone needs time to review what you’ve sent beforehand, but waiting too long means the information may not be fresh. We’ve had the most success in setting it within a week.

Taking critique is a separate post unto itself, but comments should be collated. Bonus points if you use the application you’re expecting the client to leave notes in as a method of reinforcement.

Collecting Comments

Two guidelines reign supreme in collecting feedback during and after the follow-up call:

• Have the client appoint a final decision maker to avoid competing critique.
• Seek to limit prescriptive comments (also a topic for a separate post). “This should stand out more” is more useful than “this should be purple.”

Reviewers need the means to convey two types of critique: contextual within the designs or wireframes (InVision, Marvel, etc.), and higher-order notes for the direction as a whole (we usually use Basecamp).

The Source of Truth

As decisions are made or changed, a single source of facts should be updated — the cookbook, if you will, to continue the random food analogies.

Sorting through old prototypes, videos, notes, and emails is a painful process for rediscovering a final feature choice. Whether it’s a ticket-based application, an issue tracker, or a wiki, ensure the responsibility is assigned for translating truth over.

Wrap Up

Screencasts are a great starting point for deliveries — everyone begins on a similar foundation for feedback and questions. Putting the effort in to create one, though, isn’t enough. Additional bits of process, including follow-ups, directed feedback, and a single source of truth are necessary.

This many food metaphors means it’s probably time for lunch.

Sending a Client Deliverable was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

SPA and JWT Sitting in a Tree

In recent years, as web development has moved towards a more JavaScript-heavy front end, and SPAs and PWAs have become as commonplace as APIs, another TLA has popped up: JWTs. Our tried-and-true server-side authentication schemes tend to fall down when placed into the context of a client-side web app, since pushing a global API key to the client would present some serious security concerns. In light of this, JSON Web Tokens are often presented as the solution.

JWTs attempt to fulfill the authentication requirement by sending a token to the client that provides some assurance via a signature that the data within it hasn’t been tampered with. The token can then be passed back to the server with each API request, acting as the keys to the kingdom, while also allowing “claims” to be included within the token for profile info, user roles, or anything else you like. In this way, the JWT often acts as the session store for the application.

There are lots of reasons to like this approach: it’s simple to understand (“Look, it’s JSON!”), easy to implement (“Oh, there’s a library for this…”), based on an industry standard, and designed for the Web. Combined with localStorage, which is about the easiest API you could ask for to store data like JWTs, it all makes for a very convenient package for developers. And, to back it up, there are many blog posts documenting this strategy.

Given all this, it’s clear why so many reach for JWTs for API authentication. Their sexiness is hard to resist. However, much has been written about their shortcomings, especially when used as a session store. They give the illusion of security while ignoring decades of research and practical advice. There is a time and place where using a JWT makes sense, but it’s not as an API key and it’s not as a session store.

Let’s look at some of these issues in more detail.

The Problems with JWTs

One of JWT’s core flaws is that the token itself specifies which algorithm to use for verification. Early on, there were critical vulnerabilities in many JWT libraries allowing an attacker to specify the none algorithm, effectively bypassing the signature verification step entirely. Even if those flaws have been fixed, specifying the algorithm in the token header is still problematic, as it results in an additional attack vector.

Another issue comes with using JWTs as a session store: you can’t invalidate sessions. For example, you may want to invalidate all existing sessions after a user changes his password. This is possible if the session is stored on the server, since you have access to that data, but a JWT will live on until its expiration. You can’t invalidate JWT sessions without resorting to tracking them on the server, which defeats the point of using them in the first place.

Some argue that pushing the session storage to the client facilitates horizontal scaling. In reality, for all but the largest of sites, this is a non-issue:

It is overwhelmingly likely that you do not [need] crazy horizontal scaling schemes at all, and that a single server-side session management system is sufficient for your use case.

Basically, you’re not Google or Facebook or even Reddit, so YAGNI.

And, despite what the standard says about JWTs being “intended for space constrained environments such as HTTP Authorization headers and URI query parameters”, their Base64 encoding can make them too large to be stored in a cookie or transmitted in a URL. As a result, many people resort to shoving them into localStorage. For something as sensitive as an API token, this is a fairly ridiculous thing to do, as we’ll see next.

The Problem with localStorage

The gist of the issue here is that localStorage has next to no security. While its access is limited to code running on the domain for which the data was stored, there are no restricitions in place that would prevent external scripts running on your domain from accessing it. This opens you up to XSS attacks. If a third-party script is compromised, it could result in anything stored in localStorage being stollen. If a JWT is among the data in that storage, you could have a serious breach on your hands.

Unlike cookies, which provide mechanisms to prevent XSS attacks, localStorage currently provides no such solution. Any script executing on your site will have access to all the data in the store:

Web Storage is not secure storage. It is not “more secure” than cookies because it isn’t transmitted over the wire. It is not encrypted. [This] is not a place to keep session or other security tokens.

It really shouldn’t be used for anything but caching publicly accessible data or storing other non-sensitive data like site preferences.

A Better Solution

So what should we use instead? They may not be newfangled or come with their own acronyms or initialisms, but cookies are currently your best bet. Most web frameworks provide a session store based on cookies right out of the box. In some cases, the cookie will contain the session itself in an encrypted form, and in others the cookie will merely store an identifier that’s used to look up the session on the server.

Web framework session stores have long relied on these cookies for identifying users. While they’ve had their own share of security flaws over the years, at this point cookie implementations are well-tested and hardended from a security standpoint. Additionally, because support is already built-in at the library and framework level, there’s no need to figure out your own implementation.

Cookies allow for a variety of flags to be set that limit their accessibility. The Secure flag prevents cookies from being sent to the server unless the connection is encrypted, and HttpOnly prohibits the contents of the cookie from being read through JavaScript at all, eliminating the possibility of XSS attacks. When using a session based on a properly-secured cookie, the flaws and vulnerabilities outlined above become non-issues.

And for server-side sessions, their centralized nature means they can be invalidated as needed to support new features or handle security incidents. They also enable features to be developed that would allow users to review their recent logins and invalidate sessions themselves should the need arise.

While it’s tempting to go with the flow and take the widespread advice to use JWTs in localStorage for your client-side apps, don’t do it. It’s not worth the risk to your users, it’s not simpler to implement, and it won’t make you cool no matter how many Medium posts you write about it.

Secure Authentication for JavaScript Apps was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last month, we launched the 2018 edition of The State of Theology alongside Ligonier Ministries. The microsite, updated every two years, allows users to examine survey data centered around religious beliefs. Each response is paired with demographic data, opening the door for an exploratory visualization (aptly named Data Explorer).

Having also built the 2016 edition, this year’s run offered a chance to iterate, introduce features, and revisit some assumptions. Visualizing data requires a series of choices (tradeoffs may be the better word) to present the results appropriately, which we’ll explore here in a bit more detail.

2016 Approach

Each version of the survey uses a five-point Likert scale — participants are given a statement, then asked to indicate whether they:

• Strongly Agree
• Somewhat Agree
• Neither Agree nor Disagree
• Somewhat Disagree
• Strongly Disagree

Following along with their corresponding whitepaper, our first take emphasized relative areas for the two extremes: agree or disagree. A tweaked area chart (extending out from a vertically centered axis) was picked as the clearest representation.

The Good

The approach passed the at-a-glance test: relative weightings of each response were clear, and the design itself was attractive. Demographic filters were simple to mix-and-match, and the resulting subset was easy to compare to the full population.

Pain Points

We sought to avoid different for different’s sake, but there were a few areas to improve on:

• The actual percentage for each response required an interaction to reveal, which felt a bit overkill for 5–10 numbers.
• Each area was smoothed via D3 interpolation, reducing the accuracy a bit.
• Filtering demographic data didn’t clearly visualize the subset size compared to the full population.
• The Data Explorer was mostly unusable at narrow screen widths.

Things to Explore

In addition to iterating on previous decisions, we added a new goal: using animation as a source of information. Individual responses are great, but the realization hit that a filtered group’s movement from question to question could be surfaced as well.

Plots, Sans Scatter

We tried a few options, new and old — revisiting the cutting room floor from 2016 didn’t yield any additional insights. Try as we might, radar charts are pretty much never the answer.

Bar charts did the trick (and made it into other portions of the microsite), but lacked some intrigue in showing movement of groups between statements.

Binned Beeswarm

After a some exploration via CodePen and D3, we landed on a beeswarm-esque visual that bins individuals into a bar for each answer. Benefits include:

• Bar chart-style simplicity in comparing columns.
• The ability to see how filtered demographics compare to the total population (both in proportion and size).
• The means to follow respondents from question to question.

Implementation

Putting our choice into production yielded another set of choices. 3,000 data points in motion was just weighty enough to need performance tuning.

The first build continued with the D3 and SVG stack of 2016. It worked, but switching between questions introduced a lot of jank. Paired with the usual headaches in making D3 and React coexist, we scrapped this early.

Using D3 to handle data joins in memory and output to canvas worked much better… until we tried it manually and saw 4–5x improvements in JavaScript processing time. Since the math was relatively simple, we stuck with the from scratch approach.

Lessons

As mentioned at the outset, choices in visualization don’t really boil down to right or wrong. The exploration phase serves as an opportunity to figure out which features of your data should be highlighted.

With a new set of goals in mind, we were able to revisit past decisions around rating scales and shift what held the spotlight.

The same sorts of tradeoffs are in play during implementation, too—we yielded some extra time to manual positioning math, but it offered a solid performance boost.

The most important lesson, though, is that it’s really tricky to make decently-sized GIFs for demonstrating moving particles in an article.

To see it in action, visit The State of Theology Data Explorer.

Updating a Visualization of Likert Scale Results was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a simpler time, when a website was requested, the server fetched some data and rendered the entire HTML document. If it took a long time to fetch the data, the visitor simply had to wait before seeing anything. As AJAX became more easily accessible with the likes of Prototype and jQuery, fetching data could be deferred until after an initial document was loaded into the browser. Parts of the UI could be delivered very quickly, then the remainder could be loaded in as it became available. With the advent of modern JavaScript frameworks, this pattern is now second nature.

The Problem

While it’s great that a fast initial page load is now common practice, unfortunately, so is an overabundance of loading indicators. On fast connections, those loading indicators can appear and disappear so quickly that they create a flickering effect in our UI. This isn’t what designers typically have in mind when crafting a user experience, and fine-tuning this behavior can be very complicated. Fortunately, the React team has recognized this problem and is introducing a new API to help us tackle that complexity.

Suspense: Deferred Rendering

This new API, called Suspense, aims to simplify how we build asynchronous UIs. It gives us the ability to defer the rendering of a component until its data has finished loading, as well as control the behavior of our loading indicators. Before we get started, keep in mind that while Suspense has been merged into master as of May, it is still under active development and will likely change before its official release in React 17. In other words, don’t use this in production.

Using Suspense

First, import the createCache and createResource functions from the simple-cache-provider package.

import { createCache, createResource } from ‘simple-cache-provider’;

To create a cache, simply call the createCache function:

let cache = createCache();

Next, define a resource using createResource, which accepts a function that returns a promise:

let PostResource = createResource((id) => {
  return fetch(`http://example.com/posts/${id}`).then(response => {
    return response.json();                        
  });
});

Now that we have our cache and resource, we can create a component that utilizes Suspense:

let Post = ({ postId }) => {
  let post = PostResource.read(cache, postId);

  return <h1>{post.title}</h1>;
}

And use it like so:

<React.Placeholder
  delayMs={50}
  fallback={<div class="spinner"></div>}
>
  <Post postId={1} />
</React.Placeholder>

While the API is fairly simple, there’s a bit to digest here, so let’s break it down. When we render our Post component, PostResource.read is called and our cache checks to see if it has data for the provided postId. The first time it checks, however, the cache will be empty, so it throws our promise. React then suspends rendering until that promise is resolved. It seems a little weird, but this is done by utilizing a concept called error boundaries, which was first introduced in React 16.

Placeholders Made Easy

You’ll notice we also wrapped our Post component with a React.Placeholder component:

<React.Placeholder 
  delayMs={50} 
  fallback={<div class="spinner"></div>}
>
  <Post postId={1} />
</React.Placeholder>

This placeholder component is what ties this all together and makes Suspense so awesome. While React is waiting for our data to be fetched, it renders the fallback specified in our placeholder, which is typically some sort of loading indicator. After the fetch has been completed, it removes the fallback and resumes rendering our Post component. We can even put multiple Suspense-enabled components inside a single placeholder, effectively grouping multiple data fetches in a single loading indicator.

Setting a Threshold

Last, but not least, you may have noticed the delayMs prop on our placeholder. This specifies the threshold at which our fallback is displayed. In this example, the placeholder will wait 50ms before displaying a loading indicator. This is important because it allows us to forgo that brief, but unnecessary, flicker of our loading indicator when our fetch is effectively instantaneous, but still show one if it takes longer.

Final Thoughts

While Suspense isn’t quite ready for production, it’s certainly worth getting excited about. It gives us a simple, yet powerful, API for creating asynchronous components that scale to our users’ network and computer speeds, allowing us to provide the optimal user experience with minimal code.

To try it out yourself, check out Jared Palmer’s react-suspense-starter project on Github.

Taming Asynchronous UIs with React “Suspense” was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’d probably pass on homebuilders whose outreach efforts detailed their favorite hammers. For years, though, new business in software development fixated on tools.

Nine years ago, Envy Labs opened with a simple position: we’re good at Ruby on Rails. It’d be tough to make that work today, but our early foothold hinged on that position’s subtext: we know how to use the hot technology, and prospective clients know that technology by name. Demand outpaced supply, especially as similar shops opted to walk the acquihire path.

In the decade that followed, specialized agencies sprung forth to capture the hype of each new framework or development approach. Even as Envy shifted towards other tech stacks, most work came in by way of Rails-based reputation.

Somewhere along the way, however, project inquiries stopped asking for tools by name.

Contributing Factors

Though unannounced, the ripple had speed. Résumé-like lists of specific technologies were once gospel for agency portfolios; now, they’re tougher to find, especially amongst smaller shops.

What changed? The shift has likely been brought on by a combination of (related) causes:

• Narrower tradeoffs. You may prefer a certain language, or have a better time implementing specific features with a certain framework, but the gaps between options have narrowed. Can anyone objectively say React is better than Vue?
• An ocean of choice. The number of viable options makes it nearly impossible for anyone to keep up, much less those outside the day-to-day of development.
• A slower march forward. This could likely fill a post of its own. Whether it’s due to the backing of large companies or a higher base-level complexity of the applications we build, the introduction of new frameworks and languages has seemingly slowed. As the cutting edge dulls a bit, the number of viable options increases.
• In-house talent. The pervasiveness of software today makes it more common for organizations to employ their own developers. This changes the nature of consulting work: companies look outside when they lack specialization or aren’t sure what they need.

Outlook

For a time, we had to sell prospects on the benefits of making their application responsive. Later, we had to reassure them that Envy Labs had the ability to make things responsive. Now, it’s an unwritten expectation.

Results reign, and they’ve been promoted ahead of technology lists in company portfolios.

Clients seek a solution to their problem, rather than prescribing their technology of choice — a welcome shift for consultants everywhere. In the absence of preselection, there’s a greater reliance on our ability to recommend and defend the right approach for the problem at hand.

As the how of software development fades as a differentiator, firms are left to focus on what and who for positioning.

Envy Labs was fortunate to weather the transition through Code School and a focus on technical training. Since, we’ve further refined that position to focus on helping consultants bring their expertise to web applications.

Marketing with a tool focus is still in the realm of possibility for niche technologies. If you’re hoping to be known as the best React shop around, though, you’ll be swimming upstream against a lot of competition and clients that may not be familiar with the framework.

Caveats

There’s been one recurring exception to this discussion in that prospects do bring up React Native regularly. I suspect it’s due to that request’s subtext: we’d really like a cross-platform application quickly.

There’s also an important discussion to be had regarding maintenance and deployment during project discovery. As consultants, we’re expected to solve the problem and leave software the client is comfortable with.

You’re Not What You Eat

Differentiation is far from an exact science, but the industry shift has been unmistakable: problem solving (and perspective) is valued more than the ability to swing a certain hammer.

We Stopped Marketing the Toolbox was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last month, I had the privilege of attending React Rally, a two-day, single-track conference in Salt Lake City. Held annually since 2015, the conference covers a range of topics across the React ecosystem. This year’s conference played host to an excellent lineup of speakers, and while every talk delivered, some really resonated with me.

D3 and React: Unlikely Partners in Data Visualization

At Envy Labs, we’ve long been proponents of D3, and we’ve used it to create some powerful data visualizations. While D3 and React handle completely different use-cases — D3 being a visualization and data manipulation library, and React being a component library — they have one annoying thing in common: they both want control of the DOM. It’s a struggle many developers have dealt with (and written about), so it should come as no surprise that we had a talk on this topic batting leadoff for the conference.

In her talk, D3 & React, Shirley Wu taught us how to leverage the strengths of each library (D3 for math, React for rendering) to work with each other, rather than against, to create some really powerful visualizations with minimal code. Shirley walked us through step-by-step as she outlined her strategy for building D3-powered React components, as well as best practices she discovered along the way. Whether you’re new to D3, or a seasoned user, you’re bound to pick up something new here.

Shipped Code > Clean Code

As consultants, we have to temper our perfectionist tendencies to meet tight timelines. Yes, the client is able to realize the benefits of a maintainable codebase, but do they really care if you’ve written the JavaScript equivalent of Shakespeare’s Hamlet?

As we go down the rabbit hole of best practices, optimizations, and perfectly abstracted code, it’s easy to lose sight of what really matters most: does it work and was it delivered on time? In his talk, Hot Garbage: Clean Code is Dead, Michael Chan gave us the reality check we needed (in a nice way) and reminded us that code is simply a means to an end, not the end itself.

Life as an Open Source Developer

In one of the most impactful talks of the conference, Through the (Open Source) Looking Glass, Henry Zhu (of Babel notoriety) reflected on the challenges he’s faced since leaving his job and working full-time in open source. Henry detailed the challenges of balancing work with fundraising — and the “catch-22ness” of it all — as well the unrelenting fear of not living up to the community’s expectations.

This talk resonated with me because I’ve always pictured a career in open source as one of freedom, but the picture Henry painted was anything but. It was a stark reminder that open source is often thankless work.

Check out the Rest

While I’ve detailed a select few, there really wasn’t a bad talk at the conference, and I highly recommend watching them all on the React Rally YouTube channel. And whatever you do, don’t miss Eve Porcello’s Everything You Need to Know About GraphQL in 3 Components. It’s probably the most hilarious introduction to GraphQL you will ever see.

React Rally Recap was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.

Entering the web industry can feel daunting. There’s a lot to consider: What’s the best way to learn the skills I need to know? How can I prove those skills to the world? Do I need to go to college? How do I separate myself from other applicants to companies I want to work at?

For the past several years, I had been asking these same questions. What started as a young teenager’s hobby turned into a quest to make websites as a career. Six months in to my role at Envy Labs, I’m revisiting decisions I made and advice I received that helped lead me here.

Welcome to the party

As a young industry with diverse roles, it’s hard to find two people with matching journeys to their professional gig. Even age is no clear indicator of in-field experience, as jumping into the web business has become a popular mid-career switch. And while generalists are still in need, growth and increased complexity have continued to create new roles for specialization.

Our field is growing, outpacing projected nationwide growth in new jobs with an estimated 15% increase in web development jobs over 10 years. If you’ve just started exploring the industry, you’re not too late; we’re just getting started.

You don’t need a college degree

Don’t take my word for it. Even tech heavyweights like Google, Apple, and IBM no longer require employees to have a degree. Many smaller software companies have been this way for years: they care more about the skills you have than where you learned them. It’s an increasingly large talent pool: 24% of professional developers who took Stack Overflow’s 2018 survey said that they don’t have a college degree.

Colleges have long struggled to teach up-to-date practices in web design and development. Their curriculum approval process simply can’t keep up with the rate of change. If you’re researching a program to attend, the best focus on technology-independent principles, but use current and upcoming approaches to teach it.

Ours is probably the most open industry in terms of the number and availability of learning options. There are countless quality learning platforms to learn coding and design that are either free or radically cheaper than a “formal” education. For me, studying Computer Science was interesting and helpful, but these learning sites are where I really learned the fundamentals and practical skills for web development.

CSS-Tricks was (and still is) an invaluable resource for all things web development, not just CSS. Codecademy gave me a great introduction into JavaScript. A List Apart’s great long-form articles introduced me to new key topics like responsive design. Even w3schools.com was a good starting place back in the day.

Though degree requirements are fading from job postings, college remains a valid option; it can be a great place for directed learning, community, personal growth, and exposure to other interesting subjects. Those leaning towards the technically-heavy or visual sides of web development may especially benefit from a degree. College is still worth consideration, but doesn’t have to be the default choice anymore.

Bootcamps

Bootcamps have recently become popular as an alternative to traditional four-year colleges. These programs tend to hone in on specific disciplines within design and web development, and generally take place over a few months. By focusing heavily on current skills, they—in theory—condense base learning time significantly and reduce costs from a traditional college route.

Because they aim to replace a degree, they also cost a big chunk of change ($11,450 on average); so you’ll want to find the track best suited to you before diving in. No matter the quality, high tuition bills for a few months of training can be a hard sell. This has caused many unprofitable bootcamps to shut down, leaving larger brands that have figured out the business model, as well as college-affiliated bootcamps.

I’ve heard mixed reviews on bootcamps — some say they are a great shortcut, others posit that they don’t do enough to prepare you for jobs. Ultimately it’s up to the bootcamp you choose and how much you supplement your learning with real-world experience. Do your due diligence and ask around to make sure the one you’re considering is a good choice.

Get cozy with self-directed learning

A web that is constantly evolving will always hold something new to learn. So whether you choose to go to college, a bootcamp, or turn to the web for learning opportunities, acquiring the ability to learn on your own will be a necessary part of your career.

Good design and development principles stay the same, but learning the best way to implement those principles with current tools and technologies are a huge part of the job. Thankfully, the web excels at making this process open. With a plethora of options for learning everything from fundamentals to advanced topics, there’s something for every skill and skill-level.

Though online courses are often very inexpensive (if not free), they often put out some of the best curriculum. It’s one of those rare cases where you get much more than you pay for. They also tend to add new content at a faster pace than in-person courses, so you’re likely to find more up-to-date topics.

Meetups and online communities

Wouldn’t it be nice if you could gain access to a group of people who do the type of work that you want to be doing, meet up regularly to discuss their work, happily answer questions, and offer advice? Enter the hugely beneficial meetup. Each month, there are likely many of these going on in a reasonably-sized city near you. (If there aren’t, you should start one!).

In addition to the talks given, it’s the exploration of ideas and connecting with peers that makes meetups really valuable for someone starting out. They are also low commitment (usually free and just one night a month) and can be incredibly beneficial if you’re intentional with your conversations.

Dev/design communities don’t just meet monthly in their city — they meet daily on the Internet. There are tons of online spaces where industry workers congregate to have discussions. Join those communities, listen to the conversations and ideas being shared, and start contributing.

CodePen and Dribbble are great places to find inspiration. Here on Medium you’re bound to find case studies, walkthroughs on interesting experiments, and articles on bleeding edge topics. There are question-oriented communities like Playbook and Stack Overflow that allow you to read answers to common questions or ask new ones. Even Twitter is a good platform to follow and pose questions to professionals.

Podcasts are another great medium to dive deeper into topics that you’ll want to know more about. They let you listen in on expert conversations and gain clarity on topics at a more foundational level. Pair it with your commute or some other time you’re away from screens and they can be a really useful time to learn without distractions.

Build experience by…building things

There’s a lot of learning that comes only through doing, which is convenient because building experience through real-world projects turns out to be pretty necessary. You can’t waltz in to a job interview claiming to know X, Y, and Z without the work to show it. Just knowing the fundamentals doesn’t cut it — so what does?

As Chris Coyier of CSS-Tricks famously says: “Just build websites.” There really is no better way to get good at web design/development. Building something real gives you the opportunity to put what you’ve learned to use, pick up new concepts, and seek out creative solutions on the fly.

Don’t know what to build? Take a look at your passions and interests — there’s bound to be a few crappy websites in that area that could use a redesign. Some groups are notorious for having bad websites. Find a niche that’s neglected and get building! Here are some ideas:

• School clubs, local interest groups, meetups
• Local businesses
• Religious organizations
• Family and friends who want to blog, sell goods online, etc.
• Weddings
• Open source projects

Don’t be afraid to create your own opportunities. If you have a hobby or unique interest, make a neat site around it! In my early days, I made custom sites for blogs, a single-page site showcasing playlists, my brother’s wedding, many portfolio iterations, and countless random experiments that never saw the light of day (I’ll finish you someday, Star Wars fan-site).

You don’t need to do crazy promotion for these sites; throw them onto your portfolio or share them around your design community. When you’re using a site to practice skills or learn something new, the content isn’t all that important. The point is to gain experience by making something.

A note on getting paid

There’s often a gray time period in learning to build websites when you start to wonder if you should get paid for the work you do. Don’t get too caught up on this. If your ultimate goal is to land an internship, apprenticeship, or job (you need to work, right?), then it doesn’t hurt to volunteer your skills in order to gain experience on real projects.

If it’s, say, your third project for someone else, you can think about charging. But your first project outside the classroom? Maybe not. Opt for a project that’s small in scope; don’t undertake something you don’t have the time, desire, or ability to see through. Other good fits are projects that you can self-direct. Having lots of freedom with a site gives you the opportunity to try something new instead of feeling the burden not to fail.

Internships

Self-directed projects are a great way to gain experience and stand out from others, especially as you look to get hired. Another valuable asset (perhaps the next step) is an internship. If you’re in college, you’ll have a lot of encouragement to do an internship, but companies aren’t interested solely in students.

Each story I’ve heard is different, but the biggest indicator of a good internship experience is not the position itself, but the company offering it. When applying, do a bit a research to see how they operate and see if you can find other interns at the organization to hear their take. Additionally, companies should be paying you at this stage, so don’t trust unpaid internships (these might actually be illegal unless they meet some narrow criteria).

Apprenticeships

Apprenticeships harken back (all the way to the Middle Ages) to a once-common approach where a professional in a particular discipline would closely train a young person in his or her craft. Today, apprenticeships in web development are paid on-the-job training that all but guarantees you a job at that company if it goes well. As such, these are much harder to get into than a traditional internship, but the return is much higher.

Another great benefit of an apprenticeship is that you know you’ll be getting good experience (whereas internships can be a toss-up), yet you’re still not expected to know everything coming in. Plus, you get to contribute to real work on a real team, all-the-while experiencing the company’s culture before you start on a more permanent basis.

Show initiative in your job hunt

Preparing for your first job is a journey that begins well before you start applying. Having the end in mind will help you be effective in your work and show others you’re serious when the time comes. Whether applying to a small digital agency, a Silicon Valley software giant, or a technical position in another industry, you can make a big impact by following a few tips.

Make a better portfolio. You need to make it incredibly easy for reviewers to see your work and your process behind it. Writing short case studies is a great way to make your portfolio more compelling to those initiated with the project. They want to hear the story behind the work and see the design/software decisions you had to make. Don’t just show the final product, show how you got to there.

Regularly attend local meetups and make your intentions known. If you’re looking for a job, say so. If you’re trying to get into a certain subfield or new interest, mention as much. Be obvious about the things you’re pursuing so people will know and keep you in mind as they hear of new opportunities. Local communities are probably the best way to create connections that lead to you getting hired.

Reach out to companies you like. Even before I was formally looking to get hired, I sent emails to about ten different companies and heard back from a few I really admired. Ask to tour their office or to meet someone on their team with a role similar to what you want to be doing. Most people love meeting newcomers to the industry and offering up guidance.

You can even throw out the idea of doing an internship or apprenticeship with them. They may say “no” or “not right now,” but showing initiative could spark helpful conversations and make you a contender for future hiring. Ask them to look at your portfolio and give you feedback on steps you can take to make it where you want to be.

Walking the Road

Hopefully this post has shown a light on the various paths towards a career making websites. Everyone’s journey looks a little different — and if I’ve learned anything, it’s to be yourself as your work your way there. And when you do reach your goals, pass on what you’ve learned to people who are just starting theirs.

Starting a Career in Web Development was originally published in Insightful Software on Medium, where people are continuing the conversation by highlighting and responding to this story.