My Obsession with Clean URLs

I’m webmaster for WCS at UIUC this year, and I decided to try to game the system.

Ok, maybe not game the system per se. I’m by no means an expert in search engine optimization and still haven’t gotten around to diving into our Google Analytics. But I do know that clean URLs are now being used more and more in practice. Just see this link and you’ll know what I mean.

I wanted the same thing for WCS. We had already worked very hard to rebrand ourselves digitally (check out our new website), incorporating the web trends such as parallax backgrounds and single-page scroll. Ok, responsiveness is still our weak spot. Working on it.

But it didn’t make sense to then have a url that had a .html extension. We already made this far. Why not take it a step further.

I’ll admit. If you checked out our website a few days earlier (even just a day before this is published), it would have had some .html extensions tacked onto file names because I originally wanted something quick. It was a hacky way of getting all of our information out there because we were initially focusing on design and user interface. But now that we’ve had those ground rules and styles established, it was time to make sure that the url presence was golden.

We use Github Pages to serve our website, which is mostly static (for now) and it makes for quick and easy changes, as well as easy collaboration. What is also nice is that aside from the standard username.github.io repository in which all pages/files in the master branch are served, each repository we create in our Github organization can also have the same effect with a gh-pages branch.

So I put this to practice. I wanted a URL such as http://www.illinoiswcs.org/officers, and so I first made a repository named officers. Splashed up an index.html file, along with copying some assets over from our main website, and wah-la, I had everything I needed. I first pushed to master and then went through the process of creating a new branch called gh-pages, which contained all of the same versions of files as the master branch. Pushed that to remote, wait around 5 minutes or so for Github Pages to refresh, and the link was solidified.

No more http://www.illinoiswcs.org/members.html. Now we have http://www.illinoiswcs.org/members/.

Not only going through this process led to cleaner URLs, which are easier to remember, but also it modularized a little bit our website’s codebase. I could concentrate on creating custom HTML/CSS/JS solely for the officers page without adversely affecting the main website if some styling went ugly when Gulp did it’s thing for example.

It makes it easier for our officers to collaborate on a certain page that’s related only to their role rather than the entire website. And it’ll make it easier for us to add more sub-urls based on new events or initiatives we are trying out this year.

Maybe there’s some duplication in main styling. That’s one thing we have to figure out. Perhaps I can just make a github repository specifically for shared assets (like scripts and Sass/Css files along with Gulp files), throw it into a gh-pages branch and then serve from a URL within our website. Onto the to-do list.

Maybe we could’ve done the same thing by using AngularJS’ $router and $locationProvider services and just kept everything in one code repository. But with officers working on different initiatives that were seemingly unrelated, it was just simply easier to make separate repos in case more things needed to be added or customized. It also caters to officers who may not have experience with AngularJS and the beginning of the school year quick-dive and humdrum leaves little room for it to be learned. Yea, you can follow a tutorial, but in terms of maintainability, this is much easier for our organization’s purpose.

It’s never too late to start doing best practices in code maintainability. This is one step for me and WCS as a whole to make sure we leave future officer boards prepared with a much more maintainable digital presence.