 So welcome to Sapient. We're really proud to sponsor you guys and support this sort of event, and we feel really strongly as an organization that these sorts of things are ways that we can contribute back to the community, because we use open source all the time, and we see that this is a valuable way to support you. So I'm going to talk about architecting for the enterprise. And this is a conversation I regularly have not with just people who love the browser, but with people who love things that don't belong in the browser like Java, or .NET, or Python, or Ruby, or those sorts of things. So my name is Thomas Cowell. I'm the head of interactive development. I am also known as the dark lord of interactive development. I usually cause problems on projects and annoy people, joking aside, I'm here to support people in their projects and help them understand how technology enhances people's experiences, and how we can make technology an enabler as opposed to a disabler for people. To start off with, right. Everyone knows the web, right? Started 20 years ago? Sorry? Actually, I can test that Tims Burner-Lee started the web 25 years ago. So I actually want to go back a bit further, because if you look at the 60s, Tims Burner-Lee wouldn't have invented the web if we hadn't had packet switching in the 60s, if we had not had the dawn of networking computing with all these crazy network things that they figured out. TCIP, 82, right? The dawn of the web. AOL, bulletin boards, all those sorts of things. If anyone's old enough to remember, you got everything in text, and it was dial up, and it was really fun. Well, maybe. I'm assuming the images of naked things wasn't that good. So moving on, right? 84, DNS, first web page in 91. Mosaic, the first browser, right? Open source browser, pseudo open source browser, for multiple platforms. 95, Flash, oh my god, it's that old. 99, IE5, HTML4, in 2000, right? It's not that long ago we had HTML kind of standardized. And IE6. So that's 2000, late 90s 2000, that's what we saw, right? A web that was very textual, slightly image based, kind of clunky, bit slow, dial up was amazing. Moving on, IE6 and Windows XP, right? 2001, Facebook 2004, Firefox 2005. Ajax was really kind of driven to the marketplace by Ruby on Rails and frameworks like that. In 2006, 2008, HTML5, first public draft. I was working in orange labs at the time, when it was kind of starting to be ratified. And I remember the excitement around the fact that we could figure out how to do local storage and other things that were not there in browsers that would enable us to do more interesting things, right? 2013, only 153 companies, or Fortune 500 companies, are actually doing HTML5. This year, the glorious day will come upon us, April 8th, where IE6 will no longer be officially supported by Microsoft in the enterprise, right? Five years ago, it was no longer officially supported in the consumer market. It is not dead yet, it will still haunt us. So why am I telling you all of this? Because, oh my God, they have legacy in their systems. This is not something that's gonna, we're gonna escape from. Every enterprise organization has some sort of man drowning in the back corner, hiding away, disturbing us. Actually, I wanted to call my talk how to bring the best in breed solutions to a technically conservative marketplace. But that was a little too long-winded, right? So we're gonna actually look to how we can get into the future. Going back to this map, right? I want us to focus on Chrome. Because Chrome is actually a pivot point where HTML5 and all these other things have actually really shifted in the marketplace. Look at all this history, right? Going back, there's a huge amount of history that we've had coming up. There's 10 years of nothing, right? We landed on HTML4. Yeah, CSS got updated to point one, 2.1 at some stage along the way. But it's only when we got to Chrome and that sort of push around Firefox, Chrome really pushing the marketplace and driving innovation and that we started seeing things to rapidly change. So what's everything built on now, right? Well, it should be built on HTML5. It should be built on good quality CSS3 and it should be built on really high quality JS frameworks. And what does that look like, right? So we've got thin clients, thick servers which do get, pull only. The original browsers, you know? You have to go to somewhere to get something back in return. We have thickish clients, thick servers which have some sort of maybe they do push but mostly they're doing gets. We have thick clients with thinish servers depending who writes them. And then there's an opportunity to natural push where we can do things like socket IO and those sorts of things as well. And why am I telling you this? Because I want you to understand that there's these things like low complexity pages which are things that are very kind of static and they have been around for a really long time that are actually quite useful and quite poignant today and do good things. Progressively enhanced page. I want to give you guys a sort of language that I'm thinking about things in, right? Progressively enhanced pages. This is like e-commerce solutions, right? There are a ton of e-commerce sites out there will actually fall into this category where they render up a really high quality static HTML page. Well, some may argue the quality of the HTML but they render out a really good HTML page that has a good, you know, well designed CSS that has this great sort of interaction and Ajax and all these sorts of things that make people feel like they're getting this really responsive experience. And then we have single page applications, right? These are really heavy transactions, lots of workflow. They tend to have this natural app-like experience. You know, you do these things and things happen immediately. You don't normally get that on the browser. And it lends itself naturally to push. So this is an opportunity where you can kind of push things to clients. You can push things to people and they will see a context and an environment change based on things that are external to them, interactions that occur outside of their control. Right? So we're talking about the enterprise, right? So what are some of the things? What are their constraints? What are the things that, well, don't generally keep them up at night but things that generally prevent them from getting their bonuses or make their jobs much harder? So SEO, really big one, right? So how do I get my widgets to be number one on Google so that someone comes to my site and buys it from me and doesn't buy it from my competitor? Maintainability, those are big things, right? These platforms can live for five to 10 years so they need to be able to maintain them. They need to have a process and an architecture that allows for it. The complexity of the system. So we as an organization have launched Marks and Spencer's recently and it has 25 disparate applications that exist that we touch. There is, you know, 40,000 transactions that occur sort of every day. So there's huge systems with huge bits of componentry that fit together. Platform support. Somebody in IT has decided you are using this CMS and this is the CMS we've signed off on. Perceive performance, right? So this is a, there's kind of this divide and I'm gonna go a little hobby horse on this. Performance is not necessarily what you measure, right? Performance is also what you perceive. So if you send a webpage down to somebody and it looks pretty within a second, their perception of that page is that, oh, it rendered really quickly. Even if all the functionality isn't there or if you give them a clue, like Gmail when you load it up, gives you a clue that something cool or technical or interesting is happening. And so you've got this perception that, oh, they're doing something really important and big. But Gmail actually might have a measured performance of, oh yeah, it initially loads in half a second and five seconds later you can use it. Accessibility. Everyone loves to hate accessibility but it's important because actually it helps SEO and it helps people who have less opportunity to be visual or understand or do things in the way that we understand and do things to have access to flights or shoes or sandwiches or anything else they may wanna get to. Fragmentation of browsers, right? Today, when I was working at T-Mobile years ago, we tested for 50 different devices and browsers. Today it's getting way worse, right? So there's a huge number of platforms you have to support and it's gonna get worse. Google, Google Glasses, Kiosks, all these sorts of wearable technology that are gonna introduce new things that's gonna make it even worse. Browser support, right? Next thing. How many of you guys actually still have to support IE6? IE7? Don't be ashamed. Really, honestly, don't be ashamed. Right? A couple of weeks ago, I had someone talking to me about IE6. I went and cried afterwards. It's still there because actually there are some customers that haven't, you know, customers of our customers who don't actually know they can buy new computers or upgrade their computers. So they're technically trapped and we have to decide, are we gonna cater for them or are we just gonna treat them like the technically unsophisticated people they are and ignore them. Emerging technology. So this thing about Google Glasses, all these little things that are coming into the marketplace. Somehow you have to be able to address this as well because you're a big organization. You have to appear to be accessible to everyone. My favorite responsive adaptive web. Great, whoever loves it, whatever. It's always gonna be there. It's a big conversation now with the enterprise. And a technical focus of the developers. So that's my polite way of saying there are some people who think Java is more important than good quality JavaScript. There are some people who don't actually care that it looks good in the browser. There are some people who don't actually think that it's important that people have a great experience. And that's not because they're as awesome as us or lacking in any way, it's simply because their focus is on algorithms or things that excite them and they're not like us. Oh yeah, by the way, they have legacy systems. So what does this mean? So let's kind of go through a few couple good quality architectural principles that will help us continue the rest of this conversation. We want modular components, right? We don't want 10,000 lines of spaghetti. We want nice, discrete units of code that are self-contained and they make sense. And someone new to the team can understand it within three days as opposed to six months. We want decoupled interactions. Things like where a component says, hey, I'm ready to do something. And other components, if they don't care, just go yeah, whatever. And the one that goes, oh yeah, oh yeah, I'm interested in that. So there are these sorts of interactions where things naturally occur where there's not this dependency that that interaction has to be answered. And dependency management. That's probably the hardest thing to do where you have modules that load modules that load modules that load modules and it becomes a little meta. I once went to a model village. There was a model village inside the model village that was inside the model village that was inside the model village. And then I decided I should go good to the pub. So this is kind of to help frame the rest of the conversation, right? So these are all the principles that we all agree are great things that we should be doing and they are valuable, right? This is the way we wanna code. So going back to the original thing about static pages, this is Sapient Nitro's website. This is probably the most static asset that Sapient owns to date in the digital space, right? It is a flat HTML page. Oh, by the way, they have a carousel. How forward thinking, right? I'm not supposed to be discrediting it, but it is like that's all that's there, right? That's the only interactions. There's the only kind of cool things that happen. And it's really valuable because actually what is somebody interested when they come to find out about Sapient as an organization? They want a blurb. They want a bit of text. They want the carousel because it gives them a few things they can look at and it moves around. So, static HTMLs. Where do we wanna use this technology? Carousel, where? Informative sites which don't change that often. I've built websites for people. They're static HTML, why? Because they're only gonna change it once every year. And I don't have to maintain a CMS. And I don't want someone to hack the CMS. And I don't have to think about those things. And the hosting costs and all that, right? This is a really kind of, there is value in this. And this is where things, we may not honestly find exciting, but there's value because it gets technology, it gets things out there. And it addresses issues like SEO. Makes the content available. People can go and find out about it. The next one is, actually I'm gonna show you the site. So this is a site that, can I click? Sapient's done for Harley Davidson. And this is an interactive experience. So Harley is an organization. Have you guys ever ridden a Harley? Or sat in that on a Harley with the engine running? You have. How did you feel? I nearly fell asleep. So you're the antithesis of the sort of experience that they're talking about. Thank you. Well, I enjoy your honesty. So actually, I have to confess, I am actually gonna go get my motorcycle license because I've sat on a Harley. And I have the hunger now to ride a motorcycle, right? So there's this experience that Harley has is with their customers. Is it anyone who kind of goes on the site? There's no, there's music and motorcycle noises and that sort of stuff happening. But anyone who goes on the site gets to find this experience. Like, what is a Harley? What is the sort of experience you've got? And actually it's this engaging thing that you could never get by having a static HTML page, right? It's like, how boring would that be? I was like, oh yeah, the motorcycle. It's a pretty picture. Great. People wanna see it. They wanna know about it, right? So that we have these things here where you can click on stuff, you can interact, you can engage, you can find out more, you can explore the bike. And if the music was there, it's a little more compelling. Let's close that one off, right. So, and next page. So progressively enhanced pages, right? So that's what I mean by progressively enhanced page. That's probably blurring the boundaries a bit with single page application if we're being really technical. But it's things like you want to have, you know, some transactions, you wanna have support. You need, SEO is super important, right? Let's remember, SEO makes or breaks most e-commerce providers. It's the one thing that they actually lose sleep over. And the one thing that they wind up about. And actually, James, thank you for your talk last week. Cause it was really, if you guys, I'd recommend watching it because it's really highlights some of the challenges when you're trying to integrate a single page application framework in with an existing site where actually SEO is a huge requirement and how do you kind of address it and how do you meet those challenges? And the other thing is linger, right? So how long does somebody spend on a page, right? So I've gone to, I like cats.com and I'm clicking through things and I might spend 30 seconds, maybe a minute on there and I've seen 10 cats, right? And I'm happy and I can leave. And those sorts of sites are where actually this is valuable because you serve something up quickly and they go. And the creative is not app-like, right? It's really important, this metaphor of the app and it's hitting us in the browser so we want to make sure we keep that in mind as we move forward, right? So the next example is another Harley one. So you guys will please to know this is built in Ember. I'm told by my colleagues in Toronto. It's, I'm not going to open it up cause it actually takes a while to run but you can actually go through. For me, it takes a while to run cause the, do you want me to show it? Yeah, let's see, yeah. Right, let's find out how fast it is. Oops. Oh, no, I did it wrong. The click doesn't work. The click doesn't work. So let's do that. I just asked, I was surprised when I saw the lack of IE and disappointed secretly. But can I ask, how many of you need more startups? Raise your hands if you're working with a corporate planner, okay? And so a good number of you are working with a corporate planner and not working with IE-6 or more, seven, IE-7, so that's good. Can I ask, how many are working with education bodies or civil service or anything like that? Kind of are. Yeah. Anybody for us, IE-7, not some IE-6? Six is kind of, six we know is clearly dead. IE-7 is still lingering around like a bad smell. So this is the bike builder, right? You know, it's kind of a, it's a nice way to kind of play with it and see it. You can do fun things like swapping out your wheels. Takes a little while, because the network's a bit slow. I thought it was because it was Canadian. No, it's not because it's Canadian. Please do not insult Canadians. I will have to throw you out of the building. Americans these days, hey? So, you know, this is a good sort of example of, you know, you need to build a configurator for a car. Yeah, why not build it in a single-page application, right? Why not? Because there's a lot of interactions, there's a lot of things you need to do and it actually makes sense to do it there. And, magically going back. Right, so, highly interactive and transactional. I've found that actually single-page application frameworks are easiest to implement behind authentication, where SEO is not a problem. I've not seen a huge number of solutions where it addresses the SEO in a really kind of strong and a relevant way and maybe we're just waiting for Google to catch up. So, things like Gmail, Facebook timeline, training platforms, those sorts of things are actually where it's useful and valuable. Right, so, technical challenges, right? How do we address things like analytics and measuring, right? Do you do it in the controller? Do you do it somewhere else? Content management. So, right now I'm working with a client and they've said, oh yeah, great, you can do a single-page application but we need to be able to control it from a CMS, right? Because we need people who aren't technical to change labels and move things around on the page and make life difficult for you because they're gonna break something. They're gonna, you know, they need to be able to do stuff, seamless management and deployment. So, how do you address that as well? You can wrap up an application and plunk it somebody but how does it fit with the rest of the system? How do you make sure it ties back to all the other APIs? That everything kind of works as a whole. Authentic, coming back to authentication, right? How many of you guys have seen pop-up login dialogues on a standard port 80 page? Right, did it go back to a 443 or were they clear text sending your password and username back to the server, right? This is another thing we have to think about when you're trying to do a single-page framework because actually these are sorts of things that you may not think about when you're development because it's safe, it's secure, it's sane, you know? Nobody's gonna see it because I'm on my computer but as soon as you get into the bad world somebody is gonna go and discover that you've left someone's credentials in the clear and buy a whole pile of kittens in diapers and send them to someone else. I like tables, my clients like tables because it helps them understand things. So here's a quick table to show, right? And really I'm just gonna give you an overview because when I put up the slides you'll be able to review this as well. So about technical complexity, what is the initial page? SEO, performance, total cost of ownership, accessibility, responsive adaptive, dwell time, is it app-like, how much transactions? Do we need to support legacy browsers? Complexity of the system, can business logic exist in the client, right? That's another big challenge as well, right? Because somebody needs to be able to control that when you make one plus one equal three that it always equals three and it doesn't equal two. And then the server interactions as well. And then across the other side is just the three different choices we have and it's just trying to lay it out in a way that may be not clear to people but it helps give an understanding and a framework of making decisions about actually, like when is the right time to use these technologies? So here's the secret. That's my daughter, isn't she pretty? Be smart and flexible. Choose technology for the right purpose. And also this is a reminder, we're already really skilled at static HTML pages and progressive enhanced pages. This is something that the whole world knows how to do. Even the enterprise guys know how to do it in their sleep. Everyone knows how to do it. But we need to make a place for single page frameworks, right? It needs to be application like experiences. It's easiest if we do it behind authentication where all those kind of things that will fluster clients and get them excited and terrified and eventually Google one day will be able to do this but not yet. Configurators, highly interactive, transactional, right? And also where you've got a lot of JSON APIs, right? So if you have a mobile service that somebody's building, you could probably do a single page framework site on the back of it because you've already got these great services that you can interact with. And the other one is, I think this is a real kind of trick is when do you gonna do a hybrid approach, right? So you've made your great Ember application. It's amazing, everyone loves it. People are handing you money for being awesome. They're coming and signing up to your service. You're making lots of money. But there's gonna be a time when actually having a static page or a progressively enhanced page might make sense, right? And this is, I think this hybrid approach is something that will address some of those things. So the client I'm talking to you right now about this approach is login, right? Why not have it on its own page? It gets rid of all the security risk. Yeah, and then you load up. It's great, it saves all those problems. Google's doing it if you try to log into Gmail. Things like, where are we going? Privacy, right? I'm changing my privacy settings. I don't want something else knowing that or interfering with it or plugging in or something else, great. There's terms of service. Why the hell would you put that in your frame, your application? Why not just have it on a page where you can leave it and then someone in legal can edit it whenever they please? Really sort of things that are not core parts of your framework, those are real good opportunities for you to go, why should I build it in? It's gonna be a lot simpler if I just make it a page and then the intern can do it or somebody else can do it or someone illegal can do it. So before I close, this is beautiful glacier. Where is it? Somewhere in Alaska, I believe. Sometimes it feels like glaciers move faster than our clients, right? Sometimes they don't get technology. Sometimes they just, they're just, oh my goodness, this is awesome. Why can't you do it? And you're going, I don't get it. Sometimes legacy makes it interesting. Does anyone spot the funny button on this? Come on, shut it out. Don't care, right? Who put this into a machine, right? That's so cool, right? That somebody had the technical savvy to put, I don't care, as the response to something that comes up. And there are things, there are really interesting things that are in the legacy, in the environment. I worked with a guy who told me, I love IE6, right? Just when IE6 was in the pure peak of its hatred, I love IE6 because it makes me a better developer. Because I write this amazing code that is so solid that it can work anywhere. And that sort of attitude kind of really struck me as, actually there is some value in that. There is some kind of interest in it that makes it exciting and interesting. And yeah, it might be painful and you might want to poke your eyes out and you might want to lie down. But there are some real opportunities to kind of show your technical prowess and do interesting things. Thanking you. So any questions? Oh, go for it. Is it going to be an insult? You know. No, no, no. I love that one. So the question is, in my Apple free time, I wonder things and one of the things I wonder is, when do we start to see this big take off of single page applications in London in particular, in selfish? The question I have is, since I'm not out there selling, especially in the corporate world, what I'm wondering is, when you go out there, is it you selling some of the page applications? Because you think that the sex appeal cool factor will keep people excited or are they asking for them? And do you see a turning point where the demand picks up? That's actually a really good question. So I think, I said this earlier to someone who I was talking to about what my talk was going to be about. And actually London can be very technically conservative, my colleagues in the US have been doing single page framework stuff for the last couple of years. So the Harley-Davidson configurator, there's a few other things that they've done which are quite progressive and moving on. So this is a marketplace and because I also, we work with a lot of financial service clients, there's also an extra layer of conservatism with them. Which is, yeah, we know static pages. Yeah, we know progressively enhanced pages but we don't know this new fancy stuff that's been around for five or 10 years. We don't trust it. So there's this education you have to bring to these people because they're not necessarily ready for it. And there are opportunities where you get the right people in the room and it just kind of happens. So the client that we're working with, so the other, one step back. So we as an organization tend to sell a lot of Adobe CQ CMS. They're one of our core partners that we work with. And what I've heard is in CQ 6, which is in beta at the moment and due to be released in May, is actually gonna natively support Angular. So there's this, all of a sudden, there's this groundswell of interest because, hold a second, a big huge organization like Adobe has said, yeah, you can use Angular. We support this. This is something that you guys should sign up to as well. So there, I think there'll be a real shift in the next sort of year because somebody like CQ is actually changing the perspective in the marketplace. So this client that we've been talking to, actually it's a much easier conversation to say, by the way, it's gonna be in CQ. And they're going, oh, okay. So it's not just my credibility. It's another person's credibility as well that's backing it up. I will ask no more questions but then we just do a follow up question, which is, so when, I guess there's even HTML4 really. Oh, back in the days. We started to have new features that are available, that people who were willing to pay what was considered a big premium to have that interactivity and that cool effect. They would typically be in high brand, well, less conservative but high brand sites. It was retail. It wasn't your back office application, right? And in yet, in some cases, I think there could be arguments made that there is a question you don't have to worry about, SEO when you're sitting behind the firewall and doing internal apps. Or any of your buyers are you selling or are they talking about internally is it all this retail? So, partly it's the business that I work with is much more sort of consumer facing. I know that some of my colleagues who work in global markets have actually sold single page framework stuff as trading platforms, right? So there is opportunity behind the scenes and those sorts of things to have that capability there. I think it's more just, I think the couple of messages that I want you guys to get is, yes, you can do it. You just gotta pick the fight, right? Cause there's gonna be, there are opportunities to do it. But doing it on, you know, Marks and Spencer's homepage is probably not the right battle to have today. Doing it on, you know, some sort of tool that's sitting in the site where you're picking your prettiest dress might be the right thing to do it or, you know, configuring the inside of your home or where that functionality kind of makes sense is the right way. And actually, I think a lot of these organizations are open to it as long as it's the right thing for them and it's not, it's like, it's small and it's contained and it's safe because it's not gonna ruin their entire business. It's something that they can work with. And if it fails, it's easy to fall back to something else. Yes? It's difficult to create single page apps that work for a broad audience. Yes? So the risk there is really high because if you have a massive consumer market and everyone is using IE 6.2, you know, Android browsers, then it's really hard to create a single page app that works that it still gets changed. But I think to that point as well, the two banking clients I've been talking to in the last month that we have, they've actually both said, oh yeah, we're thinking of deploying Chrome in our business, right? And this is like, well, hold a second. I thought you guys all used IE. And it's, even within these conservative organizations, they're seeing other platforms as an opportunity to help them progress and move on and address their businesses as well and not be tied to, you know, was it the ActiveX controls when IE 6 was popular? Terrible things like this that embedded in your browser, right? So there's, I think there's even a shift in the corporate marketplace as well because they're trying to comply with IE policy but they need to, you know, things are moving so quickly that they need to offer their staff something that gives them an experience that matches their expectations from home. Yes? It's your big question. Chrome Native, so he's asking about Chrome Native clients. So you're talking the sodium chloride ones, the NACL ones. Yeah, so like a kind of- So you're talking about Java plugins in the browser sort of experience, but for Chrome? I was talking about the CCL. Yeah, yeah, so this native experience, where you write an application, you then loads in the browser, it uses sort of APIs that are designed for the native Chrome client. So it basically is going to play down? Yeah. I think that's great if I was writing a trading platform for a bank because they would control their entire infrastructure. I think for, unfortunately, most people to ask them to download and install something, you know, Apple's managed to frighten a lot of people off of installing something from their browser. Yeah, so it treats it like that, but I think there's some security things and other stuff where it's not necessarily there. And Chrome has 30% of the marketplace. It doesn't have 100%. I think we can, I think it can be used. I just think from the general consumer point of view, it's not going to get the same uptake. I look at it as a sort of, I think actually that's more suited to Chrome OS and that's where the big uptake will be because they open the doors for themselves to have other sorts of things that run within their environment and it will really kind of, I think it will propel Chrome OS more than it will propel native Chrome clients in the browser. Any other questions? Go on. So I found that Ember and Angular and React are quite good for prototype. Do you think that's a way to sneak these sorts of tools into the conversation? So using frameworks as a single-page frameworks as a way of sneaking stuff into the, using it as a prototype to sneak it into the business. Yeah, when you're in the prototyping phase of some product, you might, you might choose to use a framework and they might see some stuff they didn't expect, cool stuff they didn't expect. Yeah, so I would never confirm or deny that but go for it, like honestly, like if you have an opportunity to prototype something because you know it's going to be thrown away, right? I love this. So let's do a prototype. Oh, by the way, can you make a production ready tomorrow? Right, so why not, right? So if it addresses all the needs, yeah, prototyping is an amazing place to show new technology off because clients aren't going to be frightened by it and they can go, by the way, I did this prototype and that, it's a great opportunity. I was going to develop a new team to create a prototype quickly. They can introduce a framework that has some stability, see? Yeah. And so whereas I think that it's a great way to build your skills, I don't know if you want to sneak it under the radar in that kind of way so you need to be a little bit careful about that. So to my colleagues point, I'll repeat it for the audience that we'll be listening outside is. So basically, I think what James is trying to say is you need to have a little rigor in your business around the sorts of frameworks you use for prototyping. So you need to decide, are you an Angular shop? Are you an Ember shop? Are you a backbone shop? Is that something that you want to standardize on? Great. Then use that for prototyping because it will be safe from our client perspective but anyone else in the business can pick it up and destroy your prototype afterwards. I think that, is that what you were pretty much getting at? Yeah. Yeah. So yeah, it's, I've seen stuff, people do things in prototypes and it's just like, yeah, great. Now we have to support another thing on top of it. But is it true that the corporates are already adopting standards in terms of single-page applications right there? Or is that still... I think that's still early days. Yeah. I think you can frame a lot of that. So, any more questions? The corporates care about client-based stuff. I work with small-scale business, sign businesses and tell them about technologies. They use them, they glaze them up. You know, okay? No. You know, how much is it going to cost me? Where does it get ghosted? What is it going to do on a one-to-one basis? Don't care. Whether it's rails and back, whether it's amber in the front or whether it's static, you don't care. As long as it does what they're asking you to do on the budget you're asking them to do in court. So, to your point, right? Why do you cooperate with them? So, I think to your point, right? So, just to repeat is, you're saying that, you know, small-medium businesses don't care what technology is as long as it's on time on budget, right? Is that correct? That's my question. Yeah. So, I think with corporates, the problem is you get some guy in an anorak who sits in the IT department who is interested in technology who will then want to have that conversation because he wants to have his job, right? So, I think with large organizations and corporations you'll have people who are interested. One of my colleagues here, he has this bingo game he plays with businesses where he actually tries to find the guy who's going to make ask all the difficult questions about everything we're doing to try to find out where the holes are in it. And there are people in corporations who exist like that because they have done web development at some stage or they've done things that will mean they have some sort of technical expertise whether that's dangerous or not. And to be fair, I think, yeah, those people annoy a lot of me, but there are also- They're valuable. No, no, but there's a few reasons, right? Even we have, you know, licensed arrangements so they have to use these technology bases and there may be, you know, HR concerns in terms of the flexibility of moving resources around the organization effectively. It's a problem that only makes sense for a big business. And then these people you've mentioned are the ones that you really come into, that's the word that you spend, lose all your energy, is these people who- But these people actually make you sharp as well, right? So some of the best conversations I've had with people are the guy who's going and goes, well, I don't agree with your accessibility statement and these three lines I disagree with and then you spend the next three weeks arguing it out. And actually, I find these people as painful as they are to deal with, actually incredibly valuable because they help make your craft better. Well, yeah, but that's why they're paying money to have those conversations, right? So I know that, yeah, they stop you things done, but most small clients, like I have a small business that I'm winding up at the moment and your experience is exactly them. They go, what, technology, what? No, no, just get it done, right? And that generally is, most people don't care about those sorts of things. I understand that if you're in a conference and you're saying, okay, we're going to choose back-end technology has to be hosted somewhere. It has to run on someone's machine that's been paid for. We're going to pick where it's going to be done now, if you have those two as opposed to an open source framework. That's going to, but Edward and Angela are just HTML, JavaScript and CSS, so lots of difference to a call. Yeah, but clients, I think, so two years ago I overheard a conversation with one of our banking clients and they're going, what's this sizzle framework in your page, right? Because they have huge security concerns, right? Banks are terrified that someone's going to break in and they're asking a question about sizzle, which is a core component of jQuery because they didn't understand and it's, so in certain circumstances, those sorts of things they're going to be really concerned about because they may not understand it or they may have considerations for the business, like is this security? Is this going to create problems for us? Is this going to open risks? Or is this going to enable cross-site scripting? All these sorts of challenges that they have to walk down because actually a bank, if a bank loses my money, who am I going to blame, the bank, right? And I'm going to be really angry because it's my effing money that you've lost, right? So in that circumstance, they're really paranoid that the things that are deployed are actually safe for them to deploy and match the requirements that they have from a business to protect their own interests and to protect us as customers. Yeah. I think in-house developers, they may not know about JavaScript or anything. Yeah. So they worry. Yeah, big organizations, to Denise's point, is big organizations. You don't necessarily, when you hand over stuff, you may not determine the quality of developer that they hire. You know, in a lot of, you know, what sapient builds, gets handed over to a team of developers and we don't necessarily know the quality of people that are there or the technical competency of the people they're going to hire. So we have to, you know, consider those things as well. It's a therapist, and I'm not a therapist, let's say, we're a therapist. Yeah. I would say that, you know, there's probably a 50-50 split in terms of people who are kind of wedges who are just going to annoy this shit out of you and kind of slow you down and that's, they don't see that as a driver, that's effectively what they're doing. And then a 50%, it's actually a fairly legitimate reason that are maybe not invisible to you at that point. Yeah. I would say try to find the good reasons because it can drive you crazy. If you sit there, you're frustrated because you feel like this guy that I'm talking to is maybe, he may be, but actually there probably is some good reasons in there too and if you could just focus and try to figure those out, at least you don't feel bad about it. They are. You can go drinking with them afterwards as well. What's that? You can go drinking with them afterwards. Yeah. They usually have budgets for that. Exactly. If you're really lucky, that person will come along after you ship the product and then ask you to explain to justify every decision you've made in it. Yeah. And then you know that next time you better have those answers ready for that next. Yeah. First you have to hand over to him. Yeah. Can I have that one? The observation about S&E and the relationship to the technology. So in my experience with S&E, it's fair enough to say that they don't really care about whether it's looking at dot net jar group or whatever on the back end. But what they do have a focus on are the KPIs on the front end and in particular social sharing, S&E, et cetera. So they may not be aware or have an understanding of whether you're writing a group of people through your site, a WordPress site, or a single-page app. If you write something in a single-page app framework, it doesn't support S&E, it doesn't support social sharing. They'll pick up through their stats. So you might find that your technology decisions actually come in at a different point and at a certain level of life. And so it kind of brings in a loop back on that technology twice. So you want to ask what is actually important to you in your kind of when you go to recommend technology? Because in my experience, if you don't implement these key KPIs directly within these application frameworks, then it could actually come back and bite you further down the project or kind of like part project or further on S&E in part or support what it is that you feel. And so in my experience, they do have a technology understanding that it's probably more about the bottom line rather than what it is that you're actually building or the particular language that you're writing or what you're doing. And that comes down to, does it match your requirements? Look up and don't know. Yeah, but I can guarantee the S&E S&E could be interested in S&E and social-sharing for people to decide. And if that's a result, then they will find a way to sit there and provide us or not because they'll want to make sure that people find it. It depends on what their business is, but every S&E that I've worked with has always asked, will this hit a S&E on the social requirement? And so that can be written in anything. And that can see on what happens. That's my experience. And I suggest, just based on time, that we stop here. This conversation, obviously, is picked up again in the pub. So big hand for Tom. Right. Thank you.