Credit: Lionello DelPiccolo

vrbtm.co development stream | Week IX

Content status and versioning

Not sure what this is, start here with our README, or catch up on the last stream, vrbtm.co development stream | Week VIII.

Only two tickets to work on this week.

• Content status. This is continued work from last week.
• Content versioning. Uploading revisions after a piece of vrbtm content has been rejected.

First off, content status. VRBTM content goes through the following states:

1. Received
2. Viewed
3. Downloaded
4. Approved/Rejected
5. Received feedback
6. Received revision

Our only notification system is email, so the first two states are basically email read receipts and click tracking. Since we’re using Sendgrid for email management, these are going to have to come from there. States 3–6 are all application-specific and are much more trivial to track.

I’m going to extend the Content collection to include a status object that contains the following.

{
  receivedBy: [], // email strings
  viewedBy: [], // email strings
  downloadedBy: [], // email strings
  approvedBy: [], // ...
  rejectedBy: [],
  updatedFor: []
}

Now all I need to do is update the above when each event occurs. Going to start with downloadedBy because that doesn’t rely on Sendgrid. We currently show the download button without authentication, which means that we can’t actually see who downloaded the content reliably. They might hit the download button before authenticating. Going to change downloadedBy to just downloaded and track the number of downloads instead. This can be refactored later if Wes and I deem a number of downloads to be insufficient.

The tracking of approvedBy and rejectedBy is also straightforward. Simply push an email string. However, I just realized that we’d probably want all recipients to approve a piece of content before it’s actually approved. Going to move the approved and rejected fields into status and refactor the approval and rejection code. Pretty sure this is the third time I’ve had to massively refactor this functionality. Going to do data mapping very soon to settle on a structure that covers all of our #goals.

^ lol. “[…] is also straightforward”.

A piece of vrbtm content is approved iff all recipients approve. A piece of vrbtm content is rejected if any recipient rejects. Furthermore, we should probably add a “void” mechanism if the sender wants to void the current piece of content. That’ll come into play later, when I implement versioning.

Approval and rejection code has been refactored to do the above. Wes and I decided to not implement the Sendgrid-based tracking and instead only track content views by passcode unlocks. The status object has now turned into this.

{
  viewedBy: [],
  downloaded: 0,
  approvedBy: [],
  rejectedBy: [],
  approved: false,
  rejected: false,
  updatedFor: []
}

As for the front-end implementation of content status, Wes has designed a status indicator that’s based on coloring a circle. This works pretty well in quickly identifying what state your content is in. However, when you’re talking about multiple recipients, you might want a little more granularity. I added the indicator into ContentDetail.jsx but also extended the logic to show what is basically a tiny pie chart of status. So, a quarter filled gray circle means a quarter of the recipients viewed the content. A circle that’s five sixths green means five sixths of the recipients approved the content. A circle that’s five sixths green and one sixth gray means everyone’s viewed it, but one sixth hasn’t approved it. It still needs some work, but it’ll do for now. Next time I tackle the status indicator, I’ll refactor it into its own component and use a graphing library.

Content status is fleshed out enough for now. Onto content versioning. Going to tackle the backend changes needed first. We currently have the concept of Content, but the concept of Revisions hasn’t been implemented yet.

Aaaaaand I didn’t get as much work done as I thought this week (again). We’re still on track for our November target. I just need to complete versioning in one session.

So for next week:

• Versioning back-end
• Versioning front-end

Timing was 4h 44m.

I’ve switched from WakaTime to an app called Timing, so these time estimates are about to get much more accurate. WakaTime used to track only my coding time. Timing also tracks the time I spent writing this stream and coding. Obviously doesn’t take into account how much time I stare at a screen thinking about something or trying to focus (which is always at least a couple hours).

Read the other half of this week with Wes’ VRBTM On-boarding Campaigns | Week IX where he knocks out the welcoming email and defines our on-boarding flow.

We’d love to hear from you…
Get in touch at Founders@vrbtm.co, talk with us on twitter @vrbtm.co, and read our story on medium.

Wes Jones is on Twitter @WesJonesCo
Nick Dandakis is on Twitter @Dandakis

Join our email list for Beta access.