Advertisement
  1. Code
  2. PHP
Code

Building Your Startup: Requesting Scheduling Changes

by
Difficulty:IntermediateLength:LongLanguages:
This post is part of a series called Building Your Startup With PHP.
Building Your Startup: Advanced Scheduling Commands
Building Your Startup: Meetings With Multiple Participants
Final product image
What You'll Be Creating

This tutorial is part of the Envato Tuts+ Building Your Startup With PHP series. 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.

Changing Your Meeting Plans

As the Meeting Planner alpha testing phase began, the clearest feature gap was the inability to change a meeting after it had been scheduled. It's not an easy problem. Is it okay to just change a meeting without a participant's permission? Or should you ask? Or do either, depending on your role in organizing the meeting? What if you just want to ask if it's okay to meet 15 minutes later—that should be easy, right?

Solving all this required some reflecting on the social aspects of adjusting a meeting. 

Over time, I realized that the ability to adjust meetings easily after they've been scheduled could make or break the Meeting Planner brand. 

In our last episode on Advanced Scheduling, I implemented Make Changes, which allows an organizer or participant with organizing permissions to essentially reschedule the meeting without asking permission. In today's tutorial, I'll walk you through building the Request Changes infrastructure. It requires that participants request change(s) and then others can accept or decline them, affecting the final meeting calendar details.

While you're reading, I hope you'll try out the new "request a change" feature on the live site and 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.

Let's get started.

Building Request Changes

A Tall Mountain to Climb

Aside from the meeting view and scheduling features, Request Changes required more time and new code than any other feature on this project.

As I mentioned in the last episode, coding everything with basic security takes a bit longer than rapid prototyping, but designing and building this feature also touched a lot of other platform areas:

  • Designing with the social engineering of requesting and making schedule changes.
  • Keeping the UX for change requests simple, helping people request and respond to change requests without cluttering the interface.
  • Handling requests for 1:1 meetings would be easy, but coding for the upcoming multiple participants feature would require a much more sophisticated infrastructure.
  • Handling the responses to requests with multiple participants ahead.
  • Emailing notifications of new and withdrawn requests, accepted and declined responses.
  • Updating the meeting confirmation and calendar details when accepted requests affect the schedule.

So, while this isn't a perfect picture of the changes just for this feature, here are screenshots of the eventual production server code pull.

Here are the changes to existing code:

Build Your Startup Request Scheduling Changes - Git Pull File Changes

And here are the new files:

Build Your Startup Request Scheduling Changes - Git Pull New Files

There was a lot of new code involved with this feature.

The Tables and Their Migrations

Ultimately, I decided on an architecture built around two tables. The first was Requests:

Here are the constants that explain the model further:

There would be two ways to adjust the time: TIME_ADJUST_ABIT, i.e. intervals of minutes or hours earlier or later than the chosen time, or TIME_ADJUST_OTHER, a different meeting time altogether.

And the second table was RequestResponses:

Basically, who requested the change, who responded to it and what the response was: accept or decline.

The second table is needed for a multiple participant environment.

Requesting a Change

Meeting organizers and participants can access Request Changes via the dropdown Options menu that we built in the last episode:

Build Your Startup Request Scheduling Changes - Options  Menu Request Changes

The Request Change Form

RequestController.php's actionCreate() loads the form from which the user's request changes:

Build Your Startup Request Scheduling Changes - Request a Change Form

And here's where the complexity began. What kinds of changes could participants request?

  • Do you want to meet earlier or later?
  • Do you want to meet at an entirely different time?
  • Do you want to meet at a different place?

Note: I've not yet implemented the ability to add new places and times—currently, you can choose alternate date times and places from any that were offered during the planning process.

A Dropdown of Earlier and Later Times

The code to create the dropdown list was intricate. I made it so you could choose times two and a half hours earlier or later, in 15-minute increments near to the original time and 30-minute increments after that:

I filled $altTimesList with keys of each possible time with values of the friendly time adjusted for the user's time zone. Then I used ksort() to sort the dropdown so earlier times showed up before later.

One of Meeting Planner's advisors (I only have one at the moment), suggested showing the currently selected meeting time, which I did below. I also added a separator with the disabled option in a dropdown. It divides earlier times from later times but is not selectable:

Build Your Startup Request Scheduling Changes - Enhanced Request Form with Separator

Here's the dropdown code, which shows how to disable the separator based on its $currentStart index key:

And, when participants want to pick one of the other times, there's JQuery to change the dropdowns, another complexity to building the forms:

Here's /frontend/web/js/request.js:

Here's what the form looks like with the alternate times hidden:

Build Your Startup Request Scheduling Changes - Selecting a different place

Different places are just integrated into the place dropdown list (as you can see with the top, featured image).

Handling the Request

Once the request is made, we notify the requestor that other meeting participants will be notified. And, whenever active requests exist for a meeting, there's a link to View Them:

Build Your Startup Request Scheduling Changes - Meeting page View Requests

I decided this would be a simple, uncluttered approach for people to access requests.

The List of Meeting Requests

Here's the list of requests for a meeting, most often just one:

Build Your Startup Request Scheduling Changes - List of Meeting Requests

Request::buildSubject() creates the string above based on the content of the request, i.e. time and/or place change:

This function is used repeatedly within email notifications as well.

There are also limits in RequestController.php which prevent users from making more than one request per meeting at a time:

Here's the view request page showing the limiting:

Build Your Startup Request Scheduling Changes - Viewing a Request

If it's your own request, you can Withdraw Your Request.

As you can see, there was a lot of diverse UX functionality to build for this. And I haven't shown you when people other than the requestor respond.

Request and Response Notification Emails

In the process of building these features, I decided to create generic_html and generic_text email templates as well as a reusable Request::notify() function to ease the delivery of different kinds of announcements around Meeting Planner.

Here's the Request::create() method for preparing an email:

The $content array is populated for the email subject, message heading and paragraphs, while the $button array is used for any command button such as Respond to Request or View Meeting.

Here's the notify() method, similar to the earlier send() and finalize() actions which send email:

Essentially, the generic_html.php layout is based on the simple textual update template I talked about in our email templates tutorials. It provides a well-formatted way to update participants via email with a few paragraphs.

Here's the generic_html.php view file integrating the $content and $button data. It checks for a second and third paragraph, e.g. $p2, $p3 and $button data:

Here's an example of a notification that Rob Smith asked me to change our meeting time and place (generated from the code above):

Build Your Startup Request Scheduling Changes - Email Notification of Requested Change

Responding to Requests

When I click Respond to Request, I'm taken to the RequestResponse Controller's actionCreate() method:

Build Your Startup Request Scheduling Changes - Respond to Request Form - Accept or Decline

Throughout the request UX, I incorporated the ability for people to write notes providing context for the requests and responses.

One challenge of this form was determining how to direct responses to different controller methods based on which submit button was clicked. In other words, distinguishing between different submit POST button clicks.

Here's /frontend/views/request-response/_form.php:

Essentially, I just added name values of 'accept' or 'reject' to each button. Then, this is delivered as a posted value as shown:

When the responder accepts or declines the request, they are shown a flash message and sent an email. Also, the meeting no longer has any active requests to show:

Build Your Startup Request Scheduling Changes - Meeting page after Request accepted

Here's the Requested Change Accepted notification email:

Build Your Startup Request Scheduling Changes - Email notification of requested change being accepted

A lot happens in Request::accept() below:

Prior to sending the email, the meeting schedule is updated to reflect any new date/time and/or new place. After sending the email, the meeting is finalized. This delivers a new meeting update with the updated calendar file to all participants:

Build Your Startup Request Scheduling Changes - Updating Meeting Notice

What's Next?

I hope you've enjoyed this tutorial. Building this feature took longer than I hoped but turned out quite well. I think it adds a dimension to scheduling with Meeting Planner unmatched by other services.

If you haven't yet, go schedule your first meeting with Meeting Planner. I've continued to make incredible progress towards the beta release, despite distractions (coding is hard):

I'm also planning to write a tutorial about crowdfunding, so please consider following our WeFunder Meeting Planner page

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

Stay tuned for all of this and more upcoming tutorials by checking out the Building Your Startup With PHP series. And definitely check out our Programming With Yii2 Series (Envato Tuts+).

Related Links

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.