vrbtm.co development stream | Week V
Refinement and planning.
Not sure what this is, start here with our README, or catch up on last week, vrbtm.co development stream | Week IV.
Wes and I are working at my girlfriend’s parent’s place this week. Gotta get the work done, wherever you are.
I’ve got some minor coding tickets to take care of:
- Convert plaintext transactional email templates into HTML
- Remove autopublish package
On the non-tech side:
- Feature mapping
- UX and visual design exploration
- Standardize stream of consciousness articles
HTML transaction emails first. Wes pointed out that the emails were coming through unstyled even though we were using the templates defined in Sendgrid. He did some research and found that it could be one of two things:
- The application is setup to only send plaintext emails
- The email client you’re receiving emails on is setup to only render plaintext emails
Option 1 is far more likely. I remembered setting a text/plain mime type when configuring Sendgrid objects. Changed that to text/html and they started coming through as HTML. Graci Wes for the assist.
Next up, removing the autopublish package. Meteor is pretty dope. It’s really set up for you to sprint. All data from your database is accessible on the client side with the autopublish package and editing the database from the client side is enabled with the insecure package. It’s strongly recommended to remove both when deploying to production. AfTer doing so, set up subscriptions and publications (in place of the autopublish package) and define server-side methods for database operations (in place of the insecure package).
I’ve already removed the insecure package in Week III. It’s now time to remove the autopublish package. Doing so will really lock down our passcode mechanism. Following the Meteor React tutorial’s suggestions here. Hmm, maybe not exactly. I’m placing the publication code in server/main.js instead of within imports/api/content/collection.js. It eliminates the need for the Meteor.isServer conditional this way. Subscription code goes within the container code in imports/ui/pages/ContentDetail.jsx.
Alright, this means that the Passcode collection never reaches the client. The Meteor methods for Passcode manipulation are all locked down to the server side only. Content is the only collection that’s accessible on the client side, and is only editable via server-side methods. Locked down and deployed.
Feature mapping. This mainly consisted of Wes and I writing down all the features we’d love for vrbtm to have. We’re now going to plan the next releases up until the paid plan release.
We started off by creating tasks in a Flow project. This was mostly blue-sky, but we tried not to get too ahead of ourselves. We discussed every ticket that was created, looked it over multiple times, removed dupes. Then we ordered pizza.
After that, I broke the tickets into I guess what you would call stories? Or epics? I basically grouped tickets/features together into logical higher level groupings. We then prioritized each grouping. Our next goal is to have a paid offering in five months from now. We (coincidentally) had five groupings, so we planned to push one grouping a month for the next five months. Each push would essentially be a release.
Release dates:
- 20th of November
- 18th of December
- 15th of January
- 12th of February
- 12th of March
So, we’re looking at having a product with a paid offering in March! We started calling each release by it’s month and added due dates to the open tickets in Flow. This lead to the following release plan.
November release: Beefier content detail page.
- Multiple recipients
- Feedback conversation thread
- Versioning
- Content status
- Zendesk message integration
December release: Dashboard and hierarchies.
- User accounts and roles
- Organizations that groups users
- Workspaces that groups content
- Dashboard
- Marketing page moved into application
January release: Resource management.
- Custom expiration dates
- Tracking of storage, number of uploads, users/workspaces per organization, approval rate, etc
- Restriction of resources per payment plan
February release: Payment processing and polish.
- Address book
- Payment processing integration
You may have noticed that I previously said that we’ll be launching a paid offering in March. You may have also noticed that the release plan above ends in February. You may also have been taught that February comes before March.
You’re right. I realized that I might be able to pull off the above in four months instead of five. r/madlads watch out.
Upon finishing the pizza, we had a release plan fleshed out. Things are bound to change, but we’ve got a plan and next steps. That’s all we need. We then started discussing visual design and UX. We’re obviously adding a lot of functionality in the following months and want to stay on top of the design aspect as we roll these features out.
Our pages were restructured into the following
- Landing — marketing page if not signed in, redirected to dashboard if signed in
- Dashboard
- Account — profile
- THE VRBTM PAGE — for lack of a better word, this is where content requests will be sent from
- About
- Plans
- Upsell
- Terms and Conditions
- Privacy
- Contact
We got sidetracked talking about different pricing schemes (variable, static, number of plans, variable or static overages). Then took it back to some information architecture work and mapped out some user and receiver roles.
User roles would be
- SuperAdmin — that’s me, Wes and whoever ends up on the Nonsense crew. Access to all the things
- Admin — access to billing, user and workspace management, and everything below
- Manager — access to content requests and feedback threads within their assigned workspaces
- Creator — reserved for when we start targeting content creators
Receiver roles would be
- Approve/reject — available only if passcode is applied
- Feedback — available only if (different) passcode is applied
- View
If a receiver is a power-user of vrbtm, we’d eventually incorporate Guest accounts but for now, this’ll do. I’ll implement some sort of caching mechanism for passcodes such that receivers don’t have to enter a passcode every time they want to go over a piece of content.
For next week:
- Feedback conversation thread
- Multiple recipients
- Resend passcode(s) to recipient(s) mechanism
- Wires!
Wakatime was a measly 15mins. However, we spent hours going over feature mapping, planning and design. Sometimes you gotta unplug from the Matrix, maaaaaaaaan.
Read the other half of this week with Wes’ VRBTM Looking Forward | Week V.
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
