 Hei. Yn y bwysig o'r sgwrdd o'r cwmhysgfaethau a'r llog ar gynllun. Mae wedi rhoi bod eich rhai yn oed i Rhyw Rhyw Rhaidion, ac efallai eich bod yn ystod o'u mynd i mi. Yn Rhaidion yw ymddangos ar gyfer y cyfrifodau yn Llywodraeth Gwmysgfaeth, ac mae'r cyfrifodau yn ymddangos ar gyfer Llywodraeth Gwmysgfaeth? Llywodraeth Gwmysgfaeth? Llywodraeth Gwmysgfaeth. Ryan wasnt directly involved in this project, but this is a partnership project that we did with Commerce Guys. Ryan may have lots of questions during this. I've got lots to talk about, lots to tell you, but Ryan may have questions coming through. We'll have lots of time for questions at the end from anyone. I also feel comfortable not having been involved in the project to say that it's pretty epic, Rich. Just the sheer depth of functionality that we just saw is pretty impressive. Rich, I don't know your title at ICOS, other than owner. I pull in the strings. Rich has been a long time contributor to Drupal Commerce with his team. We've had a great partnership for the last several years, maybe since 2010, I'm not sure. Having supportive partners like ICOS is essential to the development of Drupal Commerce and the Commerce Ecosystem. Of course, to Commerce Guys as a company. Really value you guys and appreciate what you've done, especially with flagship sites like Lush. Thank you very much. The first thing about Lush that was brilliant is that let's talk about it. You do so many of these sites and it has to be behind closed doors. You're not really allowed to talk about how you've gone about it. I'm sure everyone has experienced that. With Lush, they're a pretty open company and they're very happy for us to talk about the project. But if you've never heard of them, let me just check that first. Who's actually heard of Lush? Who's outside of the UK? I know Miles uses the lip scrab. Lush Digital would be working with. They're a high street store, a very big store in the UK. They're an ethical, natural handmade cosmetics company. In the UK, they're sort of known as the bath bomb people. That's their key product that everyone knows them for. Certainly, when you go past one of their stores, you can smell it a mile away. The combination of smells coming out of there. But is anyone we got involved that we understood a little bit more about this company and how much more there was to them than just this sort of bath bomb store? They're based out of the UK, but they do actually have, well, at the time I wrote this slide, 900 plus stores in 50 different countries around the world. And a massive turnover, which has far exceeded what we expected for what we perceived that company to be. So there's a more than $600 million turnover, and I'm sure that number's out of date as well. So we got involved with Lush in a joint pitch with Commerce Guys. And what they were trying to do, what they presented to us, what their vision was, what they were trying to achieve with their website. And it was very much about what they've called, is now an industry term, content driven commerce. And the idea of this, it's about mixing selling products with the stories that go behind them. So gone are the days where you build a brochure website and then strap a commerce site onto the side of it. This is now, what we're seeing in the market is all about merging these things together, making the stories that sell the products. So people don't just want to see lists of products anymore and press add to cart. They want to know a bit the background, they want to know a bit more about what's going on. Now with Lush, they're, as I say, they're a very ethical company. They do a lot of charity work. They have people out in the world looking for ingredients, ethically sourcing ingredients and stuff like that. And smoking charity pot. Yep. So they have got people out there and they've got good stories. They've got every ingredient that goes into these products, has a story that goes behind it about where it might have come from, maybe the farmers or the fair trade people that have been working with it. So this is a perfect brand to be able to do this storytelling kind of e-commerce. So what they were looking for was a way to merge together their website stories and their e-commerce. And that's how we were able to win the pitch really with Drupal and Drupal Commerce because they were looking at the time at the big name e-commerce branders. But what we were able to offer was the combination of content and commerce within one platform because Drupal Commerce being a set of modules that adds on to Drupal. Drupal has all the community, content management and everything else and the extensibility. So that gave us a real edge being able to look at it that way. The other thing was of course being open source, it appealed to their ethics and the way the company operates. So that was another big advantage for us. So this site in particular wasn't a one man show by any means. We were working with Commerce Guys from the beginning. We also were working with a design agency called Method who are a London based agency. So they did all of the visual design and interaction work. And then of course we were working with the lush digital team in-house, their own developers and their own design team. What I wanted to show you today, I want to break down this site because I have the opportunity to tell you a little bit more about what's under the hood. So we're going to do a bit of a deconstruction today. And I want to talk to you about the different elements of how we built the site. How we used a pattern guide or a style guide, depending on what the trendy term is at the moment. How we built some particularly complex page layouts and the techniques we used. How we did the search and catalogue pages using Apache Solar. And how we integrated lots of different third party systems to inter-Drupal to provide the best combination of features. And then finally, a little bit about performance. Because as you can imagine, e-commerce sites need to perform. They need to be fast. And this particular one is under very high demand. There's lots of traffic, lots of customers. So I want to talk a little bit about how we address those sorts of performance issues. And Ryan, if you want me to elaborate on anything. I'll ask the hard questions. We've got some time to do that. So it was really important on this site that the design was done in collaboration with us. There's a live, what we did in the end was we developed a live pattern guide. This site needed to handle six break points. So it's incredibly detailed, responsive work. It wasn't so much about mobile, tablet, desktop. It was very much the design will switch depending on the size of the browser that you're looking at. And we knew this was going to be a massive amount of work to do. And we also knew that we had a lot of work to do on the Drupal side. And we couldn't really wait to get the Drupal stuff done and then start working on the theme like maybe traditionally would do. So we came up with this, we'd seen around people like Starbucks and they've got their star guides out there and we were inspired by this. And we decided to build a star guide for Lush outside of Drupal. We ended up using Jekyll. And what we were able to build was the designs were coming to us in the traditional way in Photoshop. And we were able to prototype those designs in Jekyll, develop the concepts, test out the interaction stuff before we were anywhere near Drupal. And Jekyll is only a recently familiar term to me. So I don't know if you want to elaborate on exactly what that is. So I guess Jekyll feels a bit like going back to old school. It's a templating language which you can compile into HTML. So it's fast iterative development and it compiles up. So what we were able to do here is build all the individual modules as in design modules of the site in this Jekyll system. And it meant we could do the cross browser testing early. It meant we could trial things and see how it's going to work. And because the designers needed to see the stuff, the timings of things and that sort of stuff. But the key thing that we did differently was that the people building this pattern guide were actual Drupal developers, iCos developers who knew what the sort of templates and the sort of markup that Drupal was going to end up needing. So we tried, sometimes you get a pattern guide and it's delivered by an external agency and you've just got to work with it. So the idea here was that we produced this style guide with sort of Drupal markup, markup that we knew was achievable in Drupal. So lots of extra divs in our classes. Lot of divs everywhere. But all class driven. And it meant that what we could actually do is compile the whole style guide and then copy it straight over to the theme. And we also were then able to take the individual raw HTML elements and put those into the theme as well. So it gave us this portability of the system to allow us to do this. The other massive benefit to this is that it's a permanent reference. So even though the project is now live, obviously it's in continuous evolution, so everything is still trialled through this style guide approach. And I've got some, I can do a little demo of this in a minute. I've just taken some stills so that when we upload the slides there's actually something there. Because the style guide itself is not actually public yet. So this just shows some different elements of the site. So the way we're looking at it is you don't design an entire page. You design a product element. And this is what a product looks like in this scenario. And this is what it looks like on the wish list. This is what it looks like in the cart. So every single piece of content looks different in different places. And what we do is we design those individual cases on their own. And then we're able to join all those things together later to make a complete page layout, which I'll come on to a little bit later. So I'm just going to switch over, he says. This is where it gets fun because I can't actually see what I'm doing. I'll have to stand up here. So this is, if I can find my mouse pointer. This is the style guide. All of the elements that make up the site are all independently built outside here. And we also use this as a QA tool. So you'll see these green and red little Drupal icons, which are basically part of our QA process to say this piece is done, this part is being reviewed, and so on. So if we go into, let's have a look. Trying to find, sorry, here we go. The module guide here. I'll ask as it's supposed to be local. There we go. Okay. So what we're looking here is, this screen resolution is really rather large, but each, this is what a product looks like in its featured mode, then a normal mode here. And as we scroll down, and we can see what it looks like when there are reviews. Sorry, I just realised because I'm not actually online. There are images here. But on the resolution of that screen, the particular image is almost transparent, unfortunately. There we go. And then the same thing, how that's displayed in the wish list. So if I try and grab the bottom of the browser, I'm trying to be able to resize the browser here. So if we move a little bit further back up again, let's just take this one for example, around, we can just see the responsive nature of the site. I think that's a good example actually. Let's come up here a little bit. So I can't show you the super wide resolutions because this screen isn't wide enough, but you'll see that it changes as we go to the small sizes, ready for mobile tablet landscape, tablet portrait. And then as we go to the full desktops and things flip around. So we were able to trial this stuff out. And each individual element that we built, let's go back to this. And did you find a particular base theme in Drupal was more suited to porting the CSS and HTML from your style guide into the Drupal theme? Well, actually, yeah, we did use Omega 4. But by the time we've done, there's so much work done outside in the style guide that I'm not sure how much Omega 4 did for us at that point. It ended up being quite custom. But the way we used the theme here, we had these rather complex page layouts. So if you saw in the video at the beginning, I'll show you another one in a minute. When you go into a product page, there's a ton of information about that product. So you first of all got the e-commerce element. Then you've got information about the ingredients that might be in it, any related news, related products, reviews, all this sort of stuff. And it ends up with quite a massive amount of content to render into one page. Now, we had some internal debate between all of us as to what method to use, whether to use panels or contexts or whatever. And in the end, we decided to use Drupal's built-in functionality of view modes. So normally, when you're building a site, you will see you've got two view modes. At the box, you've got your default view mode, which is your full page. And you've normally got a teaser. So what we decided to do here, really for mostly ease of understanding more than anything else, was we defined additional view modes for each of the methods of displaying the content. So we might have had a view mode for wish list and a view mode for product detail, a view mode for e-commerce mode, or something like that. And that allowed us to transfer that data that we had in that style guide, those templates that were HTML. We were able to use template suggestions to tell Drupal which of those patterns to use for any particular scenario. And there are other ways of doing this, but we found this way the most portable and understandable because it meant that when someone was looking at the page, they could see immediately it's not a ton of panels to configure. That one piece there is an individual rendering of that particular piece of content. And did you use Display Suite to define those view modes or just custom? Yeah, Display Suite was absolutely the way we would go for it. And in the end, we did a lot of configuration of Display Suite and then turned off the UI at the end. Because we needed really strict control on the markup, to achieve what we were trying to do with the style guide, the markup had to be spot on, and that was the whole point. So using something like Display Suite allowed us to do that. So this is an example of one of those pages. So this is a product detail page, and I hope it doesn't make you feel sick now moving around. So you've got ingredients directly underneath, and then you've got a story, badly cut by me there, unfortunately. And then we've got reviews underneath that, and then related content underneath that. Now all of those are different renderings and different display modes of the same piece of content. So what we've done there is using context to stack them on top of each other. And to take this a little bit further, when you start looking at this site and we break down the individual elements, what you're seeing here is those modules. Sorry, we keep using the word modules. In Drupal World, that's obviously something different. In the design world, they're referred to as design modules. So the individual component design pieces of the site here, you can see them. We just lifted them out there just for visualization purposes. And this one here, so that's showing an ingredient in that particular mode. And the way this design works, we've got three ingredients, but the first one had to be slightly bigger than the other two, and it's all this sort of high-detail design stuff that we had to meet these requirements for, and this method allowed us to do that. And another one here, we've got the different spa treatment shops, different spas they've got around the UK at the moment. So allowing us to open up those individual elements as well. And then taking it a little bit further, this is the dashboard page of the site. So once the customer's logged in, and here what we're able to do again is not only view modes on content, but also view modes on orders and things like that. So when you're looking at your list of order history, you can see them in one mode. And if you're looking at them in the dashboard mode, you want to see your most recent order, and so we just render it slightly differently. And again, we were able to use these view modes to reflect that functionality. So you bought a British nanny? That's right, yeah. So that was how we achieved our page layouts? What if you don't mind me asking, I don't know how familiar everyone in the room is, but in Drupal commerce you have product data from your product display. And so in here, I'm not actually sure if you've been using a product display node type, if you're just pulling that all in directly via context. How did you actually build up a product page and then associate all of the different ingredients and reviews and whatnot with that product? So there is a product display. So the product entity itself is the part that you need to fulfil the order. So that's the SKU, the short description, the price. And everything else is actually in a product display content type. We actually had three, one for product, one for spa and one for gifts. They're just slightly different fields on each one. So yeah, it was exactly sort of the traditional model of Drupal commerce, how we would do that. But what we were also doing is using a lot of entity referencing to join all the other types of content together, whether it be ingredients, for example, is all entity referenced across. Right, so the next thing we had to think about was search. Everyone knows really on any site of any scale no one really uses core Drupal search because it's not really optimised for that sort of stuff. So we were using Apache Solar. Now that was an obvious thing to do for the main search. But what we also decided to do was use solar for the category pages and the catalogue. Now this was maybe slightly unusual but the aim was, even from the beginning, we were trying to ring out every ounce of performance that we could. And the way we were able to use solar was if you index your content in solar, you can actually pre-render using these view modes that I discussed earlier. And then what that meant was that when we do a search result page we don't have to do anything in Drupal additional. We don't have to re-render content as it's coming back. And that was absolutely the fastest way to put together a search results page. So we were able to use this for all of the catalogue pages. So when you go to a list view, like the top level bath or bath bombs or whatever, those are actually search results pages. Doing that allowed us various things that we could do. Allowed us to influence the order of products which is something that invariably comes up. You can of course do that with things like Node Queue. But what we were able to do was in waiting and rules within solar to influence how those results were coming back. And ultimately it was all about performance. If I'm not mistaken, it sounds like what you've done is you've used Drupal as the content data store. But then you're rendering the content and caching it in solar, and then you've built a custom front end, still using Drupal, but a custom front into all of this Drupal content with solar being the back end. Almost like a headless Drupal kind of scenarios. In a way, yeah. We certainly probably didn't think of it in those terms, but yeah, we are caching a great deal of stuff inside solar so that we don't have to re-render it. In terms of the custom presentation of that, there's a little bit of, it's standard using the Apache solar module you can define search pages. So there was some custom work, but a lot of it was actually already there. Yeah. Was anybody at DrupalCon second by any chance? Some folks. Do you remember Rasmus Laredor's talk? He's the creator of PHP and he did a profile of PHP to show what parts of Drupal are the slowest and the fastest and it's the rendering system that took up 70% of the page requests that he was profiling. So this is cutting out a tremendous performance hit to every page load of a user on your site. I'm impressed. Actually, the search is significantly more powerful. I mean, not for a category, a category is just a list. But for the main search on the site, you're expecting to be able to mistype terms. Their product names are quite creative. A lot of puns going on. So you want to be able to search for stuff and get results coming up. So you've got much more powerful, much more accurate search. We also are able to do faceted search very well which I'll show you in a second. And then the last piece that we used was geospatial search, which was something of course you can do in Drupal using lots of open layers and various other geo modules all bolted together. But actually Apache Solar has geospatial search capability anyway if you send it the right request. So we were able to say, right, Drupal doesn't need to do any of that stuff. We can do all of that over here and again take away say 10 modules that we don't need. So we were able to use accurate search for the category list pages, the main search and the shop finder. By using the geospatial search facility we were able to do the shop finder that way and we were able to pre-render the results in more than one format. As you've seen already there are different ways we can display stuff so what we were able to do is pre-render as many as we needed in that sort of solar cache layer. And that gives you a result like this. The category page they always have this feature caption at the top and then after that all of that is a solar generated return. So you can see obviously with the five star rating and that sort of stuff we have to refresh that solar index quite a lot but whenever a product is updated or reviewed or anything we just push another request up to solar refresh the layer there and then that works. Do any products have less than four stars? Well there may be some waiting but that's the interesting thing the community of customers that this particular brand has are quite enthusiastic should we say they even have a name, they're called Lushies and like you would with Apple you do get unboxing videos of Lush products going on so these guys are keen and let's just say if there's any problems they'll let us know. So this is an example of the main search so we're able to use a faceted search there at the top so basically showing different ingredients products, stories and shops because Bath is a place in the UK so not only is it a Bath bomb it's also a shop and we were able to use that view mode approach again to render what does this piece of content look like when it comes up in the search and one additional thing was what does this piece of content look like when it's number one in the search because it's bigger than all the others Do Lushies have to be convinced to bathe? it looks like maybe they're trying to get them to do it multiple times a day I don't know so that was search and our next challenge was thinking about all the other things that they decided to do they were pretty optimistic they were pretty ambitious about what they were trying to achieve with their new brand and what we found was that the temptation with Drupal is to grab a module here, build a custom module here you can do it all of course you can, we know that and that's what coming to DrupalCon is all about you can learn all these ways of doing stuff but that's not always the best way because sometimes there is someone out there doing a really good job of this particular thing it better just to integrate those in and I think through not just this project but many others we've learned that sometimes just because you can do it in Drupal doesn't necessarily mean it's the right thing to do so with this particular site we were able to use lots of additional services I'll just quickly run down them so you know Metapack is an external shipping system so you can do shipping in DrupalCon that's just fine because if you're shipping all around the world and your shipping rules are quite complicated that's a lot of work to set them all up Metapack is an external service where you send a bundled up version of the basket to an external API and it comes back and offers you what the shipping options are for that particular option so it basically takes that whole piece of work away and uses that they also handle the consignment shipping and that sort of thing Postcode Anywhere is a UK based postcode lookup system I think it's quite expected that you would have something like that Acreasearch we've already mentioned you'll see not necessarily through my slides but through looking at the site there's a lot of video work going on and that's all encoded offsite using Zencoder we use Statcler which is a social API service because we spent a lot of time with commerce guys working on integrating Twitter and Instagram and Facebook and it was a painful and anyone who's done that you just don't know when these guys are going to change the rules on you so in the end we decided to take that piece away and integrate a third party service to just handle the social feeds and sharing stuff we've got recommendation API which is actually Nosto Google Analytics of course New Relic I'll talk about shortly Molym we use for the reviews Anti-spam Registration Standard stuff like that we use Mandrill for outgoing mail one of the downsides of sending mail through Drupal sites is you're never quite sure if it ever went so Mandrill is an API part of MailChimp that allows you to have traceability with mail sent which is really important for e-commerce, all the confirmations that sort of stuff and then they had their own order management system which was a homespun system which we were able to once we finally get the orders done we send them out to there and on the other side we're using aqueer hosting in this case so there's varnish in there which is really important we also use a service called Cloudinary which is a CDN for images and it does pretty much what the Drupal image cache module does it sends a nice crafted URL and it brings back the optimized image for you on the right side we use this in particular because in our case it allows us to share that library of images across multiple properties and also it has some very clever additions like it can do face detection so if you want to do a customer upload it's their profile picture and we want to do that little circle then we can face detect where the person's face is in the image and we've got that nice little thing otherwise we get their shoulder or something depending on what they uploaded and then on the front of that we've got Cloudflare which I'll talk about next performance is everything with this site with any site like this this is you saw the length of those pages you saw the weight of stuff we're trying to deliver here so we've got a lot of caching going on e-commerce really needs to have fast delivery you need to keep an eye on it so that was the thing you've got to know where your bottlenecks are you've got to be able to trace things back so we use all the standard stuff that you would expect out of Drupal we use the Drupal's internal cache we use the entity cache module we use memcached all these things in varnish particularly having a reverse proxy cache at the front really essential because it reduces the amount of traffic actually hitting the Drupal stack altogether but the thing is really hard caching is hard and there are so many reasons that you can't cache so just looking at this example here this page it's just a normal product page and you would hope that you'd be able to cache that mostly in its entirety but every single piece of that where I've outlined in green I can't cache because it's personalised maybe the price is different for me maybe I'm a member of staff and I get a discount maybe the item is already on my wish list so I don't want that to wish list I want removed from wish list maybe the product is sold out so I can't do add to basket and up in the left hand that little speech bubble is actually the social feed so that's obviously not going to be cacheable either there's so much stuff and of course the basket on the right hand side I can't cache that because it's going to be different per customer so the additional problem you have with a commerce site as opposed to something else like maybe a news site is that there's so many conditions where you can't you can't get that performance enhancement you want because you can't cache everything so that's where we've been working with Cloudflare so Cloudflare was brought into the project as a CDN because for PCI compliance reasons Lush needed a thing called a web application firewall which is just something that tracks every single transaction that's going on just for compliance reasons but then we we started to get more involved with Cloudflare working with the team there and realised that actually there's a lot more stuff you can cache if you're smart about how you do it and we're pretty early in the journey here but we were able to cache Ajax requests for example which we didn't realise before we were also able to a lot of the time we were doing lazy loading of things like the cart so you pop the cart open and there's a short delay while it loads in so we're able to do stuff like that but we're investigating at the moment a mechanism in Cloudflare called cache everything which seems to my understanding of it that there are some Cloudflare people here it seems to ignore everything that Drupal says about caching and allow you to literally cache the entire thing and then we're looking into tricks like things like my profile picture maybe storing that reference to that image in local storage on the browser or in a cookie or something so that we don't have to hit Drupal the goal in the performance is not don't hit Drupal, you can make Drupal really fast but if you don't need to go near it then that's even better so it's a lot about Ajax, lazy loading and trying to you know, edge side includes is a technique but we've not, the trouble with edge side includes is you're just hitting Drupal twice so you've not really got any benefit so looking at these techniques these more advanced techniques of caching is something that's been very interesting but I guess the most important thing about all of that is it's still quite early days on that but you need to be able to see what's going on so the other thing that we've used very extensively is New Relic and I know there there's an exhibition hall somewhere so these guys it just comes with that we're hosting anyway so we managed to use that system but it traces down your every web transaction that's going on and you can dig right into the detail of what's going on so this particular graph shows the total response time for the site the green part of the top is stuff outside of Drupal like Facebook requests and stuff the blue is Memcash the orangey brown colour is database and then the rest is PHP so you can look at what your performance bottlenecks are right, do I need I'm not seeing too much database access what can I do about that is my PHP too much when I first looked at this I was actually talking to Lorna Jane she was saying if you upgrade to PHP 5.5 we can make that a little bit at the bottom shrink and she was a part it really did, we know the difference between PHP 5.3 and 5.5 is good but it was a massive performance uplift that we saw for no effort whatsoever so stuff like that being able to drill down so new relic allows us to get right in the middle of it and find out exactly what database queries are causing us pain or exactly which modules or hooks or whatever it is that's causing the trouble the additional part of course when you start caching you've got to think about purging it's the opposite of caching you need to be able to figure out what to do in certain scenarios like this one, that's really bad visibility there but that says currently unavailable on that product so I need to know that the moment that product goes out of stock or more importantly comes back into stock that the cache is going to be cleared on that so that the next customer that comes along can actually buy it so what we're using as a combination there's an expire module and there's another module for Acria hosting called Acria purge and what that's doing is poking a hole back through varnish saying invalidate that particular piece there so using these things in combination allows us to avoid that scenario where if you've got like a one hour or two hour cache going on you've got the customer on the phone saying no one can buy this product, no one can buy this product so you've got to think about those sorts of things as well the next bit Ryan talked about a little bit he doesn't remember what it is and that's about the back end so everything I've talked about so far is the front end of the site and the great customer facing stuff but also there's a whole other team of people who've got to process these orders and look after the site so what we've been working on with commerce guys most lately is a new back end system which oftentimes whenever you're building a new e-commerce site we talk about Drupal commerce as facilitating tailor made e-commerce and so you think very much about what it looks like whenever it's in the browser, on the front end to the customer but what you maybe think about last is what's it like as a merchant to actually use this interface on a day-to-day basis to administer orders, facilitate customer service fulfill products and what not and so often that's the last thing somebody touches or they just don't touch it at all commerce kickstart tried to be somewhat helpful using the commerce back office modules and implementing sort of a better practices back end for merchants to get out of the box with Drupal commerce but still every merchant has just some unique need that's slightly different from the last and so as part of all of our projects in commerce guys we do want to consider how can I tweak this view or change these rules in this business logic to directly support my merchant as another very important end user of the site and so I guess this is ongoing work still with Lush is the actual creation of a new nicely themed and relevant back end to Lush's customer service team I'm assuming this is also integrated with the order management service order management system that continues to be a back and forth thing I just had a okay yes at the end of my session yesterday I just had a scenario where somebody could actually use a custom back end to help their merchant because they were fulfilling products on an order on a line item by line item basis but wanted to have a field that was editable on the back end and visible on the front end so a customer could see which of the products in their order have been fulfilled so far and so within Drupal because this whole back end interface especially the line item list which is not present on the screen yet because the line item list is built using the views module within Drupal commerce I was able to say well you just need to add a new field to your line item type exposed to this view on the back end using editable fields so the merchant could come in and toggle the status of a product's delivery on a line item basis and then on the front end where the customer would view the order edit that view just to show the static representation of this field and he was able to then build a custom fulfillment workflow using Drupal commerce in about 10 clicks and so I know there's more to this work here and I'll let you take that back over Rich but this is just sort of a feature Rich targeted back end for Lush that ideally will be abstractable and then shareable out as a sort of new reference back end implementation I guess one of the biggest problems we were trying to solve here was well first of all multiple sites feeding into one common customer care interface so I won't go into that today but we've got a sort of a headless order management system but the other thing was that when you've got a really busy site the concept in Drupal commerce is that an order or a cart is an order just of a different status so when you start adding cart to your system it really starts to slow down so what we were trying to do here what we found was one of the pain points of the site being slow was actually the customer care team looking for an order and then what we'd find was that because the site had gone slow more customers would phone up to help with their order and the whole thing would start to snowball so our aim here was not only to provide more functionality for the customer care team but also we've managed to integrate Drupal commerce with search API so that when you're searching for orders you can pretty much search for anything that you've got from the customer whether it be their postcode their name their order number whatever because it's using solar you haven't got that additional weight on top of Drupal it sort of takes that piece outside so that's using search API and then we were able to I was doing that again isn't it add additional functionality like look customers need the customer care need like being able to do refunds reissues this is an example of the reissue page if an order never got there and the customer phones up they will often resend the order at no cost and so it's being able to manipulate those orders very very quickly and just do the tasks that they need to do to fulfill their job every day Did your UX team at ICOS design back in the interface? The UX ICOS worked with the customer care team and that was Nick extensively worked with them on-site just to make sure that they were really happy because these guys we need to make sure they're happy and customer care for lush is the most important thing and then we teamed up with commerce guys because we knew in this case there's a lot going on there's trying to make the commerce back in all in one page is really tough so we've been working very closely with commerce guys on this particular one and we still are we're not quite there yet so just finally before we go to questions maybe bringing out some of the lessons learned during this project so my first one was New Relic will save your life and I'm not sponsored by New Relic but I love this product and it really did help us when we had performance issues it helped us find them really quickly otherwise you know you can be with such a complex site there's so many interacting parts you're like I don't know what's causing this problem New Relic allowed us to pinpoint stuff really really quickly I think the next one was never underestimate the complexity of the migration part so what we were doing here was migrating previous sites from multiple countries into a new site migrating a bespoke was a slightly modified open cart system and it's a big job no matter what and also this sheer amount of data you've got to move and how long that really takes I think the full migration took about four days to actually run into it when you suddenly realise you're going live on Monday and it's Thursday you better start that thing running so that was really important to plan that thinking about the build versus buy building it is not always the best way I think I covered that earlier but knowing when is the right time to spend a bit of money even though you might feel not obliged to do so keep your partners close we worked really really closely with both commerce guys and with method we worked with a large team on this certainly with the design team it was really important we were pretty much embedded in their offices so that they could try that interactions and they understood what our pain points were and we understood how much they wanted their pixel perfection so it was really good to be able to work with them otherwise you know you have this thing where they finish their job they throw it over the fence and then no one's happy because you didn't really see the detail that they were looking for caching is hard just accept that it's hard and there's lots going on next one is maybe not so obvious think about your contrived modules and think about custom what we found was that sometimes there was a piece of functionality there's a contrived out there that would do that but that contrived might do 10 other things and we had to be really careful not to overload the site with stuff that we just didn't need so quite a lot of the time we were looking at a contrived saying like for example wishlist there was a wishlist contrived out there but it didn't do quite what we wanted so we ended up using flag and some custom work on that so we just found that just because there's a contrived it doesn't necessarily mean it's the right fit so it's basically spending time evaluating figuring out what's the right thing next one is remembering the legacy especially if you're an agency who's going to be picking this thing up who's going to look after it in the long term in our sort of situation we've got to remember the in-house team we've got to remember that these guys are going to be looking after it so we ideally want them involved and also obviously we want them to understand what we've done so we don't just arrive on launch day and say there you go have fun and then the next thing the last thing really try it when you're moving in a fast moving environment that launch day wasn't going to move we had to get this stuff out there but we had to think about what was going to come post launch there was a ton of features that we didn't quite get ready in time but we knew what they wanted to do so it's all about planning for that but if you spend all your time planning and figuring out well if we do it this way we've got to worry about that that's coming next and that's perfectly valid to do because you never launch so what we had to do was say we've got a plan we've got to think about tomorrow but we don't want to over engineer everything that it's okay to come back and change some stuff later in the next iteration so those are our lessons there's a lot going on here lots of stuff to talk about we love talking about this project and it's great to be able to talk about it with Ryan as well so any questions or anything we're open to the floor thank you very much okay I left you room for questions now otherwise Ryan would just keep talking hi do you want to come over to the mic because of the recording I'll repeat it this question is why are you making me walk with a stupid microphone sorry about that well first of all thank you very much it's really good to take a detailed look I was wondering if it's possible for us to have a deeper look maybe the actual forms for creating and editing the products on the site is that something you'd be able to do I can do that maybe not live but I can probably do that on our stand maybe later because I can definitely show you the back end how it's working for editing products I can't quite do that on a live demo but as you saw how much travel I was having earlier by your means we'll catch up how did you implement customer reviews and then it comes up fairly often customer reviews was just a custom content type using five star and flag so we used flag for the reporters inappropriate and the like and don't like part of the review five star for the stars obviously as you'd expect and then we used entity reference to refer them backwards to the product so pretty standard drupal components actually for that and probably a little bit of because of the way we had to do that the most popular theme the most popular review the most recent review and the top rated one for example we had to do some work in voting API to recalculate all those sums on Cron and stuff like that any others guess we've got one more hi really good talk looks like a really complicated e-commerce site so how difficult was it to define the requirements of a client given you had a fixed deadline to work towards so this was an agile project we were working to an MVP although that became a bit of an in-joke MVP meant everything so no but we were working on agile process so we were doing two week iterations demos at the end of each and although we weren't launching anything between those iterations it was very much keeping the client and the design team in touch with what was going on making sure that we were working on a critical path of e-commerce functionality first and then all the associated story stuff so yeah this is a pretty good agile agile based case study as well and highlighting the importance of co-location in that sort of scenario as well she's not something that I normally think is hugely important but in this case it was really good to have Drupal developers with the agency working on the interaction and making sure that everyone knew what everyone else was going through at that point so yeah hi yeah sorry go on yeah it was a great case study so thank you first I was wondering if you could talk a little bit about the mapping integration that you did and are you actually doing anything with the inventory going back to the actual stores where things are available ok so the mapping was open layers with a custom google maps overlay a custom style set as I said the actual content is delivered from solar and what we were doing is a custom no it wasn't custom there there is a way to present solar geospatial results in open layers it needed a little bit of a tweak but generally what we're doing there is bringing the results straight back and then we're displaying them like a normal open layers map so a lot of this is slightly tweaked but the fundamentals are Drupal the way it should be sorry there was another follow up sorry I'll come back to the other one in a sec I was just wondering the usual question but who were you competing with for Lush were they using Drupal already or did you fighting against Drupal? they weren't using Drupal yet we were considered the wild card I think I think it's fair to say we were competing against Miles Ciaran you remind me Dmarnweyr and Magento were the main competition in the pitch we were last in but I think because we were able to offer that unified vision of one system doing everything it was really something that they were looking for and they didn't realise they could do so yeah I think it certainly made them feel like it was worth taking the direction of Drupal I think there and now they're flipping all of their properties so it must have been okay sorry the other question was about inventory I didn't go into that that's a whole another story but they do have a thing called a kitchen which is limited around products and the way they work is that they do a limited batch out of an actual kitchen they make up 200 of something of products and they sell them out for that one day and as I mentioned the Lushies out there know what's coming this week they tweet out what's coming so what we've had to build for them is a stock reservation system so what it does we've had a couple of approaches but the one we've got currently it works a bit like a daily counter so you get a product, you take a ticket and you get half an hour to finish checkout and if you don't your ticket self destructs and then you might be able to get the product you might not, it depends whether it's got anything left so we started off building a stock module but we weren't able to get that working super reliably with that type of concept so we've ended up building a custom stock reservation system which maybe I'll speak to Ryan, maybe worthy of going into contraband so yeah but the actual physical stock is held by the external system so we're doing a lot of web services chat to figure out what's in stock at any one point and lots of caching of that and the last thing we've done is adaptive caching so when we're checking for stock levels if we know that there weren't many left we'll check more frequently whereas if we know there's 10,000 then we're probably not checked till tomorrow so again just a little performance things like that trying to figure out what we're doing now Do they have multiple warehouse system or just one in the UK and global warehouse? There is a single warehouse at the moment Can people buy and collect in stores as well? Not yet, it's on the map it's on the road map we're not doing that yet but at the moment we're in the process of launching the Dutch site and the other European sites so that's taking priority at the moment over new features so very soon we'll have pan-European sites that look like this one if you look at the Dutch, Spanish and other European sites at the moment they're using their old conceptual design I just found out actually Brazil launched this morning which is a great achievement for the team out there working with a good story that I went to the code sprint with Ryan back in a couple of years ago Drupal Promise and met a developer from Brazil I only really met him once but he seemed like a good guy and he seemed to know his stuff OK, do you know anyone in Brazil to help the launch so we phoned this guy up and he's been working there for the last six months and he's just finished launching so he was using following along behind us taking the features as we build them and doing a lot of Portuguese translation obviously so yeah, really nice little inner story there but worth going to Drupal camps and Drupal code sprints you never know what might happen Maybe the last one Is it a Drupal distribution and if it is a Drupal distribution is it free? OK, so this is not a distribution specifically there's a few bits of custom work that we've done work quite a lot I guess but most of it is off the shelf contrary modules so there's not a distribution that holds it all together but all the component parts are out there and all the component parts are free and we've been able to build where we've done a couple of new modules those have gone out into the community and we've got about three or four other modules that are probably candidates for going out like the one I just mentioned so although there's some custom work in here most of it the majority of it is out there for anyone Sorry guys I think our time is up now so thank you very much I'm around for the whole week anyway I'll come and chat any more about any of this and call my skies obviously here as well Thank you