What’s the Story?

In the beginning…

Well we don’t have time for that, let’s start from a little later in time.

Jolojo was conceived by the collective creativity of the team at BarkWeb – a provincial ‘Web Agency’ (don’t you hate that phrase) based in Eastbourne, in good old blighty no not California, or Seattle or Brighton, or a multitude of conceived ‘cool’ geographical incubators of what is termed Start Ups – by real people doing real work for real businesses with real experience, really! (So that’s off my chest then!)

We had used, tested, tried and experimented with various platforms from the ubiquitous platforms – in php, Wordpress, Drupal & Joomla and in C# .Net, DotNetNuke and Drupal.

They are all great, they all have specific talents and specific pitfalls, they can fit and be forced into fitting projects, but they just didn’t work for us.

We didn’t want to be known for being able to stick a site together and then hit a support wall when X feature became incompatible with Y feature and we had built neither…

We are creatives, we are inventors, we are restless, we want more, more, more!

More control. More capability. More understanding. More excitement. More satisfaction. And we demand of ourselves outstanding support for our clients, of which there were more.

2009

So. We built our first CMS and launched it to our clients in 2009. Code-named CMS1. Boring name. It worked though, it bore the fruits of our labour and ran websites for over 10 years (the last CMS1 site was turned off in September 2018, RIP tears in eyes, farewell old loyal friend).

2012

CMS2 (can you see where this is going) replaced CMS1 in 2012. Both platforms had been built using Php and MySQL. We worked hard at it and built some really funky tools for it such as:

• When using a menu plugin and adding a link to a page that didn’t exist, asking the Admin if they wanted to create a page at the same time.
  
• Plugin-sets – to allow pages to be created from pages that already existed (well that will do for this explanation)
  
• Internal link checking – including directing to re-directed pages
  
• Automatic 301 URL re-direction when page URL was changed
  
• WCWAW – Who Changed What And When (page by page changes)
  
• WMWAW – Who Moved What And When (to see layout changes and plugin re-positioning)
  
• Plug-in versions at the plug-in level (very useful)
  
• Run multiple sites from a single code-base and data-base (or split off if required)
  

We said hello to Authorship and built that in (when Google loved it) and then removed it (when Google discovered that its users preferred clicking on searches with authorship and click on adverts dropped).

We made the site usable for completely inexperienced webmasters. It worked. It worked well (and still does!) But we knew we were hitting the buffers as far as what we could do with Php and were losing the will to live in Php land (it is genuinely great, keep up the good work, but….) we were finding it rather restrictive.

2015

By 2015 we realised (but didn’t understand what it was called) that it was becoming more and more difficult to make BIG changes without affecting too much. This is The Monolith Application issue.

We built a new CMS, we tried to get investment, we almost got investment. But we were trying to build a better Wix / Square Space / Site builder website. We did build it, it did work. We were using newer, funkier technologies (MongoDB and Node.js), we realised we liked the funkier technologies. We even gave it a new name this time – Vitamin. We even liked the name.

But, development stalled. It was still a Monolith Application. We also were a very early adopter of Node (pre version 1) and although it was stable, it was obviously trying to properly version itself, grow and fully stabilise. Before it was too late we decided to change tracks a bit.

Late in 2015 the idea of separating the front end (HTML delivery and data inputs) from the back end (data base) was played with and we liked it. We liked building API’s that talked to the database and we liked building front ends separately. We didn’t fully understand it but we were going HEADLESS!

It made BIG SENSE.

2016

We decided to stop development on Vitamin (heck, it hadn’t attracted any new clients and we hadn’t deployed any provincial clients on it) it had though been an essential stepping stone.

So, the concept was finally born, after a long labour, for CMS3 (back to that old naming convention chestnut), we committed to our course and sleeves were rolled up and work started in earnest.

Our chosen tools were SQLite (opensource and has some nice features such as being able to query stored JSON), Golang and a smattering of Node.js (plus various other helpers of course).

2017

It took over a year of man labour to get to the point where we would start to look at it as a collective team and just as this happened (July 2017) we noticed that Facebook (the authors of react.js) were being a little fuzzy (our language) about their version of their opensource licence (BSD+Patents confused us), we didn’t like it (read more at https://medium.freecodecamp.org/facebook-just-changed-the-license-on-react-heres-a-2-minute-explanation-why-5878478913b2 ). We saw issues for our potential distribution, we discussed it and then we painfully decided to re-write what we had done to date on the front end – this time in vue.js.

Coincidentally we took the decision to pull our use of React before WordPress did who were using React (as we were) in their own development. Subsequently, and probably because of the pressure of WordPress as an internet "Giant", Facebook re-issued React on a more flexible MIT OS licence. But by this time it was too late for us, and you shouldn’t jump ship that often and the development team felt that Vue was a better choice for us even if we were to revert.

By the time that we had converted all of the front end code it was Summer 2017, not quite “The Summer of ‘69” – we felt we were making good progress.

I should also mention that we had already ‘sold’ the platform to a few clients based on very early Beta demonstrations, the most noteworthy of which for them was ‘inline editing’ of text (editing the text ON a page as opposed IN in a pop-out modal window, meaning that the page would look exactly the same on page save – in effect the user edits the page as if it IS live and not in an RTE that doesn’t render the style that is being applied to the page when viewed properly AS a page).

Work continued and more of our developers were introduced to and got experience with CMS3 during the latter part of 2017. By the end of the year we had 3 years and 4 months of developer time logged in non-paid work for the new platform!

2018

Our baby ‘pops out’

We started 2018 in late stage development of 4 websites being ported to the new platform. This did not come without risk.

Our tangible aims for bothering to build a new platform should be remembered at this point, they are:

Ease of use for US

TO be honest, although this is a requirement, it kind of comes ‘out of the box’ if you have written the platform from a standing start!

Ease of use for our CLIENTS

And having clients involved in the platform for the last 6 months of its development prior to lighting the blue touch paper and launching important marketing resources (OK websites) for said clients was invaluable.

Speed

From very early on we were measuring Page Speed from Google Page Speed Insights (https://developers.google.com/speed/pagespeed/insights/), I got obsessed… Our aim is mid-high 90’s for ALL pages. This involved a lot of work around automatic image re-sizing and optimisation as well as caching, server response times, code efficiency etc.

Headless

Yes, again… But even with a headless system you need to make sure it is properly headless.

Security

All sites run SSL’s, period. We don’t send out temporary passwords to users, just well hashed URL’s that expire.

Google

Yes, we even thought about The Big G… As per the opening paragraph and if you have Googled us you will have noticed that we have a lot of experience and skills in both SEO and Paid Search, so we have got this right.

We launched the first sites on the 22nd of March 2018 not to the sound of trumpets, but to the sound of keyboards frantically checking Google indexing and watching out for any stress testing issues from live users (yes, we had load tested the sites and servers prior to launch!)

It worked. The sites worked. We were happy.

Just prior to the sites launching we thought “CMS3 is a pretty crap name”.

Now we had been discussing this for quite a while and own quite a few domain names, apmanspaceman (thanks Professor Brian Cox), lemonjellyfish (our favourite discussion domain for start-ups we deal with, fortunately we managed to buy it after 5 years of using it…), godsballs (not the .com…) and I had registered Jolojo after an Uncle of mine had, I thought, said it in a conversation to me. Either way, it was registered a while ago, and we didn’t need to spend endless hours coming up with names we thought were cool only to find that they were already registered by someone who either had had a great idea but not had the time to do anything with it (that’s cool) or domain jacked and was for sale for $5,000 (whatever).

And it passed that on the sixth day of the sixth month of the two thousand and eighteenth year of the Gregorian calendar we published the first page, made the first Facebook post and launched Jolojo to the world.

And, I guess it worked to an extent because you have just read this!

So that is how we got to the first sites launched and that was the aim of this. So I am done, out of here, sayonara, au revoir and cheerio for now.

2019

We made a lot of sites on Jolojo in 2018 and 2019, but started to see a tail off in Page Speed in late 2018. Now it has always been a BIG part of Jolojo to just SMASH Page Speed out of the park and the early version did this and did it well.

We use Google Lighthouse and more importantly their Page Speed test online and as we added and added to the platform Page Speed scores started to get worse.

Hosting is not an issue, we have minimum latency and use high quality hasting providers with SSD HDD only, no more processors or RAM could fix the issues, And the finger was being firmly pointed as Vue.js and the fact that we were now including more and more libraries as our functionality envelope increased. One of the issues with a Single Page Application (SPA) is that you have to deliver all the code the browser needs for the visitors session on first page load. It was decided that this was too complicated a fix for Vue.js and our eyes had now been drawn to the oh-so-fast Svelte.

In the Summer of 2019 we started experimenting with Svelte and by Autumn were committed to a re-factoring of the Vue.js front end, some tweaking for efficinecy of our APIs and a general clean-up of the two year old code base.

This is not a re-write. We have a fantastic front end, it really works for the users. So we are not 'inventing too much' - just tweaking, polishing and improving.

2020-2023 (21st December)

It is just not possible to list all the work that was done over this peroid... Some of it AMAZING, some of it less so...

We kept getting closer to launch, but also kept getting held back. There were 2 factors involved:

1. We are investing in this platform without external financing.

Which means, we can only invest the time when we have the cash. And we need to be busy to survive. If we are busy we have less time to evolve Jolojo as an MVP. Kind of Catch 22, kind of frustrating, but also exciting.

2. Pride.

Realistically we have been ready to launch for almost a year. But we tempered this by both our desire to add some polish, and because we want to be proud of what we have done. The classic MVP is - build it, launch it and don't give a toss about your initial users. Prove it works, throw it away and re-launch. That is a start-ups mentality and NOT the mentality of a Company that needs to deliver working products.

22nd December 2023

We lauched our No-code site builder.

And we are SUPER PROUD :-)