A Clean Slate
By James Steele Seeley on
The Name
You may remember when we used to be called Cure Productions, we definitely do. So why the name change to Cure Interactive? It's actually a strange story. While looking to find an appropriate URL for the domain we discovered that the one that best suited us belonged to someone who had remained dormant for several years. While we may have been operating under the name first, they purchased it before we did, making it their name and their property.
We spent many weeks finding a solution. We tried asking for ownership, which had as much luck as a Sherman against an M1 Abrams, and when that didn't pan out we decided to change our operating name. Luckily we were small enough that it didn't cost too much to do so. We found the best suited replacement to be available at cureinteractive.com, which was more appealing towards our computer side of work, so we went with it. We would then spend several more weeks rebranding and swallowing that our new name won't match our existing software. It was a hard hit to take at first but has transitioned smoothly up to this point in time and we now have matching FaceBook, Twitter, and YouTube accounts!
The Server
Then there was the matter of putting together our server. It's not like it comes out of the box prepared to ship with everything. It is a painful process first time and came with a ton of problems. We had to consider: operating system benefits (Windows easier to configure front end wise & Linux based less resource intensive), programs to run the website, programs to build the website, templates to help develop the website, webpage content dependencies and more. These things also exploded into their own monsters. The Medusa Syndrome is real people and if it can go wrong it will go wrong every time.
Asking the Right Questions
Not a single thing went according to plan. Documentation was sparsely detailed to say the least and too many forum comments ended with responses of uncertainty and loss of understanding, answers which we were reluctant to accept. It was far easier to find the wrong solutions as well! You'd think most things online are trust worthy, at least most people that I know trust first and ask questions latter, but when you implement a fix for something that's broken and it breaks more stuff that's when we had to put our foot down.
It only takes a limited number of times before we learned some key tips on surfing the web. First was knowing what we were dealing with before asking any questions at all about the problem itself. What's the name of the code we are inside of at this time? Did whoever created it also work on anything noteworthy or popular and trusted? What's the code language called that we are dealing with? Knowing these things helped a lot with searching for the right answer and actually saved us a lot of time doing so. Another factor was knowing how to sniff out a bad lead. It's too easy to wander down the rabbit hole and overlook what the problem really is. It may be something simple staring you in the face, yet you'll keep going until you find the most complex fix that takes hours, before discovering a single line of code or less actually fixes most problems. Many people are out there creating complex solutions to problems which most of which won't work for you. There is at minimum 3-6 layers of processing for each load of a web page, each of which can conflict with each other and ruin your day. To make matters worse that's anywhere from 21-720 possible configuration issues and solutions per each possible issue that may arise, sometimes unforeseen. That means while in certain areas of coding like JQuery, where things can be compartment-ed out, may be a quicker fix, areas of the server and other setup solutions may not work most of the time and result in entrance barriers.
A World Under Mobile
Being mobile friendly is a must nowadays. It is easier than ever to have a mobile device and when spreading the word or your webpage you'll find a lot of people know they won't remember it for long, resulting in a quick lookup for latter. This is your first impression. This tells people if your site is worth looking up on desktop and may mean the difference in mobile shares or no shares at all. This was important for us as a media producer so we went the responsive route. It's not that easy for some people to handle. There are multiple factors that always change in this environment. You want you content to look it's best on both a small cell phone and large computer screen. We discovered many issues first thing, but like most problems this got easier to predict and at this point in time can solve almost any problem using key fixes and experience.
A Love Hate Relationship
Working with website templates was our go to approach for launch but as things got increasingly more complex we realized that our content was most of the page and took the least amount of time. In the months it took to set up the site for working on, it took half the time to get it operational, and half that time to get the theme of the website finished. The content only took less than a week and to be honest was a huge eye opener.
I'll start by saying that a framework isn't necessary at all, but was the flight we went with. Many people claimed that it was the best route. In fact we were so convinced it's what's running this whole site. Sadly enough some features didn't make the cut and I'll explain why. Turns out that our framework was last updated in 2013. And our team had been busy for months designing and working with libraries from 2015, resulting in the largest site disaster of the project. When the new stuff failed to do its job, the libraries were updated. While this seems logical it is quite not reasonable as with an update comes the removal of tools needed by older code. This resulted in a site wide disaster. Buttons wouldn't work and access panels wouldn't open either causing the entire website to become inoperable. What's the take away from this all? We've decided to rebuild the entire site by hand, only using the elements of it which we need and on the latest code. It's one thing to use a small portion of someone else's code in a project, but to use someone else's foundation, even if meant to be, causes grounds for all of your stuff at one point in time to fail.
From Here Onward
There has been a lot of progress going on here at Cure Interactive. While fraught with issue, we've managed to come through in the other side, which we are grateful for. After all if it wasn't difficult everyone would be doing it. There is a sense of accomplishment even among the disappointments that could not be replaced. Unless that may be, a newer website?