Dev

Rewriting the Timeline

Jan 06, 2015

Back in December, I went down the long list of to-dos for Cushion and thought I’d tackle one I’ve wanted for a while now—project blocks. I wrote about this before and laughably estimated a few days to finish it. Any dev knows estimates are meaningless and any guess would require multiplying the original estimate several times.

So here we are. It’s January and Cushion doesn’t have project blocks yet. I’m about halfway there because a few days in, I realized if I wanted to do this right, I would need to rewrite the schedule timeline. I originally wrote it for the budget, then made it work for scheduling, redesigned it a few times, added a few more elements, and rigged it to somehow work with invoices. I was left with a monster that looked nice, but felt like a long-running Jenga game.

After hours of just staring at the screen, internally debating with myself, I knew rewriting the timeline was the only way. I started thinking about what the timeline even represented, now that I was months along with the beta. Does the name still make sense? Up until now, I considered anything in the top-half of Cushion to be “the timeline”—even the budget bar was a timeline to me, despite its lack of time.

2015-01-06-graph

This wasn’t right. I took a step back and pretended for a moment that I haven’t been working on Cushion for almost a year now. I looked at the scheduling timeline and pieced it apart. What were its components, if one were to separate it into reusable parts? It has “ticks”, or axes, at the top and bottom, but so does the budget bar. So, then the ticks shouldn’t be considered part of the timeline. I would need to step back even further.

2015-01-06-timeline

Remove the ticks, remove the container, and you have the timeline on its own. And, the budget bar without the ticks and container is just the bar. Both of these are just visuals that could stand on their own, but are even more useful when adding the grounding and labeling of the container and ticks. It’s almost like a graph... Wait, it is a graph! A graph has axes and visuals—so do the schedule timeline and budget bar. I can’t believe I didn’t see it this way at first, but once I did, everything came together.

2015-01-06-shapes

Instead of giving meaning to everything in the timeline, like outlined dots for estimated dates and solid dots for actual dates, I would remove the context completely and treat it like a real graph. These dots are just dots with an x-position—nothing more. An outlined dot is a “weak” dot; a solid dot is a “strong” dot. The lines that were once named after their data, like duration, delay, drag, etc., are now just lines with an x-position and a length. The arrows that once represented the current date of an active project now have no idea they represent anything—they’re just arrows.

The more I abstracted the timeline, the easier it became to write both the logic and the styling. Previously, I had tons of CSS classes, like .estimated-start-dot and .remaining-duration-line—many of which shared the same qualities, like both delayed projects and early invoices being a light line. Now I didn’t need to be that descriptive. As a result, the style code was reduced to a fraction of what is was before.

Instead of bundling all the logic within the timeline, I pulled it all out and left the timeline with one job—draw. I would no longer feed it projects and invoices. I would just send it points. Then, outside the timeline, the real logic would live in factories and generate the points for the timeline. The timeline now has absolutely no concept of anything besides drawing shapes between two points and I can easily swap out the data I send it between clients, projects, and invoices.

I know abstraction is programming 101, but when you start a project and rapidly develop it as the idea grows, it’s hard to predict where the project is going. It’s even harder to take time to step back and reassess everything. I got to the point where the only way to proceed without a constant headache would be to rewrite the timeline.

Looking back, as soon as I decided I would need a second timeline for invoices, I should’ve stopped and realized I shouldn’t try to make the timeline do everything. It became too much and resulted in me unexpectedly losing a couple weeks of forward progress. On the bright side, I now have a solid system in place for future “graphs”. Schedule timelines and budget bars are just the beginning.

Share this on Twitter or Facebook

Archive

  1. Funding Cushion
    Story
  2. Hiring a Team of Freelancers
    Story
  3. Taking a Real Break From Work
    Story
  4. Slack as a Notification Center
    Dev
  5. Document Your Features
    Story
  6. 300
    Story
  7. Vacations
    Design
  8. Offering Discounts
    Design
  9. Waves of Traffic
    Story
  10. Less Blogging, More Journaling
    Story
  11. Retention Through Useful Features
    Design
  12. The Onboarding Checklist
    Design
  13. Spreading the Word
    Story
  14. From Beta to Launch - The Subdomain
    Dev
  15. From Beta to Launch - Sign up
    Design
  16. From Beta to Launch - Messaging
    Design
  17. Launch
    Story
  18. Authenticating with 3rd Party Services
    Dev
  19. Intro to Integrations
    Design
  20. Inspiration vs Imitation
    Story
  21. The Emotional Rollercoaster
    Story
  22. Designing Project Blocks
    Design
  23. Everything in Increments
    Story
  24. Deleting Your Account
    Design
  25. Designing the Subscription Page
    Design
  26. Rewriting the Timeline
    Dev
  27. Restructuring the Individual Project Page
    Design
  28. Project Blocks
    Story
  29. Redesigning the Homepage
    Design
  30. Multiple Timelines
    Design
  31. Archiving and Estimate Differences
    Design
  32. Multiple Financial Goals
    Design
  33. Zooming in on the Timeline
    Design
  34. Currency
    Dev
  35. Preferences, Accounts, and a Typeface Change
    Design
  36. Sending Out the First Email
    Story
  37. Currency Inputs, Notifications, and Invoice Nets
    Design
  38. Dots and Lines
    Design
  39. Calculating in the Database and Revealing Tendencies
    Dev
  40. Improved Form UX
    Design
  41. Cushion is Online
    Story
  42. Schedule Timeline Patterns
    Design
  43. A Slimmer Schedule Timeline
    Design
  44. The Schedule Timeline
    Design
  45. Plugging in Real Data for the First Time
    Design
  46. Transitions and Project Lists
    Design
  47. Death to Modals
    Design
  48. The Individual Project Page
    Design
  49. Estimated Incomes and Talks with Other Freelancers
    Story
  50. Statuses to Lists and the Paid Beta
    Story
  51. The Timeline
    Story
  52. Invoice Terminology
    Dev
  53. Modal Forms
    Dev
  54. Wiring the Backend to the Frontend
    Dev
  55. Balancing Design and Dev
    Story
  56. Timecop, Monocle, and Vagrant
    Dev
  57. Going with Ruby and Sinatra
    Dev
  58. Ditching local-first and trying out Node.js
    Dev
  59. Switching to AngularJS
    Dev
  60. Building the Table with Vue.js
    Dev
  61. Clients, Projects, and Invoices
    Dev
  62. Introduction
    Story

Ask a Freelancer

A podcast series where experienced freelancers answer questions about freelancing.

Listen to the Podcast

Talking Shop

An interview series where we talk to freelancers about important topics in the freelance world.

Read the Interviews

Running Costs

Take a close look at the costs that go into running a web app and why we use specific services.

View the Costs

How It’s Made

Follow along with the journal for insight into the overall experience of building an app.

Read the Journal