Building a $20 "Prince" guitar

The past weekend was the ANZAC day long weekend, and seeing as I am a little burned out with programming work at the moment, I decided to take a little break from the keyboard and screen, and to tackle a project that I have been thinking about for years now - building a "cigar box" style guitar.

I've seen many people build these online, but never actually tried myself, so I looked around the house this weekend and decided that I had enough scrap material lying around to give it a go.

I don't actually have any cigar boxes lying around, but my wife did have an old art supply carry case that she no longer used, which was sitting in the back of the shed going mouldy, so she said I could have that.  Great.  I found a nice long piece of Merbau timber that was perfect for the neck.  80% there!  Collecting some old tuners from a dismantled Squier Strat, and cutting up some threaded rod and buying an ornate bracket, and we pretty much had all the parts for the guitar.  No excuses.

I posted about this build 'nearly live' on my Instagram account.  When I started posting, I had no idea whether the project would come to fruition or not, so I was taking a risk, but also, I was putting in place some accountability, because I knew I had an audience following along with me.

I also had no plans - just a rough idea of how to go about this from a blog post I had seen many months ago.  Never mind - I actually built a real acoustic guitar 3 years ago, so this couldn't be any more difficult, could it?

As it turns out, the process was fairly straightforward, and I managed to accomplish the build using rudimentary tools, and some very journeyman carpentry skills.  As you can see from the progress photos, I decided to put frets on the neck of this guitar, although that was a moot point, as I was going to set it up as a very high action slide guitar.

Once I had assembled the guitar proper (with some able assistance from my older son), I handed the project off to my wife, and asked her to paint anything she liked on it.

Given the current loss to the music world, she decided to paint a portrait of Prince on the guitar, and I think she did a fabulous job of it.

That was a really fun build, and kept most of the family occupied and creative, and we ended up with a great tribute to a superb artist that left us all too soon.


Picking Non Random Colours for the UI

I think we are up to Part 9 of our often interrupted feature posts on the building of our new human resources SaaS app HR Partner.  I've lost count a little bit, but today I wanted to talk about one of the design issues we came across when creating the dashboard.

We love using the little pie charts from chartJS to show the relative breakdowns of male/female employees, or distribution across departments and employment statuses.  The issue was, we didn't know how to best create a colour palette for the pie segments.  You see, our users can have anything from one to many dozens of pie slices, depending on their organisation and operating requirements.

For this reason, we didn't want to create a set number of colours in our palette, mainly in case our customers exceeded this limit.  We also didn't want to generate totally random segment colours each time the chart was generated because I believe that a part of a good UX is consistency, i.e. if a customer is used to seeing light blue for the department 'Finance', then seeing it as a dark red next time can throw them off.

Additionally, one of the big features of HR Partner is that HR consultants may work across completely different company entities on a day to day basis, and it would be nice if the Finance department in one company dashboard was the same colour as the Finance department in a totally separate company.

For that reason, we decided to set the segment colours based on the segment names.  So the name 'Finance' would generate the same colour on ANY company.

Our first efforts at this resulted in some quite garish colour choices which was not pleasing at all, so in the end I decided that we would try and restrict the colours to lighter pastel hues that wouldn't clash too much, but still be fairly easy to discern.

Secondly, I also realised that because our algorithm was only taking the first 6 characters of the name, there could be collisions with similar department or employment statuses (e.g. 'Part time' and 'Part time permanent' would result in the same colour).  I also wanted similar sounding names (like 'Finance' and 'Final') to generate colours that were not too similar to each other, so I decided to do a simple MD5 hash on the name to generate a semi unique hash upon which to generate the colour.  

Here is the Ruby helper method that we use to create the colour for the view.  It simply takes a text seed string, and generates a CSS hexadecimal code for the colour.

def get_pastel_colour(seed)
  # Generate a pleasing pastel colour from a fixed string seed
  colrstr = Digest::MD5.hexdigest(seed)[0..5]
  red = ((colrstr[0..1].to_i(16).to_f / 255) * 127).to_i + 127
  green = ((colrstr[2..3].to_i(16).to_f / 255) * 127).to_i + 127
  blue =((colrstr[4..5].to_i(16).to_f / 255) * 127).to_i + 127
  "#" + "%02X" % red + "%02X" % green + "%02X" % blue


I think it ended up quite pleasing to the eye. We ended up using the same code to generate the colour within the calendars too, to get consistency with respect to leave categories.


I'd love to hear from other developers on how to improve on this so the colours can be a little brighter and stand out from each other a little more.

Disclaimer: Not saying we were the first to ever 'invent' this method, but there wasn't a lot that I could find on Google, so I thought I would post here in the hopes that it might help someone else who needed something similar.  The code above is based on something I found on StackOverflow, but I cannot find it again now to post proper attribution.


Back to recording again

Last month I had a major reorganisation in my home office/studio.  I moved my MacBook Pro to the downstair office and swapped my Windows PC to my upstairs alcove studio.  I had always used my MacBook as my primary recording platform, but the upstair studio was becoming too hot and noisy and we had just installed a brand new air conditioner in the downstairs office that I wanted to take advantage of.

Over on the left for work, over on the right for play!

Over on the left for work, over on the right for play!

So this is the first recording in the new space, and I like to say that it was MUCH more enjoyable in the cool and (relative) quiet compared to the old space.  Still need to do some work on reducing reflections etc., but overall, I think it is positive.

I still need to bring my KRK studio monitors and set them up downstairs, so at the moment I am doing all mixing and mastering using my Sennheiser HD 25-SPII headphones, which is not ideal, but all I have to work with at the moment.

My fancy stereo ribbon mic still hasn't been used in anger yet - not at least until I get a 4 channel audio interface, so I used my trusty Rode NT1-A mic blended with the internal AP5 pickup in my venerable old Maton guitar.

This piece is called 'Dandelion' and is by Masaaki Kishibe.  I've actually been playing it for a couple of years now, and it turns out to be my wife's favourite of all the instrumental pieces I play.  It is a fairly simple song, but to capture that lilting feel is a bit tricky.  I don't think I have mastered it yet, but will keep working on it.  It doesn't help that I haven't played fingerstyle guitar for so long that my fingers are still not as nimble as I would like.

I mastered this track using the Slate Virtual Mix Rack plugins - nice, but a bit of a drain on the resources on my 7 year old MacBook.  I am not completely happy with it as I think the final results are still to strident.  I need to reduce some of the high frequency and bring in more bass without making it too boomy or woofy.  It is all a learning process, and I think once I have my KRK monitors set up for mastering work, I can improve on it.


Who exactly is 'excited' by your latest release?

I've seen it on tons of blogs, tweets and posts... "XYZ is so excited to announce the release of our new feature on our app...".  Heck, I've done the same with my own apps too, so I am just as guilty as anyone else.

But lets face it.  It is usually only the authors, designers and developers that get excited.  And why not? We spent hours/days/weeks building code from scratch, overcoming seemingly unsurmountable technical problems, tweaking, perfecting and polishing.  Of course we will be as excited as new parents are, to release our baby into the wild and get some validation for all that effort.

But consider the user's perspective.  Is 'excited' really the right word for them?  We actually asked a select group of our users over time, and I think the more apt emotion would be 'interested', followed closely by 'apprehensive', or 'doubt'.

You see - as the builder, you have already envisaged what your new features will be used for.  What they can achieve.  How they can be used for the betterment of humankind.  And that is great. You have it all road mapped in your mind.

But most of this takes place behind closed doors, with little or no buy in by the user.  Which is probably as it should be, if you want to focus on maximising your effort and minimising distractions.  After all, no one wants a horse designed by a committee.

What your users eventually see is something new that they have to learn.  Possibly it might be a thing that they could use, but then they wonder if they have the time to learn it and make it fit with their day to day operations.  Will they have to change the way they do things in order to make best use of it?

So perhaps we need to change the way we word new product or new feature announcements.  I certainly intend to do so moving forward.  What would be the best word choice?  Is 'proud' a better way to announce something new?  How do we get 'buy in' from the user to that they feel like they are a part of the journey, rather than just some surprised passer by who has to reel back when developers jump out of dark doorways and say "Boo, I'm so excited about this..."?

I look forward to your thoughts and ideas.


Errors don't have to be boring

This is part 7 in the chronicles of building HR Partner, our latest web app.

A short one today.  I was designing the 404 and 500 error screens for our Ruby framework, and decided to go outside the box a little.

Usually, the 404 error page is a fairly boring affair, telling the user that they have tried to load an invalid page.  I thought to make it more interesting, I would incorporate an ever changing background for the error pages.

I am using a dynamic CSS background for the error pages, which links to to load up a random grayscale image as the background.

This way, every time that a user hits an error page, they will still get the large '404' or '500' error number, but overlaid on a different background each time.  I have no control over what image gets shown, but I find myself just hitting invalid pages every now and then during my development routine - just to see what pretty landscapes show up.

The body style tag looks something like the following:

<body class='black-bg' style='height: 100%; background:url( no-repeat fixed center center;'>
  ... rest of 404 error info

So as I said - error message certainly do not have to be boring!

How I rolled my own explainer video, in a weekend, for under $100

Being totally boot strapped, and non funded, I have to market my web app HR Partner, on the smell of an oily rag, plus do all the marketing and other promotional tasks to keep the costs down.

I’ve been told many times that I basically have to have an ‘explainer video’ to introduce people to my app, because it is the quickest and most effective way to get people interested and signing up.

Well, I hunted around and spoke to several companies that specialises in making these explainer videos. I gave them my specifications, and received back quotes ranging from $2000 up to $6000 to make a 60 to 120 second video.

I debated going to or, but in the end, decided against it because every time I began a conversation on those platforms, I always felt that the price wasn’t as concrete as the other firms I spoke to. It was always along the lines of “Well, we have a starting price of $x, but if you need this, then it will be $y extra, and if you wanted that, it will be $z more…” etc.

So I thought I would throw caution to the wind and look at doing the video myself, over the past weekend. I started on Saturday morning.

The first thing I did was to go to Envato, where I have an account, and search on their VideoHive sub site for an Explainer video template. I found one there for around $40 which I quite liked. Then, I went across to theirAudioJungle sub site to find a background ambient music track to suit the video. Found one. Total time searching and evaluating on Envato was around 2 hours.

Next issue was that the explainer template required Adobe After Effects to modify, so I signed up for a one month subscription for JUST After Effects on the Adobe Creative Cloud — total cost, approx. $20.

I had never used After Effects before, so while the app was downloading, I viewed a couple of 30 minute introduction and tutorial videos on Youtube. It didn’t seem too hard. I figured that I had managed to self learn other Adobe products before, and with my development background, I felt confident I could get to grips with it.

Once installed, I spent the better part of Sunday afternoon tweaking and customising the AE template, and wrote up a short script. Well, I thought it was short, but it ended up being around 3 minutes long.

Then came time to do the voiceover. I hate the sound of my own voice, but luckily my wife has a really nice speaking voice (she has actually been asked to be a voiceover artist on a few occasions). So she did the voiceover for me. One take, 5 minutes, and we were done.

I guess the other good part is that I am a musician as well, so I have some fairly good quality studio equipment which ensured that the recording sounded decent. I did some post processing in Logic using compressor and reverb plugins to tidy up the audio, and mix in the backing music I had grabbed from Audio Jungle.

I managed to complete the post processing on Sunday night, and uploaded to Vimeo on Monday morning, ready to embed the video on my website, which I will do later today after I have a break.

I think I spent a total of around 10 hours of my own time over the weekend doing the editing and audio post processing. After Effects turned out to be fairly simple to learn and use in the end.

So, my total costs (approx) were:

  • VideoHive explainer template — $40
  • AudioJungle backing track — $20
  • Adobe After Effects subscription — $20 (one month)
  • Voiceover artist — $0 (thanks to wifey)
  • Audio production — $0
  • Template customisation — $0

GOOD BITS: Having a voice over artist ready to hand. This is an important part of a video, and I can appreciate it is difficult to find a voice that fits. I consider myself lucky. Also, the explainer templates on Envato were REALLY good. Better than I expected.

TEDIOUS BITS: Learning After Effects from scratch. But the hardest bit was syncing up the explainer animations to the voiceover. I came close, but had to do a fair bit of chop and checking on both the explainer template and the audio file to get things to line up.

No disrespect at all to the companies who charge the prices they do for the production of these videos. It is definitely a taxing process, and my efforts are going to be very amateurish compared to theirs. If I had the funding available, I would have definitely engaged one of them to do this for me, but in this case, I had to work within my means.

Final results on Vimeo here:

Dogfooding 101

dogfooding (computing - informal) - to use a product or service developed by that company so as to test it before it is made available to customers.

We have now got to the stage where we have launched our latest web app, HR Partner.  Though we have reached launch stage, there are still a few things about the development of it that I'd like to share with you.

One of the things that we deemed was important to have from the outset, was an API (Application Programming Interface) that our users could use to query their employee data in HR Partner and integrate it with other systems.  This was slated as a 'Phase 3' project, which was to be commenced well after initial launch and we had a solid base of customers on board already.

However, one of the other things that we wanted to have in HR Partner was an extremely flexible reporting system.  Basically, we wanted our users to be able to query their data and filter (and sort) the data by any database column, including custom fields that the user can create within HR Partner.

When designing the architecture of the reporting engine, we realised that it would have to be quite complex, with a ton of checks and meta programming to enable the user to specify just about any query they wanted across the main employee file, plus the related lookup files.

We realised that we would essentially be duplicating the 'engine' for the reporting side, along with the engine that would drive the API later.  So we decided, why not kill two birds with one stone here - and we temporarily shelved the reporting engine development to sit down and build version 1 of our API engine.

Version 1 was basically purely a 'read only' API engine that allowed us to query the database tables and return the results as a JSON data stream.

THEN, we went ahead and started building the front end for the reporting engine, which directly used our API engine to pull and sort the data we needed for the reports.  All transparent, and invisible to the end user.

As you can imagine, this was a major change to our development timelines, but at the end of the day, it actually saved us time later on down the track.  The bonus is that we get to see our API being used under real world stress conditions.  We still haven't released the API specs publicly, but plan to do so in the coming months once we have completed stress testing and built the read/write components.

Building the API first also allowed us to start writing other apps for integrating various legacy payroll systems to HR Partner.  One of the payroll systems we support is Attache, which is a 30 year old Windows based system that uses the old Microsoft ODBC method to extract data.  We have designed a 'gateway' Windows app which uses a combination of ODBC and JSON API to pull data from Attache and upload to HR Partner in the background.

We used the Padrino framework to build HR Partner, which is based around Ruby/Sinatra.  Padrino allows us to mount separate apps within the same server easily, so we essentially have one app for the main HR Partner app, and another separately loaded app for the API, which allows us to still host on one AWS Elastic Beanstalk instance, yet be able to separately upgrade and take apps online/offline.

I am glad we made the design decision to shift our build targets around and get the API built first.  I can appreciate now what a lot of other startups are trying to do, by building the API, then designing their app around the API.  It makes for a far more robust and solid system.


Don't hide the delete button

Welcome to part 6 of our series on designing HR Partner, our latest web app that is slated for release in 2016.

This episode, I'd like to go through a design consideration that I had with the file upload library module in our app.  In this module, the user can create 'categories' for their files, and upload an unlimited number of files to that category.

They also have the option to delete a category if it is not needed any more.  The problem is, we won't allow them to delete while they still have files allocated to that category.

The question was how do we deal with this restriction?  On our early Alpha version, we simply hid the delete button if there were still files within the category.  However, this gave the user no indication that they COULD delete the category, at least unless the category was already empty, in which case they would see the button.

We thought that this was counter intuitive.  We wanted the give the user an indication that they could delete, as long as they deleted the files first.

So in the second iteration, we put the delete button back, but disabled it when there were active files in the category.  This still wasn't optimal, because there was no explanation as to WHY the button was disabled.

So we went to the next level, and made the button active.  If the user presses it while there are still active files, they will get a popup telling them why they cannot yet delete.  If there are no active files, then they will see the usual delete confirmation dialog.

We hope that this method means we don't clutter the interface with too much extra text, yet still gives the user an idea of what they can and cannot do within a particular screen.

When your hard work becomes invisible

In my latest project, I have been working very hard on getting the UX right.  I want the interface of my web app to NOT fight the user every step of the way, and to make some semi-intelligent guesses as to what they want to do.  Wherever part of the interface looks clickable, I want the user to be able to click on it and get the result they expected.

That sort of precognition takes hard work - LOTS of hard work.  Just today I spent pretty much ALL day on one small piece of functionality, that at the end of the day, my users will probably never really notice.

Come to think of it, *I* pretty much don't notice it now that it is finished, but I know it is there, and it is making my movements through my web app a lot smoother and logical.  

Just this evening I was thinking about it, and I was a little sad that all my work was essentially invisible to the end user - after all, they only usually notice things when they DON'T work.

But I was reassured by something a wise man once told me - "Character is what you do when no one is watching".  I like to think that my app has good character.

Don't change that menu

We are rolling along with Part 5 of my blog series that I am writing while building our latest web app HR Partner.  The earlier posts can be found on this site, and I will shortly put together an index page, so all the posts can eventually be cross referenced in the one place.

Today is a short post, and it is to do with a tiny design decision that we made today.

Clutter, specifically screen clutter, is a pet peeve of mine.  I dislike having more than is necessary on my app screens.  This must be a habit going back to my flying days.  Most aircraft cockpits have been designed by ergonomic and efficiency engineers to make the capturing of information as easy as possible.  Under IFR (instrument flight rules), the pilot has to minimise moving his whole head to avoid disorientation that can occur with no external frame of reference.

I try to always abide by these rules when designing my interfaces.  No extra clutter that will distract.  On the left hand side of the HR Partner page, is a menu showing the different HR 'modules' that the user can work with, i.e. Employee Training, Document Attachments, Absence Details, Assets on Loan etc.

I wanted to have the module menu so that whenever the user clicked on a module, it would disappear from the menu.  After all, if you were in the 'Absence' area, it would make no sense to have the 'Absence' menu option still available to click, was there?  It was another line in an already long list.  Removing it would make the list shorter and easier to scan for the user.

Or so I thought.

The module menu in question, on the left.

The module menu in question, on the left.

It turned out, that having the module list change (even subtly) via the removal of a single line tended to throw our test users off.  It turns out that most users will subconsciously memorise the placement of menus and clickable areas on the screen - even if they scroll up and down!  They tended to keep a mental map of where everything was, and had already calculated the minimum distances required to reach those spots.

Moving them by one line or so tended to throw out their entire frame of reference and result in confusion and pauses when trying to find where they wanted to go.

In the end, we decided to leave the module list exactly 'as is'.  I would appreciate any thought anyone out there might have on this.  Also, if you have any scientific research that would back up my theory about users mapping the screen layout subconciously, I would appreciate a heads up.