Welcome to the first blog post pertaining to my event planning app. This also happens to be my first blog post ever!

Initial Design

Setting the Stage

One morning I had an idea for a website. I knew the idea had some potential because it was simple. When planning for a project, any project, why do we keep track of a litany of calendar events, documents, spreadsheets all separately? This seems to always lead to redundancy, stale data, and people being out of the loop. My particular struggle with this reality was deeply embedded in my role of Science Orientation Coordinator for my University’s Orientation Week. Volunteering as a member of a 17 person team, it seemed to me as though the de-facto standard was to use simple Slack channels to discuss complex, multi-tiered issues, to arrange lists in numerous, often outdated spreadsheets, to use Facebook, email, Slack, and Google’s document chat feature to communicate about overlapping topics. Ok, I admit, I’m being a tad bit dramatic; it wasn’t actually that bad. But I knew there must be a better way. This post is going to walk through the ideas I had in a broad, conceptual level. The details of any existing or possible implementation will not be discussed, as I feel that those belong in their own separate post.

Events

A core philosophy behind the inception of this idea is that everything begins from the end. Just like you plan for a journey based on the destination, you should plan your planning based on the final event. In the case of orientation planning, the end goal is very clear: run orientation week. As you’ve probably deduced already, orientation week doesn’t occur only on a single day and is rather spread out over multiple, but for the sake of this example, orientation week is taking place on September 5th.

Firstly, let’s create our orientation week event. It’s called “Run Orientation Week” and occurs on September 5th, 2017.

Now of course, we can’t just jump straight from today to running orientation week without planning anything in-between! Let’s add an intermediary planning event called “Initial Planning” that takes place on May 3rd, 2017. To do so, all we have to do is branch off the main event and create it!

Adhering to this design, within the context of any event, you can branch off and create any number of intermediate events that are traversable through the graph and that always connect, in some way, to the final event. Now it doesn’t take long for this to get complicated:

But that’s where the second key concept comes in.

Fleshing it out

Scoping

Few people, if any, need to be involved in every single one of the events listed above. Continuing with this example inspired by the process of planning orientation week, let’s have our team of admins, Jeremy, Lisa, and Ann, be each responsible their respective coordinator: John, the leader coordinator, Lucas, the swag coordinator, and Alex, the food coordinator. We can then colour in which events belong to whom. Note that the admins attend the their respective coordinator’s events and the executive ones as well.

Now we can redraw the graph from an individual’s perspective to clean it up and provide some clarity into what’s going on. The following views are from John and Jeremy’s perspectives respectively:

And thus the power of scoping is revealed. Each team member sees only what they need to see and individuals who wear many hats can view their various roles together, seamlessly.

Delving Into Events

At this point we’ve discussed events and how they relate to each other, but I haven’t actually defined what an event is. In a general sense, an event adheres to five general stipulations.

1. An event that is not the final event must have at least one child event which takes place after it
2. An event may have one or more parent
3. An event must be attended by one or more person
4. An event may include documents
5. An event may contain discussions which belong to that event

Rule #1 results as a natural consequence of this tool’s core idea; all events must lead to the end, unless of course, they are the end. Likewise, in a similar fashion, rule #2 then follows. Both of these concepts are illustrated in the graphs above. It also goes, almost without saying, that an event with no participants doesn’t really accomplish anything. Thus we get rule #3.

Rules #4 and 5 touch on documents and discussions, other core concepts to this tool and which each deserve their own section to explain.

People

Before moving on to talk about documents and discuussions, I’d like to spend a little more time talking about people. I have a couple of ideas for how people should interact with events but haven’t nailed down all of the details of this quite yet. My general idea is that people will belong to groups which may be implicit or explicitly defined (the former would be created for any combination of people, the latter if a group was created and named by someone). According to this model, each event would be attended by a group, which consists of one or more individuals. This would make it easy to visualize the flow of events and to build relationships between them. In addition to groups which attend events, there would have to be a seperate category of groups with more refined permissions such as the ability to create, modify, and destroy specific events (anyone can create, modify, and destroy their own personal events). For example, in our orientation scenario, perhaps one exec, Ann, is actually the head honcho, and is charge of planning and managing full-team and exec events. In this case, she would have to belong to yet another group, outside of execs and swag, for people with administrative privileges.

Documents

For sharing large pieces of data, documents are among the most important and commonly used means for communicating complex ideas in the 21st century. In the traditional sense, documents can be describe as being “a written, drawn, presented, or memorialized representation of thought” (Wikipedia). Nowadays, documents are largely digital and with the advent of google docs (and other such services), are frequently created and maintained by multiple people.

In the context of planning for an event, documents may be:

1. Used as tools to facilitate event planning by storing and/or sharing data used in the planning process (transient), or
2. One of the goals for the final event, whereby data is being accumulated and worked on until its final presentation (cumulative).

Taking those scenarios within the context of events, documents can then:

1. Cease to be passed down at some point, or
2. Arrive at the final event.

In our particular example, a transient document might be food list, which is created by one of the admins and then used by Alex, the food coordinator. Once the food has been ordered and that particular event is over, the document no longer needs to exist so it’s not passed back onto the child of that event.

An example of a cumulative document in this case would be an event schedule that perhaps needs to be printed for every leader. The schedule can be worked on and refined by the admins over multiple exec meetings until it is ready to use during Orientation Week.

As you may see in the image above, I’ve chosen to represent the “Event Schedule” document a little differently this time. Instead of imagining that all of the execs (and other participants) sat down and wrote out their plan for each event in one sitting, it would be more realistic to think of them planning bits and pieces over many days.

A couple advantages of this approach regarding documents is that:

• Documents can be easily edited, and their changes tracked, from multiple perspectives and points in time, allowing for a complete reconstruction of their history.
• Documents will be inherently scoped, as a function of belonging to events, which themselves have people.
• The scope of documents can evolve over time according to the flow of events and inheritance pattern of the documents themselves to meet the project’s demands. For example, to have a new person work on a document, they can join an existing event or participate in a new one.

The integration of documents with events is the third key concept of this tool, and a large part of what sets this type of event planning apart from more traditional approaches.

Discussions

Because events contain one or more people and are actually oriented at getting particular tasks done, discussions are a crucial part of the event planning process. Each discussion occurs within a single event and ideally pertains to a specific topic that is within the scope of that event.

For example, say Alex, the food coordinator, is planning to order food on May 1st and has a general question about dietary restrictions of the group. He could then start a discussion with Ann within the “Order Food” event to ask his question. (see Event Discussions, A)

Another scenario, and perhaps one that is more compelling beyond that of a “typical” chat box, is that event participants can interact with other events, documents, and people to make their planning a more interactive and intuitive experience.

For example, Jeremy, the admin, could have a discussion with John in which he assigns Jeremy to complete a document named “master-leader-list.tsv”, and supplies a deadline of July 30th, 2017. That action could have a number of effects including setting notifications for Jeremy and/or John to let them know that the document will soon be due, and even potentially a submit button on the document itself for when the contributor(s) is done. (see Event Discussions, B)

In many ways similar to interacting with documents would be the feature allowing one to interact with events. For example, let’s say that Lucas, the swag coordinator wants to talk with the whole group about choosing swag. Perhaps he could create a new event called “Choose swag” and invite everyone to contribute directly from within a discussion with the initial planning event. From there, he would probably choose to create his own transient document to keep track of swag, set a deadline on it, and so on. (see Event Dicussions, C)

Lastly, people could also be added to an event, or even the project via discussions. For example, John is tasked with hiring leaders, who, once hired, actually belong within the project. Through their own events, documents, and discussions, maybe they can begin to get to know each other and prepare for orientation week. A representative and much simplified example of adding people to events might look like (Event Discussions, D).

Event Discussions

Back to the Big Picture

Recap

Here’s a quick summary of everything I’ve discussed here today. I hope that it all makes sense and serves to clarify any concepts which may have been confusing.

To plan for an event, start with a goal and work your way back. Create intermediate events in which groups of people (or just yourself) can brainstorm future events, tasks, and documents. Within events, work on documents and either have them persist across the course of the project or use them until they’re no longer needed. Chat with your collaborators using discussions about topics that are relevant to the event that you’re in. Create new documents and events, and add people to the project, all from within discussions.

I truly think that this is a better way to plan events. In designing this tool, I’ve attempted to take a different approach to planning events that is intuitive, comprehensive, and perhaps even more closely mimics how event planning takes place in real life.

Imagine a scenario in which you’re planning for orientation week. You book a room and invite all of your fellow execs. You bring the documents from your last meeting so that you can keep working on them. At the end of the meeting, you decide that you need another exec meeting in about two weeks but that in the meantime, each exec should probably meet up with their respective co-ordinator. So you tell them to plan their own meetings with their coordinators, for which they’ll book their own rooms, to which they’ll bring their own documents. Ultimately though, all the work that is being done will be done will contribute towards making orientation week great. I hope this sounds as familiar and natural to you as it does to me, and that you notice the implicit parallels I drew between that process and this design.

Concerns and Challenges

Like most ideas, there are still a couple of issues in this design that I have yet to iron out.

1. Having discussions be exclusive to one event:
   • Ok so I’m a little torn on this one. I really like the idea of having discussions exist within only a single event but I know it’s not entirely realistic. The arguments that I make in favour of this paradigm is that a) You’ll avoid having to sift through loads of old conversations just to reach the one you’re interested in (because, of course, you’ll be able to view previous events, conversations, etc.) b) It really forces you to limit your conversations to the topic, document, or event on hand. On the flip side, sometimes you have entirely valid reasons for consulting a previous conversation and it would be really annoying to have to switch between events just to see what you talked about last time. I think a relatively decent compromise to this problem is to keep conversations within their event by default but allow them to be shared with child events on demand. Secondly, I will consider implementing a more traditional app-wide chat functionality for simple discussions pertaining to scheduling events and such.
2. UI and UX
   • Obviously, UI and UX is going to be a major challenge for this app. The data model and operations that can be performed on it are numerous that this app could easily be overwhelming to use. My next blog post will dive into details on the process of designing a UI/UX that I hope is intituitive and powerful. For now, I have a couple of last thoughts on how to make this as user-friendly as possible. Firstly, I want the app to automate a large number of actions such as predicting event flow, inheritance patterns, and so on. However, I also want it to let the user know when it is making such predictions and allow for easy tweaking of each decision. Secondly, it could constructive to slowly introduce a new user to each feature of the app one at a time. Some of this will be inherently baked into the design; every new project will start as a “blank slate”, but some perhaps I should also include a tutorial or set of “advanced features” for experienced users to unlock.
3. Other things I’m thinking about (with varying degrees of attention)
   • How would one share resources between projects?
   • What is the name and branding of the app?
   • Should I be thinking beyond event planning and what would that look like?