usability (9)


Fast forward with a pencil >>

I remember developing a really fast technique for advancing/reversing audio cassette tapes using hexagonal shaped pencil and a lot of technique.  Part of it was the pointless childish challenge, but also down to the brutality of my stereo player at the time. Fast forwarding from beginning to end of a C90 tape could take less than  a minute, climaxing in an almighty clunk as the stereo took a few seconds to register the tape could be moved no further.  I repaired the occasional broken tape using tiny pieces of sellotape – again, a  childish challenge.  For a child, adversity can take many forms, and as a child (occasional tantrums aside), we are persitent in our goal of navigating round obstacles put in our path – be they parental rules, or dodgy stereos.  Our dogmatic belief is there is always a way round a problem.

An application presents a tester with a systematic set of challenges to overcome.  We know there will be bugs somewhere, we know improvements can always be made, and we know there will be vulnerabilities.  But unlike a child, we have to follow a more logical structure rather than the unstructured systematic approach of a small child. However, we can have both … end users can be viewed as childlike beings, and there is no reason you cannot add some method to the erratic methods of children to reach a goal.

I am well aware of my own behaviour when surfing.  I turn into a cantankerous, impatient user who will leave your unusable site, just to spite you.  Yes, I can be that petty.  As a tester, I try to carry that with me.  When users encounter a problem they may just give up, or they may just hammer away trying to get something to work.  They may be bothered to write you an irritated email, but lets face it – how many of us can be bothered with that.  I do it – but only as opportunity to introduce myself and testing services 😉

So we need to account for two broad user groups – those that give up at drop of a hat, and those that will persist doggedly to get round a problem.  Both a major traits of a small child that are carried through to adulthood, and surface in differing situations.  None more so than the web, which is most likely to bring out the sulky child in us all.  This is possibly why I have always had positive experience using school leavers/undergraduates as testers, as they still have significant amounts of that childlike energy. You need to channel of course, as random chaotic testing can end up providing little value.

There are advantages to both, and testers need to play both roles, depending on the type of testing you are trying to perform. Doing a usability check definitely warrants the former group, as by far a major cause of people dropping off sites is Usability. If you are doing a security test, then an approach that covers multiple courses of action will highlight potential unexpected behaviour or security issues. You must have noticed, if you have ever been in a User Acceptance Test session with project stakeholders, there is also one person who will ask the awkward questions, and will deviate from path of instruction. They are the most useful person in the room, even if it may be painful to hear what they have to say sometimes!




How to code with no standards … by .NET

Coding standards on .NET projects is traditionally poor – I don’t know if this is related to the type of developer who ends up in .NET world, or the awkward nature of the main toolset (Visual Studio). Or a general problem endemic in modern developers – we all have our unfavourite tasks, but we are working in a business – it’s not a “pick ‘n mix” scenario.




Code bloat

Every web application developer should learn html, css and javascript coding standards – given how frequently they are also charged with resultant front-end output. The forgiving nature of modern browsers can mask a whole heap of problems, that will cause performance issue, and on more extreme level, applications errors. Sloppy html coding can result in passwords being exposed, session tokens visible in URL’s – so security can be an issue also.




Is it really that hard to label a form field?

Web Accessibility – countries that have legal requirement, this isn’t optional. It is sad that it takes legality to force websites to comply, even with the basic (and very attainable) Level A compliance. Something such as a form label, regarded as a very low prioirty issue within the SDLC, could prevent a user using accessibility tools to be unable to complete a transcation, or miss an important checkbox option.




UX – doesn’t the lazy acronym say it all

User experience or UX as its annoyingly known as these days, is disappearing up its own rear end. As usual, a very good concept has been taken and butchered/tailored according to the compnay/individual using it as a self-marketing toy. User Experience is part of Usability, not some ethereal designer concept playground. The primary issue around approach to user experience is it quickly becomes personal opinion, i.e. the UX designer defining what the user wants, rather than observing user demographics of the web application in question. User experience is part of Usability, and as such in the realms of QA. Usability is something than all developers should observe as general rule when coding, as there are certain fundamentals around the user exeperience that should not need definition. Clear registration process, for example.

User Experience (abbreviated: UX) … quality of experience a person has when interacting with a specific design. This can range from a specific artifact, such as a cup, toy or website, up to larger, integrated experiences such as a museum or an airport.

Not so #nathanbarley now – the easiest way to view IT terminology is to apply them in more general context than just IT projects. We don’t need anyone to tell us that putting one leg in front of the other is the best way to walk. In IT you can get away with doing that, and even documenting such levels of banality.

A good recent example of this obsessive level of pointless granularity is a query I had, around security questions set by website users on their profile. I logged a defect that when entering this section, the answer fields were blank, implying I had not entered any before (I had). The developer claimed this is a requirements change, and needed to go through that process. My first question was under what circumstances would that ever be “required”. of course there are no circumstances – it is an error in code that failed to return the previously entered answers.

User Experience (UX) is full of this kind of hyperbole – and it doesn’t belong. You can get round this by having a set of best-practice rules, and I would suggest you do to avoid the frankly comical discussions you can get trapped into around User Experience and Usability in general. Everyone thinks they know UX, becuase we are all users. Do understand other users requirements is more the question to ask. Do we understand UX/usability demands of our user demographic, as well as good UX/Usability fundamentals.