UX

UX (User Experience) is a term that’s thrown around left, right and centre these days with little thought to what it means.
I guess you could look up the World’s source of truth – Wikipedia and you’d quickly find what the community at large generally argues UX to be.  Mostly UX related articles talk mostly about emotion and look and feel (they tend to ignore the usability part feel bit for most part – and few mention it).  If you ignore usability you will soon get angry or aggravated users who won’t want to use your system.  A system that looks great but works like shit, is less valuable than a system that works great that looks shit, however its important to strike a good balance between the two.

I had the luxury of working with a client to perform a UX survey  of over 5000 of their users and what was interesting, the majority of feedback we got went somewhat against current market trends. They didn’t disagree that products shouldn’t look great but they didn’t like the fact that most Web Apps were slow, cumbersome and just plain tedious to use when performing everday tasks.

Our core audience were divided into two main categories of users. The first category which made up about 1300 users, were the ones that used the system daily but irregularly throughout the day to perform minor tasks. Generally their volume of data was low and they were more focused at doing a specific one-off task for the day before leaving the terminal.

The rest (the bulk) of the users where larger volume users who typically spent a great portion of their day, or long periods during the day entering data among other related tasks.

Interestingly the most requested feature of the test system was to have the ability to open and work on more than one form at a time.  A close second was the ability to print directly to a printer including from mobile devices and thirdly, friendly keyboard control was requested. Then followed a variety of adhoc features and functions.

In looking at the market for such systems and frameworks that provided as a minimum, the most requested features it became quite obvious that there weren’t a lot of choices – from our perspective we wanted something fast, secure and reliable (these btw were requested but not among the top 3).  Probably the closest we found was a commercial product called bindows which does a pretty good job of what it set out to do – that is provide a Windows look and feel for the Web App.  After some consideration of multiple open source frameworks (including Microsoft’s MVC, Backbone.js, CakePHP, Dojo, ExtJS, FuelPHP, jQuery, MooTools, Node.js, Twitter Bootstrap, Yii, YUI, Zend and some others), tools and technologies we chose the following for which to start our project:

– JavaScript + jQuery as they are good and established client-side technologies that could easily be expanded as required in addition to being able to find additional resources easily.

– PHP + C# for similar reasons than the JavaScript + jQuery options. In fact we chose PHP as our priority for server-side technology as it has a lot more hosting options – in particular with 3rd party hosts and on Android devices. Of course we have also proven we can switch the server to C# with little impact to the client.

– RapidOS lots of hard effort was put into this custom framework using plain JavaScript and jQuery to come up with something very solid, reliable, fast, flexible, secure and easily maintainable set of coding patterns in which to quickly develop our apps.

Our first product using the RapidOS framework extensively is RapidFMS and so far our clients love it.

JC