Early September saw the end of my Montana Code School experience and the successful completion of final projects. For the last few weeks we shifted from working in a small group on only one project to working as a whole class on two separate projects. Our instructors linked us up with a couple of non-profits in Missoula so that we could have the experience of working from the beginning with a real client. So, in addition to getting more technical experience we got a taste of project and client relationship management.
The Project: GRIT
For the first project we worked with staff at YWCA Missoula to build a web site for the GRIT program (Girls Representing in Trades). Before even starting the project we met with the GRIT program manager to get a sense of what was needed from a future site. The GRIT program in Missoula is fairly new—only a couple years old. Consequently, the program manager expressed interest in something that would help her market the GRIT program and enhance her recruiting efforts. Since the target audience for the program is high school girls the website needed to be “hip”. It also needed to optimized for presentation on mobile devices since that’s where the teenage girls are hanging out—on their phones. Girls visiting the site would need to be able to “see themselves” in images, videos, and testimonials. The website should present the program as something they could do and enjoy being a part of.
Lessons Learned: Project Management
Because we worked on two projects simultaneously, and because there were now ten of us working as a team instead of four, project management became a thing. We set up a couple of boards on Trello that we could all access. We used a modified Kanban workflow to track what was getting done and by whom. Once we got into the projects, people started selecting tasks and breaking off into various work groups. I became the default Project Manager, overseeing the Trello boards as well as checking in with work groups to get an overall sense of how the projects were shaping up. I also took the lead on facilitating communication between the client and the rest of the development team. Having done quite a bit of facilitation in my career as a teacher and workshop leader, project management came pretty easily in spite of the different environment. Nevertheless, the experience taught me a few things.
I began to realize that clients may not have a clear idea what a web site or app may be useful for beyond basic marketing. They’ve used sites, or seen nicely designed sites and been left with a good impression, but getting clients to articulate what it is they want in a site may be difficult. This may be because clients are not thinking about functionality in the same way as those who code the sites. Not having experience with the technologies, a client might find it hard to know what one can potentially do with the web beyond what she’s seen on other sites. I also began to see how website creation often has more to do with organization and communication than it does with actual coding. This is especially true for a marketing-focused website. In order to tell the organization’s “story” on the web, you have to get the primary stakeholders to agree on and articulate the organization’s basic message and mission. You have to make sure they all agree on the necessity of a website (re)build and on what organizational goals it will achieve. You then have to spend a fair amount of time facilitating communication: between client and the software development team, between the dev team and the designer(s), and between different work groups. Without these, the project might not even get off the ground. The technology is really just the means to an end. The real story is the organization, or the program or project—what it is, what its purpose is, what it’s trying to do, and who it’s trying to help.
Lessons Learned: Servers and Mailgun API
One of our goals for the MVP was a clear way for prospective participants and volunteers to contact the organization. We wanted to create a contact form to reduce the steps needed to connect with the organization. We could have just set up a mailto: command in the jsx, but that would have opened the user’s email client and I personally don’t like that approach. I don’t use my computer’s own default mail client and so when it gets triggered automatically (through a mailto: command), I end up having to deal with another application that I don’t normally have open. That defeats the purpose of making a call-to-action easy and straightforward. I settled on using Nodemailer (a Node.js module designed for making it easy to send email) and the Mailgun API. Nodemailer can work with SMTP but I opted to go the API route since I was a little bit more familiar with getting an API integration working. It also looked like the API had some better built-in security. It did require, however, that I set up a separate server.
We had used the Create-React-App npm package for the front-end GRIT files and the package came with its own development server. However, it wasn’t set up to be used in production. Since we were working with an API it became necessary to create a new production server. I created an Express server in Node.js and set up Nodemailer to work with Mailgun there. Initially I tried to keep the server files in the GRIT project root folder, but had problems with this. We thought that maybe having the two servers in one project was complicating things. In the end I moved the Express server to a different project folder and that seemed to clear things up. Mailgun email service seems to be set up primarily for large email campaigns and is probably overkill for one simple contact form, but it was pretty easy to work with. It does require you to set up a free account, however. I relied heavily on the following tutorial to get things set up: http://denisecase.github.io/2016/10/08/enabling-contact-form/
Lessons Learned: Heroku and Git
Deploying to Heroku was always a challenge, both on our first project and then again for our second projects. In the case of GRIT we had to deploy both the front-end files and the server to separate Heroku instances. One issue we faced had less to do with Heroku deployment and more to do with getting our master branch on git updated. To make Heroku happy and get the deploy working, we discovered we had to make several small changes to the files, such as adding a procfile, specifying node and npm versions, after our first deploy attempt. We forgot, however, to update those file changes on the local master branch, do a pull request and get them in the git remote master branch before attempting to deploy again to Heroku. Once we finally got the front-end deployed correctly in Heroku it was out of sync with the remote master branch in git and it was difficult to go back and fix. We finally resolved it, but it took some work. So this ended up being more of a problem in our version control process than a problem with Heroku.
Heroku is great for simple apps you want to deploy quickly and for free, but it’s not going to be great as a long-term solution for a business or organization. If the site isn’t visited regularly it takes a long time for a free Heroku app to get up and running (about 30 seconds)—not great if most people leave a site after 4 seconds or so when nothing appears. If you are going to deploy to Heroku, make sure that your git process is clear so that the code you have on your master branch looks like what’s on the Heroku instance. Otherwise, someone coming in to work on your site won’t have a good idea where to start with any work because the instance that is live on Heroku won’t clearly reflect what the code is on github.