Content to Components: Transitioning from Marketing to Application Front End
Building the front end of a modern web application is a far cry from creating traditional content- and marketing-based websites. The learning curve may look steep, but it’s not as daunting as it first seems. I recently made the jump to building web apps and wanted to share what I’ve learned about this other side of front-end development.
Joining the Envy Labs team in late February marked a few major moves for me: becoming a specialist where I used to play the generalist, gaining access to larger teams and resources, and also getting used to seeing googly eyes on every plant in our office. Having previously worked primarily on marketing sites, my first two months felt like playing catch up. I had to re-learn much of what I thought I knew about developing websites.
Why are web applications different?
Aren’t they just a combination of HTML, CSS, and JS like every other site? Technically, yes, but we build web apps differently because users interact with them differently.
Most websites I’ve built aimed to a) provide information/media for users to better understand an organization (content-based sites), or b) try to persuade users to take an action: often a purchase, sign-up, or some other commitment (marketing sites). In each of these, there was some sort of invisible funnel guiding a user to an end goal.
Web applications are different. They are software that help people accomplish tasks they have based on their domain of interest. Depending on the domain, users might spend significantly more time in the application than on, say, the website of their favorite local business. With complex actions and large swaths of the user’s time, web apps require new levels of performance and structure that many marketing-based sites do not.
Concepts to Re-Learn
Data Source and Manipulation
When writing web apps, the first changes you’ll encounter are a new data source and a new method of altering that data. Content-driven sites are usually backed by a management system — WordPress, Drupal, and Craft (my favorite) are relied upon to handle data. In application land, that job belongs to a custom API.
For consuming that data, we swap out templates and rigid CMS data manipulation techniques for a single-page application (SPA) library such as React (our current choice of the SPA crop). The result is a beautiful distinction between data and presentation, plus the ability to pick the best tool for each side of the development fence (something the headless CMS movement has also embraced).
Like a traditional CMS, most web apps have a user interface for creating and altering data. However, the advantage of building a web app is that you get to control the entire data pipeline. Any UI that is needed to manage it is built by you and can be custom-tailored to the needs of your data and users. CMSs take a one-size-fits-all approach that works in a lot of cases, but building your own software grants you the freedom of shaping the data and the data-editing experience to your domain.
Component-based Structure
This is by no means a web-app-only concept, but it is vital to them. Components are the building blocks of every part of an app, from buttons, forms, and links all the way to navigation, sidebars, and even page layout. Components live inside components that live inside components. Here’s a basic example:
If each component is already styled, we can easily write this layout in React:
The advantage of building this way is that each component has its own structure, style, and functions, which are siloed from every other component. Gaining access to component A’s accompanying code for use in component B becomes a matter of importing A into B, which is fairly straightforward in most frameworks. This drastically simplifies development and iteration since you have the freedom to utilize components wherever you need to place them.
While globally-scoped CSS has its advantages, component-based architectures are prime candidates for writing styles that scope to a single component. This CSS modules concept takes time getting used to — it feels funny to write CSS that doesn’t cascade — but the benefits of avoiding conflicts and gaining easy dependency management can be worth it. This is especially true for large-scale apps with large teams where structure and order are crucial.
Let’s say we want to style the above button using CSS modules. We can do so in React using styled-components, which implements the CSS modules approach. It looks like this:
By following React’s method for exporting and importing, this Button component can now be imported to other components that needs to use it, like we did in the first example.
Tip: Use a UI development environment like Storybook to create and catalog your components, especially lower-level elements like buttons, form elements, and text. These environments allow you to view each component and all its varieties, creating a nice testing bed to create and update component styles.
State
State is a set of attributes that describe a component which can be used to drive its behavior. One basic example is that a hidden dropdown menu is inactive until a user clicks on its corresponding menu link, changing the menu’s state to active, which the menu component understands to mean that it should display itself. Click again and the menu is hidden again. That’s changing state.
Traditionally we might have used CSS classes like .active and a corresponding JavaScript function to manage when that class is added or removed. SPA frameworks build in easy ways to manage a component’s state without resorting to a mess of CSS code, and they allow other components to subscribe to its state so they know how to react to its state changes.
Working on traditional websites, state had always been there but I didn’t quite realize it because it was isolated to a few elements. When moving to a component-based architecture, state seeps into each element as you build out every permutation of it. Even for smaller applications a common button can have states for being active, inactive, disabled, hovered over, and even for different colors or sizes.
There is no one best implementation of state management out there — it really depends on the needs of each app and how you are building it. Whether you use a popular library like Redux or build your own solution, state management is an important concept to understand when it comes to web apps.
Animations
Again, this is not a new concept, but the way it applies to web apps is different from how it applies to content-based sites. Marketing sites use animations to direct your attention and add eye candy, but often don’t extensively use it otherwise. Web applications additionally use animations to transition between states, make heavy processing feel fast, and to make interfaces feel right.
Animations have the power to dramatically alter the way users feel when using a website. Anxious, confused, delighted — these are all subtle emotions your interface can cause. Animation techniques have been developing in other mediums long before the web adopted them. Take time to study these disciplines to understand principles like motion, timing, and easing that are common to all animations. Pay close attention to how animation is utilized in other web apps and non-web properties to improve.
Take the above animation, for example. A user is interacting with a card component that contains a summary of the project and offers a few actions. When selecting the archive action, it would be easy to show a confirmation message via a pop-up modal. But if we animate the card itself into a confirmation message, a user understands the context and consequence of their action, and they get to see a fun animation instead of a distracting pop-up.
Related to animation are loading states, a relatively new design pattern that fills an interface with placeholder shapes, indicating that real content will soon take its place. This helps lower perceived load time and affects how you introduce animations.
Writing Good Code
Web applications tend to be a little more complex than content-heavy sites, so code readability and standards aren’t just for the benefit of your team, but also for the benefit of your future self. We have an application that’s six years in and constantly being developed. Putting standards in place and committing to consistency have allowed us to build a strong foundation that holds its own over time and among different developers.
Even if you can get away with being code-sloppy on a small content site that isn’t touched after launch, most web apps have teams that continually iterate upon it.
Clear always beats clever. Your code should be as clear as possible so that someone can jump into your work and quickly figure out a) what your code is doing and b) how it relates to the broader app. If you’re the sole developer, it’s still to your advantage to make each line of code a welcome sight for the next time you want to bang out a new feature or improve what’s already been built.
Beefing up your code editor with the right plugins will also help keep standards and minimize errors. Linting will point out errors and syntax issues as you type and Prettier keeps code style consistent in a project. And if you find yourself thinking, “I wish it were easier if I could do _____” or performing the same repetitive task, there’s probably a plugin out there for your needs.
Refactoring is a practice of all good coders. In the past I have been guilty of getting a feature to work and then leaving it in that raw, hacky state. But with web apps where components are being used throughout the entire application, you’ll want to build that component just right.
That initial get-new-feature-to-work step still exists, but it’s important to revisit your code and rework it. As with naming conventions, clear and concise code wins the day. When code is easy to understand, you are less likely to make mistakes and it becomes more clear to you or your team how to make it better.
Know the “How” and “Why” Because the “What” Changes
At the end of the day, no matter what type of website you’re building, the end result is an HTML document stuffed with CSS and JavaScript. The key is having knowledge of the final output, its behavior, and building with the end in mind. The tools change, you’ll swap frameworks, but the mindset stays the same.
Both applications and content/marketing sites are taking cues from each other: applications are putting greater emphasis on animations, illustrations, and delight, and content/marketing sites are adopting component-ized architecture and speedy development practices. The lines are starting to blur.
Whatever you build, keep these tips in mind as you step into the world of web apps:
- Ask someone who knows more than you for help/advice/input. Don’t be shy in asking them to review your code and point out ways you can improve. Most developers would love to help you out.
- Don’t be afraid to read the documentation. It can be overwhelming, confusing, and some documentation really does suck, but it’ll save you hours of headache when you learn things the right way. Supplement your learning with tutorials and examples, but read the documentation first.
- Make things! Often, the best way to learn something is to dive right in and figure it out as you go. Start a new project and don’t worry about how trivial the result is. As long as you’re learning, it’s a worthwhile endeavor.
