B&R Enclosures is based in Brisbane, Australia. They are a B2B company selling through Electrical Wholesalers domestically and through agents in other parts of the World.
B&R have an array of websites including: –
- Australian site – brenclosures.com.au
- Mobile site – brenclosures.mobi
- New Zealand site – brenclosures.co.nz
- Chinese site – brenclosures.com.cn
- and more!
One of the problems they were seeing was being able to keep all these sites, many using different technologies in sync so that updates on one site do not have to be reproduced on every site they own.
On top of that, they also supply wholesalers chains with information on their product range. This involved producing electronic files and images for each of their products for each wholesaler that needed this information. Again, managing this information when updates have taken place was not an easy task with each wholesaler having to be informed then information provided again.
The solution to both of these problems has been the implementation of a REST based central information repository (we call it a feeder site). This single site now feeds B&R’s sites with up-to-date data which they then display as required by that particular site.
To do this we first had to break up their standard webpage content into smaller groups of content to make reuse and reordering easier. A WordPress ‘feeder’ website was then used to house all of this content and give the system an interface that was already familiar to them. This ‘feeder’ site is not used to display anything, it just provides a data source to other sites, rather than them using their own database or html. The ‘child’ site then takes this data and displays the sections it needs in the manner most appropriate to the audience.
So how does this differ from responsive design for say a main site and a mobile site? Essentially size, speed and flexibility!
- Size – Responsive sites are great for flexibility, but when you load the site up on a phone, there tends to be lost of large scripts that load that just aren’t used on a mobile. In B&R’s case a main site page is typically 1.7MB, actually quite small for a modern website. However on a mobile that is 1.7MB of your data allowance and can represent a significant load time in some areas. The same page on their mobile site loading exactly the same page contents is now 101kB. That’s nearly 17 times less!
- Speed – With a reduction in page size also comes a faster mobile site. Both Google and clients love this! Instead of a 4-5 second delay for a page to load, even with no caching page load times are around a second. This could be reduced even further with more local web hosting of the mobile site.
- Flexibility – With a responsive site the site content is set by basically hiding or displaying content blocks. The content, styles etc all still load, you just hide the bits you don’t need. Using a REST based system is similar, in that all content is still loaded. However you aren’t forced to just hide something that’s already there on the page, you can choose to use any bit of content, anywhere you like, or not, if the mobile site doesn’t need it.
One of the issues with having a repository such as this is security. What happens if that site goes down for any reason. In this case B&R use a backup ‘feeder’ site. If a response is not detected from the main site, the page will automatically go to the backup. In practice this is seemless as every page runs this check as it loads.
All of the above has concentrated on the site performance. However our second problem was providing wholesalers with product information they can add to their site. Rather than files of hard to update information, B&R are now in the position where they can provide their wholesalers with an API (or code) that will pull current information into their site. If a product is updated, that will automatically be reflected on their site at the same time as it will be for B&R. They can also use as much, or as little of this information as they need to be consistent with other information on their site.