I recently participated in redesigning a Django website, and got introduced to a lot of new tools. I thought I should share what tools and process Scott Mahr, my wife Amanda, and myself used redesigning the website of Pacific Rim Early Childhood Institute. Maybe it will help others undertaking a redesign, or introduce you to some new tools, but at very least it will help me remember them!
So I reached out to my elementary school friend, and former coworker, Scott Milligan for help with making it slick. Even since our youth, Scott has had an amazing knack for originality, design, and intelligence. I knew he wouldn’t disappoint.
Our first step was to identify our priorities. Scott had a good questionnaire that got Amanda and I thinking. We identified:
- what users liked about the current website (navigating it was simple because it had a very flat structure, you could reach almost any other page from the menu)
- other websites Amanda liked (like color schemes, images, layout)
- the pages Google Analytics reported as most frequently visited, which needed to be easily accessible (for example the programs and FAQs were more popular than we previously realized, and so should be easily accessible from the menu)
Ok, having given you an overview, here’s the details of what we used to make it happen.
I hadn’t heard of Notion before, but as I understand it, it’s basically a web app for taking notes, making a wiki, communicating tasks, and maintaining a database.
Scott creates a project in it to organize his work, and periodically shared pages he creates to communicate the project status.
In the role of client, it was nice viewing a page with information rather than just an email because if there were updates to make, he just updated the page and notifies us of the change, rather than sending an email with the updated info. My main problem with emails for communication is that they quickly become buried, or lost in confusing threads. Just having a single page to refer to for the most up-to-date information was great.
Figma users will probably be offended at the comparison, but it seems like a Dreamweaver web app. A designer can drag-and-drop elements on a page, then export them to CSS and HTML files. It’s also great for team collaboration (and other things I’m sure, as it’s getting quite a bit of attention in the WordPress world too.)
Scott created the designs using Figma, then sent me a link to view and collaborate on them, and used it to created PDF copies to share with others fnot interested in signing up for the service.
My use of Figma was light, but it seemed to ease designing a mobile-friendly site, and converting it into source files for use elsewhere.
Pelican is a static site generator for Python. You can define a site design in HTML and CSS, then content for various pages, and it will take care of combining the two.
Scott brought the Figma designs into Pelican, and created a few sample pages’ content in Pelican too, in order to create a separate demo site.
Jinja is a template engine for Python. It’s very similar to Django’s built-in template engine, and so worked well with Pelican.
Scott used Jinja to make template files which worked for the Pelican site, and later could be used with almost no modifications on the Django site.
Netlify specializes in deploying static websites, so it was a helpful tool to use with Pelican. Scott set it up with the demo site’s GitHub repository so that any changes made there would automatically have a brand new demo site setup for them.
Even when we created a pull request on GitHub, we could view a new demo site using the content from that pull request. That was much slicker than having just a single demo site hosted somewhere (which we’d need to manually update anytime there was a change). So it definitely a handy tool.
SASS is a preprocessor for creating CSS files. When writing CSS files, you end repeating a few of the same things a lot: like what font size and colours to use. SASS let’s you instead define variables (eg one for the standard font size you want a page to use, and another for the colour) so you can refer to those variables throughout your CSS files. That means you do a bunch less typing, and makes it easier to change things down the road. Oh and SASS does a ton of other magic I haven’t explored.
So instead of creating the CSS files directly, Scott created SCSS files (the first “S” stands for SASS), which SASS (with help of build tools like Node.js and NPM) used to create the final CSS file used on the website.
Scott basically set the project up to let me use Bulma, so that I could make existing website content (like the FAQ pages, for example) look good by just adding some CSS classes from Bulma. It was pretty easy to use.
In full disclosure, it was a bit of work to change the entire site’s HTML structure and add the necessary CSS classes, but certainly no worse than switching to any other CSS framework.
Django Crispy Forms is a Django module to help generate HTML forms. Django has a built-in dorms system which helps creating HTML forms and the corresponding server code for processing them. It majorly cuts down on repetitive code.
But it’s one problem: unless you’re going o circumvent how it generates the HTML for the form, it’s not very flexible.
This proved to be an unexpected problem with Bulma: in order for Bulma to work it’s magic, it required specific HTML structure and CSS classes.
So you can instruct Crispy Forms how you generally want the form HTML to be laid out (in my case, I created a new layout specifically for Bulma) and then it magically makes it happen.
Before Crispy Forms, we had a lot of repetitive code saying how to lay out the forms. It was great to reduce all that into a single line (the equivalent of telling it “just lay out the form as usual”.)
The difficulty was our Forms were a little inconsistent in how they were laid out. So there wasn’t a 100% predictable way to lay them out, so I needed to make quite a few exceptions to the Crispy form’s layout (eg, Crispy Forms lets you define a lot, but it makes the reasonable assumption you don’t want different forms intermixed with each other… well, we did, and so working around that was tricky.) Still, that was a problem with the existing code’s goofy design, not Crispy Forms.
Stocksy is a website for purchasing stock photos. What I found unique about them is that they charge by image size: so if you just wanted a small image for a corner of your site, it’s pretty cheap. You only pay larger fees if the image is going to be a big hero image. And that makes sense.
Hopefully people will be sharing links to Pacific Rim on social media like Facebook or Twitter. It turns out, neither platform does a great job of displaying your website on posts unless you provide special HTML meta tags on your website. The Facebook Sharing Debugger and Twitter Card Validator are helpful for making sure your site looks good when being shared on social media.
When it was all said-and-done, this is what we produced:
As you can see, it turned out pretty slick and is mobile friendly. You can check out more of Scott’s work at smahr.net.
Questions or feedback? I am too eager to chat with strangers on my blog, so I’ll reply really fast!