The Bridge Digital

Agile doesn’t have estimates, right? Well, that’s not quite right. It’s true that Agile embraces change, and does not attempt to define whole large projects up-front, but individual ‘Sprints’ are estimated, and sometimes multiple ‘Sprints’. 

Of course, you can always give a big range for the estimate, but if all you are doing is expressing uncertainty, it will be of limited use.

There are a couple of other ways of approaching this. Both of them take a top-down approach, rather than a bottom-up approach, which attempts to break the project down into small components, estimate each one, and then add them up. Even if you do this accurately, it’s highly likely that requirements will change. It’s also very time consuming.

The approach we like to take at The Bridge is not so much an estimate based on a given set of requirements, but an estimate based on how long it took to build previous systems of similar size and scope. You need substantial experience in order to do this, but it has the advantage that it’s based on real data. It also incorporates the time that it takes for the toing and froing between developers and client, and the long tail (see my previous blog) http://thebridgedigital.com.au/blog/Real_Life_Mistakes_in_Project_Management_Part_3_Planning_and_the_long_Tail. For example, we are sometimes asked how quickly we can build a substantial website. In theory, maybe a month, but we never have, not only because of change, but because of the other factors influencing time to completion.

Another interesting top-down approach is budget-based estimating. This involves firstly establishing the objective of the estimate eg go/no-go for the project, add resources, allocate budget. The next step of the process is to estimate by requirement/feature from the top down, increasing granularity until a reasonable range can be provided. In the final step, some statistical analysis can be applied to give a probability of the functionality being delivered within a certain budget. Hence a decision can be made regarding the objective of the estimate.

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

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

SEO

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

Many of our clients have heard of Agile for software development, but some are confused as to what it is. They know it involves building software in stages, which is normally I good idea, but that’s hardly makes it a distinctive approach.

There are of course, many flavours of Agile, and we have our own at The Bridge...

In my view, for an approach (note it’s generally not referred to a as methodology) to be considered Agile, it must:

1 Involve a phased approach

2 Consist of working software right from the start

3 Embrace change, and not attempt to define all the functionality of the software up-front 

4 Involve close and continuous collaboration between clients and developers

‘User Stories’, ‘Sprints’, ‘Scrums’, ‘Paired Programming’, ‘Velocity’ etc all have their place, and are features of successful variants of Agile.

It is not the same as prototyping, which is a common confusion. A prototype might certainly make sense when you need to test a concept with a small or minimal version of the ultimate system, but it need not involve (2) or (4) in the list above.

At The Bridge, we’ve adopted the four points above for our approach to Agile, but in addition we pay particular attention to feedback for the client on time spent, which of course equates to time to deliver, and cost.

This is particularly important because a concern that clients have with Agile is that they can’t budget a fixed cost up-front project, or if they do fix the budget, they can’t guarantee a complete set of requirements being delivered. Of the course, the difficulty/impossibility of defining a set of requirements up-front, that won’t change, is at the heart of the Agile approach, but the apparent open-endedness of the project is still a concern.

To provide more assurance, the feedback we provide to our clients is not just the progress of the project itself, but details of the activities, time used, category of work etc (essentially old-fashioned timesheets). As you’d expect, this is used for billing, but it goes beyond the concept of person-days, and helps both us and the client understand the ongoing nature of the project.

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

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

We sometimes work with clients that are new to software development. This might be because they’ve worked in other areas of their business, or because they are involved with a start-up, which of needs a website that will be an integral part of the business.

"What Process?"

We’ve talked about ways of specifying systems previously in our blogs http://thebridgedigital.com.au/blog/5-ways-to-spec-a-system and http://thebridgedigital.com.au/blog/software-development-specs. These are still relevant, but we also have to be mindful of the fact that if a client hasn’t been I involved with software development before, they may not understand the need for a specification process - “we can just tell us what we want, and then leave them to it”. 

So this has to be explained carefully upfront. Even when using an Agile methodology, it may be misunderstood as an easy way to avoid writing a big spec. In fact, Agile has many benefits, but it is extremely dependent on frequent client input.

The same applies for ongoing tracking – planning, review and testing. Ideally one should use one of the many online project and task management systems. But if that isn’t practical, then at least an Excel or Word document that records issues and progress in one place. Again, it may be assumed by a client new to software development that progress just happens because the developers are experienced and experts. We are experienced experts, but a bespoke development is almost by definition, a new development, and so in that sense has not been done before.

It's not like a Product

One common misconception that we’ve seen is that a bespoke development is much like a ready-made product, in that the developers go away and build it, and when it’s finished, the client gets some training and then starts using it. That would be nice, but the nature of software development is that the software being produced is new. Hence it’s a very creative, interactive process, involving the best ideas from both the experts in the business you are aiming to improve, and the software developers that will ultimately bring the system to life.

As always, a discussion and setting of expectations up-front helps immensely. A little time spent explaining why methodology and process is important will pay off in spades, and you can look forward to creating software that will become the foundation of a new business.

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

At The Bridge we both manage and consult on website and software development projects for many industries, including financial markets, media, automotive, and government.

Whatever the industry, I’ve noticed a number of recurring pitfalls. Note that I’m assuming at least a basic level of project management, for example a plan, structure, stakeholders etc. If you don’t have those, then there are plenty of publications you can refer to, and if course there is just common sense. 

The mistakes I’m going to describe in this series are from our real experiences with website and software development projects we’ve seen over many years.

Planning Adjustments not carried out on an ongoing basis

Project plans look great at the start, and are often the basis for business planning and contractual agreements. I won’t touch in the contractual side here, but from the point of view of managing the project, the project plan frequently gets abandoned after the ‘real work’ starts.

The problem is that no adjustment of expectations is made when components of the project are held up. The end date is kept the same, in the unjustified hope that time will be made up.

At the very least the plan should be pushed back based on the dependencies of the delayed task. A good project planning tool will help with this. 

However I would argue that a further adjustment needs to be considered, depending on the cause of the delay. If for example certain parts of specifications, or content creation have taken longer than expected, then this might indicate potential delays in other areas of specification or content. This may be due to certain personnel being unable to spend as much time on the project as expected, or maybe they were just overly optimistic in evaluating the task. Hence there could be a case for extending the time required for future tasks, unpalatable as this may be.

The ‘Long Tail’

What I mean by this is the time needed after the system is essentially built, and is being tested, or refined on the basis of the user experience. This can drag on for much longer than expected, as even seemingly small changes can take time to implement, or maybe the right resources aren’t immediately available (see my previous blog ‘5 Reasons Why Building Software isn’t like Building a House’this part actually is a bit like building a house). For a website there might be a long wait for a legal/compliance review of the final site. Maybe most of the project personnel aren’t busy, but the project still can’t go live. The better the upfront specification and design, the less likely this is, but in my experience it’s very difficult to avoid. 

Testing nearly always involves, well, testing, but it also involves fixing and changing, which takes time. Best to just allow for it in the plan, and don’t assume testing can be rushed through at the end of the project.

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

At The Bridge we both manage and consult on website and software development projects for many industries, including financial markets, media, automotive, and government.

Whatever the industry, I’ve noticed a number of recurring pitfalls. Note that I’m assuming at least a basic level of project management, for example a plan, structure, stakeholders etc. If you don’t have those, then there are plenty of publications you can refer to, and if course there is just common sense. 

The mistakes I’m going to describe in this series are from our real experiences with website and software development projects we’ve seen over many years.

Plain Underestimates

This sounds so obvious, but it’s so easy to underestimate how long things take, whatever the task. To make it harder, software and website development normally involves creating something new, and in their enthusiasm people base their estimates on a best case (or even less).

This is difficult to prevent, but I’ve found that peer reviews of estimates are useful, and as a manager it’s wise to consider the worst case!

Part-time Resources

This is related to ‘Simple Underestimates’ above, but more to do with the proportion of a person’s time that can be spent on the project, rather than the number of hours or days it will take to do if that person did nothing else. 

More often than not, a software development project will involve specification, development and testing by people who also have other work, or even a whole other ‘day job’. This makes a lot of sense in that for example you will benefit from testing by a person that is currently familiar with the day-to-day processes of the business. But if that person is unexpectedly landed with urgent extra workload, the project will take second place. 

The only solution here, apart from using dedicated resources (which isn’t always practical or even desirable) is to plan for it – again, consider the worst case.

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

At The Bridge we both manage and consult on website and software development projects for many industries, including financial markets, media, automotive, and government. 

Whatever the industry, I’ve noticed a number of recurring pitfalls. Note that I’m assuming at least a basic level of project management, for example a plan, structure, stakeholders etc. If you don’t have those, then there are plenty of publications you can refer to, and if course there is just common sense. 

The mistakes I’m going to describe in this series are from our real experiences with website and software development projects we’ve seen over many years.

Content not considered early enough

This relates particularly to websites. Requirements are gathered, followed by beautiful designs created and approved for the developers to build. Templates are set up in the Content Management System, and filled with Lorem Ipsum (dummy text), to be replaced with the real content some time later.

The problem with this is that different content will influence which designs will work best. A simple example is where the amount of text doesn’t match the space provided for it in the template.

So content needs to be an integral part of the design. Designers and content providers need to work together early on in the project.

All Stakeholders not involved early enough

This issue occurs in all types of software development. The project is set up to include relevant stakeholders, and everything appears to work smoothly, with decisions made along the way to the final release. 

Then someone, normally a senior manager for client, sees the nearly finished product for the first time. He or she had previously approved the project to go ahead, and had delegated the details to someone, but not spent any time at different stages of the project cycle. This is fine, but if the senior manager doesn’t like what they see, then substantial rework may be required.

This is particularly an issue with public facing technology such as websites and mobile applications, where the company image is at stake.

Once again, early involvement is crucial, with the right people.

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

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!

Caching

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 

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

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.

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

You want to build software for your portfolio/risk management, compliance, market making or perhaps investment/operations reconciliation. So you design, plan, build and you’re done, just like building a house, right? 

I used to hear this a lot from our clients in the Finance Industry, although not so much these days since Agile has become more popular.

So why isn’t it the same? Why can’t we make accurate plans the same way they do in the building industry? 

Leaving aside the fact that building construction doesn’t always go to plan either, there are some key differences, in reverse order of importance:

Number 5…

For larger, longer projects, such as major portfolio management or risk systems, business requirements may change under one’s feet. That doesn’t happen so fast with buildings, and if it does it’s too late to change anyway!

Number 4…

It’s generally easier and cheaper to change software than it is hardware – so people do change it! There’s an expectation that things such as security types compliance rules will be added and altered because it can be.

Number 3…

Technology changes fast in the world of software, and that can lead to uncertainty in development timelines as unexpected issues arise. The finance industry is subject to rapid change too, in as markets evolve and regulations are adjusted (normally tightened).

Number 2…

It’s extremely difficult to envisage the entire system behaviour up-front, there are so many degrees of freedom, if not infinite for even a small sized system. This is particularly the case if current operational processes within a financial services organisation are being reconsidered as part of the project. Houses tend to be more straightforward functionally. This is of course a key reason why Agile methods are popular.

And the Number 1 Reason building software is not like building a house…

Software systems are often unique, and being designed for the very first time, more like new type of building than a new construction which is a variation on something previously built. Many financial systems are available off-the-shelf, so if a fund manager, trading operation or bank is building a bespoke system, it is because their processes, trading or risk management is proprietary and by definition the system has not been seen before.

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

You may have heard about it over the past few years. Launch is planned for the second half of 2017 and interest is certainly heightened. 

I won’t provide an explanation of the concept here – the New Payments Platform Australia website www.nppa.com.au launched in December provides plenty clear information and many useful references and videos.

Australia certainly won’t be the first country to adopt a fast payments systems – several others including the UK, Japan, India, Brazil, Republic of Korea, Switzerland and others have been around for a number of years. However, Australia is at the forefront because the really exciting part is that Australia’s version will be one the most innovative (or to be more precise, facilitate innovation). 

Of course it will be fast – but one key advance is potential for Overlay Services – additional data and context over and above the very basic transactional information. An analogy is the difference between texting and content rich emails and apps.

What kind of apps? It’s difficult to know, but of course anyone can think up of ideas, the same way they have for smart phones.

Who will build them? Banks of no doubt, but if the NPP enables new entrants to the marketplace, the possibilities are endless.

Security? The speed and ease of payments has been reported in overseas versions as resulting in exposure to fraud. But in the case of the Australian version, with its overlay services and additional information, there is opportunity for solutions – maybe an app that does some security checks, or additional information required payees.

Expect to hear a lot more about the New Payments Platform Australia as we approach launch date later this year. 

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

The Cloud has steadily revolutionised our world in recent years, perhaps in a quieter way than smart phones and Social Media.

It’s a very broad subject, and I won’t attempt to cover all areas. I’ll focus on a number of small to medium sized clients that we know, and can add insight based on our experiences working with them.

What about security?

A detailed analysis is not the purpose here, but I once heard a Microsoft speaker say that they spend a billion dollars a year on security. Of course Microsoft are a big target, but it’s hard to argue with that.

It’s true that in a sense you lose control of your data in the Cloud, and it’s a good idea to have some kind of backup strategy in place, but can you really convince yourself that it’s safer in your own rack?

There is the question of sovereignty, but many services now guarantee that data won’t be stored overseas.

So, what are the flavours?

1 Selected Applications

The first point to make is that many companies have been using Cloud based systems for many years, it’s just that they referred to them as ‘Web Based’. Everyday products like Salesforce, Survey Monkey, Mailchimp, and many, many others.

Something like Zoho Apps aims to provide every application you could ever need – all in the Cloud. Our very Seymour product for automating and displaying spreadsheet data to websites run fully in the Cloud. 

2 Basic Business Tools

Major change has come with Google’s office products. And the highly significant Microsoft 365 – basically you can completely remove your (high maintenance) Exchange Server hardware and software, and enjoy all the tools – email, contacts, calendar as you did before, but without the worry of what happens if your exchange server goes down. The move for a small organisation is relatively simple, and I from our own experience at The Bridge, you won’t look back!

3 Business Applications

Excludes standard applications such as Word, Excel here, or any application where user interface is tied very closely to the data stored (see 4 below).

Pseudo Cloud – just taking an application and running it on Cloud server, using a remote access tool like Citrix. It’s cloud for the purists, but it does get the application off your in-house infrastructure, which is one of the reasons for having the Cloud.

This aside, you don’t have to have web based application to benefit from the Cloud in a more sophisticated way. At the Bridge we’ve built complex desktop applications that install locally on PCs and laptops, but with the database residing in the Cloud. With some security built in, you can use the system from anywhere you have the application installed. And the database is truly pay-as-you-go in Cloud fashion.

The only word of warning is it be aware of external connectivity of your applications – this may be affected when you move server based components.

4 Files and Standard File-based Applications

In spite of being the simplest conceptually, file storage can be difficult to work out. My experience is that keeping a small server (or just a storage box) on your local network will consistently give you the fastest file retrieve and save, but the difference may be minimal.

Where it matters is for some file-based applications, such as complex spreadsheets or other file types that have many links to other files or services. This can be very slow outside of a LAN. If you are considering this, you should test thoroughly first.

So if like we do, you decide to keep some local storage, you can then use the Cloud as a backup location for the files.

I imagine one day Internet speeds will be consistent and fast enough as to be indistinguishable from a LAN. 

5 ‘Thin’ Desktops

Another option is to host everything – I mean everything, from files, common applications though to email clients in the Cloud. Access is either by Remote access to an application running in the Cloud, or a cloud version running on a browser. But I haven’t heard of this working well, and I imagine it could get quite costly. And it really wastes the capability of your desktop or laptop.

How do you choose?

With the possible exception of Thin Desktops, you can mix and match as you wish. The costs comparison will likely involve sunk costs of existing systems versus immediate ongoing fees, plus the initial cost of the move. Backup strategy will also need to be considered.

In my mind though, the long term benefits of having reduced infrastructure, pay-as-you go, and reduced support headaches, are in most cases compelling for the first 3 flavours, and the 4th flavour in some cases.

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

You’ve decided you need a system developed, or perhaps a new website.

What next? How do you turn your business objectives into clear instructions for software developers to create a system that will fulfil your needs?

1 Write a Spec 

The traditional approach is still used widely. Sometimes it’s used in conjunction with other approaches, eg writing small specs during Agile development, sometimes referred to as ‘Stories’.

My view is that you should always start with some kind of written statement of what you intend to develop. Doing so focusses ones thoughts and leads to further insight.

Problems can arise when too long is spent on this stage and either the business has moved on in the meantime, or the level of detail is more than can be reasonably worked out without reviewing a prototype or an initial phase of the development.

Is there a template for writing specifications? Yes, there many, but no one of them could reasonably by regarded as a standard for the industry. At The Bridge we have our won which we modify depending on the kind of system eg website, interface etc. A quick online search will reveal many to choose from.

I recommend you choose a template that is closest to what you are doing, and make sensible modifications that will enable you to ask the right questions. You should also ask your developers what they would like to see.

Then start writing, but don’t overcook it.

2 Agile

Agile is more than just writing software in smaller stages. 

There are different flavours of Agile, but the key characteristics are small stages (often called Sprints, typically of 3-6 weeks each) and production-ready software at the end of each stage. 

So it’s not the same as prototyping, or just breaking up a large project into smaller pieces. There also has to be usable software at the end of each phase.

At the heart of the Agile approach is the notion that it doesn’t make sense to try to specify large systems up-front – it’s too complex and subject to change as business requirements themselves evolve.

Of course by definition, you can’t accurately estimate a full set of Agile phases that represents the end goal. Only the individual Sprints are estimated. But the client can stop at any time, they aren’t committed to a long multi-period contract.

Once the principles are accepted, Agile can work very well. The only issues I’ve seen are when the client underestimates the involvement they need to commit to. Frequent iterations means constant feedback in the form of requirements (or Stories) and testing. 

So accept the principles, and stay involved!

3 Develop a Prototype

Prototyping is another approach that reduces risk by taking smaller steps, but it differs from Agile in that it’s not intended to be a production system at any point, and there are no real guidelines as to how the process is supposed to work. 

It’s an obvious way to go if what you are doing is breaking new ground, or you need a proof of concept.

I’ve seen it work very well using Excel as a way of specifying a system that contains a lot of complex calculations. The business user may be skilled in the use of Excel and so can quickly create and modify formulae until they are happy with the results. Then the development team working on the full system can more easily emulate and compare during testing.

In the right situation, with appropriate business users involved, this approach can vastly reduce risk and development effort.

4 Templates

This is commonly used approach for developing websites, rather than developing a bespoke site from scratch you can choose from a selection of templates.

Of course your websites will look like hundreds or even thousands of others, but if that’s not a problem then there is the potential to reduce costs and timeframe.

The other issue is that it may not be easy to add more complex functionality later on, so choose carefully. 

May also be a good temporary solution, to be replaced later on as the business evolves. 

5 Leave it to the Developers!

This might sound very risky, but in certain situations where talented developers understand the business very well, they are able to create useful applications, sometimes that the users of the systems hadn’t thought of.

Obviously this kind of development needs to be kept under control, with frequent deliverables. It shares features in common with Agile in that management overhead is kept to a minimum, and timeframes are short. 

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

Seymour is simple solution to a common problem – how to move data held in spreadsheets onto your website in an automated way. Check out the interactive graph below, produced by Seymour.

The Problem

For years we’ve seen organisations such as Fund Managers go through a manual daily process of receiving Unit Price and performance data from their custodian in the form of emailed spreadsheets, checking the columns of data, and then keying the data into the website content management system.

Even for a small organisation with minimal amounts of data, this approach is prone to error, or even being missed altogether if key personnel are unavailable.

In addition, even when the data arrives on the website, it is often displayed in a drab, tabular and non-interactive fashion, with visitors to the site having to download and examine the data themselves if they want to do more than just view a list of numbers.

Our Solution

Seymour is a solution that completely automates the process, from receiving spreadsheets via email or FTP, extracting the data you require from the spreadsheet(s), and displaying the data on your website in a stunning graphical format (you can still have tables of data if you want).

In addition the system checks that daily data has arrived and alerts key personnel if it hasn’t. Tolerance checking is also provided to help protect against erroneous data that may occasionally be received.

Highly flexible

A key feature of Seymour is its flexibility. Any type organisation can use it, not just in Financial Markets.

There setup process is very straightforward. The user of the systems firstly sets up the names of the objects and fields, and their types, according to the type of business. These objects and fields can be anything you want.

The second step is to provide an example ‘template’ spreadsheet and map the columns to the Seymour objects that have been created in step 1.

The final step is to insert a ‘link’ or ‘code’ on the website where you want the data to be displayed.

Once the system is set up the way you want it, the process will happen automatically every hour, day, week as required. You will of course be informed if data hasn’t arrived or appears incorrect.

Secure Cloud based, no local installation

Seymour is hosted in a highly secure Cloud environment, with access to the portal login via browser. An audit trail is kept of all files loaded into Seymour.

Low pay-as-you go, easy setup

After an initial straightforward setup, payment is made on an as-you-go on a monthly basis. No infrastructure is required on your site, and Cloud hosting and licensing to use the software is all included in the fee.

If you'd like to learn more about our Seymour product, feel free to call Lawrence on 02 9993 3300 or email lawrence@thebridgedigital.com.au

I love spreadsheets. Spreadsheets are wonderful things, I use them all the time, and so do our clients. But it can be difficult to know when to stop using them.

When the subject arises with our clients, the issues are the same for both large and small organisations.

Consider a boutique Fund Manager using an in-house developed complex spreadsheet for managing portfolio, orders and risk. This might make perfect sense when starting up – low cost of technology, developed by an investment manager who knows exactly what they need and how to maintain the spreadsheet.

As well the business grows, and the spreadsheet is adapted and evolves with it – the same as any other software. But there are some problems specific to spreadsheets.

It’s more than just data input Errors

This is certainly a problem, as data validation is limited, and there is always the risk that a formula gets accidentally overwritten. That said, it’s also possible to make input errors using technologies other than spreadsheets, so it’s not actually the main problem that distinguishes spreadsheets.

Security, in more than one sense

• It’s just a file - the spreadsheet file can be copied and taken
• User access can be restricted, but it’s difficult to create an audit trail of who has used the spreadsheet

Multi-user

• Of course, anyone can use it, but there is limited ability to control who can use which functions via roles and user ID’s
• Maintaining consistent data is very difficult. Other than protection from writing over the whole file, there is no ability control over when different users edit specific parts of the spreadsheet. One client told me that the way they handle this is to shout across the room to let other know that a spreadsheet is about to be edited!

Database – history and audit trails

While you can of course store a large amount of data in a spreadsheet, the ability to update that data in an automated and consistent way is limited. New rows can be added, but only in a very simplistic way, and relationships with other data are difficult to maintain (see below). This makes historical reporting very difficult to do.

Keeping an audit trail of when and how data was changed is not something that can be incorporated into a spreadsheet. This obviously an extremely important issue for risk management and auditing.

General Robustness

One of the great benefits of spreadsheets is that data and formulae are placed in the same place ie cells of the sheet. It’s so easy to just start typing data in and manipulate it with formulae right next to the data. For more complex logic, you can write code too.

The problem arises when data gets moved around or added in ways that the writer hasn’t foreseen. Sometimes errors indicate the problem, but it’s easy to point to the wrong cell without knowing, or even to completely overwrite data!

If you are struggling to maintain your spreadsheets, The Bridge can advise on how to restructure or even replace them with a more robust technology.

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

How do you specify a system for a software development project? In the majority of cases clients do not have a detailed set of documents describing the system that they’d like to build. Hence we are often asked how this can be done, and whether a standard way of doing this exists.

The short and correct answer is “no”. We do use some templates which ask key questions and guide the client in the process, but there is no single approach applicable to creating a spec for a business software application.

To clarify, we are referring here to the development of a substantial system that requires complex business logic, probably with a database containing fairly complex data structures, not, for example a simple website that can be created using available template designs. Nor am I referring to systems on the other end of the scale, such as NASA space guidance systems!

If you search online for spec document templates or workflows you are unlikely to find what you are really looking for. The reason is that there is no one-size-fits-all approach. Why?

1. The multitude of delivery platforms – desktop applications, browser based and mobile devices, all from different vendors, makes it difficult to standardise the user experience
2. Many companies don’t have time and resources to create a detailed spec at all, let alone a spec based on a standard
3. The often used Agile methodologies discourage the use of detailed up-front specifications. Instead they recommend small project iterations that can be easily described in plain language, which is translated into code by the developers
4. It’s very difficult, if not impossible to completely or even partially specify a system up-front, mainly because it’s often something that hasn’t been done before. So it’s not surprising that having standard to follow doesn’t help much – a standard for what?!

So what do we do at The Bridge - leave it to chance? From our experience, there are a number of things we can do, depending on the circumstances:

1. Use prototypes – if you can create something that looks like what you want in say Excel, this gives our developers a much better idea of your vision. In fact Excel works particularly well where there a lot of calculations involved eg financial markets tools
2. Even if you don’t have time and resources to write a detailed specifications, at least spend time writing up key points of what you expect in terms of user experience, information flow, and of course functionality
3. For bespoke websites (ie non-templated), use standard Content Management Systems and graphical files for designs

Lastly, as with all aspects of project management, always keep involved in the development process, whether from within an agreed Agile development approach, or a Waterfall methodology. Interpretation of requirements is crucial, however they are communicated, and the only way to ensure that the software is in line with expectations is to review regularly. Very regularly!

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

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

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

We often meet businesses looking for a system that will help their business, but they aren’t sure whether to go out and review what’s in the marketplace, or look to develop their own.

These days of course, virtually all businesses use off-the-shelf technology for their general needs such as email and collaboration, accounting, timesheets, and billing. Our involvement is normally in specific systems that are used by individual industries, such as financial markets, media, automotive, government, sport etc. It’s within the scope of a single industry or type of business that the decision becomes more complex.

There are a number of reasons why businesses start to look for systems:

• Start-ups requiring a system to run some aspect of their marketing or operations

• Growth in an existing business requiring a change or more efficiency in process 

• Dissatisfaction or limitation with current software

• A change in a business requiring new or unique processing

• Software products are your business

With the exception of unique processing, all of these situations warrant a review of existing systems that may fulfil a similar need. This is true even when software products are your business, because it may make sense to license existing software, perhaps with your own branding or front-end.

So how do you go about making the decision?

Here are some questions to ask:

• How generic are your requirements? 

Unless your business is intending to take on the likes of Microsoft or Google, exceptionally few businesses would have need to develop a dedicated email system, but your requirements might be more generic than you think.  If they are then it’s likely there will be many good systems available in the marketplace at reasonable cost (or even free in some cases).

• Are existing solutions expensive? 

Possibly a vendor has a strong market position and well-regarded platform, but often it is because the software that is available includes many features and functionalities that you will not need and cannot be licensed without those additional parts. In this case it may make financial sense to develop a cut-down or more specialised version of an existing product. Several of our clients in financial markets fit into this category – systems are available but they only require a small subset, for example for compliance reporting of a specific kind.

• Are your requirements truly unique, or close to? 

Here’s where you will obviously consider a development. It’s likely that your business itself is also unique, and hence the software you use will become an integral part of your competitive edge. There are examples of this on our website – a media planning system that was required for planning and measuring buying effectiveness. There was no such system available because the approach to the business was unique. Or a video sharing website providing full control over advertising revenue to channel owners.

• Are you a software vendor yourself? 

In this case the decision is complicated by the fact that if you buy off-the-shelf software to re-package yourself, you will need to establish licensing agreements for branding and distributing that software. Also, you may need to control the future direction of this software, which you can only do if you own the source code or are allowed to modify it yourself (such as with most open source components)

• You need to control the future direction of the software 

Whether you are a vendor as above, or a company whose fortunes depend on the ability to evolve internal processes at your own pace, you can only really do this if you own the source code and are able to direct future development.

• How quickly do you need a solution? 

Normally bespoke development takes a lot longer than setting up an off-the-shelf product, even where a lot of customisation is needed. These days the wide availability of Cloud-based systems has speeded up the setup process massively. Another option might be to use an off-the-shelf solution for the short term while building a more suitable bespoke version. This has the advantage of easing the pressure on the bespoke development project timeline.

• Are you unhappy with your current system? 

Whatever the reason for your dissatisfaction, it may be time to look around. Hopefully you will have a good enough idea of what you need (and don’t need) that you can make a highly informed decision, and provided your existing solution sat least gets you through the day, you have time.

So, build or buy?

The best reasons to buy are:

• The functionality is very generic, and you don’t need to ‘reinvent the wheel’

• Cost – this partly relates to the point above. Software development can be expensive and time consuming, and it may be a lot cheaper and easier to license software already available in the marketplace

• Timeframe – if you need a system very quickly then buying one readily available in the marketplace may be your only option in the short-term

The best reasons to build are:

• Uniqueness – your business or process is very unusual, or in the case of many websites, it needs to look unique

• Control – you need to be able to make changes at will (you could of course buy the source code, if available, to achieve this)

• Lower cost – this will normally only be the case where you only need part of a bigger system that is already available off-the-shelf

How can we help?

The Bridge are passionate about building software to help our clients’ business’ grow. 

At the same time, we appreciate that a development project may not suit you at this point in time, but we know what high quality software looks like and we can help you to assess off-the-shelf products.

So please contact us if you are looking for a new system, whether your inclination is to buy or build, we will provide an honest, unbiased assessment. 

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

In a previous blog Responsive Design vs Mobile Websites we explored the differences between dedicated mobile sites and responsive design. 

These days, either a dedicated or a responsive website is a given, but where do native mobile apps fit in if we are developing for Financial Markets?

While a mobile site or responsively designed site is intended to be viewed in a mobile internet browser (such as Safari on the iPhone), a mobile app provides a different experience, with the trader or investor downloading and installing software directly to their phone via the Apple or Google Play stores, or directly from the developer in the case of an App for corporate in-house use.

Mobile apps are generally designed to provide a specific functionality, with a more narrow focus than a mobile website.  Mobile apps should not be viewed in opposition to mobile sites but as a complimentary part of your online strategy.

Mobile apps are able to take advantage of native functions of the phone such as geo-location and notification systems to deliver information to its users. Mobile apps can also interact with other software on the phone. Mobile sites, on the other hand, are restricted to the phone’s internet browser and will not be able to provide notifications to users if that browser app is closed. Hence mobile apps providing market data feeds and charting functionality are a better solution as they will utilise specific features of the mobile device.

Examples of this are Bloomberg and Yahoo Finance apps, and various Twitter client apps that exist for iOS and Android phones. These apps will remember your login credentials and allow you to track portfolios, financial news and market data, or send messages and post tweets to follow other users. 

They are able to run in the background and provide notifications to your phone when market conditions change, receive messages, or connect to new followers through the system. The apps can also use your phone’s geo-location data and access other data such as the camera or photo library. While these organisations’ mobile sites could be used through your phone’s web browser as well, a mobile site would be unable to provide this level of interactivity. 

Native mobile apps are able to provide a fully tailored experience, without the constraints that browser-based apps or sites can suffer from. Particularly in the case of iPhones where there is minimal deviation in the hardware, mobile apps can be designed with the best User Experience practices in mind without much concern for cross-device or cross-browser compatibility.

So what’s a good use case for a mobile app?  

Think about a core feature of your website or business that is utilised on a regular basis by you, your clients or potential clients. 

In the case of a stock trading app, creating an app that delivers your online database of previous trades and portfolio holdings would be a great choice. The app would then be able to notify investors about trading opportunities directly via their phone’s notifications. Users won’t need to remember URLs or rely on browser Bookmarks to reach your service – they simply load up the app from the phone’s home screen.

An App may also be of benefit when a user has no access to the Internet. This is not often the case these days with plenty of free Wi-Fi available, but it does happen!

In these two examples, the same functionality will probably exist on your desktop and mobile site as well, but of course, mobile apps can also provide exclusive functionality not found elsewhere. For example users of an app will benefit from location based services.

What’s involved in mobile app development?

There are two main approaches to mobile app development. 

Best practice is to develop apps directly in the native language of their intended delivery device. Apps for Apple smartphones and tablets use Objective-C and, more recently, the Swift programming language. Android apps are written in Java. 

By utilising native code and functionality, these apps will provide the best performance and usability. The downside of this approach is that you will require two apps for the main mobile platforms (more if you wish to include Microsoft and BlackBerry), each with different code bases and distribution methods.

The other approach is to use mobile “wrapper frameworks” such as PhoneGap or Trigger.IO that will allow the use of HTML5 and JavaScript to create the app. The app is then bundled up inside a “wrapper” compatible with iOS and/or Android.

This has the advantage of being able to use one HTML5 codebase for your app, with only the third party wrapper system requiring additional code and updates. This also means your app will be much faster to develop. The major downsides are that, these apps tend to run slower than those written in native code and because of the “one-size-fits-all” approach, will not be able to make the best use of all the phone’s hardware features.

So do I need one?

While a mobile website is essential for your business, mobile apps are a case-by-case consideration. For many businesses, a mobile/responsive website is all that is necessary but where a suitable use case exists to deliver a service to your customers via an app, then it should definitely be a part of your mobile strategy. Mobile users spend around 30% of their time in apps as opposed to the browser, so these can be a great way to keep customers engaged with your business.

It’s also common for Apps to be the front-end of a business model in themselves. Users are used to paying for a downloaded App, or for an upgrade to a free version. If this is your intention, then of course you will need to assess the business opportunity vs costs etc. as you would with any other venture.

If you'd like to discuss your mobile app or site 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.

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

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)

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

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.

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

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

Welcome to ‘The Bridge Digital Solutions’ blog!

We write software, we build websites and we create apps. We were doing this for years as part of Tango Technology.

We have been operating as a separate company for 12 months now, and have fully settled into our new offices in North Sydney, but we’ve been too busy developing clients’ websites to spend time on our own site blog!

As an introduction I’d like to explain how we work with clients, designers and SEO experts to build compelling and effective websites.

Working with our Clients

Our website page http://thebridgedigital.com.au/why.html shows examples of our work.

At the initial stage of a website development, clients often want to know what is possible before they commit to a brief – how much content they will be able to access and change themselves, how we will store videos, what is involved in creating a secure login for their customers to access, what options are available for hosting.

As website builders this is where we provide crucial input to our clients’ decision making. For a complex website we maintain this dialogue throughout the development process so that all key decisions are fully informed.

When we are presented with a client’s branding and graphical design, we often work closely designers in order to maintain the integrity of their creative work….

Working with Designers

In our conversations with designers they have told is that the most important things they want from developers is the ability to communicate, and a willingness to adhere to the creative concept. We achieve this not just because we know the technology very well, but also because we enjoy the challenge and ultimately we want the client’s website to both look great as well as benefit from rock solid engineering.

SEO

Once you have a website you obviously want people to visit it! Paid links from the likes of Google AdWords is one way. The other is from ‘organic’ search.

After that, optimising your site for organic search is a specialised area of expertise and involves ongoing care and attention to keep your rankings high. We work closely with SEO experts to ensure that the basics are done, including the correct use of META and H tags for your content to ensure that each page to be indexed has an appropriate, search-friendly title and correctly coded headings in your content. We can also integrate tracking and reporting features such as Google Analytics, Crazy Egg and Omniture.

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