Search Blog

Blog

Get the latest on what's happening at itomic

Informative commentary on the web industry from the experts at Itomic.

August 6, 2014

Itomic supporting Connecting Hands

By Ben Townsend

Connecting Hands Logo.png  237×150Connecting Hands is a not for profit charity reaching out to young victims of Human Trafficking & Slavery in Cambodia. They work to eradicate enslavement in the sex industry by offering young women who have escaped lives of enslavement and abuse with the opportunity to start a new life free from such vulnerabilities.

Itomic support this fantastic cause by looking after their web assets.  Please join with us in supporting them and make a donation via their website http://connectinghands.com.au/donation/.

 

 


July 18, 2014

Top 10 Tips for Website User Testers

By Ross Gerring

User testing in relation to software development (incl. website design) is the phase during which persons other than the software developers themselves give the system a good going-over in an attempt to identify and – with the help of the software developers – resolve all issues that would otherwise stop the system going live.

Naturally the larger, more sophisticated, and more mission critical the system, the more attention must be paid to testing, user or otherwise. I (Ross Gerring) began my working career as an analyst programmer for a large international bank, and so I’ve seen first-hand the huge amount of testing, time, process and technology that goes into the rigorous pre-live and post-live examination of banking systems. The following advice is much more aimed at the relatively much smaller and less complex world of user testing for websites.

In no particular order, here are my top 10 hints and tips for website user testers:

  1. Expect bugs! Don’t be shocked that they exist! Bug or issue resolution is a completely normal and expected part of any software development lifecycle. Trust us on this one.
  2. Issue resolution is an iterative process. An issue is not resolved until you say it is. It might take a bit of to’ing and fro’ing between yourself and the developers until an issue is finally put to bed. Sometimes it might even feel like you’re going 1 step backwards for every 2 you go forwards (e.g. previously squished bugs reappearing). Expect this. It’s the nature of the beast.
  3. If you do nothing else, make sure you’re using great tools to help you report issues to your website developer, and then for the issues to be well managed thereafter until a satisfactory resolution has been reached. We use, and are big fans of, Bugherd. There are lots out there: 17 Bug and Issue Tracking Apps to Developers.
  4. Indicating priority is important. Make sure you can flag issues in terms of their business criticality, e.g. critical, important, normal, or minor. Remember this is about YOU telling the developers what’s business critical and what’s not. They could take educated guesses, but you don’t want them too. Generally speaking developers will tend to hit the most critical, showstopping items first. Here’s an example of priority and category labeling from the Drupal project: Issues for Drupal core.
  5. Grouping, categorising, or tagging issues is also very helpful. Suggested tags might be: typo, error message, graphic, broken link, content, logo, layout, etc.
  6. Try to distinguish between feature requests and bugs/errors. There’s no such thing as a finished system (it’s a competitive world out there – you can’t stop innovating!) so be careful about getting carried away at this stage with all the new stuff (feature requests) you’d like to see. Your ideas are important, but ultimately the business has to decide between “must haves” and “can wait”.
  7. Developers will typically respond to issues in batches. Your labeling of issues by priority and type will come in handy here. Issues of a similar nature can be more efficiently dealt with by developers, not least because fixing one of them will often fix lots of them at the same time.
  8. We all strive for perfection, right? News flash: there are very few (arguably zero) perfect systems out there. And by perfect we include ‘bug free’. There’s a genuine business trade-off to be made between getting something out to market quickly, versus spending more time attempting to getting it closer to perfection and with all the associated diminishing marginal returns that come with that effort. Indeed, some systems go live to the world with the word ‘Beta’ (or even ‘Alpha’) prominently displayed. ‘Beta’ is acknowledging the existence of bugs – perhaps lots of them – and is an open invitation to the public, typically motivated or incentivised early adopters, to help the development of the system by reporting back their experiences. A beta release of software is very suitable for some systems, but totally unsuitable for others – e.g. banking systems! Bottom line: there’s no such things as a finished or perfect website - in the same way that a business is never ‘perfect’. There is always room for improvement. Got ideas on how to improve your website? Great! Jot them down on a wishlist for the future when time, budget and priority permit – but don’t let them hold you back making your otherwise awesome website live!
  9. Where possible and reasonable, DIY, i.e. fix an issue yourself. “What?! Isn’t that job of the developers?”. Not necessarily. Most websites have a content management system (CMS) behind them, i.e. a web interface to allow you to relatively easily self-manage many facets of the site yourself, especially content. Often it’s the future content authors of a site that are the user testers, and therefore it stands to reason that the user testing phase is the perfect opportunity for such persons to learn all about how to self-manage the site to the fullest extent that the CMS permits. Broken link? Typo? Photo needs replacing? DIY! Much better to learn how to (or not to!) do this now, than when the site is live.
  10. Consider automated testing of your website using software dedicated to the task, e.g. Selenium. If you’re finding yourself having to do lots of re-testing of a repetitive and/or complex nature (e.g. testing a shopping cart process), a more automated approach might help, This will requires its own investment (time and expertise) to set this up, which might be extensive, and therefore it’s a cost/benefit decision.

Bonus Tips

  1. Naturally you’ll want to give most of your attention to the most mission critical components of your site, but this assumes that you know which these are! The larger and more sophisticated your website, the more important it is that you have a plan in advance of starting to test.  At minimum, ensure you’ve identified all the essential functionality of the site (so you don’t miss anything important), and more generally that you’re clear on the size/breadth of your site so that you don’t accidentally overlook sections. Be sure to include any instances of where your site exchanges data with external systems, .e.g. are your ‘Contact Us’ form submissions getting through to the inbox of the correct recipient(s), and is your newsletter subscription form to MailChimp or CampaignMonitor working as intended?
  2. Avoid reporting duplicate issues. It just floods your developers with extra reports that they have no choice but to tale time to review. Common causes of this are:
    i. Multiple persons testing the same site… so perhaps make clear rules about who’s testing what areas of the site, or which functionality.
    ii. Reporting the same issue in lots of places on the site, even though you only need to report it once. So wherever you have common or recurring functionality, design, or layout on your site, rest assured you only need to report the issue where it occurs on a single page, and not every page where you see the same issue. For example: the font size might need to be bigger for the title of each page. When your developers resolve the issue in question, it will almost certainly resolve the same issue on all other pages simultaneously.

 


June 18, 2014

What is 2-factor authentication, and why you should be using it

By Ross Gerring

In the space of one hour, my entire digital life was destroyed. First my Google account was taken over, then deleted. Next my Twitter account was compromised, and used as a platform to broadcast racist and homophobic messages. And worst of all, my AppleID account was broken into, and my hackers used it to remotely erase all of the data on my iPhone, iPad, and MacBook.

In many ways, this was all my fault. My accounts were daisy-chained together. Getting into Amazon let my hackers get into my Apple ID account, which helped them get into Gmail, which gave them access to Twitter. Had I used two-factor authentication for my Google account, it’s possible that none of this would have happened

source: How Apple and Amazon Security Flaws Led to My Epic Hacking

2-factor authentication goes by various names including:

  • Two-factor authentication (of course!)
  • 2-step authentication
  • Multi-factor authentication. OK, multi-factor authentication could involve 3 or 4+ steps, but the principal is the same. This movie clip shows a fantastic example of multi-factor biometric authentication  :-D

So the words ’authentication’ and ‘verification’ are interchangeable, as are ‘factor’ and ‘step’.

It’s a very easy concept, wrapped up in big words. All it means is that you’ve got to provide more than just one method of verification (such as a password) to successfully access something, but typically a computer system such as online banking.

By having to provide more than a single method of verification, you’ve sacrificed a little bit of time & convenience for exponentially greater security. Which makes 2-factor authentication a very, very good thing to be taking advantage of whenever you’re offered the opportunity. (authors note: I use 2-factor authentication for approximately 10 different systems at time of writing, and I want that to rise).

2-factor authentication app

The most common forms of providing a second method of authentication are:

  1. Using a smartphone app to generate new passwords for you that change every 30 seconds or so. Such passwords are also known as one-time passwords. One such app is called Google Authenticator (see Samsung smartphone image to the right) and is available for Android, iOS and Blackberry. Don’t think that just because it’s a Google app it’s therefore biased towards Google devices or systems. Quite the opposite. Any computer system can choose to use it – or other similar apps – to provide one-time passwords for users of their systems.
  2. A physical device such a security token or dongle that your bank might provide and that can hang on your keyring – see image below-right (the RSA SecureID). Such devices offer exactly the same service as your Google Authenticator app, except that they’re typically limited to providing security for just a single system – so less versatile. You certainly wouldn’t want to be carrying 10 different dongles on your keyring for 10 different systems.
  3. Good old fashioned SMS. When you try to login to a system (or indeed perform a significant event inside a system such as a money transfer from your bank account), it sends an SMS to your phone (smart or otherwise!) that you must first enter before the transaction will complete.
  4. Biometric security, such as a fingerprint or eye (iris or retina) scan. In other words, any method that is able to distinguish you from anyone else on the planet with a sufficient degree of confidence. It’s quite amazing how many biometric opportunities there are.
  5. Not necessarily to be used only in a 2-factor authentication scenario, but this use of NFC technology looks very interesting: the NFC Ring. For example, imagine that the only person who can use your mobile phone is the person (hopefully you!) who is wearing the NFC ring that has been ‘paired’ with your phone. Just don’t hold your phone in the wrong hand!

RSA SecurID Dongle

You can expect to see more and more systems adopting some form of 2-factor authentication in the near future. It’s no wonder because all the signs are that, overall, cybercrime is on the rise, with no suggestion that it will ease off any time soon.  The systems that adopt it first are typically ones that contain the most sensitive information and/or provide the most ‘power’ (such as funds transfer) to the authenticated user. But increasingly you’ll see less obviously confidential systems employ it – such as social media websites, CRM systems, etc. – simply because no-one likes having their data abused or stolen. Indeed, if you use a system that you consider to be confidential in nature that DOESN’T yet offer 2-factor authentication, we suggest you should demand it! For example, these increasingly disgruntled and shocked users of the very popular online accounting software Xero have been demanding it for over a year: Two Factor Authentication on Xero login.

No system is 100% secure in perpetuity. And 2-factor authentication is by no means the be-all and end-all of system security. But at time of writing it’s certainly one of the most potent, accessible, and relatively easy-to-use security methods out there.

How to find out if a system you use makes 2-factor authentication available? Google is your friend, e.g. here’s a search for Linkedin 2-factor authentication

Itomic’s recommendation: use 2-factor authentication at every available opportunity. The costs are hugely outweighed by the benefits.


What is cache, why you might want to clear it, and how

By Ross Gerring

Wikipedia defines (computing) cache as

…a component that transparently stores data so that future requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere. If requested data is contained in the cache (cache hit), this request can be served by simply reading the cache, which is comparatively faster. Otherwise (cache miss), the data has to be recomputed or fetched from its original storage location, which is comparatively slower. Hence, the greater the number of requests that can be served from the cache, the faster the overall system performance becomes.

We’ve borrowed a bit from the above for our entry on cache in our glossary module: http://www.itomic.com.au/glossary/cache/

Cache is ‘good’ – and very necessary – because it speeds things up, e.g. the internet.

Cache is ‘bad’ (challenging!) because sometimes you see old information in (for example) your internet browser when you really want to see the newest, latest information. A good example is when you know information on a web page has been updated (probably by yourself), but when you visit the page that’s supposed to have been updated – it hasn’t.

Wouldn’t it be great if you could just push a button and clear (delete) *all* the caching services that sit between yourself and the latest, newest web page information that you’re trying to look at? Here’s the bad news – you can’t, and probably never will be able to. This is simply because there’s cache that’s within your control to be able to clear, and cache that isn’t. That said, it *might* indeed be your web browser’s cache that’s the only cache that is stopping you from seeing the latest information. So clearing your browser’s cache is definitely worth a try.

We’ve found a great article about how to clear your browser’s cache, covering all the major browsers: Chrome, Firefox, Safari, Internet Explorer and Opera. So click that link!

If you’re using Google’s Chrome browser (as most people do these days) then we’ve recently spotted this Chrome extension that can clear all the various types of cache that Chrome uses with a single click: Clear Cache. Very handy. Once installed, be sure to review the configuration options for this extension (Settings > Extensions > Clear Cache Options) so that you can fine-tune exactly what the extension does when you click on the button.

There are other caches you might want to try clearing on your local computer: DNS, memory, and thumbnails. The first on that list – DNS – is most likely to be helpful in relation to seeing updated web page information (especially if your website has just been re-hosted). Here’s an article on clearing all those caches for Windows machine. And here’s another for clearing the DNS cache on a Mac.

If, in spite of all your enthusiastic cache clearing, you’re still not viewing the latest web page information that you expected to see, then either:

  1. Call your web and/or hosting company (it’s easier if they’re one and the same – like Itomic!). They should be able to help or advise further.
  2. Er… could you be mistaken? Perhaps the information you’re seeing in your browser *is* the latest there is? :-)

Itomic website gains a glossary module

By Ross Gerring

Every industry has its jargon, and arguably IT is one of the worst offenders. But hey, give us a break! The pace of innovation is insane, so it’s no wonder that new words, acronyms, and the like, have to be created in order to describe and differentiate all the new stuff.

It’s hard enough for us lot in IT to keep up with the jargon, let alone our clients. So the least we can do is to help better inform our clients – actual and prospective – in terms of what various web words and phrases actually mean. To this end we’ve recently added a glossary module to our site. Here it is:

http://www.itomic.com.au/glossary/

What we like about this module is that it’s not a standalone, static page of information. It’s clever enough such that, if there’s a match between a glossary word and text *anywhere* on our website, then the text is automatically enhanced so that rolling your mouse over the word will pop up the glossary module definition. So no need to click… but you can if you want to.

Oh, and having a glossary module on your website can only be a good thing in the eyes of the major search engines.

If your industry has jargon, why not consider a glossary module for your site? Ask Itomic today.