Building Your Startup: Meetings With Multiple Participants

Final product image
What You'll Be Creating

This tutorial is part of the Building Your Startup With PHP series on Envato Tuts+. In this series, I'm guiding you through launching a startup from concept to reality using my Meeting Planner app as a real-life example. Every step along the way, I'll release the Meeting Planner code as open-source examples you can learn from. I'll also address startup-related business issues as they arise.

Introduction to Group Meetings

Scheduling meetings with multiple participants was always part of my plan—but not part of the earliest Minimum Viable Product (MVP). The alpha release of Meeting Planner launched with only 1:1 scheduling. The goal of supporting group scheduling sat on the task list like Mount Everest to a climber aiming for the seven summits (and I'm not even an outdoor climber).

Multiple participant meetings are the most challenging to schedule and therefore valuable for the Meeting Planner product to offer. I was excited when the beta task list reached the point that I could begin work on this.

I've been planning, architecting and coding with group meetings in mind from nearly the beginning. I hoped that updating the site for this feature would not require significant UX changes or coding updates. It turned out to require a middle path, 7-10 days of very focused work and testing but no major re-architecting.

In fact, testing proved to be the most difficult aspect of building this feature. It also helped reveal shortcomings in earlier code. It's just that it's not easy... sending to multiple email addresses, checking that every one of them receives all the proper notifications but not the wrong notifications—and sees all the correct menu options throughout the site.

In today's tutorial, I'm going to cover enabling multiple participants, upgrading the UX for groups, appointing organizers, removing participants, and sorting date, time and place options by their popularity with participants. 

In the next tutorial, I'll describe the rest of the work: reviewing all the areas of the site affected by multiple participant meetings, handling and smartly displaying lists of recipients of various status, properly managing notifications and notification filtering for groups, and finally upgrading the recently launched request meeting changes feature.

Try Scheduling a Group Meeting

Please do schedule a group meeting today! Share your thoughts and feedback in the comments below. 

I do participate in the discussions, but you can also reach me @reifman on Twitter. I'm always open to new feature ideas for Meeting Planner as well as suggestions for future series episodes.

As a reminder, all the code for Meeting Planner is provided open source and written in the Yii2 Framework for PHP. If you'd like to learn more about Yii2, check out my parallel series Programming With Yii2. I've heard great things about Laravel, but Yii2 always meets my needs quickly and easily.

Looking Back

When I first designed the Meeting Planner scheduling interface, it showed the current availability of the other participant in its own column. And it was a bit confusing as there were disabled controls. 

Meeting Planner Startup Series - The old You Them Availability Panel

At the time, I worried about how would I make space for displaying the availability of groups.

Fortunately, when I rebuilt the UX for a better responsive experience, I replaced the participant availability column with a small text summary:

Meeting Planner Startup Series - The newer built for mobile responsive planning view

The text summary of availability would coincidentally work well for group meetings.

By redesigning for mobile first, I solved the most significant UX barrier to multiple participant meetings!

Coding for Group Meetings

Let's get started going through all the code and testing that multiple participant meetings required.

Enabling Multiple Participants

Meeting Planner Startup Series - Who Panel - Enabled Button for More Participants

The funniest aspect of group meetings is that activating them was straightforward. I just needed to turn off disabling of the plus icon button on the Who panel for meetings in the planning stage:

Then, I began by creating a MEETING_LIMIT in the Participant model:

It's used in ParticipantController::actionCreate() on submit:

Advancing the UX and Related Features

For a long time, I've wanted to allow meeting organizers to remove participants, places, and date times without cluttering the user interface. Similarly, I realized that there might be several commands to perform on participants.

After finding so much utility in the compact Bootstrap dropdown button in the Advanced Commands tutorial, I decided to use it for displaying meeting attendees:

Meeting Planner Startup Series - New Buttons and Dropdown Menu for Organizers

Organizers are denoted with a star. Attendees that have declined the meeting are displayed in orange. Attendees that organizers remove are displayed in red. 

Here's the code in my new partial /frontend/views/participant/_buttons.php:

Anyone can now send a message to any participant (the meeting notes features is currently distributed to all meeting participants). 

Organizers see a deeper dropdown which allows them to anoint additional organizers, i.e. Make organizer. This is now a very cool feature. Organizers will receive more complete notifications and have more power throughout the planning phases. They can also Remove participants.

Building AJAX Features Into the Participant Buttons

I decided on a whim to AJAXify all these menu options. That turned out to require several complex hours of coding.

Here's the code that defines the initial button menu and prepares the JavaScript:

There are so many button states, colors and stars to update as changes are made interactively on a page that the code becomes fairly intricate. I added functions to the meeting.js JavaScript file for toggleOrganizer(), i.e. make/unset organizer, and toggleParticipant(), i.e. remove/restore participant as attendee.

These required accompanying JSON controller methods in ParticipantController.php to process the toggle requests and update the databases:

Activating the Accordion Feature on Panels

Meeting Planner Startup Series - Open and Closed Panels with Bootstrap Accordion Feature

At this time, I also realized that as meeting plans increased in complexity with more recipients and options, there would be more scrolling. I decided to implement the Bootstrap accordion feature for all the panels on our meeting view.

In other words, you can now click on a heading to collapse or open each and/or all of the panels.

Here are the changes to the partials for meeting place _panel.php:

Note the settings above on the panel-heading and then the surrounding div for the later panel-body. These control the opening and collapsing of each panel.

This led to some small cosmetic problems such as unwanted padding around the list of items, which I'll need to clean up in the future.

Model Infrastructure for Group Meetings

While I'd been planning for multiple participants from nearly the beginning, there were some minor to modest infrastructure enhancements to support them.

While the MeetingTimeChoice and MeetingPlaceChoice models keep track of whether participants prefer specific date times and places, I wanted to track the overall availability for all participants at each date time and place. This would allow me to sort places and times by how popular they are—and show the most popular settings at the top of the panels.

First, I created a migration to add this to both models. It's infrequent that a migration of mine affects multiple models, which makes this one kind of special:

With this capacity, I was able to begin display possible meeting date times and places sorted by their popularity with participants, from MeetingController::actionView():

You can see this in action in the below planning screenshot:

Meeting Planner Startup Series - Sorted Date Times and Places By Popularity

To track whether participants are organizers and to allow for future opt-out of a specific meeting's notifications, I added this migration for the Participant table:

I also added a number of constants in Participant.php to work with these properties:

And I knew that it would be helpful to have some helper functions within the massive Meeting model. For example, IsOrganizer() tells me if the current viewer is a meeting organizer:

Wait, There's More?

As you can see, there's a lot of ground to cover to build this feature. In the next episode, I'll cover the second half of development and testing required to launch multiple participant meetings: recipient strings, notifications, requests, and responding to requests.

If you haven't yet, go schedule your first meeting with Meeting Planner and try all this out. Please share your feedback in the comments below.

A tutorial on crowdfunding is also in the works, so please follow our WeFunder Meeting Planner page

You can also reach out to me @reifman. I'm always open to new feature ideas and topic suggestions for future tutorials.

Stay tuned for all of this and more upcoming tutorials by checking out the Building Your Startup With PHP series

Related Links



Related Articles