As soon as I started using Cushion again as a full-time freelancer, I fell in love with it all over again. I also realized that it still holds up after all these years! As a returning user, however, I immediately noticed a few rough spots since I last freelanced. These are the kind of rough spots that I’d otherwise miss if I weren’t a user of my own app—and I did miss them. After reminding myself that I can actually fix the rough spots that I come across, I spent an evening smoothing them out.

The next day, I used Cushion as I normally would, but with the usual pain points no longer there. I felt an instant jolt of delight when an especially cumbersome flow in my daily routine was reduced to a single click. If I were a regular user, I would’ve never bothered to reach out to support to mention the extra clicks in this flow, but I’d still feel them chipping away at me. Rough spots like this could’ve worn me down enough that I might eventually fall out of love with the app. But because I work on Cushion—and now use it regularly—as soon as I feel a rough spot myself, I want to fix it immediately because I know other users feel it, too, …but not enough to report it. This prompted me to send a message to my users, giving them the chance to share any rough spots they experience in their day-to-day use of Cushion, but haven’t bothered to mention.

Unsurprisingly, I heard back from a handful of users with plenty of rough spots to keep me busy for a while. The biggest surprise, however, was the number of users who replied that they couldn’t think of any. (Some Cushion users are too nice to give it to me straight!) While I appreciate the kindness, I’m craving feedback right now. I spent the next few days recording all the rough spots into a to-do list. Now I have the low-hanging fruit I need to build some momentum as I get back in the saddle.

I’m not a “Let’s fucking go!” guy, but now would be the time to say it.

Reply via email

A couple months ago, when I was first planning to go independent again, I ran into my friend, John Watkinson, on the walk home from my studio. John is half of Larva Labs along with my good friend, Matt Hall, and they’re responsible for industry-defining projects, like CryptoPunks and Autoglyphs. I actually sat next to them when they were first working on CryptoPunks, and they asked if I wanted to have any. I remember telling them that I was too busy working on Cushion to be bothered. So that was cool. In any case, we caught up for a bit and I mentioned my plans to return to freelance life. John had an immediate lightbulb reaction, as if this was perfect timing—and it was. It turns out Matt and John were weeks away from announcing a new project, and they were looking for someone to animate it.

Matt invited me over to their studio, where they told me about Quine. In their words, “Quine is a generative art project that blurs the line between its code and the art it produces.” At first, these quines just look like cool procedurally-generated pixel art. And, while that’s true, if you look closer, you’ll see that there’s real code embedded within each quine. Matt explained to me that if you extract the code and run it, it’ll generate the next variation of that quine’s sequence. I was immediately intrigued from that concept alone, but it goes even deeper than that.

Each quine has a number of characteristics, including one that Matt and John refer to as its “quinity”. This can be a 3-Quine, a 5-Quine, a 7-Quine, etc. Basically, the quinity relates to the quine’s generation loop. For a 3-Quine, if you would repeatedly extract and run the code within each quine generation, after the third generation, it’ll loop back to the beginning. A 5-Quine will loop after the fifth generation, etc. As an engineer, I caught myself chuckling and shaking my head at how cool and clever this is. And, if you’re a sucker for collectibles, it gets even more interesting. Apparently, there are two very rare types of quines, known as a “Perfect-Quines” and “Pseudo-Quines”. Perfect-Quines, when executed, will only ever recreate themselves. And, Pseudo-Quines will generate an effectively infinite number of generations without ever looping. At this point, I went from intrigued to hooked.

So, where does animation come into play? If the written explanation of Quine had you seeing the math meme, you’re not alone. Sometimes the easiest way to explain something complex is through visuals. Matt and John thought that an animation simulating the generation process would go a long way to demonstrate the overall concept. That’s where I come in.

At its core, the code that generates and is embedded within each quine is JavaScript, and when executed, this code generates an SVG. Coincidentally, I happen to have a ton of experience animating SVGs from my time at Stripe, so I’m right at home with this project. The SVGs that make up these quines, however, are very dense to say the least. Each quine is 1440x2560 pixels in dimension, and the squares that construct each quine are 14x14 pixels with a 2-pixel gap between them. This means that a single quine as an SVG could potentially have up to 14,400 <rect> elements. On top of this, each quine could also include between 3,500 and 4,500 <tspan> elements from the code printed within it. For anyone familiar with SVG performance, this is a lot of elements to display, let alone animate. I didn’t waste any time even considering we stick with SVGs before immediately switching my attention to <canvas>—the hardware-accelerated HTML element that can animate thousands of shapes without breaking a sweat. Even though Canvas can run circles around SVGs, I still felt compelled to do some performance testing.

I started by testing the extreme—animating all the shapes individually. I had no intention of actually running with this approach, and I knew it would perform the slowest, but I still wanted to establish a baseline to gauge how slow this would be—surprisingly, not bad! I then tried animating the text that would represent the code. Instead of animating the positions again, I focused on transforming scale. Again, not bad! Next, I tested the more realistic approach—animating elements as groups. This would certainly improve performance because I’m not only animating a single layer, but I’m also avoiding the iteration loop on every element. Lastly, I tested animating groups of elements that are layered behind text. Because of the flat nature of <canvas>, I didn’t expect this to factor into performance at all, but I was still curious to see it as a disorienting visual!

Once I had a better grasp on performance, I moved onto the actual animation. When thinking about the quine generation process, I immediately imagined a quine being “printed,” like an inkjet printer—line by line in a single direction. From the performance tests involving layered groups, I also imagined printing individual colors as separate passes, like with screen printing. Combining the two metaphors, I iterated through several variations:

• single direction linear passes where the “ink” carries with the squeegee until it reaches its spot

• single direction passes with easing

• bi-directional passes with easing

• single direction linear passes with a printer line that reveals each row

I found myself most drawn to the mechanical approach—slow and linear. I wanted the quine to emerge from each layer with a sense of anticipation.

Now that I had the movement dialed in, I zoomed in on the detailed part of the quine—the code within it. Originally, I “printed” the code together with its squares, but this buried the lede too much. By printing them together, they held equal weight despite the code being the reason the quine even existed. And to the untrained eye, you might even miss the code altogether if it’s printed along with the squares. Thinking back to the concept of layers, I decided to try printing the code first—on its own layer—to emphasize that it can stand alone and that the viewer should notice it. Only then do I start printing the layers of squares to combine the two. In doing so, I introduced another transition opportunity—the code inverting itself as the squares are printed. With this visual, we really drive home the message that there’s code within the quine.

With the printing animation behind me, it was time to move onto the scanning animation. I already highlighted that there’s code within the quine, but I also needed to communicate that the code is both meaningful and legible—not just a random snippet. People typically interact with code using an IDE, so why not include one in the demonstration? Taking a page out of the text streaming effect often seen in AI chat interfaces, I decided to combine this effect with a faux “scanner” that passes over the original quine. As simple and straightforward as this is, it gets the point across that the code within the quine is actually real and recognizable when displayed in a familiar format and environment.

Now that I had printing and scanning animations in a good place, it was time to combine the two. I would start with the printing animation for the original quine generation, but then I’d reuse it for the next generation, in parallel with the scanning animation. Even though I built these animations separately, they locked into place so well that I had no notes. The overall animation continued to write itself as long as I continued to lean on the analog metaphors. Print the quine. Scan the quine. Scanning the quine prints the quine.

Upon screen recording the animation, I had my deliverable—an animation that would be used as b-roll for Matt and John’s announcement video. And, thanks to the animation being in video format instead of live and interactive, I didn’t need to worry about all of the typical considerations that I’m used to, like responsiveness, performance on slower machines, compatibility with different browsers, or what even happens next. I could focus on a single animation that visualizes the core concept while Matt voices over the it with the verbal explanation. Larva Labs announced Quine on Art Blocks, where they also held their auction for 477 of the 497 quines. The auction was another success with the sale closing at 7.56 ETH ($31,000) per Quine NFT.

Once the dust settled from the auction, Larva Labs reached out again regarding an extension of the project. In a few weeks, they would be displaying Quine in gallery format at Art Basel in Miami. In addition to framed prints of several quines on the walls and a massively long table with a grid of every quine, they would also have a 4K TV to, again, aid in visually demonstrating the concept, but as a looping video this time. The video format deliverable still saved me from the considerations that go into a live animation, but now I needed to “upgrade” the animation. Instead of finishing the animation after scanning and printing once, it would need to generate an entire quine’s sequence with transitions, automatically proceed to the next quine, then loop back to the beginning when finished. John provided me with a list of 10 quines, with quinities ranging from 3 to 11. This would result in an animation that is 8 minutes and 28 seconds in length.

Luckily, the layout of the quine generation flow, along with my intuition for how it should move, led me to nail it on the first try. Upon scanning and printing the next generation in a quine’s sequence, the two generations and its “code editor” would slide and fade, so the generated image would become the source image, which would get scanned and print the following generation. In theory, I could let the animation run uninterrupted and it would loop forever because my actual animation code literally extracts the quine’s code and uses it to generate the next animation. A generator of generators, itself.

It might go without saying, but I absolutely loved working on this project. After years of solely working on product and web, life presented me with an opportunity to return to the creative code world—in a practical sense. I also got to collaborate with close friends I haven’t jammed with since the last time I freelanced in 2018. This truly felt like the perfect reintroduction to independent life, and it was all because I bumped into John on the walk home from the studio that night.

Reply via email

If I’m being honest, I’ve always felt like an imposter at a full-time job—a freelancer in full-timers’ clothing. Not needing to pay for healthcare, my laptop, or lunch was surreal at first, like I was getting away with something. Holidays counted as actual time off instead of regular workdays without distraction. Tax season was the push of a button compared to the soul-crushing marathon that I’d brace for each year. To a freelancer, full-time life felt like an all-inclusive resort.

Over the years, I definitely embraced this more stable way of life, but it never felt real to me. In the back of my mind, I knew I’d someday return to independent life. As much as I wanted to fully commit myself to a company—no matter how successful it might be—it would never come close to the excitement I have for my own ideas. This excitement is a palpable energy that’s impossible to hide. The thought that I could someday support myself by growing one of my own ideas into a sustainable career is a constant daydream that feels almost painfully attainable.

I’ve had this thought before, and I came up short, but this time feels different. I have an additional decade of experience under my belt, an exponentially larger network than before, and a real hunger to jam with startups again. We also live in a time where being independent isn’t as isolating or limiting as it once was. And, most importantly, I have an idea that makes me feel like I’m going to burst out of my skin every time I think about it. Without a doubt in my mind, this is the time. This is my time. I’m so ready to run it back.

Reply via email

Collaboration in Cushion was like “teams for freelancers”, but there were no dedicated teams. Any user could invite any other user to a project. Or they could invite a non-Cushion user to a project solely to track their time, like a subcontractor. Then when it came time to create an invoice, they could include their own tracked time along with the subcontractors’. The original user would simply pay extra for “seats” for their collaborators, and that would be an extra $5 per seat per month or so. By inviting subcontractors to a project, this would potentially encourage more non-Cushion users to start using Cushion. This is that “network effect” I mentioned, combined with a way to get more monthly recurring revenue out of a user—especially since a handful of folks have begged for multiple users in the past.

On paper, it sounded like a great idea that makes complete sense. In the implementation, I think we went about it the wrong way both on the backend and on the frontend. Instead of taking the straightforward approach of introducing a separate parent “team” model that could have many users and be the owner of the shared projects, we decided to shoehorn the database associations for collaboration into the existing user model. With this approach, a user could have “members” (users) and “readable” and “editable” datasets for anything that’s shared. Then for anything created, like time tracking entries or workloads, the user ID for these would be the member, but model would also be tied to the parent user. This led to an entire layer of complexity added to almost every database query that involved these models. And that led to slower database queries for everyone in the app—not only folks using collaboration.

On the frontend, “collaboration” was its entirely own section with subsections for all the existing top-level sections—scheduling, time-tracking, etc. This essentially doubled the footprint of the app, but in a way that felt duplicated instead of built-in or well-thought-out. Again, if I had only followed the straight-forward approach of a team-like model where you could view different workspaces, ala Slack, it would be much more straightforward—especially if one of those workspaces is your own personal one.

In hindsight, the correct solution seems so simple, but I need to remember that six years of time and experience has accumulated since then. Of course, it seems simple now, but it didn’t then—especially in the stressful situation of needing a home run. I can’t knock myself for that, but on the glass-half-full perspective, at least I didn’t actually launch collaboration, get loads of folks to rely on it, then realize it wasn’t right for the app. And, if I ever wanted to revisit the concept with a more straightforward approach, I now have the wherewithal to do it in steps. First, I’d introduce the concept of workspaces for individual users, so they could have multiple businesses. Then, I could introduce the ability to invite other users to those workspaces. That would be the correct approach.

As much as I want to give it another shot, I first need to make Cushion perfect for the individual. Then I could reconsider collaboration. With this in mind, I’m determined to be much more consistent with user research going forward, so I could polish all the rough spots that nag folks on a regular basis. If you’re eager to share your thoughts, I’ve re-enabled chat in the app. Hit me up!

Reply via email

When I first started building the table, I knew I wanted to lean on markup as much as I could. I’m a purest at heart, so I prefer writing HTML when I need HTML and CSS when I need CSS. If you read the previous post, I’ve certainly had my fair share of “clever” approaches to rendering HTML, like concatenating strings, and I’m so over that phase of my engineering life. Luckily, Vue 3 is incredibly fast when it comes to rendering, so I don’t need to worry about performance the way I did with Angular back in the day. Now, I can just write the markup, wire up the data, and expect instant rendering.

Since I knew I’d be reusing this table throughout Cushion, I decided to make a “base” table that I could use across clients, projects, and invoices, but I wanted to make sure it was specific to “items”—not an entirely generic base table. I’ll explain. There’s bound to be areas where I need a table that doesn’t look like the tables for invoices, etc., and doesn’t use the kind of data that goes into an invoice table, so instead of making a <Table> component and calling it a day, I opted for an <ItemTable> that’s more intentional in its use and infers that this is a table for “items”. (I admit “item” is an incredibly ambiguous word here, but I strangely don’t like using the word “model”, which is what I’m referring to—a model with an ID.)

From here, I was able to build all the child components for an ItemTable, which include an <ItemTableCell> (or <td>), <ItemTableHeader> (or <th>), and <ItemTableRow> (or <tr>). These components are intentionally primitive because they’re meant to be extended. Within the components themselves, however, they’re styled to the design of the item table. They also handle all the aria-role attributes, so I can maintain accessibility while ejecting from the table-based display styles. With these low-level components, I can…

• extend the <ItemTable> to make an <InvoiceTable> that takes an array of invoices and renders them as invoice rows

• extend the <ItemTableRow> to make an <InvoiceTableRow> that takes an invoice and renders the relevant cells

• extend the <ItemTableCell> to make a collection of cells to handle any formatting needs, like currency, dates, durations, etc.

All of this combined lets me easily compose tables while compartmentalizing their logic and styling. I no longer need a long config object full of callbacks to determine everything, like in past attempts. I do still have an initial config, but it’s limited—in a good way—and makes much more sense now through the use of composables (or hooks in React).

The last time I rebuilt this table, in 2017, the concept of composables didn’t even exist. Now, I’m able to configure a table with a `useTable` composable that takes an array of columns (for config), an array of rows (for data), and an optional order (column name and direction), then returns reactive arrays for the filtered columns and sorted rows.

const { columns, rows } = useTable({
  columns: [
    {name: "Color", type:"Color", sortKey: (invoice) => invoice.client?.color || "#bbb"},
    {name: "Number", type:"String", sortKey: "number"},
    {name: "Client", type:"String", sortKey: (invoice) => invoice.client?.name || "(no client)"},
    {name: "Created", type:"Date", sortKey: "created_at"},
    {name: "Updated", type:"Date", sortKey: "updated_at"},
    {name: "Sent", type:"Date", sortKey: "sent_on"},
    {name: "Due", type:"Date", sortKey: "due_on"},
    {name: "Paid", type:"Date", sortKey: "paid_on"},
    {name: "Amount", type:"Currency", sortKey: "total"},
  ],
  rows: invoices,
  order: {column: "Amount", direction: "Desc"},
});

The config for the columns includes the column name as well as its type and sort key, which is either a key on the model or a callback to dig deeper. Callbacks are handy for specific cases where the sort key isn’t the raw property value. In Cushion’s case, sorting by color—which is a thing—requires that I convert the hex colors into HSL colors and sort by hue. As for “type”, I’m especially excited about this approach because it removes so much manual work. As an example, if a column is of type “date” or “currency”, the table knows to align those columns to the right and narrow their widths. Or, for a color-typed column, I could actually pass the raw hex color as the sort key, like above, and the column could know to automatically convert it to a hue before sorting.

const { columns, rows } = useTable({
  ...
  includedColumns: ["Color", "Number", "Client", "Amount"],
});

If anyone’s especially curious, you might be wondering why this composable would need the array of columns only to return them again. This is because it also takes an includedColumns property, which is an array of the column names to show. In Cushion, there are actually three invoice tables under the “Invoices” tab—“Drafts”, “Invoiced”, and “Paid”. All of these tables render invoice rows, but each of these tables show different columns that are relevant to the invoices’ status (e.g., a due date for the “Invoiced” table and a paid date for the “Paid table”).

const { columns, rows } = useTable({
  ...
  includedColumns: ["Color", "Number", "Client", ...props.includedColumns, "Amount"],
  order: props.order,
});

In the past, these were three separate tables, which meant a lot of copy/pasting and reusing code on a column-by-column basis. This time around, however, I’m actually thrilled with the idea of using a single <InvoiceTable> component that by default includes all of the possible columns that an invoice table could have. Then, I can specify which columns to show—solely by name—as well as which column to sort by. This makes the actual implementation of each invoice table incredibly simple because the code is only several lines of markup whereas before each table had its own file with a full config. Also, now that Vue supports generically typed props, composing these tables is much easier and type-safe because the table knows which columns and specific model it supports.

<InvoicesTable
  title="Paid"
  emptyMessage="No paid invoices"
  :invoices="paidInvoices"
  :includedColumns="['Sent', 'Paid']"
  :order="{column: 'Paid', direction: 'Desc' }"
/>

While I’m really happy about this approach, I admit I’ve only dealt with rendering so far, which is the first step, but it’s the easy one. Next up, I’ll need to dive into interactions, like context menus and drag-and-drop. I’m not worried about these, but I know full well that they’re pivotal decision moments. Can I still maintain a “pure” approach that’s clean, reusable, and intuitive? I think so! And that’s my goal.

Reply via email

Here’s the e2e.yml workflow file that you need to add to your project’s .github/workflows directory (assuming you’re using Node v20 and pnpm):

name: End-to-end testing
on:
  deployment_status:
jobs:
  e2e:
    if: github.event_name == 'deployment_status' && github.event.deployment_status.state == 'success'
    timeout-minutes: 60
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
    - uses: actions/setup-node@v3
      with:
        node-version: 20.x
    - name: Install dependencies
      run: npm install -g pnpm && pnpm install
    - name: Install Playwright Browsers
      run: pnpm exec playwright install --with-deps
    - name: Run Playwright tests
      env:
        BASE_URL: ${{ github.event.deployment_status.environment_url }}
      run: pnpm exec playwright test

This should read pretty easily if you’re familiar with GitHub Actions, but it triggers upon a deployment status change and only runs Playwright if the deploy is successful.

In your Playwright config, point the use.baseURL property to your BASE_URL environment variable, which represents the generated URL for the preview deployment:

export default defineConfig({
  use: {
    baseURL: process.env.BASE_URL,
  },
});

Finally, push to GitHub. Assuming you have automatic deploys set up with Vercel and GitHub, you’ll see the results of your deploy in your pull request, then upon a successful deploy, the e2e workflow will start running—pointed at your preview deploy. It’s this easy. Don’t be like me and go down the outdated path of waiting for Vercel deploys or deploying from GitHub Actions. You don’t need that. And if you do, you don’t need this post.

Also, If Playwright seems to stall when running, it’s probably because you have Vercel Authentication enabled in your Deployment Protection settings. You’ll either want to pay Vercel $150/mo for Protection Bypass for Automation, or disable authentication. Unless you’re working on something super secret, disabling authentication is fine. And if it is super secret, you can afford $150/mo.

Hope this helps someone.

Reply via email

If I’m looking to build a working app sooner than later—and I’ve already proof-of-concept’d out the fun-yet-uncertain parts—then I can start with the boring-yet-essential parts. These tables are basically spreadsheets fed from the database. They ingest the data, display it, and add it all up in a way that’s useful for freelancers. At the end of the day, when a user is looking for a specific date, invoice amount, or payment status, they’re going to look at the tables first. Then, for a quick look at their progress over the year, they’ll check out the visualizations.

Believe it or not, I’ve actually built half a dozen versions of these tables for Cushion over the years, and what I’ve realized from revisiting the code is that my age and experience is directly correlated with my “cleverness”—or lack thereof. The younger I was when writing the code, the more roundabout my approach was. As I got older, my code became more straightforward. I’ve found that this applies to my code in general, but it was truly highlighted when revisiting the code for my tables.

The first table I built for Cushion was actually written with Vue.js, but it never made it to production because I switched to Angular shortly after. Vue.js was brand new at the time and not battle-tested enough for me to have confidence in it yet. As a funny aside, I know for a fact that the journal post about this table was written a long time ago because its images weren’t even retina yet!

The first table that made it to production is hilariously a single Angular file that takes a config object and renders the HTML by plus-equalling a string all the way down… Yeah, you heard right. I assume this was for performance reasons (because Angular), but it’s also complete madness. At the same time, the code is well-organized and pretty easy to grasp, but here’s the best way to put it: I wouldn’t want to see this code on the first day of my new job.

The next iteration of the table was a CoffeeScript class that gets extended and uses getter methods for everything. Again, too clever and requires a sherpa to find your way around the code, but at least I used templates this time (with lodash) instead of manually concatenating a string. I did notice, however, that I completely abandoned semantics with this version by ditching <table> tags in favor of living in <div> city for easier styling. Little did I know you can have the best of both worlds with semantic tags, easy styling, and proper accessibility, but I didn’t learn that until years later.

The most recent iteration of the table (albeit five years ago) uses Vue 2’s Options API and Mixins. This approach had a lot going for it because of Vue’s templating and reactivity, which was a huge leap forward because I no longer needed to manually re-render the HTML with every change. I still relied heavily on config objects, but they were now computed properties, so I also didn’t need to directly call getter methods like before—I simply looped through the data and referenced the properties.

My overall gripe with this version was the use of mixins. I never loved mixins in Vue because it’s never clear what a mixin is doing under the hood unless you dig through the code. This makes troubleshooting and searching for specific references really difficult—especially when a mixin creates props or reactive data. This is also why I’m head-over-heels for Vue’s composition API because, combined with composables (aka “hooks”), everything you need to reference is exposed, and it feels like writing straight vanilla JavaScript—nothing is buried and nothing feels “magical” (in the way that you can’t understand or troubleshoot it).

Ok, phew. This brings us to today. I’m building a table for the nth time, but the scenario is different:

• I have 10 more years of experience under my belt

• I now fully test the frontend, which helps to weed out “clever” code

• I’m committed to semantic HTML and accessibility, so the markup will be “proper”

• I’m using Vue 3 with the Composition API, which is the closest Vue’s syntax has gotten to clean ol’ vanilla JS

I haven’t finished building the table, so this post is somewhat premature, but there was plenty of “history” to share before writing about the latest iteration. That said, I’m making great progress already.

I mentioned before about using <table> tags with proper accessibility and flexible styling. Here’s what I meant. If we keep the <table> as display: table, styling is affected by the default table styles, which make certain styles impossible, like putting a bottom border on a <tr>. If, however, you set the table’s display to grid or flex, you can gain the styling flexibility, but you also lose accessibility—the table will no longer have its “table” role (in Safari, at least. It looks like other browsers no longer drop the role as of the time of this writing). Fortunately, it’s not difficult at all to reinstate accessibility roles for the table by simply setting the role attribute on each element. Every single table element has its own role value, and since I’m writing my own components for these elements, it couldn’t be easier to set these roles once and have them applied everywhere. I could actually write an entire post about this, but… it’s getting late, so I’m going to stop here.

While I do feel great so far about how I’m building this table component, I know I’m still in the easy stage—I have yet to implement any interactions, including sorting, drag & drop, or context menus, so there’s still plenty to work through. That said, I feel like I’m in the best position I’ve ever been in to write the most future-proof version of this table yet. And I know—it’s just a table. But when you’ve iterated on a single component over the course of a decade, recreating it every few years with the latest tech becomes a fun exercise, like building a to-do app with different frameworks. Or maybe I’m strange for thinking this is fun… It is fun, though, …right?

Reply via email

I still remember this ironic tweet of mine and how I fell right into this hole:

Now that I’m rethinking everything, I’m eager to go back to basics with a navigation that limits—or rather contains—the scope. The original tab-based navigation for Cushion actually fits the bill pretty well, as it’s confined to the max-width of the app, but it’s also influenced by the tab count. Three tabs look great. Four tabs is pushing it. Five tabs?—time for a long look in the mirror. That’s probably an extreme take, but this time around, I’m really aiming for laser focus.

For Cushion, if I want tabs for “Clients”, “Projects”, and “Invoices”, then a few admin tabs, like “Account”, “Preferences”, and “Billing”, I can simply put those in separate views, like I did with the original Cushion—one view for actually using the app and the other for admin. Clicking the user’s name in the header takes them to the admin view and swaps out the tabs for the admin tabs. Then clicking Cushion’s logo follows the standard of returning “home” to the main view of the app, where the feature-focused tabs are shown.

Going back to tab count for a moment, while I do think three is the sweet spot for feature-focused tabs, I actually don’t have a problem with a higher tab count for admin views. The user doesn’t spend nearly as much time there as they do in the actual app, so I’m not bothered by a few extra tabs for clarity—as long as the user can get to where they need to go in two clicks or fewer, I’m happy.

Since I’m looking to return to simpler times while also modernizing and improving Cushion along the way, one consideration I’m thinking about is personalization through color. The existing Cushion is pretty grey, but the original Cushion was very grey. That said, once the user starts filling up the graphs with client colors, the grey fades into the background as a canvas. In any case, I’m toying with the idea of introducing a personalized “theme” color that could be unique between users. Strangely, Cushion has always had a setting for the user’s favorite color, but I never ended up wiring that to anything. While I’m currently focused on the navigation, this might be a good time to tie the theme color to the UI.

By using the background of the top “header” area for the theme color, I could introduce personalization while still maintaining a neutral canvas for the graph below it. The tabs would then need to embrace black or white alpha colors instead of using a greyscale, and I’d need to add logic for determining whether to use black or white text to maintain strong contrast, but that’s easy enough. The real question would be whether I provide a preset color palette to ensure the UI looks good or allow custom colors. The answer to this might be the “why not both?” meme.

I’m off to a good start with this navigation already, and I feel good about its longevity. I am anticipating several edge cases, like clicking into an invoice and how to handle that with tabs, but I’m not worried—there are plenty of best practices to lead the way and I’m not looking to reinvent the wheel.

Reply via email

Personally, I’ve never had a problem thoroughly unit testing components, but when it comes to code that interacts with the API—where you should rely on end-to-end testing—I always feel the weight of the initial setup and tell myself I’ll do it later, but never do. With the existing Cushion, if I wanted to set up e2e testing at this point, I’d need to find a way to run all the servers within GitHub Actions, which is a daunting task (for me). Alternatively, I could do what plenty of folks probably do, which is to run their e2e tests against the staging server. Then, you just need to make sure you clean up after each run.

Since I’m starting from scratch—and determined to start on the right foot—I can keep e2e testing in mind from the get-go. Of course, I’ll also unit test components, but the coverage from e2e tests will be invaluable for sanity-checking the actual user flows. It’s far too easy for unit tests to pass while an unwritten e2e test would be failing—especially if you resort to unit testing API interactions with spies, but your API changes and your spies don’t. (I can hear a few of you nervously laughing right now…)

By using Supabase as my pseudo-backend that provides a direct client-side connection to the database, it’s much easier to set up e2e testing from the beginning (as long as their API is available). They do also have a self-hosted version if I wanted to go full neckbeard, but hosted will suffice for me.

As for the test harness, I’m using Playwright, which has emerged as the go-to option for e2e testing. There are others, like Cypress, but I feel like Playwright speaks more my language and would be familiar to anyone who has used Jest or Vitest. For those who haven’t written any e2e tests before, it’s actually fun. You simply write line-by-line what the user should do, like “go to this page”, “find this input”, “fill it in”, “click this button”. Obviously this is pseudocode, but the actual API reads just as easily. Playwright also has a codegen feature where you can record yourself clicking through the browser and it’ll write the test for you. Seriously, with features like this, you have no excuse.

So far, I’ve been able to fully test the auth flow as well as an initial setup form. These two cases have given me enough experience in this new stack to know how to quickly handle most situations. Along the way, I’m even writing helper functions, like one-line sign in, etc. The only hiccup I’ve come across is how best to reset the database, so I can do a clean run each time. I’m sure you can run a query on the database directly before or after the tests run, but instead, I saw this as an opportunity to implement a feature folks have asked for in the past—resetting an account.

For Cushion, users often become subscribers for a couple years, then they might take a full-time job and no longer need to freelance or use the app. Several years later, they might return, but want to start fresh with an empty account instead of returning to their old data. This is where a reset feature comes in handy.

I do realize that this is a dangerous feature and resetting your account is not something to take likely—especially for the users who have been with Cushion since the beginning. With those folks, we’re talking about almost 10 years of data. Because of this, resetting your account will certainly come with a safeguard in the form of a dramatic “Are you sure?” prompt that makes you type exactly what this feature does. I imagine I’ll eventually opt for a database query to clear the database to save time on click-throughs, but for now, this works and unblocks me.

Next up, I’ll start to dig into the actual app by setting up all the models as I need them, and make something usable. I’m excited!

Reply via email

The existing Cushion is hosted mostly on Heroku—a once-exciting platform that now seems stuck in 2010, when it was acquired by Salesforce. There’s still a lot to love about Heroku, but I’m looking elsewhere this time, in the direction of Vercel. This is a no-brainer for me and not much of a risk because I’ve been using Vercel for pretty much every website I’ve hosted over the past several years. The speed and ease in which you can go from repo to hosted website—with automatic deployments between dev, preview, and prod—is the way the web should be. That said, this will be my first time hosting an actual app with real users on Vercel—beyond a marketing site or a hosted form—so I can’t say I’ve had to troubleshoot something going wrong on Vercel. At the same time, I plan to greatly simplify the backend because it honestly doesn’t need much beyond what can be done in the database. And that’s a perfect segue into our next topic—the database.

Since the start, Cushion has used Postgres as its main database, and I have no regrets with that choice—I’ve always been a relational guy and Postgres only seems to get more and more feature-rich with each and every upgrade. The world around Postgres has gotten pretty interesting over the years, too, with database providers making the new Postgres features more turnkey. This is why I’ve landed on Supabase as my database provider. I have no problem coding a backend, but as soon as I saw that you can use a Postgres database directly from a static frontend and it handles authentication?—I was sold. On top of that, Supabase takes care of the hairiness of Postgres’s realtime features, so you can subscribe to messages, presence, and database changes with a simple client-side listener—sold again. These features unlock so much potential for a modern Cushion, and Supabase makes the features so easily accessible that I can casually experiment with a random idea before feeling like I need to commit.

Now that I’ve touched on the backend—or rather the lack of need for a traditional backend—let’s look at the frontend. Anyone who knows me knows my preference for Vue, so this is another no-brainer. Oddly enough, though, the majority of Cushion’s frontend actually isn’t Vue. When I first started working on Cushion back in 2014, Vue was only starting to make a name for itself. I gave it a shot for a few trips around the block, and while it was fun, exciting and new, Vue didn’t have the maturity I was looking for, so I friend-zoned it. I ended up playing it safe with Angular (v1.2), which shared some similarities with Vue at the time, but was also structured like the MVCS (model, view, controller, service) architectures I knew and loved in the AS3 days. While I found that appealing at the time, I can assure you my interests have since changed. A few years into using Angular, I fell out of love because of its complexity and sluggishness. Fortunately for me, Vue had grown up a lot in those years, seemingly waiting out my relationship with Angular. We’ve been together ever since.

While most of the Vue code that lives in the existing Cushion is Vue 2 with the Options API, I’m using Vue 3 with the Composition API, which is so much more TypeScript-friendly and reads like vanilla JS. When using <script setup>, any const or function is exposed to the template automatically, so it’s immediately familiar to any straight-JS dev and even more inviting than it was before. I could wax poetic about my love of Vue, but I’ll stop right here and save you all.

When we talk about frontend, we unfortunately still need to talk about bundling. Back in 2014, the initial build scripts for Cushion’s frontend used Gulp—remember Gulp?? Gulp existed well before we had hot module replacement, but we did still had LiveReload to refresh the entire page on save. For several years, I tried to migrate to Webpack, but gave up each time—those who have also tried know what I’ve been through. Then, in 2019, I successfully switched to Vue CLI, which does use Webpack under the hood, but at least provides a wrapper around it to make it less painful. Still, with an Angular frontend that has Vue embedded throughout, there was no way I could get HMR to cooperate.

These days, Vue CLI has been replaced with Vite—an incredibly quick, easy-to-setup, and extensible bundler and dev server from the folks behind Vue. I’ve been using Vite ever since building ProtoPen, my prototyping environment when I worked at Stripe. Like everything Vue-related, it speaks my language, and I just get it from the start. I’ve tried other frameworks over the years, like Nuxt, but the magic that happens behind the scenes always ends up causing problems down the road, and I always find myself needing to troubleshoot magic. To save myself the future headache, I’m keeping it simple, and sticking with straight Vite.

That’s all for the initial setup. We’ll see if these choices stand the test of time.

Reply via email