It's a Duffy Thing t-shirt

I recently released a major overhaul for this website. The old website used an old version Node.js and used Ghost to power the blog. I didn't find it very easy to maintain and wanted more flexibility. While the new website may not have the best design, I'm a lot happier with it overall. Along with the rewrite of the website itself, I also gave it a new name: It's a Duffy Thing. This was inspired by a shirt that my Dad bought me.

In this blog post I want to go over a few of the technologies used to power the website. Partially so it's all together and in one place, but also as a kind of "behind the curtain" look at the website. If you want to dive in even further, take a look at the source code on GitHub.

The new version of the website is built using Node.js, SASS, and Handlebars. There's no front-end JavaScript on the website other than a couple of little external scripts (such as Google Analytics), so there's nothing to discuss when it comes to front-end JavaScript.

Node.js

I've liked the idea of Node.js for a while. For simple websites (such as this) that receive little traffic (such as this) and can be used to experiment with new technologies (such as this) I think it's great. My previous projects have used io.js, which was recently merged in to Node.js, but this project uses the latest stable version of Node at the time, version 4.2.2.

Gulp

Using Node has a few other advantages. Ones of those is being able to use gulp. There a lot of workflow automators out there now, and which is "best" seems to change fairly rapidly. I'm happy with my workflow using gulp so that's what I stick to. I use gulp to automate all of the following tasks:

  • Compile my SASS files, including Bootstrap
  • Automatically add browser vender prefixes to support the latest 2 versions of major browsers
  • Removed any CSS rules that aren't used anywhere on the website
  • Minify the output CSS
  • Generate sourcemaps for development

This is all done in a single gulp file. I've also added a watch task so that changes made to SASS file automatically trigger a recompile. I'll likely extend this to the views directory, too, so that any CSS rules added or removed from the HTML will be add or removed from the compiled CSS.

Poet

When looking for a blogging engine I was torn between one which provided a lot of management and functionally out of the box (such as Ghost), or one which offered more of a basic set of scaffolding to work from. After trying Ghost for a while I opted for the simpler approach, which led me to Poet. Poet takes in a directory containing markdown files and converts them to HTML, pulling out some extra meta data from a JSON structure at the top of the file such as the URL slug, publish date, and tags.

I've really loved working with Poet. It doesn't get in the way and me choose how things should be. I actually override most of the routes and mainly use it as a markdown to HTML converter, but it works great for me.

SASS

I've used SASS on an off for a while but I really wanted to dive in a bit further this time. The design and layout for this website is fairly simplistic so I can get away with using Bootstrap and just adding a few additional styles. SASS is perfect for this, and as described in the gulp section, it ends up being really nice workflow which produces a fairly small file.

Handlebars

Along with SASS, Handlebars is probably my favourite things that changed about my workflow when working with the web in recent years. I still find it hard to not put logic in to the Handlebar files (thanks, PHP), but I'm loving partials and inheritance. Magical!

Helmet

Helmet is a great piece of middleware for Express which helps improve the security of a website. There's always more that can be done, but it's been very easy to add things like the Content Security Policy and setting the X-XSS-Protection header.

Open Source

I decided to open source the website for a couple of reasons:

  • It makes deployment via PM2 or just the command line a little easier
  • It makes a good portfolio piece
  • It forces me to write slightly better code since people might look at it

I'm happy with my decision to open source the website. I can already see that I'm writing better commit messages and separating my commits up further.

Future Posts

I've got a few other post ideas (some of which are already 90% written), so there's going to be more activity on here soon. You can subscribe to the RSS feed, follow me on Twitter, or simply check the website soon to see new posts.


Touch ID is a wonderful piece of technology, to the point where wouldn't buy an iOS device without it. It had many great uses, such as:

  • Unlock the device
  • Authorise Apple Pay payments
  • Add biometric restrictions within apps

However, I wish to discuss the first of these: unlocking the device.

When is fast too fast?

I do not currently own an iPhone 6s or iPhone 6s Plus so I have not been able to try out the new (claimed 2x faster) Touch ID. However, from my own experience using my iPhone 6 I can confirm the problem that some people feel they are having: the device unlocks too fast. Simply pressing the home button to check the time or a notification is often enough for the device to read the fingerprint and unlock. Personally, the majority of the time, unlocking the device is what I want to do. However, assuming that Touch ID continues to improve and its uses continue to grow I see a potential new way for it to work.

Pre-authorise

Touch ID currently works on the principal of:

  1. The user asks for an action that requires biometric authentication (or the PIN, which is loaded after biometric authentication if we want to get technical)
  2. The system asks the user to authenticate with their fingerprint
  3. If the authentication fails, return to step 2
  4. If authentication succeeds, continue with the user's action

This is of course an over simplification, but it demonstrates what's happening. However, in the case of unlocking the device the action of "unlock the device" is assumed, which is not always correct. My proposal is to allow the user to pre-authorise an action from the lock screen. The user could then perform any of the following actions without having to touch the Touch ID sensor:

  • Unlock the device
  • Authorise an Apple Pay payment
  • Perform an action on a notification that requires authentication

Letting the user know what's happening

This would obviously be a confusing change for some users, and is something would likely only appeal to the nerds that care about the small time save/loss. For this reason I would personally set it as an option that is off by default (or mentioned during setup) and have a visual indicator of what's happening.

LockGlyph device unlocking UI

LockGlyph (shown above) is a tweak available for iOS 8 that adds the Apple Pay animation to the lock screen when unlocking. If instead of fully unlocking the device when authentication the checkmark were to stay to indicate authentication and acted as the pre-authorisation for the next action. To try and keep the action of unlocking quick the checkmark could also be tapped to unlock the device, as well as the classic slide to unlock. It may even be possible for Apple to implement some form of check so that when the user may wish to interact with the lock screen (such as a notification or music controls being shown) this options is turned on, but in other situations the auto-unlock would only happen based on the user preferences. To summarise, the interaction would go a little like this:

  • User unlocks device (via home button or power button)
  • User's fingerprint is read and authorised
  • If there are pending notifications or music controls showing, do not unlock the device
  • If there are no pending notification or music controls showing, auto-unlock the device based on the user's preferences

Conclusion

That's a simple little idea I thought about recently. I'm no UX Designer so this may be an awful idea, but I feel I would personally benefit from it. Either way, I'd love to hear your thoughts. The best way to contact me would be via Twitter.