Building Your Startup: Approaching Major Feature Enhancements

Building Your Startup: Approaching Major Feature Enhancements

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.

How to Approach Major Feature Updates

These days I'm most often working to add small incremental improvements to Meeting Planner. The basics work pretty well, and I'm trying to gradually improve the application based on my vision and people's feedback. Sometimes, my vision is for a bigger change, and that can be harder now that the codebase has grown so much.

In today's tutorial, I'm going to talk about ways to think about making bigger changes to an existing codebase. Specifically, I'll walk you through the impacts of adding the ability for meeting participants to collaboratively brainstorm and decide on activities, i.e. what we should do when we meet up.

If you haven't yet, do try to schedule a meeting, and now you can also schedule an activity. It will help you understand as you go through the tutorial.

Before we begin, please remember to share your comments and feedback below. I monitor them, and you can also reach me on Twitter @lookahead_io. I'm especially interested if you want to suggest new features or topics for future tutorials.

As a reminder, all of the code for Meeting Planner is written in the Yii2 Framework for PHP. If you'd like to learn more about Yii2, check out our parallel series Programming With Yii2.

The Activity Planning Feature

Building Startups - Approaching Major Features - Planning an Activity page

Basically, Meeting Planner and Simple Planner are designed to make scheduling as easy as it can be. You propose a few times and places and share it with one more people for them to weigh in on the options. Then, you decide together, and Meeting Planner keeps track with calendar entries, reminders and simple ways to make adjustments after the fact.

As an example, here's a video of scheduling for groups:

I wanted to expand the scheduling support provided for times and places to the concept of activities. For example, when planning a meetup with your friends, you're essentially asking, should we go to the movies, go dancing or snowboarding.

In other words, I wanted to create a panel like the one for times shown below but for activities: 

Building Startups - Approaching Major Features - The Older Plan a Time Panel

The MVC architecture and my code naming scheme are very similar between meeting times and places, so building activities seemed pretty simple on the surface. However, the decision to do so had wide ramifications.

Scoping the Changes

It's important when adding a big feature to think both about where the code will need to change and also all the places in your application that may be affected to think through the impacts.

Customer-Facing Impacts

From the design side, I thought about how activities will affect the customer-facing service:

  • It will change organizing a meeting to allow a new type, an activity-driven event. There will be an additional panel on the planning page.
  • The activity panel will need to be designed to allow people to choose from defaults or to customize and add their own, e.g. backcountry skiing instead of just skiing, "Go see Star Wars Rogue One" instead of just "Go see a movie."
  • Email invitations will need to include space to list activity options.
  • Calendar events will want to integrate the chosen activity with the subject of the meetup.
  • Organizers may want to send some activity ideas to a friend or a group without having chosen a place, so I need to allow this. Currently, the system doesn't let you send an invitation until there's at least one time and place suggested.
  • If someone requests a change to a meeting, the support for change requests will have to be expanded to support activities.

These were most of the basics. Now, let's think about the code.

Code Impacts

Source Code Branching

Frequently, it's helpful to branch your own code in GitHub so you can work on the new feature apart from the stable production-level codebase. This allows you to return and fix bugs or make smaller incremental changes while working on a major change. The GitHub folks are stricter in a way that makes definite sense for teams:

There's only one rule: anything in the master branch is always deployable.

Since there's just one of me and I'm pretty good at managing my codebase, I am a bit more laissez faire about this rule.

But branching code is also useful for reviewing code changes when you're ready for testing. I'll share a demonstration of this at the end of today's tutorial.

Replicating Common Code

There will be two types of meetings now: those based around only dates and times and those around activities, dates, and times. So the meeting model needs to adapt.

For times and places, there are specifically the models MeetingTime and MeetingPlace as well as models for the preferences for these with participants, called MeetingTimeChoices and MeetingPlaceChoices. You can read more about building this in Building Your Startup With PHP: Scheduling Availability and Choices.

So adding activities would essentially require duplicating these, creating MeetingActivity and MeetingActivityChoices and their accompany controllers, models, views, JavaScript and Ajax and database migrations.

Account and Meeting Settings

Also, organizers have the preference of various account settings and per meeting settings for whether participants can suggest and choose the final activity.

Email Templates

Adding activities also affected email templates for invitations and completed meetings.

Event History and Logs

Since every change to a meeting is logged, each activity option and change also needed to be logged.

Other Miscellaneous Areas

The .ics Calendar file should be changed to include the activity. Ultimately, the API would need to be updated—and even the statistics for the administrative dashboard.

While it seemed simple up front, adding activities actually required a lot of new code and testing.

Coding Highlights

While there's too much new code to cover in one tutorial, let's go through highlighted aspects from some of the concepts above.

Database Migrations

First, I created the database migrations. Earlier I spoke of replicating code with feature aspects in common. Here's an example of the MeetingActivity migration vs. the older MeetingTime table migration:

Here's MeetingTime's migration, and you can see the similarities:

 Ultimately, I needed five for the following new tables:

  1. m161202_020757_create_meeting_activity_table
  2. m161202_021355_create_meeting_activity_choice_table, for storing the availability preferences of each meeting participant for each activity
  3. m161202_024352_extend_meeting_setting_table_for_activities for a particular meeting's settings for adding or choosing activities
  4. m161202_024403_extend_user_setting_table_for_activities for the account's default settings
  5. m161203_010030_extend_meeting_table_for_activities and for adding is_activity to denote the property of a meeting with or without an activity 

Building the MVC Framework for Activities

Building Startups - Approaching Major Features - The Gii Scaffolding Menu

I used Yii's Gii scaffolding capability to create the model, controller, and initial views. I've covered migrations and Gii earlier in the series.

JavaScript and jQuery Changes

There were also substantial additions to the JavaScript and jQuery used, especially now that interacting with planning elements for a meeting is done with Ajax, without refreshing the page.

Here, for example, is the code loop to see if a meeting time is chosen:

By using a common naming scheme, writing the code for activities was replicable from this:

Other functions, such as those that display responses to the user, simply needed to be extended for activities:

Even with a feature so reflective in qualities as existing features, the additions of new code were extensive. Here's more of the JavaScript, for example. This code covers a lot more of the interactive ajax functionality of meeting times on the planning page:

Framework Additions

Certainly, there were models, controllers and views that had to be added. Here's an excerpt from the MeetingActivity.php model which lists a number of default activities the user can quickly typeahead to use:

Building Startups - Approaching Major Features - Activity Typeahead List

And here's an excerpt of the /frontend/views/activity/_form.php with the TypeaheadBasic widget using the above defaultActivityList():

But there are numerous changes to the code outside of common framework needs. Here's the Meeting.php model's canSend(), the function that determines whether the user is allowed to send an invitation for a meeting. It determines if a meeting's met the minimum requirements for sending, such as having a time and activity or time and place.

Below, you can see how a new section had to be added for activities:

Email Templates

Updating the email layouts required a tiny bit of thinking about design and how best to present activities in meeting invitations and confirmations. Here's a sample of the updated email invitation:

Building Startups - Approaching Major Features - Email Invitation Theme

Essentially, if a meeting has an activity, then the invitation includes a wide row above times and places, again replicating a lot of the existing code for times and places:

Reflecting on the Changes

Ultimately, the activity feature required a huge new branch of code. Here's the pull request:

It was so large that I decided to make a fun video scrolling through all the changes in GitHub with appropriate music playing in the background... enjoy:

Overall, building the activities feature was challenging and helpful for me to think about the site architecture and how to make fast, stable progress on the codebase of a one-person startup. Use replication, but reflect first on the overall scope.

The activity feature ended up touching more areas than I had anticipated. 

Planning ahead will help you avoid getting stuck in never-ending coding traps for new features. If you do find yourself in some deep trench, a coding nightmare that just won't end, check in your changes to your feature branch, switch back to master, and work on something else. It helps to clear your head.

I definitely took a slightly different approach to guiding you in this episode, and I hope it was helpful.

Have your own thoughts? Ideas? Feedback? You can always reach me on Twitter @lookahead_io directly. Watch for upcoming tutorials here in the Building Your Startup With PHP series. There's a lot of surprising stuff ahead.

Again, if you haven't tried out Meeting Planner or Simple Planner yet, go ahead and schedule your first meeting:

Related Links

Source: Tuts Plus

About the Author