I said in my last post that I would focus next on the reasons for building your tools as a webapp. However, feedback received since my initial post, along with this discussion thread over on The Chaos Engine (login required) made me realise that I also need to define what exactly I mean by ‘webapp’ and also cover the negative aspects, not just the positives. It’s resulted in quite a long post so if you’re in a hurry just read the italic bits, which contain what I think are the most important points.
What does a webapp based tool mean?
As I see it, there are two main points: the first is that the UI runs in a browser of some kind, with the interface constructed using HTML, CSS, Javascript and likely some custom plug-in running in the browser. The second is that you introduce a server/client model with data storage and processing being centralised on the server – the client becomes a very thin layer focussed on presentation.
That’s essentially it. I’m sure there are other subtleties I could delve into, but for the purposes of this post those are the two key elements I’ll keep referring back to. In fact the majority of my points focus on the UI side of things.
What are the reasons you’d want to build your tools this way?
Better Looking User Interfaces
For me, the initial inspiration to start experimenting with HTML interfaces came from my frustration with doing things the ‘traditional way’. The tools interfaces I was working on were mostly created as forms in Visual Studio and then driven using C++ or C#. Up to a point that works, but the interface ends up looking pretty plain, and trying to override the styling is tedious and baffling enough to drive any developer crazy. Alternatives such as Qt and WxWidgets are better than Microsoft’s offerings, but I still don’t find them as flexible or feature rich as using HTML and CSS.
The games industry is a creative business, so you need the users of your tools to be enthused by them – to actually want to use them. Having an attractive interface is a critical to that aim, and HTML can deliver it.
Better Development Workflow
A big advantage of HTML over a traditional form based UI tool is the iteration time. Make a change, refresh your browser, and there’s your change – unlike editing a form in Visual Studio, which generally forces you into a time consuming recompile. The combination of HTML and CSS also makes tasks such as inserting a new checkbox into the middle of a form a two minute job, unlike the the chore that of trying to slot it in using Visual Studio’s form editor. Live-editing tools such as FireBug are also a huge workflow win.
As I talked about in a previous post on iteration times, slow iteration not only makes tasks take longer, but results in bored and frustrated developers who produce sub-standard work. My experience of HTML as a UI layout tool is that has vastly improved workflow.
More User Interface Flexibility
One major criticism often make of UI toolkits is how difficult it is to customise the existing controls, to add completely custom controls and to make use of third party control libraries. This results in unambitious user interfaces that only barely allow users to carry our the task for which the tool was designed. Browser based interfaces have, for our team, proved more flexible and powerful – especially since the advent of HTML5, CSS3 and in particular the canvas tag.
HTML and CSS have been designed over many years to provide a flexible and powerful presentation layer for the browser, and they do it well.
Standing On The Shoulders Of Giants
Perhaps the most important of all the points I could make. The web development ecosystem is huge, Google and Apple have embraced it heavily, and even Microsoft are finally pulling in the same direction, for example with some of the Windows 8 feature they’ve been showing off. Not to mention web heavyweights like The Apache Foundation and Mozilla, and the thousands of other web development companies and individuals out there.
I can’t remember a time when so many companies, both large and small, were so closely aligned in their goals, and where so many development and learning resources were being made freely available. As game developers I feel we’d be foolish not to capitalise on all that shared knowledge and development.
It’s the Future… probably
It’s impossible to say that the current trend for web based applications will continue indefinitely. But the resources being invested by so many large companies, and the great products that are appearing, make it likely that web apps are more than just a fad. Individual plug-in technologies such as Adobe Flash or Google’s fledgling NaCl may yet come and go, but the core HTML, CSS & Javascript browser model now appear well established.
Any technology you invest in runs the risk of becoming obsolete, but common web technologies seem less risky than most.
The Right People For The Job
When designing and implementing the user interface for a game, that would most likely involve a range of specialists including artists, designers and programmers. For tools however, a programmer is often left alone to design and implement the user interface with very limited art and design input – and even there is art and design support the technicalities of implementation process means the programmer becomes the bottleneck for any work done.
With a web-based interface this is much less of a problem. There’s a whole generation of web developers out there whose primary skills are creative, but who also possess the technical knowledge to work with HTML and CSS to implement that creative vision. We recently hired a web developer into our core tools team, which is mostly made up of C++ programmers, and the difference in the quality of the user interface design and the speed of development have both markedly improved.
The design process for tools user interfaces can learn a lot from the design process for games user interfaces. Web technologies put the power in the hands of the developers with the right skills.
Transferrable Skills
Although I think it’s important that we employ specialists for user interface creation, it’s also true that game developers are now frequently expected to understand web development and interface with web APIs such as Facebook and Twitter. In my experience most developers have also built their own portfolio websites and have at least a passing understanding of HTML and CSS. The once hard line between web developers and games developers is becoming ever more blurred, and I think it’ll be increasingly more common for web developers to be employ at games companies, and vice versa.
Broadening the use of web technologies within a company will both strengthen the existing employees and open up opportunities for hiring talented developers from outside the traditional games industry.
Cross Platform
A nice bonus of web based tools is that you can use them on any device with a web browser. There are obviously caveats, such as browser compatibility and use of browser plug-ins, but these are continually diminishing as plug-in technologies improve and browsers strive to meet current standards.
The ability for developers to work on Mac, PC or even a tablet or mobile device is hugely exciting.
Easier & Faster Roll Out
If you can get to the position of having a fully web-driven tool chain then you can eliminate the install process and roll out tools updates with ease. I think we’re still a long way from that being a feasible proposition, but even being able to send someone a URL and says “what do you think of this UI change” is far easier than sending them a new build to try out.
Separation of Interface and Logic
One of the worst sins in tools development is to mix the logic and data storage up with the user interface. This makes it difficult to change the interface without also breaking the logic, or to allow automation of your tools through scripting. Unfortunately the design of many UI toolkits (MFC in particular) leads you down that path, and although it can be avoided through careful design and code review, it’s easy to accidentally break the rules. The implementation of a web application forces a complete separation because the only way the UI can communicate with the back-end is via HTTP (typically AJAX requests using JSON or XML data).
If you can drive your tools back-end entirely via the HTTP connection, then it will be trivial to also script your tools and much simpler to make revisions to the user interface.
User Created Tools
An extension of the previous point – if the tools back-end can be driven entirely via a simple interface such as JSON data, then it becomes much easier for end users to write their own custom user interfaces to help them achieve their goals. That might be as simple as automating a commonly repeated task, but every workflow gain is time and money saved.
No matter how good your tools are, given the chance your users will find ways to improve them and bend them to their needs. Tools should be built with that in mind.
Interface Re-use and Standardisation
Being able to re-use code is great. A couple of examples of how web interfaces have helped us achieve this are:
Debugging – Our BlitzTech engine supports a variety of debugging and live update features via a HTTP interface. All you need is a running copy of the game, and a web browser and straight-away you can start examining the heap usage, performance metrics and so on. By using a web interface for our tools we can share many of the UI controls and styles.
Remote Administration – Most tool-chains I’ve seen have some form of central servers for distributing intensive tasks such as lighting generation and asset conditioning. A web interface is the perfect way to manage those servers – so why not share that UI technology across all your tools?
Make Tools Development Fun
This was an interesting point raised on the chaos engine thread. Developers love to learn new skills, especially when they can see how it will improve their own workflow and that of their end users, and when they can see how those skills will transfer to other areas of development, allowing them to do more ‘cool stuff’. Developers also love to be on the cutting edge, and there plenty of advancements going on in web development that I would consider place it in that category.
Developing web UIs involves learning new skills, but that’s what makes it fun.
Right, that’s the good stuff out of the way. It’s not an exhaustive list, but it’s quite a long list so I’ll leave it there.
Why wouldn’t you want to build your tools this way?
Performance Concerns
Most of the concerns in this area centre around 3D rendering or data processing. There are various rendering alternatives ranging from the open-source WebGL, through Google’s NaCl tech (which promises to do away with plugin authorisation) to plug-in technologies such as Flash and Fabric Engine. At the moment it’s hard to say whether any of these are viable approaches to build your own technology on top of. I really hope that NaCl, or a variant is adopted across multiple browsers, and I look forward to seeing how Fabric Engine develops – but for now the BlitzTech tools are sticking with our custom renderer. This means we don’t get all the advantages I talked about earlier, but by pushing the rest of the toolchain UI into HTML we get a good trade off.
For data processing, BlitzTech has a well established distributed processing architecture, so although we’ve re-implemented some of the user interface in HTML (to allow for easier remote administration and monitoring) there’s not been much change in this area. In future there might be more scope for leveraging web technology to help with our distribution architecture – putting more of the work ‘in the cloud’. For now though, I can’t see the justification for expending effort on doing so.
As for more general user interfaces, performance has actually turned out to be better than the equivalent Windows form-based interface despite some of the additional abstraction – that’s possibly more of a reflection of the terrible architecture that Windows clings to, but it’s certainly fast enough for our needs.
Compatibility Concerns
It’s true that browser compatibility can be problematic if you want to use recent HTML and CSS features and rolling out fully web-based tools could lead to extra work resolving compatibility issues. As Mike mentioned in his post about Insomniac’s web tools they’ve chosen to only support Chrome. At Blitz we’ve done much the same, rolling Chromium into our install to avoid any compatibility problems.
Multi-Monitor Support
When running an application in a browser you’re very much limited to working within that browser window. To take advantage of dual screens you need two browser windows, which can’t communicate directly with each other. This certainly imposes some architectural restrictions but nothing that can’t be solved – hopefully I’ll go into this more in a future post.
Lots of Rework
Someone pointed out to me that reworking your existing tools with a web interface is an expensive business. That’s certainly true and I wouldn’t recommend replacing functional tools just for the sake of it. But if you need a new tool, if your old tool is due a significant amount of re-work anyway, or the benefits that a web-application bring (e.g. remote access, feature rich UI) will make a dramatic difference – then it should at least be considered.
You don’t have to use a web-app to get the benefits
Several people have told me this. Citing Qt as a better alternative to MFC or WPF, and pointing out that some of the architecture problems such as sticking to an MVC model can be solved purely through careful design. I wouldn’t argue that either of these are untrue, but I do think that the web-based model I’ve talked about gives you the same benefits and more.
Retraining Staff
If you don’t know anything about HTML, CSS, Javascript or HTTP servers then there’s certainly a fair bit of learning to be done, and depending on the scope of your project and tools you have to choose whether you have time to allow for that, or whether you can afford to hire developers with those skills to fill the gap. There’s a wealth of information out there though, and learning these skills may take less time than you think - and of course, the skills you learn will be transferable to a whole variety of other tasks.
In conclusion…
To sum up, a browser based user interface allows for flexible and innovative designs, improves development workflow, enforces better tools design, paves the way for cross platform tools, encourages the learning of transferable skills, and perhaps most importantly, gives you access to a vast array of existing technologies and documentation upon which to build your tools. There are some areas where development is very much in it’s infancy (e.g. 3D rendering) but even here progress is swift; I believe that within a year we’ll be looking at a much more stable set of technologies for high performance web development.
In my next post I’ll start to talk about how on BlitzTech we took some off-the-shelf components and combined them with our existing toolchain to start developing web interfaces.