It’s been an active week for the project. Even though I haven’t been feeling too well, down with a cold, I feel progress has been great. Out of curiosity I also started logging time on when I work on it.

You can see last week times below:

That doesn’t include the 3 hours I did after Sunday :) All in all, I spent 32 hours on Simple Schedule this month.

There are many things I worked on as I etch closer to the beta launch of the site.

Email templates

Monday was pretty much filled with hate of hacking together email templates, using tables. I don’t want to go into too much details, but at least now the emails look nice when I send them out. There are further tweaks I’d like to do this week.

I’m not sure why I say that “links are only valid for roughly 15 minutes”. I know exactly how long they are valid for. The email above has changed in wording since.

I’m glad you signed up and hope you enjoy the service. It's ever evolving and run by me personally.
You'll need to verify your email account using the link below.

I'm always around to help you get set up with Simple Schedule, so drop me a line if you have any questions. You can reply to this email if you'd like to say hello.

Note that links are only valid for roughly 15 minutes. If you need another, you can do so in Settings.

There is also a delete email, with a red button:

That swiftly concludes email templates. May I never speak of them again.

Event details redesign

As I started implementing the logic for the details page, https://frontend.dev.simpleschedule.net/app/events/details/, I quickly realised that I didn’t like the look too much. It felt very distracting and all over the place. True, I rushed it a bit when I designed it.

So, starting from scratch I came up with the following:

Much nicer and cleaner… I hope. With some real world data it looks like this:

You can see I introduce some additional controls and a search bar when there is data. I don’t actually show search until there are more than 5 bookings for an event.

I also introduced some slight changes to wording. Instead of “Attendees” I am now just calling these “Bookings” for events. Easier to type in code ;-) And obviously makes a bit more sense!

Add a booking

I’m not sure why, but this section was rather difficult for me. But… as most things… got there with determination. We have a simple booking page, which also does a autocomplete for any attendee in your database. It works quite well and I’m happy with the results here.

Clicking on anyone will pre-fill all the data for you. Nothing else required. If you’re interested I’m using this: https://github.com/Pixabay/JavaScript-autoComplete

It’s vanilla JS and doesn’t rely on jQuery. So a win win for me!

Although it all seems quite simple there is some logic going on behind the scenes when you create a booking, even if you decide not to use autocomplete.

When you save the entry it checks if the attendee exists in the database. If they do, it will check if there are already any bookings for this event for this person, if there is it will tell you and offer you a link to the booking in question.

Ok, if there is no booking, it will create a booking. Easy as that. If the attendee is already on the master list, it will not create a second entry there, nor will it update any data - doesn’t matter if you type it in manually or not. I just check against the email here.

Next scenario is if the attendee is not on your master list. Here I create the attendee entry in the system and assign the booking after it successfully creates the attendee.

The booking logic is some of the longest I wrote for the entire app. There are many checks I have to perform to make sure it’s all good. However I found that Rails really helps a lot here especially with validating models of different data.

The public booking, for when someone enters their details on the public page for the event, works in a very similar way. So I won’t go into detail. Although it performs similar checks and stops you from registering twice.

Booking search

This one was hard. But glad I spent time until very early morning completing this. I had to get my head around how to best search bookings by date and also filter them by name.

My booking table looks like this, with the following columns:

event_id, event_date_id, attendee_id

Obviously not everything there but I had to scratch my head on how to get the attendee data across. Thankfully, after hours of looking into it, it’s quite easy. I also want to thank John Maguire over at http://www.rubyonrails.link for help with showing me how to best try and search when it comes to referencing different models.

I’m actually using ‘pg_search’ for attendees already: https://github.com/Casecommons/pg_search. After reading through the documentation again and again I found out that you can search for associated models too. Handy!

 pg_search_scope :search, :associated_against => {
 :attendee => [:name, :email]
 }

Here we go, this did the trick for me on the ‘Booking’ model. Works as advertised and returns exactly what I want, including the date filter! Happy about that small achievement. I was actually going to leave out the name search until after beta, but I had to scratch the itch.

Public event view

Not sure why I was holding it off, but here is the public display for an event:

Simple and clean, no drama. It’s got room for improvement for sure, but it does the job nicely and shouldn’t be an eye sore!

I’ll be working a little more on this over the course of the week but feel it is feature complete for now. The logic is working and bookings are created without issue. As people use it and hopefully give me feedback I’ll make changes here and there. I do want to offer a few options to let the user decide what shows up or not.

Next steps… beta

The app, as it stands, is pretty much ready for beta testing. There are a few tweaks I’d like to do beforehand. There are certain specific beta features I need to add before it goes out to the public. Not to mention finish off those items on my 'alpha' Trello board.

There is also now the urgency to work on a simple holding site to show off the product a little more and get the help page up.

I’m planning to open up another Trello board and have a Slack group for the beta so I can work with everyone that signed up. I’ll also be looking at emailing everyone on the list to give them an update on the app. It’s important I get feedback so I will probably ask them to fill out a very short questionnaire.

No doubt errors will happen, so I’m going to be setting up some extra logging. I already use Papertrail for my servers so I will try and add it on in Heroku (not even sure you can use the same account).

Before I open up beta invites, there also need to be T&C’s set up and all that good legal stuff…

If you like to contribute, please email me or let me know via Micro.blog. There is also the Simple Schedule holding site where you can sign up for a beta. On top, there is now a public Trello board with dev site progress. You can visit the 'pre-alpha' website to play around.

For other posts on the challenge, check out the links below:

1. Code challenge - from zero to web app in 60 days.
2. Code challenge - Prelude and Day 1 - Setting things up.
3. Code challenge - Day 2.
4. Code challenge - Day 3. Holding page.
5. Code Challenge - Day 4. A login page and a few tweaks.
6. Code Challenge - Day 5. Registration page and preliminary app navigation.
7. Code Challenge - Day 6. Getting in the groove, new events, MVP considerations.
8. Code Challenge - Day 7. 'My Events' view.
9. Code Challenge - Day 8. Burning the midnight oil, loud music and good progress.
10. Code Challenge - Day 9. Progress, changes and regrets.
11. Code Challenge - Day 10. There are no events, pricing thoughts and badges.
12. Code Challenge - Day 11. New logo, further changes to event details and a tiny tweak.
13. Code Challenge - Day 12. Final frontend stretch.
14. Code Challenge - Day 13. Choosing Rails, getting into the swing and thoughts on a multi tenancy app.
15. Code Challenge - Day 14 & 15. Blog post thoughts, passwords and learning.
16. Simple Schedule - Day 16 & 17. Register, Login and sharing progress.
17. Simple Schedule Dev Diary - Week 4. Profile, Settings, Passwords and Attendees.