Search Blog


Get the latest on what's happening at itomic

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

September 15, 2014

Webmail Access [How to]

By Izumi Mitsui

Using POP email? need access to emails when you’re traveling or not near the home computer? Here’s a quick tip!
To access your webmail login portal type ‘/webmail’ at the end of your web address.


This will take you to a login portal that looks like this:

Enter in your email address and password and you’re in!
If you can’t remember your password contact our team and we’ll be happy to reset it for you.

Happy days!

September 8, 2014

WordPress 4.0 is here. Welcome Benny! [FAQs]

By Izumi Mitsui

It’s about that time again, the latest version of WordPress has now been released. This time in honor of a Jazz Clarinet player, Benny Goodman (aka The King of Swing).


What does Benny bring to the table?

This update focuses on smooth management and delivery of your content with less clicks and scrolling.

Quick cap of Benny’s highlights:

  • Intuitive Editing

  • Seamless Media Embeds

  • New Plugin Browser

  • Media Library Grid

For detailed information visit here:

Why is Benny good for me?

Since relevant content is a crucial factor with organic SEO, WordPress has done a great job with Benny by allowing you (as the website admin) more effortless control over your content.

Should I update to Benny?

Our best recommendation is you contact your web developer to get advice.

As with any other updates, there’s a chance it could result in unexpected behaviour or causing the site to break. Please take precaution before updating the platform yourself.

Do I have to update?

The short answer is no, however there are many reasons why you should keep your platform updated at all times. If you’d like more information on this topic please let us know.

Don’t have a web developer/consultant? We’re more than happy to have a chat and offer you assistance.

Feel free to contact us at anytime!

September 2, 2014


By Ben Townsend

By “Post-Live” we mean that your website is operational and outside any warranty period.


We love providing service and support for our clients to ensure their websites are delivering maximum business benefits.


We charge for our time to provide this service and support. We always strive to provide a satisfactory resolution as soon as possible using available resources and minimum billable hours.


There are two pricing models by which we provide support, Pre-paid (preferred) and Post-paid.




Pre-paid *best value*



Client pre-pays for blocks of service and support in advance.

After the event, Itomic invoices client for service and support provided.


Yes. The more hours you purchase in advance, the bigger the discounts.

No. Standard hourly rates apply.

Minimum fee (‘flag fall’)?

Minimum 5 mins. Time is logged in 5 minute increments thereafter.

Yes, equivalent to 30 mins of time, and 15 minute increments thereafter.


Yes, priority is given to clients with Pre-paid credits.



1 year from date of purchase.




Q. What’s billable and what’s not?

A. Broadly, all our time is billable, except where it’s explicitly included by another contract.


Q. I host my website with Itomic. What service and support is included?

A. Your website hosting fees are for Itomic to provide the hardware, software, power, and network connectivity for your website to be up and running 24/7, or as close as possible to that. Where a clear failure by Itomic’s hosting services is determined to be the cause of issues with your site, then our time is not chargeable. In all other instances, it is. Our priority is to get you website up and running smoothly as soon as possible, and then to determine the root cause if it’s not already obvious as part of the fix. On occasions it’s not time or cost effective to determine the root cause, e.g. where a simple server restart resolved the issue and the issue doesn’t recur.


Q. I didn’t do anything to my website, and yet it’s got a problem. Surely therefore it’s not my fault, and therefore I shouldn’t have to pay for Itomic to fix it?

A. Websites operate in an extremely dynamic (some would say hostile) environment. There are a multitude of reasons why a website might experience problems in the apparent absence of any causal activity by the website owner. For more on this phenomenon, we strongly encourage you to read this article:

Our time is chargeable – unless the cause was identified as a failure of our hosting services.


Q. My site has been hacked. Will Itomic charge to fix it up?

A. Yes. Itomic cannot be held liable for malicious attacks on your site by 3rd parties. Advanced security systems built into our hosting services ensure that thousands of potential threats are deflected every day, but it only takes one of them to get through to potentially cause issues.


Q. I pay Itomic to regularly patch my website with security updates. If it gets hacked, will Itomic still charge to fix it up?

A. Yes. As stated in such contracts, regular patching of a website is a smart and recommended insurance policy against getting hacked, but it can never reduce the threat down to zero. Prevention is better (and cheaper) than the cure, even if the protection isn’t 100% guaranteed.


Q. It took several attempts by Itomic before the issue was fully resolved. Do I pay for all attempts?

A. Yes. In complex systems, and when there is pressure to get a site back up and running asap, sometimes there is necessarily a degree of trial and error involved. A great analogy is the “House” tv medical drama, where the complex system is the human body, and the #1 priority was to make the patient get better, even if it meant trying a few things that didn’t work before arriving at the best solution.


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



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.