Design

Designing Project Blocks

Mar 22, 2015

Back in December, I wrote about the initial concept of “project blocks”. To summarize, this feature would be a first step towards a more detailed view in Cushion. At the time, projects only had a start and finish date, but with blocks, you’d be able to know what’s happening throughout a project. When is it most intense? When is it at a standstill? When is it focused on sketches or revisions? These are the questions I wanted to answer with project blocks.

With an established design for the schedule timeline in place, I started to think about how to best integrate project blocks while staying consistent with the other visual elements. I wanted to emphasize a project’s workload when it was heavy and de-emphasize it when it barely affected my week. This lead me to pursue scale as a method for differentiating these two kinds of scenarios and everything in-between.

2015-03-22-timeline

Looking at the timeline, I had a lot of negative space. I had room between rows where I could utilize blocks. When a specific region of the timeline was piled high with intense projects, I wanted this area to feel congested. It should look overwhelming, so you feel more inclined to try to avoid those situations. I use this same approach with late invoices—animating the line with distracting movement to encourage users to seek closure.

2015-03-22-project-blobs

Since project blocks are still an approximation, using start/end dates instead of hours, the visual shouldn’t be as exact as a hard edge. I intially worked with transparent “blobs” around projects. These gave a really good sense of intensity for a project and certainly overwhelmed me when seeing it applied to the month that caused me to start working on Cushion. This felt really good for a few days until I realized it just wasn’t right.

The first clue emerged from thinking about how users would resize project blocks in the timeline. At first, I thought I’d be able to reuse the same date input fields from the project form. I thought wrong. Instantly, I felt the burden of adjusting a block. Since these are elements you’d want to tweak occasionally based on estimated date ranges, specifying exact dates made no sense. The user should be able to easily resize them by eye, through a more “hands-on” interaction, like drag and drop. This made me second-guess using blobs because...where do you drag? How do you know to drag? This blob shape made more sense as a static highlight—not an interactive element.

2015-03-22-blob-circle

The second, and more important, clue detering me from using blobs was that they were too encroaching on the horizontal space. On longterm projects, blobs looked great, but shorter projects were deceiving. For a one-day project, the blob would be a full circle, which appears to span a week on a year-long timeline. That initial decision to avoid a hard edge resulted in a bigger problem—innaccuracy. I’d much rather have an accurate visual than a better-looking lie.

Since the first beta accounts were coming to an end soon, I decided to shelve project blocks for a few weeks while I worked on subscriptions. When I returned, I had a much clearer idea for approaching project blocks—using a rectangular “block” shape. It was a “duh” moment for sure, but a block shape fixed all of the existing issues.

2015-03-22-project-blocks

With a hard edge, the blocks now represent an accurate date range. And, I was able to avoid an overly rigid look by rounding the corners a tad.

2015-03-22-heights

Along with the horizontal issues, the blob shapes spanned both directions on the vertical axis, so similar block intensities were more difficult to distinguish from each other. Since these new blocks rested on the lines of the projects and grew in a single direction, they were much easier to compare.

Moving from visuals to interaction, I worried about the drag and drop. Before actually working on the drag and drop, I was unsure how to approach it. I knew I wanted to be able to resize the edges and drag the entire block, but I also knew there’d be a slew of hurdles along the way. As soon as I started implementing it, however, the hurdles shrunk in scale. One after another, the problems I anticipated ended up much less significant than I intially imagined.

2015-03-22-resizing

The issue of indicating to the user that they can resize a block was as easy as darkening the edges. This suggested that the edges of the block were different from the rest of it. Upon hovering the edge, the cursor changes to the horizontal resize icon, revealing to the user that they can interact with the block. Then, as they drag an edge, a small tooltip appears, marking the date that the edge represents.

2015-03-22-repositioning

Repositioning a block follows the same flow. Hovering the draggable area of the block switches the cursor to the drag icon, and upon dragging, a tooltip appears, marking the range of the block. For an extra touch, I added an ease to the edge positions, so whenever you release the block from resizing or repositioning, it will smoothly snap into place.

Up until this point, I’ve been focusing mostly on the horizontal aspect of the blocks, but the vertical intensity is just as important. Luckily, this was much more straightforward. I figured draggable resizing of the height would be overkill because the height ranges only ~40px. Because of this, I decided to rely on the form for vertically resizing a block.

Since the height of a block is directly tied to its intensity, it makes sense to use units that most freelancers are familiar with—hours and days per week. For the hourly freelancers, you can choose from 1, 4, 8, 16, 24, 32, and 40+. And for the freelancers who work on a day-rate, like myself, you can choose from 1 hour, half day, 1 day, 2 days, 3 days, 4 days, and 5+ days. I also offer a preference to use both, in case you switch based on the type of project.

2015-03-22-dropdown

While adding the dropdown, I realized I would need to reflect a change in the timeline upon selecting a different value, so I wired the timeline to the form and animated the height of the block when updating the intensity.

One piece still remained—phases. If I were to stop now, project blocks could work pretty well for most freelancers. The ability to indicate the intensity of a project goes a long way, but there’s another type of freelancer who works in terms of phases. They might start with sketches, then move onto designs, and lastly work on revisions until arriving at the final deliverable. With blocks, this is as easy as adding a label.

2015-03-22-phases

In the form, I added an optional input field to label the block. Upon hovering the block in the schedule view, a tooltip appears, displaying the name of the block along with its intensity.

With project blocks, Cushion adds another level of detail to your schedule—break projects into phases, differentiate a heavy project from a light one, or account for that few-month lull in the middle of that longterm project. Thinking ahead, I have a few more ideas for blocks. I won’t go into them now, but if project blocks are for visualizing estimated intensities of a project, imagine integrating them with time-trackers to measure the actual intensity. Interesting, indeed!

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