Please can OUICE converge on Bootstrap, soon?

Some years ago (I should research when), bright people at The Open University created a CSS-based design for OU-branded sites (public sites, and our virtual learning environment/VLE). And, they named it “OUICE”.

And, they saw that it was good… And, milk and honey flowed … And… (you get the gist)

Fast forward to 2016, and one of my colleagues, Sam Leicester, is working hard on OUICE version 4, which is being used on The Open University’s new super-faculty web sites (as part of our latest re-structure, sigh). Sam, and his design and developer colleagues are hard-working and good at their jobs – the result will undoubtedly be a powerful, responsive, mobile-friendly system. He said, “you should give it a try”, and “it’s got lots of powerful features”. I’m afraid I wouldn’t have come across as very enthusiastic (sorry Sam!). Why?

Well, my current Web development project is Applaud. Its OU-branded, an internal strategic project. Seems to tick all the boxes… The problem from my standpoint is that OUICE isn’t Bootstrap. My approach for this project has been to use the OU’s page-header, and its associated CSS stylesheets and Javascripts, and then to use Bootstrap for the other 80% of the page (editing the responsive “break-points” for Bootstrap, to match the OU header’s mobile/tablet break-points). (I can imagine design purists gasping in horror!)

I’m doing this because I know Bootstrap (fairly well), I know I’ll be using it on future projects (OU branded or not), my colleagues use it on their projects (so we all have more chance of understanding each other’s code_!_), solid documentation, steady, incremental development … (lot’s of pluses).

Unfortunately, given our time-poor working environment, I don’t have time to invest in learning about OUICE 3, or 4 or … I’ll learn the minimum I can, to solve my problems. I have to use my time learning and developing October plugins, Laravel libraries, learning Angular (another project), using Travis-CI to improve our QA … (a long list). And, actually solving the problems of each individual project. If I have any spare time, I would follow-up on the merge request I put in for open-source library ‘X’, re-kindle my own projects, write more blog posts, research new technologies, or a new language, or that course I’ve been meaning to … (another long list).

In short, and whether we like it or not, Bootstrap has become a de-facto standard, much as jQuery has.

So, OUICE will continue to be used thoroughly by the small group of our developer and designer colleagues working on the OU’s core public web sites, it will be used by our VLE developers (…?), but I suggest it will be used at a much more superficial level by us developers/designers (quite a number of us), working on a wide variety of strategic and externally funded (mostly not OU-branded) Web projects.

I’d like to suggest to colleagues that we work to make OUICE 4.1 or OUICE 5 converge, so that it is built on Bootstrap. Put our efforts into a seamless experience (for end-users and developers/designers) across the OUICE-Bootstrap boundary, work out how to cope with the Bootstrap release cycle, and concentrate on components that can sit on top of Bootstrap that are unique for the OU’s needs.

Now, tell me why I’m wrong!