Well, it’s been four long months since the last update on the development of this online collaborative stage planning and production tool, and developed it has. Some of the cause of this gap in information has been due to reluctance to share our coveted industry secrets, but most of it has been down to just being too darn
lazy busy. Since the last post, a horrendous amount of work has been poured into this thing by both myself and, more recently, our fantastic, super-intern, Ciaran Schütte. We’ve turned it from the basic, sandbox style prototype you will have seen in the last post, into an (almost) fully fledged working Beta of our product.
From one trick pony to fully working demo app
Having gotten used to the marvel that this was actually gong to be possible, I set out to actually get it done. Before long, I was well on my way. That’s when I was joined by the Schüttenator.
Big Decisions in Back
I’m not going to pretend i’m in any way an organised person (I’m regularly down to my last pair of underwear before I cop on and put on a wash) so we needed some existing framework to keep our code spick and span. I wasn’t up for creating that. And so began our quest.
Publish – Subscribe Design Pattern
The Ruby Debate
Neither myself nor Ciaran know ruby on rails, but we knew it was a powerhouse capable of quickly and easily building a backend to meet our needs. We would have loved to have learned it, but the time it would have taken to do so simply wasn’t available to us, so we had to make a decision to stick to good ‘ol PHP.
Laravel PHP Backend.
Thusfar, Ciarán’s most recent stage in his research quest has lead us to a PHP application framework called Laravel. This essentially made it nice and easy to structure a large scale app and database to manage user log in and saving of all things user and production related. Nice one Ciarán. Now the thing has scaled up to be a monster. The foundation is laid for this to grow to be a proper, commercial level, stable web application. That’s what we want, so this is good.
Big Decisions up Front
Enough about the backend. Let’s talk pretty, precious things.
To be honest, this is such an “out there” product that it seemed weird to be back using plane old HTML to construct a U.I. I had toyed around with the idea of making the U.I. 3D as well, but I think that would have been overboard (not to mention far more complicated and also heavy on client-side processing power).
So it consists of a series of “panes” which change their contents depending on the state of the U.I. For example, if you switch your role to set designer, the edit pane will show you the tools related to set designer. I prefer to segment tools based on the current use case instead of pushing everything in your face. This saves space and overall, makes the whole thing neater and ultimately easier to use.
You can have a look here, at the non-techie accompanying blogpost for a full rundown on the U.I.
So there we are. That about brings us up to date on everything that’s going on. But what’s next? Well, first port of call is to fix the host of bugs throughout the software. Since we started rushing a month or two ago, decisions stopped being as well thought out in place of quick fixes. For that reason, we want to make what we have so far rock solid before continuing with any further feature development.
After doing that, and adding in a few more aforementioned beta features such as better lighting U.I. and the script pane (more on that here), we will most probably start switching the backend over to work on Node.js. We wish to create a truly collaborative product. That is to say that we want a Google Drive style character-for-character, click-for-click, live updating collaborative experience. For that, we need to use web sockets, and apparently, Node.js is the good for that.
But what do I know? I’m no expert…