Why I Decided to Build My Own Casual Event Planner

 

I’m a gamer and I had a problem. Some might posit that’s a problem in itself, but I guess that’d be a different essay. Regardless, my games were hard to coordinate among my friends. I wanted to fix this problem rather than live with it, so, I had to either find a solution, or I had to create one.┬áThis brief post explains why I ultimately decided to solve this problem myself.

Of course I wanted to solve my own gaming coordination problem, but, if done right, I might also produce value to others for planning of their own casual events.

The problem as I experienced it, was that, having set a date/time/place, and after sending out invitations by email, some annoying followup work was required. First I had to field and collate the responses, and then, either manually or mentally, I had to keep track of the status as the responses from my friends came in. Inevitably, one or more friends would reply to me only, while others would reply-all. Similarly some would phone me their response. Making matters worse, some would phone another person in the group, and not me. Either way, there was no communal knowledge of the status of a session. Furthermore, if a critical mass was attained, or not, it’d up to me to follow-up with another message – this time a ‘confirmed’ or ‘cancelled’ email. This process was clearly neither effective nor simple.

The spec then for the solution I needed was – “…provide a system that simplified planning, automatically tracked and maintained event status, and reduced ineffective communication between organizer and invitees.”

At this point I had reached a make or build decision. If something already existed, then great, I’d use it – if not, well, time to start building!

Calendar apps and planners are ubiquitous, surely there’s one that would meet my spec, right? Google Calendar, Facebook Event, Evite, Outlook and many apps let you easily set date/time/place and send notifications, and most have slick well-tested UI’s Many collect responses, and keep a tally of yes/no/maybe’s, and some even enable a de-confliction phase of planning characterized by back and forth proposals and counters. Remember though, my spec said nothing about deconfliction; I just wanted to float an event and see who bit. My feelings weren’t going to be hurt if an event fell through – in fact, the earlier it crashed, the better for me to move on and plan something else for my time. At best the above offerings solved only half my problem, but often at the expense of fancy UI’s and unneeded features.

Also, my research at the time, and since, for other similarly themed projects revealed a common property. They often seemed to be spec’d to solve the appearance of a problem without actually getting to the heart of the matter. For example, and this is often the case with design class projects, the spec was loosely written in the form “…simplify the decision process for the organizer and attendees of casually planned social activities.”

Solutions* emerging from the above type of spec often looked nice, and seemingly would provide nominally useable features. Still though, they did not address the fundamental problem I had which was, “what is the status of my event, how can I convey that as easily as possible.” Simply put, these solutions produced systems that had been cobbled together from what available technologies and frameworks could provide, rather than what they needed to provide. Some solutions actually complicated the process rather than simplify it with the proposal/counter-proposal feature.

To help visualize things here are a few models:

  • Based on my spec, these are the functions I needed in my planning system, presented in the form of a Data Flow Diagram (DFD):

20151025_102254

  • This highly simplified DFD captures the functionality in many of the mainstream offerings:

20151025_102332

  • Finally, the Use Case diagram on the left is representative of “the offerings” and on the right, my user interactions of “my system:”

20151025_102356

Without having been explicit before now, the focus of this post is to draw attention to the functional analysis and resulting models done to respond to an informal spec. What I think has happened, especially in the offerings alluded to here with the purpose to simplify things, is that focus has been placed on the life-cycle of the planning process, rather than emphasizing the life-cycle of the event itself. This is true at least so far with respect to addressing the problem I had first identified and specified.

I haven’t attempted to describe “how” I have solved my problem; that will be better addressed in a followup post.

Instead, I hope the post adequately describes “why” I felt I had to take the initiative to solve the problem for myself, which, as it turns out, is the very definition of a “home-grown solution.”

With that said, you are welcome to try out my solution for yourself – it is available as a fully functional Beta at Zejoop.com

* Note: DCDR, Google Fiesta, Tossup, Planito (among others) are examples of well-intentioned projects or offerings that may be viable for others, but do not meet my spec for simplicity.

Visit Zejoop Now, and Start Planning!

Exhausted

The previous post mentioned another submission to Y Combinator; this time for Winter session 2016.

Even though I started early enough that Tuesday should have been a breeze – only should require enough effort to apply finishing touches – it turned out to be anything but. All of Monday was consumed making a Zejoop demo video, required because there’s been none previously and that probably reduced chances of success. Then Tuesday morning in its entirety was creation of the founder intro video. Both required many takes, but all told, they turned out great!

Then at maybe 2 PM Tuesday afternoon, a mere 6 hours before the deadline, I attempted to open my draft application on the YC ‘apply’ site. But then, BAM, it was empty – I had to redo all the previously invested work. Frustrating.

Anyway – finished it – was happy with the result. This feels like my strongest attempt so far. I’m very proud of how far I’ve come – Zejoop presents well, and I’m happy about that. The YC outcome is out of my hands now. May the hard work pay its reward.

Once Again, a Y Combinator Application

After two days of marathon video production, and enduring the shock of hearing “the draft application you thought you saved, and which only needed some minor cleanup was lost and is irrecoverable” I’ve once again submitted to a Y Combinator session, this time Winter 2016.

Here’s the proof:

every shot you don't take is a miss!

Video production you ask? Well, simply put the application requires [1] a short ‘founder-intro-video’ and [2] I created a ‘demo’ video to give an overview of Zejoop features and give a walk-through of a typical event planning example.

Stay tuned; notices for interviews in November will go out on the 28th of this month – exciting!

Wanna see what all the fuss is about? Check out the new landing page, create an account, and start planning! It’s fun and easy!

Visit Zejoop Now, and Start Planning!

Please help get the word out, and share on social media using the widgets!

Zejoop Casual Event Planning is for You!

cropped-cropped-2014-11-17-zejoop-logo-on-hoodie.jpg

Just when you thought there was no answer to your frustrations planning casual events with your friends, along comes Zejoop!

You already know it – planning by email or text alone doesn’t work! Use Zejoop, and start having fun with your friends. Avoid the mis-communication and headaches using built-in features that track event status and automatically confirm or cancel your meeting! It’s easy, and for most users, it’s FREE! Check it out!

Visit Zejoop Now, and Start Planning!

(please share on social media using the buttons below, thanks!)