Level 6, 122 Walker Street, North Sydney 2060  |  (02) 9993 3300  |
Posted 20th March 2018 by Lawrence McCrossen

Of course we all want our browsing experience involve fast response times, but how do we manage performance when designing a website?


It’s worth remembering that sometimes you want to slow down the process eg confirming deletions, purchases, important form submissions, and forcing the user to read certain text before committing to an action. This is becoming particularly important as some processes can be completed from verbal instruction.

Authentication in another important example of slowing down the user experience.

But what about just plain slow-to-load? Possible causes are, in no particular order:

• Database queries

• Hosting resources or location

• User bandwidth

• User device eg ageing computer, low powered device

It's a given that we review all of the above when presented with this problem, and fix the issue if it’s under our control. Even if you can’t actually speed up the full loading of a page, there are still a few approaches you can take:

• Caching – keep previously loaded information within the browser or client

• Make loading more gradual – displaying content piece by piece, perhaps skeleton and text first, then images

And if you can’t do that, then maybe you can at least improve the perception and experience:

• Make loading processes more informative and transparent – spinning wheels, % complete bars, and steps complete messages. Even if it’s not accurate, it will be appreciated. It’s very annoying to wait on a page, not even knowing if it will ever finish

• Provide animation to at least make the waiting more entertaining

• Keeping users busy while waiting – perhaps displaying pricing or other information for the user to consider

• And if you really want to steer a user in a particular direction, you could make some things slower than others, but I would generally avoid this more manipulative trick


This is fairly complex topic which we’ve covered before in a previous blog http://thebridgedigital.com.au/blog/Do-Google-PageSpeed-scores-matter and needs to be carefully considered in the context of automated PageSpeed results, real-world loading times, and offsetting against some of the approaches to page loading that we’ve described above.

If you'd like to discuss your website or software development options with The Bridge, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 19th February 2018 by Lawrence McCrossen

A conversation we have with clients at the beginning of a website development project is about when the copy will be written. One common misconception is that you can design the website, with sections full of “lorem ipsum”, in the knowledge that this can be filled out later with the real copy. The most important thing being that the design looks beautiful, and the structure of the website is easy to navigate.

The problem is that this is like building a box before you know what’s going to be in it. The eventual content might fit, or it might not. Sure (unlike a physical box), you can put in scroll bars if the content is longer than expected, but this already starts to compromise the design, as the layout starts to become unbalanced. And what if the content is very small, within a box that’s quite large?

Add in links and maybe even some images, and you can see how the design might need to be changed to accommodate the content.

The problem is sometimes exacerbated because the copywriter is a freelancer, somewhat external to the main project team, and brought into the project in an ad hoc manner. By the time the copywriter has been briefed and is available, time pressure on the project deadline has necessitated the main website design and development has already started.

There may be lessons from the world of printed magazines, where it would be even more difficult to accommodate a change in page layout after the copy has been written. Consequently, magazine designers must make their pages content-centric.

The world of software is of course much more flexible, but our recommendation is always to generate content very early in the project. If nothing else, it means that the that copywriting (and reviewing of copy) doesn’t end up causing delays in go-live because it’s been left to a later stage.

If you'd like to discuss your website or software development options with The Bridge, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 06-03-2017 by Mitch Brown

It’s no secret that we’re big fans of Drupal at the Bridge. After an epically long development time, Drupal 8.0 was finally released in November 2015, representing a big shift in how the content management system works under the hood and the way developers must work with it. A little over a year on, we’ve launched several brand-new websites with Drupal 8 as the back-end. So, what do we think? Answers below…

Almost everything is “in the box”

Drupal 7 was great, but it was always a must to install additional modules to bring out its functionality. Now plugins like Ctools, Entity API, WYSIWYG editors, jQuery and so many other ubiquitous features are built into Drupal Core, making deployment and configuration much faster so we can get on with the real work of developing websites! Without knocking our other PHP CMS WordPress too much, it'd be nice to see more of that CMS' essential modules (CPT UI, Total/Super Cache etc) built in as well.

Templating with Twig

The drastic overhaul of the Drupal templating engine makes building custom themes easier, more intuitive and easier than the old PHPEngine. PHP logic can be kept out of template files, making life much easier for front-end development. For our clients, this means, better code that's easier to manage and overall faster implantation of your custom web layouts.

Symfony is music to our ears

Drupal is now based on the MVC framework Symfony. Cleaner, more elegant and mercifully more contemporary in architecture than Drupal 7. Sure, this represents something of a learning curve coming from Drupal 7, but this change, despite being somewhat disruptive, is for the better for developers working with Drupal and for the stability and modernity of the content management system. MVC Frameworks for PHP are the way forward to keep PHP relevant against the likes of Ruby on Rails, and it’s great to see members of the PHP CMS “old guard” embracing contemporary coding.

Even more extensible and modular

Hardcoding overrides through hooks was often the norm in Drupal 7 to develop functionality but now, it's much easier to develop modules/plugins rapidly to build on the CMS core without constantly reinventing the wheel.

Streamlined content management

While still familiar for veterans, the content management back-end has been given a welcome overhaul. Faster, snappier, better organised and packed with CKEditor out of the box, there's lots for our clients to love when it comes to day-to-day content management. While not as “pretty” as WordPress' back-end, it's a much smoother experience for a lot of seasoned content managers.

There are of course a few things to watch out for...

Smaller Support Community

While the documentation and developer support is great, there are less resources available for developers in terms of forums and articles to give you a head start when you get into trouble. If you encountered a Drupal 7 bug or oddity, a quick Google search can save a lot of research time on getting back on track. However, being a newer system with a significantly different core, this is not always the case with Drupal 8. Additionally, while almost everything you need can be found in Core, there are still some niche but useful modules that have yet to be ported, over a year on from release.

Changing Gears

For new Drupal projects, we will always choose the latest version. For existing sites, though, the upgrade to version 8 is not an insignificant undertaking as themes will need to be re-worked and custom modules made compatible or replaced. Because of this, clients with an established and well-functioning Drupal 7 may be less inclined to upgrade for some time yet.  This leaves us in a position of having to support both versions, switching mental gears between Symfony, Twig and all that good stuff, and the "old" way!


Now, this is possibly an unfair one. We LOVE Drupal's new caching. Pages load faster than ever before and cache rebuilds are still straightforward. But, anecdotally, we have had more display bugs due to caching issues than any other problem while developing with Drupal 8, especially when Views share the same content but are intended to be styled differently. Without going in to detail, this has caused a fair share of developer headaches! 

Ultimately though, Drupal 8 represents a huge step forward for the CMS. We’ve been enjoying our time getting to know it and are looking forward to releasing many more new Drupal 8 projects in 2017. It builds on everything we love about Drupal and drags it into the contemporary CMS landscape. It’s not perfect and won’t necessarily suit every client or project, but no Content Management System ever will and we will continue to wholeheartedly recommend Drupal as a solid and dependable CMS for our clients.

If you'd like to discuss your website or software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 23-02-2017 by Mitch Brown

The first in a regular series spotlighting exciting libraries and frameworks that find a place in the Bridge Digital’s web development toolkit...

Susy (http://susy.oddbird.net/)

An oldie, but a goodie. Susy is undoubtedly our go-to grid system for responsive layouts. Sure, Bootstrap and Foundation are amazing frameworks, packed full of features, but most of the time as front-end developers, we simply need a fast, elegant, no-frills way to quickly build responsive grid layouts, and Susy is simply, the best tool for the job. It has a small file size footprint and you get only what you need, not a bloated framework. Susy is Sass powered, with a beautiful and easy to work with structure and fits easily into just about any web project. Your CSS classes can remain semantic without any strict presentational class names leading to simple beautiful and easy to understand markup. 

Algolia Places (https://community.algolia.com/places/

This thing is a godsend. You know all those wonderful predictive address form inputs on Google Maps? Algolia Places gives you that functionality in a plug and play library that can supercharge any form field input into a dynamic auto-complete address field. It will handle map suggestions, auto-completion of customers’ shipping addresses, country or region selectors, anything requiring user location input. It’s mega-fast and has built-in typo tolerance. 

D3.JS (https://d3js.org/)

Data manipulation and visualisation is big, and it’s only going to get bigger. Tools like HighCharts, Google Charts and Periscope provide users with highly functional, responsive and beautiful charting of complex data. D3.JS is a newer kid on the data visualisation block, offering powerful visualisation components to build dynamic, data-driven webpages using SVG, HTML and CSS. With D3.JS you can build simple or complex table layouts, calendar views, bullet charts, bar charts, diagrams, scatter maps, bubble charts, tree maps, motion charts, data or word clouds, line charts, wheels, the list goes on and on (and on).

Lottie (http://airbnb.design/lottie/)

As Flash lets out its death rattle, HTML5 animation is becoming more and more essential on the modern web. There’s lots of animation libraries out there for inserting simple effects but for more complex requirements needing timelines, character or dynamic animation, you’ll either need to spend a lot of time calculating timings, curves etc. by hand or turn to a tool like Lottie. The go-to for animators looking to transform their creations into HTML5 has often been the Adobe AfterEffects “Bodymovin” plugin, which is able to export complex AfterEffects animations to a JSON file full of all that timing and sprite data for use with your web page. While attempts at importing full AfterEffects data has been limited previously, Lottie provides a library that claims to be able to handle (or will handle in the future) much of AfterEffects’ functionality - masks, line art, mattes, paths etc. The best thing about Lottie though is that it automatically makes your animation responsive without having to code your own media queries and adjust image sizes manually. It works seamlessly with iOS, Android and React Native as well. Lottie was developed by Air BNB and, while still in its infancy, looks like it will quickly become the number one HTML5 animation plugin on the block.

Pure.CSS (https://purecss.io)

Yahoo’s Pure.CSS is a modular, lightweight alternative to bulky, one-size-fits-all frameworks like Foundation or Bootstrap. It provides ubiquitous CSS resets based on Normalize, layout and grid modules, forms, buttons, menus, tables - all the common building blocks of any website or app. Very easy to use, override and customise, Pure.CSS is a great go-to for rapid front-end prototyping or even as a basis for a production project. It even plays well with Bootstrap by allowing integration with whatever specific Bootstrap modules you require. All that said, a Sass version would be nice Yahoo!

ReactJS  (https://facebook.github.io/react/)

We’ve saved the biggest, most complex and arguably best for last. When released by Google, AngularJS revolutionised web development by providing powerful, client-rendered dynamic views for mobile and web applications in a relatively easy-to-use and learn MVC JavaScript library. To over-simplify what Angular and similar frameworks do, it is to leverage JavaScript to create dynamic web applications with data-bound form data all within the one HTML page without needing scripting languages like PHP to render the data. Since then AngularJS has evolved into Angular (dropping the JS), and inspired several other similar frameworks for mobile and desktop web app development. ReactJS is Facebook’s web application framework which is rapidly overtaking Angular. At a functional level, ReactJS provides similar features to Angular but does so under a very different paradigm (far too detailed to explain here). Depending on your app’s requirements and architecture, ReactJS offers significant advantages to Angular. First and foremost, ReactJS is a lot easier to learn as it relies more on existing JavaScript and jQuery knowledge rather than enforcing a strict way of doing things, that is, in Angular you must always do things “the Angular Way”. Skills in ReactJS are transferrable to other frameworks like Ember, whereas as a developer proficient in Angular is, well, proficient in Angular. The new version of Angular also forces you to learn Microsoft’s TypeScript rather than using standard JavaScript/ECMAScript. Another big advantage is that ReactJS tends to have better performance in larger web applications. Probably the most exciting part of ReactJS is the introduction of ReactNative (http://www.reactnative.com/) which allows building cross-platform desktop and mobile ReactJS apps that run natively on IOS, Android and Windows.

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 01-02-2017 by Mitch Brown

Google Analytics

No one can deny the ubiquity and importance of Search Engine Optimisation (SEO) in the modern web. Having the world’s most beautiful, functional and interesting site doesn’t mean much when no one can find you!

In the rush to optimise every keyword, craft the perfect META tags, manage your redirects and generally out-do your competition, it’s tempting to turn to online analysis tools as the be-all and end-all of your SE, treating their automated scoring as gospel. Today we’re going to have a look specifically at Google’s PageSpeed Insights tool (https://developers.google.com/speed/pagespeed/insights/) and answer the question of how useful hitting that coveted “green score” is in technically optimising your website SEO.

As developers, we are often engaged with SEO companies who consult on client projects, and often brand manager, marketing staff and other stakeholders become heavily involved in the development process. Quite often, the topic of PageSpeed Insights rankings comes up, with a strong push to hit the optimum green ranking levels on Google’s tool. PageSpeed Insights will analyse your website and give it a grade based on a number of rules and recommendations (most of them eminently sensible) for improving your website’s performance e.g., compressing images, ‘minifying’ code etc.

This can create an extremely difficult balancing act between matching aesthetic design, site functionality and hitting these PageSpeed Insights targets. And as a set of guidelines and recommendations, PageSpeed Insights is an important part of your SEO analysis but, in our view, “hitting the green” is often not as important as people have been led to believe.

Obviously, page load speed is incredibly important to your visitors. A webpage that takes too long to load may leave them frustrated and quick to close their browser tab in favour of an alternative site.  Google too, uses page load times as an important metric in ranking your site. While content is most certainly king, out of two identical sites with similar levels of optimisation, external links, the faster loading one will likely have an edge in the rankings.

However, it is important to note that when crawling your site, Google does not use your PageSpeed Insights score to determine if your page is fast to load. The GoogleBot will simply record the actual load time of your site as it crawls your site.

It is actually quite possible to somewhat game the PageSpeed Insights score by hitting all of their recommendations, while still having an incredibly slow site. Why is this?

Well, because, while in general they will boost the load time of a site under Google’s assumptions of how your website looks, acts and is coded, a lot of the metrics they use to determine your score are extremely flawed under various scenarios.

Our first example comes from the complication of the rising practices of using CDNs (Content Delivery Networks), to deliver commonly used components or “libraries” like jQuery. These CDN services can greatly improve performance of your website by taking the load off your own hosting and leveraging the powerful bandwidth and server distribution system. 

Sounds good right?  Well, the thing is that because these libraries exist off-site, you don’t have any control over a number of the metrics that PageSpeed Insights uses. A classic, and rather amusing example, is the embedding of Google Analytics from Google’s own CDN, will cause warnings and score reductions like the below.

Save Browser caching

That’s right, Google PageSpeed Insights is complaining about HTTP headers for its own code for Analytics that is served (by their recommendation) from their own servers! A developer cannot fix this but it will negatively affect your PageSpeed Insights score. This sort of warning flag can occur on all manner of third party CDNs and libraries, including common components like jQuery, Angular and Bootstrap from Google’s own servers!

The other recommendation that causes massive headaches for us as developers is the dreaded “Remove Render-Blocking JavaScript and CSS” warning. In general, to decrease the load time of your page, it’s best to make all your JavaScript and CSS load last so all the content of your page loads before the code that formats the content and makes the page look pretty. This prioritises the “meat” of your site to hit the browser first. Sensible right? 

Well it is, until you realise that there a lots of common site components like image sliders that may either break or cause unwanted rendering of hidden content if the code for them doesn’t load first. An example – we have an image slider. The code automatically forwards a list section on the page of 5 photos into an image carousel. If the code loads first, everything looks as it should. If the code to format the carousel loads last? Well, we may end up with those five images just loading in a long list on the page, potentially blocking the page content and just making things look ugly until the JavaScript kicks in at the bottom of the page. This becomes more of an issue the more media and content-heavy your page is. In this case, it makes no sense for the user experience to load the slider code last, but that’s just what PageSpeed Insights suggests you do!

Obviously, smart developers will be able to find ways around the above example but, at the end of the day, it’s often not worth spending the amount of additional coding time necessary as, it’s actually the real-world page load time that matters to Google – not the arbitrary score it gives you in PageSpeed Insights.

So, how do we check how the website actually loads? There’s plenty of tools for that, our favourites being Pingdom - https://tools.pingdom.com/ and GTMetrix - https://gtmetrix.com/. These will actually give a more accurate reflection of the speed of your site.

So, does that mean PageSpeed Insights is useless? Absolutely not. It’s a fantastically useful tool for flagging potential problem areas such as un-minified code, uncompressed images and web server settings. But, chasing the spectre of green or perfect rankings in the tool is an often wasted exercise. Our recommendation? Use it as a guide, not a hard measure.  Carefully review each warning and recommendation and determine if actioning them is firstly, possible and secondly, going to actually improve the page load times and check your real-world scores.

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 19-10-2015 by Mitch Brown

This is the first in a series of posts discussing the various technologies and techniques we make use of at here at the Bridge for client projects.

We have previously discussed the selection and use of content management systems when building your website. Another, far more recent concept that has changed the face of modern web is the introduction of HTML & CSS front-end frameworks. 

The use of frameworks in the development process is nothing new in back-end and software development. One of the leading development technologies, Microsoft .NET, is itself a framework consisting of libraries and tools to speed up and assist in development of projects using various programming languages. PHP has a number of development frameworks available for use as well, including Laravel and Symfony. In recent years, the same concept has been applied to front-end development.

Front-end web frameworks vary in complexity but generally include code for a responsive layout grid, as well as visual and user interface components like buttons, table styles, navigation systems (mobile menus, dropdowns) and/or other visual effects using jQuery or CSS3. The main reason for making use of these frameworks, whether integrated in a template or theme for a Content Management System or used for a static website or landing page, is to speed up development time. Front-end developers can use the existing components to rapidly build complex layouts without wasting time creating custom layout code or styles. 

This works particularly well for time-sensitive, deadline-driven projects such as campaign microsites and landing pages but these frameworks also give front-end developers the ability to rapidly prototype projects with functional UI elements, preview-able by clients, graphic designers or back-end developers directly in the browser. In some cases, this approach can used to bypass traditional static “wireframing” techniques for experimenting with page layouts and User Experience design. Doing so can also allow front-end developers to work on projects concurrently with the graphics and back-end team, once again creating obvious workflow efficiencies.

An important distinction to note is that, while frameworks include visual and layout elements, they don’t provide a layout or content on their own. Out-of-the-box, even full-featured frameworks like Bootstrap do not resemble a content management theme or template, they are to be used as the building blocks for your own unique designs and layouts. Visual elements included can be customised and themed and used in other systems.

At the Bridge Digital, we work primarily with four main front-end frameworks: Susy, Foundation, Bootstrap and jQuery UI, which we outline briefly below:


Susy is a relatively new kid on the block and, compared to the others mentioned above, is very minimal. Susy is focussed on one functionality only, but its an extremely important one: the responsive layout grid. 

Foundation and Bootstrap both include their own layout grids, but also a host of other libraries, tools and UI elements. Susy comes with none of this but there are plenty of cases where use of more fully-featured framework is either unnecessary (smaller projects that won’t make use of the additional elements) or undesirable (more bespoke projects, highly graphical layouts, projects with strict technical requirements etc). Susy on the other hand, can generally find a home in any front-end project.

Susy is focussed on being able to create grid-based layouts quickly and simply, with easy creation of media queries. Layout grids and responsive design components can be time consuming, so having a lightweight, go-to solution for generating content areas in re-sizeable, fully responsibly columns and rows is a godsend in front-end development.

Foundation & Bootstrap

While different products, Foundation and Bootstrap are direct competitors and share enough similar functionality to discuss in tandem. An in-depth comparison of the two is a perhaps a subject for another time.

Foundation, created by Zurb and Bootstrap, built by the internal developers at Twitter, are fully-featured frameworks with a host of components: the aforementioned responsive grid, UI tools and effects, jQuery and JavaScript plugins, image styles, typography elements and much more more.

Both these frameworks are very powerful and can greatly speed up development time. Using either system, a skeleton or prototype of a website or HTML app can be created quickly using the default styles. This can be extremely useful when trying to create a usable UI for a more complex project that can be utilised by back-end developers before the full graphical design has been completed. Because of their customisable nature, either framework can also be radically altered in design to form the base code for a website or CMS theme.

The only significant drawback of these kinds of full-featured frameworks is that the code often contains a lot of elements that will not be used in your project, adding complexity to the codebase. While both frameworks do allow a level of modularity, where only select components are loaded, this can be something of a turn-off for developers due to perceived performance issues and “code bloat”.

jQuery UI

Unlike the other frameworks that are based mostly on HTML and CSS, jQuery UI is a library of jQuery-driven user interface elements that can be plugged into existing projects. jQuery UI includes widgets such as collapsible accordions, date-pickers, buttons, progress bars, tabbed content areas and tooltips, as well as effects like colour animations, visibility alterations and toggles. These libraries are extremely useful for front-end developers to draw on when creating interactive or animated elements and can easily be used with other frameworks as necessary, in content management themes or static websites. jQuery UI elements are cross-browser and device compatible, cutting down on testing and troubleshooting for developers as opposed to constantly writing or re-writing code for similar design elements.

These frameworks and other modern front-end techniques like CSS pre-processing have become an important part of the Bridge’s development process, which we use to improve our response to client’s needs, whether technical or delivery-focussed. That said, frameworks aren’t always appropriate in all cases. As we’ve touched on, code from Bootstrap and Foundation can seem bloated and often additional components will go completely unused. However, the benefits of quickly deployable code, rapid prototyping possibilities and reusability are difficult to ignore when approaching a new project from scratch. 

If you'd like to discuss your software development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 22nd June 2015 by Lawrence McCrossen

We are often asked to provide a hosting solution along with the development and ongoing support of a website. There are normally two reasons why clients ask this:

  1. There are a bewildering array of options, so unless their organisation insists on specific hosting providers it is difficult to know how to choose, and what represents value for money
  2. The client wants us to be a one-stop-shop and not have to work with a website developer as well as a hosting provider

At The Bridge we work with a small number of different hosting providers depending on a number of factors:

  • Technology specialisation
  • Cost
  • Scalability
  • SLA’s available 
  • Security and Backups
  • Value-add tools available
  • Onshore or Offshore


1   Technology Specialisation

Typically this is based on either Windows or Linux, although other software such as database products are relevant here. Of course a number of hosting providers provide many technologies, but often one or other is dominant at any given hosting provider. .NET-based websites will require Windows Server to operate, while PHP-based websites may run on either Windows or Linux (though are arguably better suited to Linux).  

2   Cost

Reasonable quality hosting services are available at very low prices these days, although there are number of things that need to be considered:

  • Does the cost include all the components of hosting eg/ servers (shared or single), data in and out, databases?
  • Is there an SLA associated with the service (see below)?
  • What kind of on-call service is provided?

One thing to remember is that the difference between two hosting provider or plans may be significant in terms of service quality, but the difference in cost, while large in percentage terms may be insignificant in the big picture. The consulting costs to fix problems or loss of business for just one outage will dwarf the hosting costs for many months or even years.

It is worth noting also that due to software licensing costs, Windows-based hosting will generally be more expensive than Linux-based offerings. Microsoft SQL Server will also generally be more expensive than MySQL-based services.

3   Shared vs Dedicated Hosting

Most average websites can be operated on shared hosting platforms, where a hosting provider will house multiple client websites on the same server infrastructure. Low-to-medium traffic websites without a lot of resource requirements or those without high security requirements are prime candidates for this type of hosting. Shared hosting offerings by respected providers are generally very reliable and offer no great drawbacks for the majority of websites. 

For more complex, high data, high-traffic or data-sensitive websites however, dedicated hosting may be a preferred option. In this case, clients will generally rent a Virtual Private Server (VPS) that is dedicated to running their website(s). This has the advantage of more environmental control and a potentially wider range of technologies able to be used. VPS hosting is often considered to be more secure than shared hosting.

Dedicated hosting will always be more expensive than a shared option, however economies of scale emerge when reaching high data and traffic volumes, as well as giving you the ability to run multiple websites from your VPS. Dedicated hosting will also require greater amounts of support and management.

4   Scalability

Scalability takes two forms – volume and location.

For global sites for which you to need to ensure high performance across multiple regions, a Content Delivery Network (CDN) is a good solution. 

For large volumes of data such as in video sharing sites, the cost of storage may be a significant factor for the client’s business, and so hosting providers with different types of storage will have an edge here. Indeed a true Cloud service such as Amazon uses the concept of a type of service rather than an individual server (either virtual or physical) – hence all you need to specify is resource you want rather than have to specify a server configuration.

It is also worth considering whether you expect a generally fixed and predictable amount of traffic per month or whether your website will be prone to high usage spikes eg. The ATO website at tax time or a sports club website during the on-season. Services such as Microsoft Azure and AWS allow easy addition of server resources during these high usage periods, paying only for what you use.

5   SLA’s Available

Not surprisingly low cost hosting providers often don’t have SLA’s. That’s not say that they are unreliable, but just that there is offer made on behalf of the hosting provider to compensate for downtime or reduced performance. 

If you need to have a tight SLA with relevant compensation clauses this is likely to cost significantly more that standard hosting, and many providers simply won’t be able to accommodate it. 

6   Security and Backups

It is sometimes thought that dedicated hosting is more secure than a shared server hosting plan. This is not necessarily so. What matters for security is that the hosting environment is configured in a secure way and that security patches for both the operating system and the CMS are kept up-to-date. Normally the hosting provider takes care of the operating system and we at The Bridge look after the CMS and related web components.

Where a dedicated server does differ in terms of security is in regards to not having other websites beyond your control operating on the same infrastructure. If the shared hosting for one particular website is breached on a shared hosting platform, the other websites on the same system may be compromised.

Not all providers offer a backup option at all, and if they do you need to understand what the backup means – file copy of the site, ‘hot’ standby etc. Some kind of file copy to an alternative location is essential as a minimum. 

Even if a hosting provider has very high levels of server redundancy there is still a possibility that the site software or data gets removed or corrupted. 

We recommend taking your own backups separate from the hosting provider’s environment, as there has been cases where hosting providers have had their backup servers compromised and customer backups deleted.

7   Value-add Tools Available

You or your web developer may need additional tools from time to time, and it’s going to be easier if you know up-front that your hosting provider approves the use of these tools, or even better supplies them. These tools can vary from management software such as WHM/CPanel or Plesk to video conversion services such as Amazon’s Elastic Transcoder.

8   Onshore or Offshore

Increasingly this is becoming less important as Cloud computing has grown in popularity and acceptance. However for some clients, particularly Government with highly sensitive data there are hosting providers that guarantee that data is physically hosted in Australia. This is of course difficult to verify in practice. 

The good news is that it’s not necessarily much more expensive than overseas hosting.

It pays to think about hosting early on....

When we speak to clients at the beginning of a website development project, the hosting solution is often left until later. To some extent this is reasonable as the hosting will depend on the final form of the site. However it is important to understand the options and costs involved, particularly for high volume, fast performance such as video sharing, with a global reach.

If you'd like to discuss your website design and development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 14th May 2015 by Lawrence McCrossen

In a previous article we discussed the first step - the choice of a content management system (CMS). Once you have made this decision we can start the process of actually designing and building your new site.

The first question to answer for the design of the site is whether a template-driven approach is appropriate, or a completely bespoke design.

The most obvious difference is uniqueness. There are many free or low cost templates available online, but by definition they won't be unique to your business.

The things you will need to consider are:

  • Do you need your site to stand out in a unique way?
  • How well the template will fit in with the CMS that you've chosen. Some templates are simply front-HTML consisting of graphical elements only, so development work will be required to fit the template into a CMS. Other templates are CMS specific, including plugins or modules that interact with the template. In this case a template built for say the Drupal CMS will not be suitable others such as DotNetNuke
  • How easy it will be to work with the chosen template and add functionality
  • Whether the template will work well with the SEO that you wish to implement (see our later article on SEO)

Bespoke Design

If you really need to implement a simple website fast and for the lowest cost possible then a template may be the way to go. In many cases our clients are initially attracted to the potential for cost savings in a template driven approach, but often decide to take a more strategic approach which will save costs (and very importantly, their time) of redevelopment in the long run.

Of course, if you do decide to opt for a bespoke design, you must for insist that the creative design has to be good enough to actually look different.

When we work with designers of bespoke sites, we work hard to ensure that the technical implementation preserves the integrity of the creative design.

As with any software development project it helps a lot if you know up-front what you want to do. And, of course, thorough testing is essential, particularly for sites with complex logic within modules, or high volume sites requiring performance testing.

But for website development there are also a number of specific issues to look out for:

  • The designer of the website should ideally be a website designer or, if not, then at least familiar with both the potential and the limitations of web based technology. A designer without this knowledge risks wasting time by providing nice-looking designs that are either not practical or too costly to convert to the online environment. What works in print doesn’t necessarily work in a web browser! When designers work with The Bridge we can help the creative if we are involved early on, when we can provide guidance on what works and doesn't work in a browser
  • Provide content as early and as fully as possible. While content, including graphics will change over the lifetime of the website, the style of the content will to a large extent determine the best structure for the site
  • Also for content, allow sufficient time to create your content. This will often require the approval of multiple stakeholders within your business (and sometimes external to your business where lawyer or consultant reviews are required prior to the content being made public). Loading content from a previous site can also be very time consuming, and often not easy to automate
  • Arrange training for non-technical staff on how to use the CMS, otherwise the website developer will need to update content, thus defeating the purpose of having a CMS!

If you'd like to discuss your website design and development options with The Bridge at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au



Posted 23rd March 2015 by Mitch Brown

Unless you’ve been living under a rock the past five years, you are no doubt aware of the importance of considering mobile devices such as smartphones and tablets when developing a website. It is frustrating trying to view a website on a mobile device that may be difficult to read or navigate, or worse yet, not work at all. As these devices have become a ubiquitous part of everyday browsing habits, we have come to expect that when we visit a website on our iPhone or Android tablet, that it will simply work.

The most obvious solution to enable strong mobile user experiences is to load different design templates programmatically or to re-direct users to dedicated mobile or tablet websites altogether.

Perhaps less obvious, despite it’s growing adoption, is the use of Responsive Design techniques to accommodate the screen resolutions and unique functionality of mobile devices.

A website employing Responsive Design uses CSS techniques to modify its layout in response to the screen resolution of the visitor’s device. This technique allows the website to be served directly from one URL, without directing visitors to mobile sub-domains.

Are you with us so far? What may not be clear are the advantages and drawbacks of the Responsive Design approach and those of a separate mobile site.

Responsive Design

Why Responsive Design?

Single code base – The website can be based on a single code instance rather than needing to keep track of and controlling multiple sets of code. This keeps ongoing maintenance and development costs lower overall.

Flexibility – Design changes can be deployed rapidly. New website features can be deployed across multiple devices in one code release, designed to work across all devices.

Not just about mobile – Responsive design is based around resolution, rather detection of device model or operating system. The same approach used to deliver a mobile or tablet layout for smaller screens can also be used to improve usability and aesthetics on larger screen sizes or user-changes to their browser window size as well, allowing designers to make use of high pixel density retina display, 4k devices as well as lower resolution desktop and handhelds.

SEO – SEO is heavily dependent on incoming links to your website from partners, bloggers and social sharing. Creating an m. subdomain for your mobile site can dilute this “link juice”, negatively effecting PageRank as shares of your content may be split between two different URLs. Google also penalises repeated content across different websites. Responsive design with its singular URL avoids this issue.

Easier for repeat visitors – Visitors who are already familiar with your desktop site should have little trouble navigating and using your responsively designed site on their mobile devices. Likewise, visitors switching from mobile to a desktop viewing experience will generally feel right at home.

Why not Responsive Design?

Difficult to implement post-launch – Truly effective responsive design needs to be considered during the initial design phase. Adding responsive design functionality to an existing website can be difficult and time-consuming (read costly!).

Requires a design re-think – A lot of graphic designers seem to have not quite caught up to the responsive design paradigm of grid-based layouts, percentage-based grids, scalable images and re-usable elements. Not all designs will suit this approach.

Visitors can’t easily view the “Desktop version” – Because of how responsive design works, visitors generally can’t access the full desktop version from their mobile device. Because the layout that is loaded is dependent on the device being used.

Why a separate mobile site?

 Control – As the layout will be completely unique to the mobile version of the site, every part of the site can be fully mobile optimised and customised. If desired your mobile/tablet site can be radically different to the desktop version.

Easier and cheaper to add post-launch – If you already have an established desktop site you are happy with and want to create a mobile experience for your visitors, it is likely easier and more cost-effective to launch a separate mobile site as it does not require you to recode the existing website.

Users can override the mobile layout – A lot of users hate mobile sites and would much prefer to load your desktop site on their phone or tablet (regardless of how small the text may be). Mobile Safari and Chrome both offer a “Request desktop site” option that will allow for this.

Why not a separate mobile site?

Multiple codebases – Developers will need to maintain multiple instances of site layout code. This can make ongoing maintenance inefficient and create delays in making layout changes.

SEO – There’s rarely a one-size fits all approach to SEO, and there are certainly ??? exceptions, but generally having a separate m. sub-domain is an SEO no-no. As mentioned above, it can greatly dilute your “link juice” and runs the risk of repeated content penalties.

Not future-proof – Your mobile site will be harder to update in the future to accommodate changing trends in mobile devices.

Our Verdict?

 In the majority of cases, the Bridge recommends the Responsive Design approach. It is a technically superior and flexible mobile solution and reduces the cost of both up-front development and ongoing maintenance for new website projects.

Dedicated mobile sites still have a place, particularly, as mentioned, as a means of implementing a mobile or tablet experience for an existing website where a full design or code overhaul is not required. Mobile sites, arguably, can provide a more highly optimised, “best-of-breed” user experience, but outside of extremely high-traffic, interactive sites like large careers pages, social networks or other highly interactive concerns, this is an unnecessary solution. In fact, for these sorts of websites, a dedicated mobile app may be an even better solution for servicing their audience. But that’s a topic for another time!

Feel free to call us for a chat on 02 9993 3300 or email lawrence@thebridgedigital.com.au

Posted 21st February 2015 by Lawrence McCrossen

When we initially discuss website development, either with a designer or a client directly, we follow a process that we adapt to our client’s circumstances. Whether you are creating company website for the first time, upgrading due to business evolution, or redesigning, there will be a number of key elements to address:

  1. Choice of a Content Management System (CMS)
  2. Bespoke design or template driven
  3. SEO objectives
  4. Hosting requirements


In this article we talk about the choice a Content Management System (CMS).

The CMS is a database-driven system that empowers non-technical users to update content – posting new articles, images, video without the need to access the actual code that runs the site. This obviously has cost and convenience benefits over the process in days gone by of requiring a website developer or grappling with HTML code to make the simplest of updates.

Of course structural changes to will still technical expertise in configuring the CMS, and additional modules will require programming expertise.

The selection of CMS will largely determine the capabilities of your website. Once completed it will require almost a full re-development of the site in order to switch to an alternative CMS. Hence the suitability of the CMS requires careful consideration up-front.

The question is which CMS do you choose? It can seem like there are almost as many different CMS’s as there are websites!

Like any other software built for a purpose, the same questions of general functionality, ease of use, longevity, cost, support apply.

The criteria we consider are:

  1. How well can the design of your website be implemented? This is one reason why we at The Bridge always like to be in communication with designers early on in the project
  2. Is the CMS free, Open Source or commercial licensing? What type of support can you expect – helpdesk, community forums etc.
  3. Somewhat related to this is the backend language used eg ASPX, PHP, MS SQL, MySQL. The available skillset of your developer is obviously important here
  4. Usability – do you like using it?
  5. Ease of development or interface with existing systems/databases. Again this more a question for your developer, and will be important if you have future plans for incorporating a lot more functionality into the site
  6. Built-in functionality such as ecommerce, comments or forums, wiki, blogging. An obvious point in considering the cost of delivering the functionality you want

Once you have chosen the CMS you have the basis for the all the future development and maintenance of your site and you will be able to start the design process. We will cover the options for design in the next blog in this series.

If you’d like to discuss your choice of CMS with us at no cost or obligation, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au