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.

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.