[DAY 6] Developing Our First User Story

[DAY 6] Developing Our First User Story

This is Day 6 of a 10 Day series on building N-ter, a place where you can manage your job applications online, from idea to launch. You can find the previous posts here:

[Day 0] Let’s Build an Online Startup in 10 Days
[Day 1] Creating a Value Proposition for Our Idea
[Day 2] Refining the Business Model and Naming the Baby
[Day 3] Designing the Product Using a Method from the Lean Startup
[Day 4] Establishing Our Website
[Day 5] Creating Our First Webpages

Today it’s all about starting to develop our solution. We are going to:

  • Prioritize our user stories and select a user story to develop
  • Get into how and where to add custom code
  • Start developing our first user story

 


A Quick Note

There’s one important thing I forgot to mention in yesterday’s post. There’s the possibility to enable open registration in either the s2 Member plugin or in the standard WordPress settings. We will need this functionality later on, but for now make sure you don’t enable it. Otherwise, people will be able to sign up and access your website behind your coming soon screen.

Also, we’re starting to dive into code today. As I’ve mentioned before – I am not a programmer and do not pretend to be one. What I am showing you here is the way I’ve developed for myself to make ideas reality in a short timeframe. If you’re coding yourself and are in doubt about any technical things, please consult someone who is experienced in this field. Especially when that topic is security.

That being said, let’s get started!

 

Selecting and Prioritizing User Stories

We didn’t come up with our user stories just for fun a couple of days ago, so now is the time to actually make use of them. If you haven’t done so already, you should prioritize your user stories now. The two ways that work best in my opinion are colour coding or sorting (highest priority on top). I’ve done both. These are my colour codes:

  • Red: Must have
  • Yellow: Should have
  • Green: Nice to have

To have a good overview when going forward and creating our solution, I organized my board in multiple buckets. This way I can see at which stage a user story is and make sure I don’t forget any functionality I planned to create. This type of board is called a Kanban-board by the way. That’s how it looks like today:

(Click to enlarge)

Our goal: To have ALL red user stories and as many as possible yellow and green user stories in the “Developed” bucket by the end of this 10-day series. As you can see, two user stories are developed already, as we created the login and user management functionalities with the s2 Members plugin yesterday.

The “in development” bucket is a good way to pick a few user stories for the current day and therewith organizing the goals.

I only picked one user story to focus on today and that is:

As a logged in user, I want to create a new application record from the overview page, so I can add new jobs that I’ve applied for.

The reason I only picked this one is because I assume it is a bit more complex than some of the others, as it involves a few sub-steps, some of which are:

  • Creating an input form for users
  • Sanitizing and transforming the user input
  • Saving the input to our database

The last two steps were also the ones why I assumed we would have to dive into developing some custom code at some stage, as I haven’t found a good plugin solution for creating custom database tables and saving user input in them yet.

 

Before We Start: Setting Priorities

Getting caught in tiny details when building a website and its functionality happens very easily. That’s why we are setting clear priorities before we begin.

  1. Make it work somehow
  2. Improve it
  3. Make it look good

A good summary for this is “design follows content” – not “content follows design”. It happened before that I was focusing on making something look good, only to discover later on that I had to change it when improving the functionality and do it all over again. Of course we should have the design in our mind when creating functionality. But the actual beautification should happen at the end.

 

The Application Editing Page

There was one page that we didn’t touch on yesterday, the page that allows users to record new and edit existing applications. To develop our user story today, we need this page as we will be putting the user input form on it. I’ve set a page level restriction to signed up users on this one, as users that are not logged in should not be able to see it.

To record an application along with the required data, we need an input form consisting of all the input fields and a submit button. Initially I was determined to make the user input form with Contact Form 7. But the amount of “bending” that’s required to get the plugin to store input in the database instead of doing what it’s designed to do (letting users contact you via mail) is just not worth the effort. I literally spent hours today trying to make it work, but for every solution two new problems seemed to pop up. That’s why I decided to go with a simpler solution that required a little bit of HTML code. I’ll explain this a bit further down in this post.

 

Coding Preparation – Ensuring We Can Access the Files on Our Server

Now we are going to focus on making our three sub-steps “work somehow” before we focus on improving and beautifying. And this is the part where we need to dive into custom code.

If you’re just building a web presence for a service, a blog, a personal brand or an offline company, you can do everything you need in WordPress without touching a single line of code. As we are planning to have some logic and functionality on our website we will need to adjust some code here and there.

To be able to access and edit our files on our hosted server, we need to establish a so-called FTP connection to it (that’s short for File Transfer Protocol). You’ll need software to access your server via FTP. Every decent hosting provider should have a tutorial on how to do this. I installed the open source tool Filezilla and hooked it up to my server following the instructions and provided connection data from SiteGround. (I did this one yesterday already but didn’t manage to write it down in time.) What you’ll see in the tool is that it’s divided in a left and right side. You can access the local files from your computer on the left and the server files on the right. Files can be transferred between those two with a simple double click. As you can’t edit files that are on the server, you’ll need to download a file you want to edit, work on it on your computer and then upload it back once you’re done.

 

An Example on How to Edit Code

For future reference, I will quickly describe how to edit code, using a template example from yesterday. You can find templates in your themes folder, usually under “public_html/wp-content/themes/[theme-name]. These are the templates you can select on the right-hand side when creating a new page in WordPress admin.

I used Filezilla to make a quick template to use for the page “n-ter.co/sign-up” that would redirect users to “n-ter.co/login”. I did this because we don’t really need a sign-up page, but the s2 plugin requires a “membership options page” (which is our sign-up page) in order to work properly. What I did exactly is:

  • Copy an existing template from our theme’s parent
  • Rename the template file and the name of the template itself, which is written within the file itself.
  • Remove all code from the template (just the part after the template details on top).
  • Insert two lines of code:
    wp_redirect( wp_login_url() );
    exit; ?>

(I don’t even know whether the second line is necessary or not, but it works, so why change it.)

  • Save the new file to our theme’s child folder (Remember, if we put it into the parent folder, this template gets overwritten with the next theme update.)

Here’s how the entire template we’re using for “n-ter.co/sign-up” looks like now.

/**
* Template Name: Blank Page Login Redirect
*
* The template for displaying a full width, unstyled page
*/
wp_redirect( wp_login_url() );
exit;

wp_redirect and wp_login_url are both standard WordPress functions (you should know what functions are from your PHP and JavaScript course on CodeAcademy 😉 ) and are documented in the standard WordPress documentation. With wp_redirect you can redirect users wherever you like and wp_login_url retrieves the current login URL. Together, those two redirect us to the current login page. Easy, right? 😊 How to find the correct WordPress functions for our purposes? Just google something like “wp how to redirect users to login” and you should find them fairly quickly. Just make sure to include the “wp” in your search. Once done, everything left to do is select the “Blank Page Login Redirect” template for our sign-up page and we’re done. Btw, I use “Atom” as a code editor. You can download it for free.

I made this example a little more detailed on purpose, as I can’t do this every time I’m adjusting code. You can come back to this example if anything in the next sections or posts is unclear.

 

How to Add Custom Code to WordPress

If you don’t need a custom database table for your input in the WordPress database, you might be able to skip this step by using a plugin called “CFDB” (Contact Form to Database). This plugin stores input in standard WordPress tables, though. That’s why we are not using it here, as we require a custom database table. We also might need to implement more advanced queries on our dataset and using the plugin would make it difficult.

You have probably noticed that I’ve left out sub-step 2: Sanitizing and transforming user input. I first want to make sure we can save user input to the database, before ensuring that a user can’t store senseless or dangerous values. I’m the only tester for now and I’m not going to put anything dangerous into the database. That’s why we can take care of validation and sanitization later.

To develop sub-step 3, we will need to add custom code to our WordPress installation. In common practice, there are two ways to do this:

  • Developing your own plugin (create PHP files in an own plugin directory).
  • Adding your code to the page template you’re using and adding functions to the functions.php file of your theme (remember, always the child theme!).

For our purposes, we’re going to go with the quick-and-dirty way number 2. Keep in mind that there is a downside to the second option. If we change our theme, the functionality gets lost and we have to copy it to the new theme we’re using. This wouldn’t happen if we’d develop a custom plugin.

 

User Story Sub-Step 3: Saving the Input to the Database

Here’s what needs to happen in order to store the user input in our database.

  1. The user input needs to be sent from the input form (front-end) to the server (back-end)
  2. On server-side, the input needs to be written to the database

Step 1: As I already mentioned, instead of going with Contact Form 7, I decided to go for another solution which requires a little HTML code. The code essentially creates a form, consisting of input fields and a button, whose content is posted straight to the server. This a good explanation for beginners on how to create such a form. I put the code right into the template that our page is using (just like in my “How to edit code” example above).

Step 2: Before we can actually store values in our custom database table, the table needs to exist first! That’s why I’m creating a new table in our WordPress database using phpMyAdmin in the cPanel on SiteGround. Here’s a tutorial on how to do this. For now, I’m only creating four columns for that table: User ID, Application ID, Job Title, Employer. Once that is done, we can create the code in our child theme’s function.php that inserts the user input into our new database table. There is the WordPress documentation on how to interact with the database (the part important for us is “Insert Row”). Here’s an example of how that code can look like (careful, the user input is not validated in this one).

If you’re new to all this, it might seem a bit overwhelming at first. But trust me, once you understand what’s happening there the code is short and easy to follow. Also, again, this whole part is only required because I decided to use a custom table to store the user input in. If you don’t need that you can use the CFDB plugin and save yourself the coding trouble.

Here’s how the application editing page looks after today’s session. Visually it doesn’t look like much progress, but the base functionality is set now and just needs to be expanded in the following days.

So far, we’ve got a form with input fields for job title and employer, which are written to our database when the user clicks “save”. Also, the ID of the user that is currently logged in is retrieved and stored along with the application record.

 

Day 6 Summary

If you’re following along, do the following today:

  • Organize and prioritize your user stories
  • Select one user stroy to start with today
  • Using the examples above, get creative and make it happen!

 

That’s it for Day 6! Tomorrow we will select more user stories and keep on developing our solution.

 

Meanwhile, sign up for the email-newsletter and I’ll let you know when the new posts go online!

One Reply to “[DAY 6] Developing Our First User Story”

Leave a Reply

Your email address will not be published. Required fields are marked *