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.
Ongoing Development of Group Meetings
Welcome! This is the follow-up episode to Building Your Startup: Meetings with Multiple Participants. Today, I'll be completing the work that we began in that episode: scheduling multiple participant meetings.
A Brief Refresher
Scheduling meetings with multiple participants was always a major goal for Meeting Planner, which launched with only 1:1 scheduling. Multiple participant meetings are the most challenging for people to try to schedule with each other and therefore one of the most valuable features for the Meeting Planner service to provide.
In today's tutorial, I'm going to cover 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.
Schedule Your First Group Meeting
Please do schedule your own group meeting today! Invite a few friends to meet you for kombucha or kava. Share your thoughts and feedback of everyone's experience 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.
Reviewing the Code
As you can imagine, transforming Meeting Planner from 1:1 meetings to group meetings touched nearly all of the code. I had to think through all of the areas, review the code, and make small to moderate changes in many places. In other areas, I'd architected for multiple participants, and changes were not needed or were minor.
For example, group scheduling touched:
Sending invitations and Finalizing (confirming) meeting schedules
Making Changes, Resending, Repeating, Rescheduling a meeting
Sending a running late notice
Meeting Reminders
Requesting meeting changes
Notifications
Mostly, where I'd previously just send to participant[0], the first and only participant, I now needed to process the array of participants. And, in doing so, I needed to check:
Is this participant an organizer?
Has this person been removed or declined on their own?
In the future, has this person opted out of notifications for this meeting?
The Challenges of Testing
With more resources, I could have managed this more comprehensively with automated testing. However, working solo with shipping as a goal, I manually tested everything exhaustively.
I used a catchall domain email so I could invite n1, n2, n3, n4 and n5 @mytestdomain.com to my sample group meetings. Fortunately, the Meeting Planner invitations make it easy to log in quickly with any account by clicking within each meeting invite; this aided my testing.
It was important to review nearly all of the meeting planning code.
But let's get back to the more specific coding challenges of the second half of the group scheduling feature.
Smartly Displaying Participant Lists
A while ago, I built a MiscHelpers method to display lists grammatically correctly in English with "and" before the last name, as shown in the meeting index below:
However, I wanted to simplify the display of date time and place availability. For example, rather than listing five names of people who accepted meeting at Herkimer Coffee, I updated MiscHelpers::listNames to say, "everyone else":
You can see this in action below:
But rather than say "No response from everyone else," it's more proper to say "No response from anyone else," which the code does.
Below, you can see MeetingPlace::getWhereStatus() preparing these strings for each place in the meeting places panel:
Each user has a MeetingPlaceChoice row related to a MeetingPlace which records whether a place is acceptable, not acceptable or not responded yet. MeetingTimeChoice also exists similarly. This information is passed off to listNames().
Declining and Withdrawing From a Meeting
Groups also required more intricacy with declining a meeting invitation. Earlier, if one participant declined, the meeting was effectively canceled. Now, one might decline, leaving three others to carry on.
So if a participant receives an invitation to a meeting, they can Decline it. But if the meeting has already been confirmed and finalized, then they are essentially Withdrawing as you can see below:
Note: In the above image, it's Sarah Smithers seeing the Withdraw button; Robert McSmith had been removed by another organizer, either Jeff or Alex.
However, if it's an organizer (meeting owner or anointed participant organizer), they can just Cancel the meeting. Below is from _command_bar_confirmed.php. It determines which buttons to present:
Prioritization is a key element of building a startup. So while I wanted to offer a way for a user who had withdrawn to rejoin a meeting, I decided to add this to the Asana task list for later. A user who rejoins would need updated notifications and possibly some updates to their scheduling data structures.
Thinking Through Notifications
While with 1:1 meetings, every change needed to be sent to the other party, this didn't necessarily make sense for 12-person meetings—or did it? It depends.
Initially, I created general guidelines. If a participant was updating their preferences for a specific date time or place, only the owner and other organizers needed to be updated about this.
I created an array $groupSkip in MeetingLog which determined events that should not be sent to other participants:
In MeetingLog::getHistory, we skip notifying a participant for these events but always notify organizers:
In one unusual example, the code was actually made simpler with multiple participants: Meeting::findFresh(), which looks for updates of meeting changes to share via email.
Earlier, we had to identify which of two users performed the actions and whether or not to notify either. Now, we just notify the owner and then notify the participants:
Any filtering is done deeper within the event log textualization.
Enhanced Notifications: "Everyone Is Available!"
I also created a new notification for alerting organizers when everyone is agreeable to at least one specific place and time, MeetingLog::ACTION_SEND_EVERYONE_AVAILABLE:
This notifies organizers when the meeting is ready to finalize/confirm.
Here's the code that looks at all the meeting places and meeting times to see if everyone is agreeable to at least one place:
Similarly, I built a function to flash a notice to the organizer that none of the date times and places are acceptable to anyone, Meeting::isSomeoneAvailable():
This indicates that they should suggest additional date times and/or places.
Updating Meeting Reminders
Everything about meeting reminders worked well for multiple participants, but I did need to turn off reminders if a participant had declined or withdrawn from a meeting or been removed:
STATUS_DEFAULT indicates an attendee that should be added to the array of users to email reminders too.
Reviewing Calendar Files
I also reviewed the work of generating calendar files for invitations to ensure that all the attendees are included. In Meeting::prepareDownloadIcs(), I put together an attendees array with the owner and participants actively attending:
During this time, I also learned how to indicate that a calendar file of a canceled meeting should trigger removal of the event from someone's calendar. The ics standard is powerful though not easily learned.
Updating Request Changes for Groups
As I wrote about recently, the Requesting Meeting Changes feature required a lot of work and new UX.
For multiple participant meetings, the social engineering needed to change again. For example, organizers can accept or reject requests and change the meeting schedule. However, participants can only express Like, Dislike or Don't Care about change requests. And organizers should see all the participants' responses to aid them in their decision-making.
Here's what the participant sees after they submit their change request:
New change requests needed to be sent to all participants. This is handled transparently by the activity log notifications. When a request is made, this event is created in RequestController::actionCreate() submit:
Here's what the requested change notification looks like to other participants:
Everyone is asked to respond. Clicking Respond to Request jumps right to the request. Or you can find it through the list of requests from the flash alert link on the meeting shown above.
New UX for Participants Responding to Requests
Here's the form that participants see when they respond to a request:
If there are other participant responses already, they'll see them:
Here's the top part of that form in /frontend/views/request-response/_form.php:
The Gridview lists the existing responses, e.g. Like, Dislike, Neutral, and any personal note attached.
Then, here's the code for the lower half of the form, which will display Like, Dislike, Don't Care to participants but Accept and Make Changes or Decline Request to owners.
Participants that are anointed organizers are shown both sets of buttons and can either express their opinion or make or decline the change.
Here's the email notification that a change has been accepted:
Of course, an updated invitation and calendar files will be sent out to everyone if a change is made.
Always More Improvements to Make
I hope you've enjoyed these two episodes (today's and Building Your Startup: Meetings With Multiple Participants). In startup mode with a huge new feature, there's always a focused, streamlined launch effort, which leaves many loose ends undone and defects unpolished.
A few examples of this include:
Rejoining meetings you've declined or withdrawn from.
Improved presentation of the participant list in invitations.
Options to keep the participant list and/or their individual statuses private from other participants.
Improved handling and presentation of group contact information and virtual conference details, e.g. a conference line and participation code.
Secure URL for sharing meeting invitations. This would allow organizers to share a URL on Facebook or via email to invite new participants.
Despite these shortcomings, I've worked super hard to reach this level of function and usability for Meeting Planner. I'm super excited about its progress and hearing good feedback about it from friends and colleagues.
I'm turning in these two tutorials today and taking a few days offline in the forest for some downtime. Rest is important. Being in touch with nature helps remind you of what's important in life—startups aren't always, actually. They may be creative pursuits, important to our income and careers, they may in some cases help people live more efficiently and productively—but they are often distant from the earth, from friendships, and from helping others less fortunate. These are all things I think about every day and will do again while I'm away.
I'll ask myself repeatedly am I doing everything I want to be doing with my time—especially in light of my brain surgery.
I'll also take heart from the fact that I'm proud of Meeting Planner, especially the work to date and its growing usefulness. Overall, the service's beta is nearing completion.
Multiple participant meetings had been the most daunting, complex remaining work item. Looking ahead, features and tasks are more moderate, smaller, and more easily manageable. I'm excited about its future prospects!
If you haven't yet, go schedule your first meeting with Meeting Planner now!
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
Meeting Planner
Follow Meeting Planner's Funding Profile
Programming With Yii2 Series (Envato Tuts+)