And another thing 71
by Jon Honeyball
Jon Honeyball sets his sights on UI design, release schedules and the importance of surround audio to VR.
HardCopy Issue: 71 | Published: May 10, 2017
I am faced with a quandary. A client is working on an app which fronts a piece of hardware. The market sector and functionality isn’t relevant to the discussion, and I won’t name names. However, they are building an app in both Android and iOS versions. This of itself is not unusual – the customer base for their product, and the combination of the software and hardware, has to support both iOS and Android users.
What is unusual is the decision to throw the rule-book out of the window when it comes to UI conventions, especially in the case of the iOS product. If you go to the Apple website, there are a huge long set of UI design recommendations, and the tools with which to implement them.
Now I have absolutely no problem with the concept of throwing away the rulebook and writing your own UI. It is indeed one of the most fascinating experiences when reading Petzold nearly thirty years ago. The idea that you took responsibility for the window’s contents, and it was entirely up to you to maintain state and be able to repaint any of it at a moment’s notice, was fascinating to someone coming from the Stone Age of DOS, CP/M or even PrimeOS before that!
The problem with defining your own look and feel is that it becomes a self-fulfilling prophecy. All of the learning that the user has made, both consciously and subconsciously, in the operation of the standard UI gets thrown out of the window when you paint your own UI.
To be clear, this can be a huge advantage. I remember with fondness a set of paint tools called Kai’s Power Tools, which took a radical new design idea, and threw all preconceptions out of the window. (Or was that Window?) It worked too and showed what was possible.
But when it comes to a mainstream app, which does the usual select, play, choose track and so forth, it is very hard to see what has been gained by writing the UI from scratch. Especially when you really throw the baby out with the bathwater and insist on taking away the top line status bar too, so you cannot see how your battery is holding out, or any other status information that might go up there, including the clock. (Interestingly, their Android version manages to keep the top bar in place.)
And I have no problems with black user interface designs for those applications where light pollution is an issue, or whether colour acuity could be compromised by an overall background tone. When it is done ‘just to be different’, then I find my hackles rising.
At the end of the day, design decisions have to be made. But all too often, it seems that app developers allow themselves far too much free reign to try something “cool” or “distinctive”, without the cold hard reality of user experience being brought to bear. My rule of thumb is simple: when I see a custom UI design, I require a full written justification for what is wrong with the standard UI tools. And “No” is my usual answer, because most times the claim that the standard UI tools won’t do the required tasks simply means that the tasks haven’t been clearly defined or thought through. At the end of the day, you cannot ask the user to learn your pet design methodology just because you want to be cool.
And petulant designers just hate the word “No”, which adds to the fun immensely, I find.
What is considered to be an acceptable release schedule? I ask the question because it is clear that the expectations, both of the user and of the developer, are changing rapidly. Back in the past, a team defined a product, they wrote it, and then delivered it. A few bug fixes might follow on, although the discipline and expense of sending out floppy disks was quite a good reality check for the financial spreadsheets of the team leaders.
Then along came the web and the possibility to deliver ever changing ‘content’ to the user. Unfortunately, the same viewpoint appears to have filtered back to apps and OS development too. Whilst I have no issues with using the power of the internet to distribute patches to bugs, and to do so in a fast and timely fashion, things get a little more weird when the very definition of what is being delivered, and when, becomes foggy. After all, if you can’t get Feature X to work right, then just wait a few more weeks and then ship it out on the next drop.
It would be churlish to be disdainful of the rapid rate of development progress that this can bring. However, all too often this can lead to an emerging sense that nothing is ever “finished”. That there is no target that is being aimed for, and then the results delivered. And from that comes quite a subtle but important disconnect between the development team and the customers, especially over the cycle of delivery and expectation management.
The best teams handle this very well. I would applaud the way that Microsoft is handling the rollouts of Office, for example. You can get the standard update cycles, or you can sign up for the Office Insider Program to get things in advance of the mainstream release. And there are two speeds, Office Insider Slow and Fast, for those who want to get a little closer to the bleeding edge.
The user expectation is clear here – you get the newest things early if you are on Office Insider Fast, but it might not be totally stable or suitable for a production environment. Insider Slow trades off speed of access for better stability. And if you are being cautious, then the main release cycle is the one for you.
However, the new era of ‘continuous downloads’ means you actually have no real idea what is going on.
Having the conversation with your customers about the timescales they want, and how they want to receive it, is becoming critical. For home customers, frequent updates is rarely a big problem, provided the operation is seamless, simple and reliable. However business customers can take a very dim view of updates being pushed out all the time. Much here is defined by the market into which you serve product, but communication is key here. Set expectations appropriately and then deliver to them. Nothing grates more than a promised released schedule that fails to materialise. And when this happens time after time, the customer’s rightful view of your development team is that it is staffed by morons.
Surround audio and VR
Much is happening in the world of Virtual Reality, and some of the really interesting stuff is actually in surround sound. Although the visual part gets all the “oohs” and “aahs”, the sound component is critically important.
In the surround sound world, there is one big player, namely the Soundfield system. A fully surround microphone system that captures left/right, up/down, front/back plus an all-around omni signal, the system stores this in something called B-Format. (A-format is what comes natively from the microphone – you can tell the British inventors of this stuff were really into flashy branding).
The Soundfield microphone technology is still around, both from Soundfield itself which has recently been sold to Rode Microphones, and also from third party vendors.
Why does this matter? Because once you take B-format and output it to binaural, and then feed that into headphones that have head position tracking built in, you can build soundscapes that take account of how the head is moving in real time. All of this is critically important to getting compelling VR to work well. Rode has promised a Video Soundfield microphone to complement its existing range of mic systems which will clip into a camera hotshoe, but record the full surround signal. And hopefully delivered at a price which is much more affordable than traditional Soundfield microphones.
And this technology is all over the place: just pop a smartphone into a cardboard headset arrangement. Google, Microsoft, YouTube and others all have content delivery systems in place that support the surround format, along with VR visuals too. If you are working with audio, or audio-visual content that goes beyond standard stereo, then this is a technology you need to be considering. Even something as simple as stereo audio in binaural format can be truly compelling, as the BBC is demonstrating with its various binaural format broadcasts of events, concerts and so forth. This is a robust technology, and the customer expectations are changing fast, especially in the new world order where people listen on headphones through their smartphone.