Don't want to read? Jump to the tl;dr.
Please Respond by Saturday (3/29)
Ankit has designed super-detailed mockups of Tea With Strangers User Flows from attendee and host perspectives, available here. I've used these to identify the four core functions of the TWS Platform:
V1 Goal: a landing page that gets visitors to grok Tea Time.
Long-term, Ankit and I have discussed expanding to include host and attendee Tea Time memories, heatmaps that show Tea Time activity and prove strangers are Not That Bad™, etc.. This is mentioned only so we remember to keep such data accessible down the line.
- Screens:
- What’s Tea Time?: information-station-*.png
- Landing: splash-*.png,
A tea time with one person isn’t tea time…it’s someone sitting alone at a coffee shop checking email with some obscure command-line mail client, and we can all agree there’s enough of that in the world.
We need hosts and attendees to register in droves; put on your user onboarding hats folks!
- Screens:
- Attendee Creation: createaccount-*.png
- Host Creation: createhost-*.png
- Host Info: hostpage-01.png
V1 scheduling is easy. It's merely:
- Host enters availability+location+capacity
- Display remaining capacity+location+times to users.
- Users register for a scheduled tea time
- Registration stops once capacity is reached
- Transactional Emails and Calendar Events go out to Attendees+Host. Reminders get sent sometime before event
However, this has potential to become wicked interesting as TWS grows. Additions could include: waiting lists, proximity based reminders for last-minute cancellations, dynamic scheduling that allocates newbies and tea time veterans in equal measure, and plenty more.
- Screens:
- City Overview: citypage-*.png
- User Scheduling: scheduling-*.png
- Host Availability/Scheduling: createhost-0[5,6,7].png
- Cancellation: createaccount-0[3,4].png
V1:
- Send email reminders 24 hrs in advance
- Attach an ICS/Appointment upon initial signup with the event details
- Devise some other ‘fun’ ways to encourage people to show up. We’re open to ideas!
- Track attendance (the hosts will record) and punish or prod repeat offenders
Ankit’s data indicates people flake all the
time. We’re hoping that the new scheduling system will reduce flakiness, but we
want to bother gently remind attendees as much as possible. Further
suggestions desired!
Now that you’ve a notion of V1's scope (and a bit beyond), let’s talk tech.
We want contributing and extending the Tea Time ecosystem to be easy. Whether that's creating a mobile client, an interactive visualisation of how TWS has grown, or something totally off the wall, supporting mashups and alternatives to 'official' Tea Time experiences is a goal.
Accordingly, I propose we develop API first.
Instead of building a monolithic app, à la 2006-era Rails, we design around an API that our clients will consume. I've seen it in action at Podio (Disclaimer: I worked there), raved about at Trello, and ranted about at Google (RE: Amazon, cf. "Yegge Rant"). Why?
- No post-hoc scramble to graft an API onto a web app to support building a
mobile client or single-page app.
- Forced to consume your own dogfood
- Smaller surface area – separates presentation layer from data.
- Easier versioning, testing, deployment
Once the API is built we'll create the user-facing portion of the site. This would also double as a canonical "How do I integrate with Tea Time?" example. Scheduling wise, it will likely be:
- Weekend One: Build API
- Interim Week: Test+Bugfix as contributor time allows
- Weekend Two: Build User-Facing Front-End
- Post-Build Week 1: Test+Bugfix; Document
- Post-Build Week 2: Public Beta with Subset of Visitors to tea.byankit.com
- Post-Build Week 3: Launch, Pray.
I'm sketching out potential API surfaces but haven't typed anything in case there's vehement disagreement with the above approach.
While I love Turing Complete type systems as much as any PL aficionado, choosing a mainstream language+framework for the TWS platform is better if we desire contributions from outside the initial team.
Thus, contenders are:
- Sinatra: Poster boy of the microframework movement. Lightweight and easily grokkable. BYOB.
- Flask: Is it unfair to call this Sinatra.py?
- Express: My concession to the node people.
- RoR: Everyone and their pet knows it. May be overkill.
- Django: Haven't used since 1.3 days; didn't loathe it. Pythonistas seem to think it's nice.
I've been off in Clojureland and am consequently a bit out of date. If there's something I've missed, let me know and I will add it to the survey polls.
On the front end, our requirements are simple enough that we can get away with a static site and a bit of one-page app style JavaScript magic. Outside of registration and the host/city pages, there's not much that has to be updated.
For this, I'm thinking:
-
jQuery: What could go wrong? Really, our requirements are simple. It's doable with just this.
-
Angular: New, shiny, multiple people mentioned liking it in email exchanges. I'm totally willing to give it a shot.
-
Backbone: I've used it and had a good experience in a similar scenario. Less preimposed structure than Angular, possibly easier for newer contributors to pick up?
TWS Development will likely be API-first with a mainstream framework+language combination. It will occur over two weekends, with the front-end dev occurring the weekend after the back-end is completed. Please critique and propose alternatives.
Before we commit and create a detailed spec, we want your feedback, so fill out the: