I am the director of FT Labs which is an emerging web technologies division of the Financial Times in London, we make the FT web app amongst other HTML5 applications and we are actually one of the first examples of an HTML5 app that had a native user experience to appear on iPad and Android and I think still one of the most often cited examples although they are plenty of them now.
Well, the FT has actually charged for content for a really, really long time, I think we were one of the first businesses to put up a paywall, probably over ten years ago, I would think, and the model has proven that people are willing to pay for content that they really, really want to read that they can’t get anywhere else, that they value and they think it’s worth money. So it’s probably a matter of making that mechanism work, making it easy for people to purchase the content and making it easy to access and introduce people to the content they haven’t subscribed to before. I’m not a business person, I could certainly tell you about the mechanism of how the paywall works and how we do the charging for content, but in terms of why people buy it, and why it’s successful I think it probably just simply comes down to that it’s premium content that people want, that they have a willingness to pay for it and we demonstrated over a decade that is the case.
Brian's full question: Speaking of the mechanism of how that works, obviously the paywalls all have various ways that they allow certain amount of free content and even in a discussion earlier you mentioned there is a partnerships that allow free content, does that present particular difficulties in developing the app in terms of how do I allow this person, this number of free things, these persons to get free stuff because they are here and so on?
Yes, absolutely, the number of combinations and permutations of deals that you can do with customers is almost endless and I always feel like there is a temptation from the engineering side to push back and say “no, everybody pays the same, there is one formula for everyone”, because it would be so much easier, but obviously it’s a meet in the middle situation that you’ve got to have. You’ve got to have these deals in place because they are important for earning revenue for the business and you have to find a happy middle ground of making that work in a way that is reasonable practical technically. We have examples like corporate sales where if you want a particular company network then you have to access to premium content without logging in, but then if you log in you then become a member, affiliated with that network that you can take that premium access outside that network. Or maybe you have premium access because you are in an airport lounge, there’s more premium access to the content, but if you change the Wi-Fi network you no longer have it.
So, there are a lot of permutations like that that are technically very difficult to implement, new ones appear all the time, like when the app introduced offline capabilities, the challenge of metering what the user has read even though we can’t do that in real time because we are not synching that data back to the server as soon as the article is read, so that has the potential for extra reading to be done because you can read on multiple devices at the same time. So, you have to have a certain amount of practical leeway around these things to administer the paywall in an effective way. It’s never really about absolute security and absolute control, it’s more about getting close to what we want.
Well, this is a very well-worn debate, isn’t it? The benefit of the web as I see it is around constraints, we want as few constraints as possible, we want to be limited as little as possible in what we can do, so we see the web as being the technology designed for our use case as a publisher and which is inevitably going to be ubiquitous across any device that is a connected device. If you have a connected device with a screen of some kind, then it’s absolute you can have a web browser in it, I mean I have a web browser in my television, I don’t use it because it’s not any good, but I think we will see more and more of these kinds of devices with better and better browsers. I was on play the other day and for the first time the seat pack screen had a web browser in it that I could use to browse the web. It was an embedded Firefox browser, I tried to work out what version it was but it was locked out, it wouldn’t let me. So, the more and more of these new channels that we have, the more we will want to innovate in ways that we can’t necessarily predict today and the web really gives us a lot more flexibility than any other technology. It gives us a lot of headaches as well as there are a lot of ways in which if you pick any one platform there will be a technology which is easier to use, easier to implement, quicker to market than the web. And that’s pretty much the case on any platform you choose to use, but the benefit’s when you look at the holistic picture rather than any one particular user’s experience.
Sure. I often think that actually as web developers we are in the 200 meter hurdles and the person that uses the native SDK is already 100 meter down the track when we start the race. And that’s to some degree because they have much higher level abstractions for many of the user interface patterns that they would want to use and when we try and slavishly copy what are actually very good innovations in user experience that have been made in native apps, then we have to start far further back because we have to build those abstractions from the ground up, and the result can be quite hit and miss, you have 95% of the users interactions with software in the device are maybe native or absolutely consistent in the sense that they are all using the same abstractions for say elastic scrolling or transitions or have you. And then you go to the web and you find it’s a kind of Wild West of all sorts of implementations of all sorts of different scroll mechanics and all sorts of different transition animations, precisely because they have all been built from scratch.
And I think to some extent that gives us an advantage because when you have access to those primitives you do have the creative freedom to build whatever you think works for you. But at the same time it’s obviously a lot slower and it’s a lot harder and sometimes you really just wish you could do that thing which you can do natively very, very easily. But I think there is a lot going on to try and address this and what you tend to find is that those sort of patterns which become very common on the web, we start to see standardized.
So, I was quite interested to see Microsoft recently published a draft spec for scroll snapping in CSS, so if you want to do page scrolling you would be able to do that with a couple of CSS properties, where today you need to essentially re-implement the entire scroll mechanics yourself. So, I think when we can go through that cycle maybe a couple of dozen more times, we’ll have a great set of higher level abstractions available to the web community that are equivalent to what we have natively. By then of course native developers will have invented a whole load of UI paradigms that we can’t do on the web, but it’s a constant battle to catch up when you’re trying to support a standard platform that’s across, that transcends all operation systems and all application ecosystem. And any proprietary technology is going to be able to innovate faster.
Brian: Well, you mentioned some new APIs and new features in HTML5 and CSS3 and whatever, I always tend to drop, personally, the 5 and the 3 and stuff.
Yes, it’s relatively meaningless.
That’s a good example of something simple, and I think the simple things are quite powerful because not only is that two CSS properties that could potentially take thousands of lines out of your code base, but because it’s small it can iterate very quickly and you hope that means implementations aren’t too far behind. There are larger efforts, we’ve had a lot of problems with app cache for example, there’s an effort going on to replace that with something called service worker and that is being discussed and a draft spec is being written for over a year now, almost a year now. There are some efforts which do take an awful lot of work, but I think on so many different topics we are making a lot of progress and every new browser release gets us closer and closer to where we want to be. And of course, another great advantage that we have now is that we have evergreen browsers. Even Microsoft is getting on this now and managing to produce browser releases relatively quickly, I think Safari now has the slowest release cycle of the major browsers. So, it means that we can use these technologies much, much more quickly.
Brian: Funny enough, a bit of on the side here, I was giving a presentation the other day, it was going through the history of this, talking about back to when I started my career and at some point IE6 came out, I was actually quite excited about it.
I think we all were.
It’s amazing, isn’t it? I think for us at the moment it’s Android, really, because I was talking to one of our android developers, or any of the Android developers recently, about how the move by Google to use Chromium as web view on Android, how big of an impact is going to be on our ability to have really quality web apps inside embedded Android applications, because we actually have an app store app on Android and it loads the web app inside your web view and up until KitKat we were very limited in what we can do with that because it was using the old Android web view component and that was very, very buggy. So, now we’ve got a great web view component, with great performance and it’s being updated automatically, I understand, we just need to get all the people with Gingerbread devices to go upgrade them. Unfortunately, that’s more difficult than it sounds. There are still OEMs in China selling new devices with Gingerbread on or at least they were still selling them a few months ago. So, when you are in that kind of situation that really is the new anchor holding us back, I think.
Brian: Yes, I can see that. In fact, I was reading though, and maybe I am misremembering this, but I was reading that that switch has started to accelerate to some degree where some of these older Gingerbread devices are finally starting to recede.
I think we are all seeing that now, we see the split being much more even between those legacy versions rather than being a big lump of Gingerbread ones. But it’s still there and not going away any time soon.
Brian: And Safari and iOS, the new Safari is making sure your headaches don’t go away, adding new ones.
iOS7 was certainly a wakeup call for us, and as nice as the OS is, the browser was pretty terrible and a lot of the problems have been fixed in 1 and 2 point releases, but I think there are still one or two really big bugs that we’d like Apple to fix.
Brian: It just goes to show that you have to constantly, when developing for the web, speak into the issues that you talk about, you have to constantly remain on your toes.
Absolutely. Even if you don’t build any features you are still going to be working very hard, every new release is now work because there is a huge testing overhead and know that the key way requirements are so arduous, we are now working so hard on getting functional test automation in place across all the devices that we use, all the devices we support, because we simply don’t have the man power to do manual key way on all the devices that run on Android whenever a new version comes out. Google have got a lot better at providing early access to new Android versions, so that’s a big benefit that we didn’t use to have and I remember that with Honeycomb, you would actually have to buy a device in the hopes that you would get over-the-air Honeycomb update, because Google weren’t releasing any developer previews with Honeycomb, and they were actually just putting them out there in the wild and doing operator over-the-air updates and you just couldn’t predict whether you would get one or not, so we had customers that had an OS we didn’t have. But I think they got awful better at that and I think these days we can manage these upgrades much more effectively, but it certainly it’s a very high level of background work that goes into just keeping these apps up to date and working on evergreen browsers.
Brian's full question: One of the things you talked about was the lack of some of these prebuilt UI elements or interaction elements and stuff like that, so I was curious about your thoughts. There’s been a lot of talks about web components lately and how you see that affecting in the future your ability to be able to, say, plug-n-play elements that may exist now in native prebuilt components?
I think that’s going to be inevitable, that when you have a workable practical solution for components, I see a piece of web UI that we’ll see people producing reusable generic components which are more high level than the ones we have today, so we’ll see date pickers and calendars and maps and all kinds of rich components like this and it will be interesting to see you’ll go to a website and find the map component looks eerily similar to the map component on some completely unrelated website because they happen to both use the same web component. So I am looking forward to that because when that happens we can all stop worrying about everyone building their own gallery or everyone building their own map component and do more innovative or ingenious things.
Brian: Coming from even my background, I’ve been in and out of HTML and JavaScript for many years, I was doing then I moved into Flex then I moved back out for obvious reasons.
Good choice.
Brian's full question: But one of things that is interesting is just that the tooling in HTML and JavaScript. For instance, I go to Microsoft conferences and they think the tools stink, and for the most part I somewhat agree with them, but do you see any changes in tooling that might affect this being a little bit easier to do in the future?
I do and I agree, I remember the last time I was a Microsoft developer was in 2001, so I haven’t been in that ecosystem for a very long time, but I still remember Visual Studio being the best IDE ever used, and that was 12 years ago. So, I think a lot of web tools are very, very good and very innovative and some of the stuff that is now coming out, like Brackets by Adobe, for example, is an excellent project, I saw a demo yesterday, some really amazing functionality which you just think if you can harness that properly into your workflow it’s just going to save you so much time. But I think we are still just getting there, it’s taking a very long time to get there in terms of developer tooling, just in terms of code authoring and then in terms of debugging, we’re getting tools in Chrome and in Firefox and in Safari that allow us to discover problems we never knew we had.
We’ve had memory leaks, we had really slow allowance which we were never able to inspect before and suddenly we have the capability to do that kind of stuff. And Google has just started to introduce the tracing tools into the proper dev tools and I think that’s the next step, the next level of sophistication which comes in the practice of web debugging. So, I think that gets better and better and better, but it certainly had a long way to go, so I think we just now are getting to a point where we can say we have a decent level of sophistication to the tools that we have to use.
Brian: Yes, I totally agree with you. So, anyway, that was the last of my questions, I want to thank you for your time and thanks for chatting, this was very informative.
Cheers. Thanks, Brian.