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!