Sometimes You Have To Fail

Here at Crowd, we are always finding new ways to improve and keep up to date with all the latest technological advances, however, sometimes things don’t go as planned and you simply have to admit defeat.

We recently came up with a new idea for our website called the ‘Good Fit’ Campaign, taking advantage of the high levels of traffic to our ‘About’ page, as well as making the process of joining the Crowd team more interactive.

The ‘Good Fit’ Campaign was essentially to work as follows:

• Capture user’s name and ‘superpower’ as text
• Request access to live video feed from device’s built-in webcam
• Capture user’s ‘serious’ image from device’s built-in webcam
• Capture user’s ‘silly’ image from device’s built-in webcam
• Recreate Crowd’s ‘About’ page with the user’s image included in place
• Enable user to share their images on Facebook

Development of the web application began, as many projects do, with an initial Google around the subject to try and find working and well-documented examples of similar functionality. After finding something suitable, it took just a couple of days to get the basic functionality working in the current desktop version of Mozilla Firefox. Google Chrome had a requirement for a secure https connection to grant access to the user’s camera, but aside from this, the prototype was functional. A simple Facebook sharing function was also added that allowed the user to log in and post one of their images to Facebook at the end of the process.

The original Crowd ‘About’ page stored each team member as a custom post type in the WordPress-based CMS. We decided it would be useful to store all the submissions in a similar way, so we created an additional custom post type for ‘Custom Team Members’ and updated the application to programmatically create a post, upload the media to the media library and attach it to the new post.

The initial prototype code had a dependency on the jQuery JavaScript library which wasn’t ideal, so we spent some time replacing the jQuery-specific code with pure JavaScript instead.

The initial prototype version of the app exposed some of the challenges that would be faced later down the line and prompted a thorough investigation into Web Real-Time Communications (WebRTC) technology and specifically, the getUserMedia method. Although not officially deprecated at the time, the navigator.getUserMedia method that we initially used had been surpassed by a newer method, navigator.mediaDevices.getUserMedia:

After getting the app working properly in Firefox and Chrome, and having established that it could not be made to work at all in Safari, it was time to test it on mobile devices. Unfortunately, Apple’s Safari browser (v10) did not support WebRTC or the getUserMedia method, but they were both supported by the more recent versions of Google’s Android OS. However, a workaround was available for iOS 9 and 10 that involved using the standard Apple File Chooser instead.

After making the necessary updates to the design and layout for mobile devices, I wrote some code to detect the user’s device and then use the default File Chooser to allow the user to take a new photo or select an image from their library.

An issue with photo orientation required some further investigation. iOS always tries to display the photo the correct way up but doesn’t necessarily store it at that orientation. This required code to be written to detect the actual orientation and correct it after upload so that the image would be stored the correct way up in the backend.

At this point, testing on actual physical devices began (as opposed to testing in virtualised environments such as Browser Stack). iOS devices running version 9 or 10 seemed to perform as expected for the most part, but Android devices were far less reliable. Unfortunately, device vendors using Android often implement their own custom vendor-specific versions of the OS. In each test case, our app would fail to perform due to a lack of support for WebRTC and getUserMedia or other issues caused by non-standard implementation of the Android OS.

The initial Facebook sharing functionality was a little too simplified to make the most of, so the decision was made to rewrite the sharing function to post a multi-photo story to Facebook instead, with a tag to Crowd’s own page.

Whilst still in development and testing, Apple released a new version of iOS and desktop Safari. Both Safari 11 and iOS 11 have full support for WebRTC and getUserMedia. This meant that our iOS 9 and 10 workaround code would no longer be required for iOS 11, which should be able to use our default code again.

Despite investing significant time and effort into this project, unfortunately, it never felt robust and reliable enough to launch, especially due to a lack of security in place to stop inappropriate images being taken on the Crowd site and with Crowd branding.

It is also exposed the fact that even today, differences in support amongst platforms can mean that ideas can’t be realised to their full potential. It’s not just IE6 we have to cater for these days, it’s a slew of vendor-specific mobile OS’s, screen sizes and security protocols.

It’s never easy to put a project down, but by taking time out of client work to explore some pet projects, we keep in touch with the technical boundaries that we still to need operate within and this removes risk from our work for clients.

After all… “Failure is success if we learn from it.” - Malcolm Forbes