While software already has a major impact on our lives in modern production lighting, there is much more to come. On Stage Lighting looks at three traps to avoid and encourages us all to get involved.
Our own world of production has a long history of bootstrapping up technologies, particularly borrowed ones. This decade, a good part of this productive creativity appears in the form of software: Apps. Here, we are not using the term ‘apps’ as in App Store but as a catch-all for software based ideas and products ranging from lighting console platforms right down to little soft-widgets that run on your smartphone.
Some individual developers have gone on to build companies and highly influential lynchpin stuff, such as Chris Ashworth with Figure 53’s QLab. Everyone these days could be some kind of developer. Don’t get me wrong, I’m not saying good app development is easy but the barrier to entry is now low when it comes to putting down some code, building a UI etc.
This prevalence of app creativity means that On Stage Lighting gets regular requests to look at some app-gadget or soft-gizmo in its early stages. In order to help all those app developers, here are three common themes that I regularly feedback to those creating our next generation of software products.
Is this just a ‘production’ wrapper?
You know how Facebook is Facebook? You can’t out-Facebook Facebook, right? Just as with social media platforms, there is only so much mileage to be had in creating a niche version of something that already exists in a generic market. This includes stuff like scheduling, calendars, note taking, communications, sharing, blah, blah along with social. Is your app really just a series of functions that are possible using Google Apps or something similarly generic but with field labels aimed at production?
If so, I may have bad news. If the function and arrangement of the functions is really quite similar to something else that is less niche, what makes you think that your app is going to out-Facebook Facebook? Niche markets are great but is your corner really defendable with functions people can actually get somewhere else? Anecdotally, I see people moving away from specialist towards generic apps UNLESS there is a really amazing reason why the specialist wins out. Be honest with yourself, is the functionality really amazing or is it really a ‘lighting’ or ‘production’ wrapper?
Why Would I Use This?
On many occasions, I’ve found myself asking the developer “What would I use this for?”. For a start, if I have to ask, if I can’t see the usage immediately then we already have a problem. It is relatively easy to come up with a series of functions and put together some code, in comparison to really having a compelling case for usage. For developers right in the thick of it, knowing how it would be possible to achieve something using software can often lead to the ‘why’ fading into the distance.
Ideally, I’d be able to ‘get’ the usage from maybe a sentence or two. Even better, playing with the UI would also give me a sense of it. Lastly, some detailed explanations and case studies are one way of communicating the use of the app but with a caveat: If I need to understand this through explanations and case studies, are you sure that this is marketable? If my immediate need is sketchy and my vision of the future relationship between the app myself or colleagues in production is not clear, is this even a thing? Developers are quite good at answering “How do I use this?”, which is totally a different question.
On occasion, this lack of clarity is simply because the app is a ‘solution looking for a problem’. That’s an easy decision. Go in another direction.
Sometimes the issue with the app at an early stage is simply poor communication. That can be solved but don’t wait, it needs to be solved at the development stage – not just before you start shipping. Otherwise, how can you get meaningful feedback before it’s too late?
Quite regularly, the problem is that the scope seems to broad to a new user. The developer has a mutable, ‘all things’, product that they hope will enjoy a wide makeup based on a large range of usage possibilities. That leads us on to…
The Main Thing
There is risk in not having clarity of use for evaluators and early adopters. Give people at least a plank to hang onto or they may be put off by the thought of an ocean of possibility. “The main thing is to keep the main thing the main thing” (Covey) are words to live by and in the early stages of app development it holds true. Having worked out one or two usage and customer models that you really believe in (and that would be supported by market analysis), stick with it and develop that.
Keeping a focus should also help avoid the lack of clarity mentioned above. Understanding how an app fits with my need is a whole lot easier if it doesn’t try to be ‘all things’ or give me a set of endlessly flexible tools that I have no idea where to start. When you have a large user base, they will more than likely develop new usages and workflows that you hadn’t envisaged when you packaged the tools.
To get that user base, keep the main thing the main thing.
Start – > Run
Everything starts somewhere, often from nothing. Software development still has much more to give us in all areas of production, not just in lighting. In the connected, information age where data underpins everything we do and software provides tools for manipulation of that data, it’s hard to see how even a ‘real world’ environment like live production is not going to continue to be disrupted.
Learn to write some code, have fun and create stuff for our world. Keep on learning around what we do and considering what we might need. And keep sending apps and ideas to On Stage Lighting for feedback. You can email details via editor at onstagelighting dot co dot uk.