 I'm getting too close to something there, I'm just going to go this way. All right. Apparently, I'm safe over here. Okay. Has everyone got a food coma? Like I have? Anyone that's feeling like they want to go to sleep? No? Okay. So today I'm going to talk to you guys about a project that we did at Boomcom Pixels, which was for one of our bigger clients, which I'll talk about in a second. I'm pretty much just going to tell you a story. Hopefully it's not too boring. And then you guys can ask me all the questions you want. I have, I may not know all the technical details, so I apologize if I don't. But let's get started with this one. So, nope, turn it on. So the most exciting part of this talk, who the hell am I? My name is Thomas Hurd. As we just mentioned before, I'm from New Zealand originally, so I've come probably the furthest distance you can to get to Finland. By trade I'm actually an industrial designer with a, I also did service and system design when I was studying. And that's kind of through a very long process led me to what I do now, which is at the moment managing a team of designers and sort of graphic UX developers to build a lot of experiences, as we call them, at our company for our different clients. And one of my big things is about really focusing on user experience. And I know that's a really, really almost overused term, but I think that the experience that you give all your users, and I'll talk about that in a moment, is really, really important and almost more important than anything else you can kind of come across in a project. So the project that we're talking about is a company from the north of Italy called Torgla. They are basically dealing with bathrooms, building products, pretty much anything you need to build a house, they sell. They're mainly selling to businesses, small businesses, big businesses, contractors, all those sorts of guys. And they've had a shop online for quite a while. They have a few customers that order online, but the main reason that people use it is just to find out, okay, how do, like, do you have this product or can I get this product from you? So they came to us. We'd already worked with them before, and we'd actually done another website for them. And they said, okay, we want to change our online store. But the current person that we have doing it, they can't really continue anymore. And even if we could continue, we want to really overhaul it, and we think that we just need to completely start from scratch. So they came to us, and we said, cool, we can go through this. They, basically, the big challenge in some ways was the fact that they were using SAP, which I'll get into a bit later. But also, as we were talking about, or as was just mentioned by Daniel before, that a lot of WooCommerce shops are quite small. So I think on a scale level, they're not really tested. This store had 7,000 products, okay, big, not crazy. But there's actually 30,000 product variants, okay. There's 660 categories, still big, but okay. 10,000 attributes, this was really fun. And then just to really make it really exciting, we had to have two languages, of which neither was English. In some way, we actually had three, because we have to translate everything from English, and as I said, we had to do some SAP integration. So quickly at the start, what do we actually sort of approach this from with them? They were a little bit skeptical, and they really were wanting to make the right choice about what they did with this new shop. They knew they wanted to invest money, they knew they needed to invest money. So on that side, we're like, yes, this is good. But the question was like, okay, how do we actually convince them that we're the right way to go? So luckily we had a lot of freedom with these guys. They said, we trust you that you're gonna design it the way that it should be. We trust that you guys are experts in what you're doing. So luckily for us, that was quite easy. But they wanted us to do something really different. Italy is kind of behind in the internet, quite a bit. It looks very 2000s, most of the websites. Also, things like here, we have, everyone's pretty much got 100 megabits per second at their home or office. They're lucky if they get 10 in a big office, and they pay thousands to get fiber and store to their home. So there's quite a different shift in the way that we have to think about it. Then they said to us, okay, well, we had this old supplier who made the old shop, but it was all closed source and we couldn't do anything with it. We had to pay them heaps and heaps of money every year just to keep it going, let alone if we wanted to add something to it. So we want it to be open source because if we want to change, like if we want to switch from you guys or if we just, we want something more secure and more trustworthy and more reliable. So we said, okay, we'll do this on WooCommerce. The whole open source thing and having an easy access to a pool of developers kind of ruled out magento. And we had had experience in the past with building an online shop with Drupal and that killed that right there. Sorry if anyone likes Drupal. The last thing was about making it flexible. No, maybe not the last thing, but one of the last things. As I said before, they wanted to really overhaul the way they did things. And this meant that they had lots of intricacies that are involved with their business, about different ways that people have to order products, the way that the system had to integrate with SAP and a whole bunch of other things. And then, of course, as I think Lisa was saying earlier today, when we're talking about the user interface and user experience, not just their clients experience, but also their experience administrators of the site and of everything within the site that they had to take care of. Because the old one was horrible, it didn't make sense. And that also leads to another thing, which I think is often overlooked when we're developing websites or these sorts of tools for clients, is that we sometimes have a chance to sort of build this internal efficiency or create an internal efficiency by taking tasks that they used to take forever to do and somehow integrating that into the website or the tool that we're building for our clients so that they can actually... It's not just, OK, here's a new website, this is more than a website, this is actually a tool to help you do your work faster or more efficiently or better. And the last thing that they were sort of quite big on is that we had to help them convince their customers that they should move on to this online platform. So basically, in the past, they had a few people... Well, a few, they had a certain amount of customers who were ordering online from their existing store. They had the majority, though, ordering via order forms, like written order forms, or through phone calling up and saying, OK, I want this, I want this, I want this. So they wanted to really move all their customers to the website. They wanted to start shifting their client base to the digital age, as we like to call it. So for us, the idea then sort of became, OK, WooCommerce, they were very happy with this, they were on board, it was great. Then we got the joy of going from their old shop to the new shop, because as I said, they had 30,000 product variants in two different languages, they had an existing shop where everything was translated, all the products were there, all their customers were there, everything. So we got the fun job of migrating this. The old website, as you can see in the background of this, is... I don't even know if it's 2000, I wonder if it's 1990s, possibly, maybe. It was horrible. Then, document what? There was no documentation at all. So we had to kind of dig through their databases and understand how it went, usually not such a bad problem. Who of you guys here sort of have a big sort of interaction with databases? Oh, not as many as I thought, OK. Sorry, this gets a bit techy, but you have a Boolean, you have a Boolean column, you define it as being a Boolean, yes or no, true or false. They like to use spaces, for true. So we're looking through this database, I remember there was one time it took us four hours, searching through a database, trying to work out where this one little flag was coming from, and then my colleague realized, hey, this is column with random spaces every now and then. Lo and behold, that was their true or false. Even if they'd used that, it wouldn't have been a problem if they'd actually documented it. Hmm, fun. So how do we do this? And this is when I'm going to start giving you guys some advice, or at least our experiences. It may sound really obvious, but take it one step at a time. Don't try and do too many things at the same time, because if something in one part goes wrong and then you have to start changing things in the other, it just gets a mess. So we started off, first of all, by having all that fun of digging through their databases, and we actually created, quickly with a PHP boilerplate, just a really quick way to output the data that we had and to work out what we needed and to make sure that we could get all the data correctly. Nothing to do with WordPress at all, just us purely querying a database. And then we went on to the building the scripts, making sure they all worked, and then we actually started implementing it and copying everything into WooCommerce. Just one tip, don't upgrade stuff when you're trying to do this. I think WPML at that point had a big upgrade where they changed a whole bunch of stuff and we had to start a whole bunch of scripts from scratch. So as I mentioned before about designing efficiency, so now I'm talking about how we can start making WooCommerce and taking it to the next level. First of all, I want you to all think about your users and not just the ones who are using the website on the front end, but the people who are having to input things or manage things on the back end. As Lisa mentioned before, actually at the end of the day, they're the ones who are paying your bills, so you probably want to make them happy. So try and make things simple for them or explain things. I know that maybe for WooCommerce, most of it's there, but I've seen some horrible, horrible back ends where there's just random fields with names that don't mean things, so my advice on this respect, think of also your actual clients as users administrating things. With this store, we had a pretty simple brief. They had to be able to load the site quickly in Italy with their slow internet, find things really quickly out of 30,000 products in which there was a bunch of attributes, and then be able to order things quickly. So in terms of the loading, that's not too hard, you just sort of optimise things. The ordering is luckily taken care of by WooCommerce. The searching was something that we really had to spend a lot of time on, and basically what we did is that we spent the majority of our time on the things or the interfaces that the users would be looking at the most. So basically searching, finding things within search results, and then once you go from a search result to a product page, actually finding the actual product that you need. We had a lot of tables of variations because that's how the users are expecting to see these things, but you might have 40 variations. So we had things like when you would click from a search result, it would actually highlight the variation and scroll you down to the one that you're looking for. So you really didn't have to search through this list of 40 things again that you've already searched for to try and find the one that you want to order. So in terms of crafting a store, so this is sort of getting into the actual development side of things. There was a lot of challenges. We had taxonomies, we had these fields, we had SAP integrations, and it was quite a big test about how WooCommerce can scale. So first of all, WooingCommerce, as I said before, we had to customize. We had to add brands. We had to add a bunch of custom fields that were taken from imports because they have, as I said, this SAP system, which has 1,000 other little fields to do with custom pricing and special codes and the supplier codes and things like that that they need. So we really had to kind of do a lot of extension and manipulation of what WooCommerce could do and really try and make sure that it worked and it was secure like Otto was saying, we had to be really, really careful with security, especially since this is a store. And on top of all that, the biggest joy in my life was internationalization, which I will talk about quickly in a moment, but that probably was the biggest issue of everything that in terms of playing with WooCommerce. And then it was about taking not just SAP out to dinner, but SAP's mother out to dinner because this wasn't some SAP one new sort of this cloud system that they have. This is SAP from the late 1990s. So it's really not fun. But we've got integrations working already. They're basic, basically in terms of efficiency, it allows things to be imported directly as soon as they're added to SAP, so new products. And we are working on bi-directional integration, so going from WooCommerce back into SAP. And then lastly, the whole scale of this thing. I mean, it was huge, at least from my opinion and what I've seen, there aren't many stores with this many products. So, we were taking WooCommerce really beyond where it could go or where it maybe had been used before, and we had a lot of interaction with the team at WooCommerce. I think there's a few feature improvements. We were basically the people who discovered the bug that they then fixed, which has now made things faster. As I mentioned, the, what are they called? Not variations, the attributes, that's the right. The attributes were a huge problem because we had 10,000 and I think WooCommerce was sort of saying to us, okay, we think we've had maybe 1,000 in one shop at once, so this was a total big thing for them. But they were really, really good. So, if you're thinking about WooCommerce in terms of a, there's a little bit of a plug for them, I guess maybe, but they were really, really good at getting back to us and really helping us, not just for our sake, but also for their sake improving their product, so they were very responsive. And then my favorite, favorite thing of this whole project, which I think everyone here gets to deal with at some point in their life, if not every day, is internationalization. It's bloody unpredictable. For us, this was the biggest cause of problems on this entire project and we had a lot of them purely related to trying to make this site work in both German and Italian. The biggest challenge was actually we didn't really have much control over how the sort of, some of the plugins we were using, WPML. Which basically is the only option at the moment if you want to store. They did their best at supporting us as much as they could. We did have some frustrating moments, but generally they were trying to help us. And I think, again, as with WooCommerce, we were really pushing the boundaries of WPML working with WooCommerce, so for them, it was also kind of this path of discovery and working out okay, we never even thought that we would have this many variations or this many attributes that we would have to deal with, so now we have to rethink about how we maybe do some of the programming. But what are the alternatives? Unfortunately, as I said, there's not really anything. I believe the last thing I saw that Polylang has got, someone has been building a integration with WooCommerce, but I believe it's very basic. I'm not sure if it's totally production ready. Don't quote me on that, I might be wrong. But I would really like to see other options, so I'd like to see Polylang being given an option for WooCommerce, but I do understand it's a lot of work to get these things working, and WooCommerce by itself is very complex, let alone adding an internationalization there. Lastly, we had, well, maybe not lastly, but we had this PDF export, so this was the kind of big custom thing we had to build. They had this in the old shop. I forgot to bring it with me, but they have a catalog about that thick, which their old system could export as a PDF. So we had to produce this and we had to make sure it was exactly the same, basically, because that's what they were expecting. This is my conclusion. The PDF plugins absolutely suck. I'm really sorry, but they're horrible. The only ones we could find did one of two things. Either they required you to install stuff on your server, which isn't always the easiest option, especially for your maybe more everyday WordPress user, or they have very limited abilities, like you can print the page, it's like, well, I can do that from Mac OS, I can print a page and I can say PDFs are wide. Okay, I don't get that. But that was my general approach or sort of feeling about that. So when stuff sucks, build your own. And that's exactly what we did. So we had to make our own plugin, which spits out these big print-ready PDF catalogs. It took a lot of time, a lot of efforts. I can't remember exactly which library we used, but we tried a few just to make it work. If anyone's interested, the main catalogs, like we have these huge thick catalogs, those are generated every night because new products are being added daily. So it's not something that we can build and then suddenly, okay, we'll do this again in a month. It actually has to be done every day. And I think it takes about 10 minutes to generate one catalog. But these other smaller catalog sections, you can actually download on the fly. So the new sort of thing we built for them was that you don't have to download the entire catalog. You can actually download a subsection of what you're looking at. So if you're just looking at taps or something like that, you don't need to download every concrete bag and everything else that they do. So does it work? So after all this massive project that we had that I think took about a year in total from an original estimate of six months, yes, it does. For them as a client, things have been going up, up, up for them. They've had an increase of online orders of about 15%. They've seen a massive increase of visitors. A lot more people have registered. So one thing about the shop actually that I forgot to mention is if you want to see prices or order anything, you actually have to be, you have to actually have an account with them since they're a B2B company or supplier. And they've actually had an increase in international visitors which is kind of a weird side effect that they weren't expecting but as good because they're wanting to expand a little bit internationally in the near future. So pretty much all good for them. Sort of as a summary, the main sort of from their side of things, the benefits are looks, speed and reliability. So we really managed to improve the look. I think it's much better than what it used to be. The speed especially with the help of AWS, Amazon Web Services, we managed to really get going and it's just much more reliable than their old system. Their old system had a bunch of issues with just falling down basically every now and then with no apparent reason. So for the clients, every part of maintaining their shop is now so much easier and there's things that have been sped up because they no longer have to edit products manually. They just import them straight from SAP. So into the future, we're still working with this client and doing a few things. The next thing we're looking at with them is actually using the REST API in combination with SAP to take advantage of customer specific pricing because some customers have very specific pricing and improving a lot of the bidirectional the bidirectional integrations that they have. And then also more interfaces. So they actually have a lot of in the past or they would like to have a lot more ways that people can order. They have some customers who order three products at a time. They have some customers who are dealing with massive, massive projects where they've got a spec sheet of 100,000 products they need to order and clicking through an online store for them just doesn't make sense. So we're building other interfaces to help them there. So WooCommerce, yay or nay. For us, our basic conclusion that is that it's a really good toolbox because it starts off working really well. It's really easy to do basic improvements or sort of enhancements through plugins but then it's very easy to customize and extend. It's not perfect, but then nothing else, sort of nothing is and I don't expect it to be. Of course, every time you wanna do something custom it's always gonna be a bit funny and tricky. But for us, it's been a really good experience and it's worked really well. And that is the end. Now you can stop listening to me. Cool. Thank you, Thomas. Any questions? We've got plenty of time for questions. Gonna move somewhere where the light is not in my eyes. Okay. I think there's someone at the back. Over there? Oh, okay. In the front first, yeah. Hey, great talk. Thank you. My question is, do you have any recommendations from a theming or user experience perspective for WooCommerce at scale? Having built a lot of smaller WooCommerce sites, I'm wondering how the either theming or user experience might differ at scale. Yeah, I think maybe from, it depends also from the side, like from the customer side, we actually spent a lot of time with the client understanding as much as we could from them about their users and about the people who are actually gonna be using it and then from their sort of building things and we didn't really get to have too much interaction with their clients as per se. So the sort of end-end users, let's call them. But they have a lot of insights because they've got a lot of research and they know their clients very well. So they were able to give us a lot of insights and they've also been talking to some of their key customers. So we did a, I guess a soft launch or like a pre-launch with a select group of their customers who are ones who are already using the old online store and some ones who wanted to use the online store but hadn't sort of got moved there yet. And so from their feedback as well, we've been doing it. So I think we sort of started with the base of, okay, let's ask them what they know, let's use it as our base and then let's just sort of trial and error a little bit because I think you can ask people what they want but sometimes what they want isn't actually what they need if that doesn't sound too horrible. Sometimes people don't know what they actually need. From their sort of point of view as a company or internally and the people who have to administrate it, that was the easier side because we knew we could sit there with them and work out what exactly they were doing and then go, okay, we can, first of all, we can optimize things for you and then we can really sort of create an interface that is, I mean, we didn't totally change WooCom or something like that, but we could sort of, for example, the importing from SAP, we could start speeding up their processes in the past, they used to have to write everything in two places. So, yeah. Okay, there was a question in the back, I think. Yes. Okay, the mic over there. One, one, one, one, one, one, one, one, one. Is there anyone upstairs, by the way, who wants to ask a question? Yeah, did you need many extra plugins for WooCommerce and what kind of? No, I'm trying to remember. I don't think so. We made a lot for ourselves. There were some very specific things. For example, there is a plugin, quite a popular plugin for adding brands to WooCommerce, but we found that actually just due to some very specific things we needed, that that wouldn't work. So I think we didn't use many publicly available ones or sort of externally made ones, but that was purely because this project was very, very specific in what it needed. So a lot of the plugins that we kind of came across, unfortunately, weren't really suited for what we had to do. Okay, more questions? There's someone upstairs. We have a question from upstairs, so. Yes. Could you go a bit deeper into the technical aspects of how you optimize the queries you had to make for the searching and stuff? Maybe not. That's probably my colleague is better at that. Fortunately, and he's currently not here. I know that, I don't think we did too much modification to things, to be honest. I think that luckily things worked pretty well. It was, I think the biggest help actually was just putting it onto the client, onto AWS. That was what actually gave it the grunt that it needed. The fact, I think, I mean, of course I'm sure that WooCommerce could be improved with what it's querying and things like that, but we pretty much relied on WooCommerce working the way it was and just making sure that we had a server that had the grunt to support that. One thing we did find, as I was saying, about finding these issues with in combination with the WooCommerce team, one thing we found was with those attributes that when you go into the interface and a product to actually select attributes, at that point it used to load those as it loaded the page. And so if you're imagining it's trying to query something like 10,000 attributes, it takes kind of a while. So pages were taking around four seconds in Italy to load. So we talked with WooCommerce and then I think they started doing it via AJAX. So now it doesn't actually matter. It doesn't affect the page loading time. More questions? There's one guy there. Yeah, there's one over there. Hi, and thanks for the talk. Did you have any other options besides WooCommerce? How did you end up with selecting WooCommerce? Well, like I said, as a company, we'd had experience with Drupal and one of the e-commerce sort of modules of Drupal. That was a challenging experience, let's say. And I think we looked at the others, but what the client was really wanting was something that was, I mean, first of all, with WordPress, that they were interested in that because they were like, okay, well, we know about it. We know it's being developed continuously. We know it's got a pretty good reputation in terms of it's not just someone on the side building something that they're going to suddenly cut development or something like that. And kind of the same thing for WooCommerce. Like, there are other store options, but I think for them, they just thought, let's go with the safer option of choosing the biggest one. So I think we were kind of in some way dictated by their desires that they wanted to have. They'd had, I think, a semi-bad experience with the previous supplier in having a very, very close shop. So that was pretty much, it was more them than us like this, in that way. Okay, the next question over there, please. Hello. The solution that you have built looks really nice. Are you planning on open sourcing any part of the bigger implementations that you needed to do? I think that there are, one thing we have been talking about is actually the PDF part of it because we've actually had a few projects where we've needed to have customized PDF generators. And as I said, we've never found anything that really works. We've actually been sort of using our own implementation of a PDF generator for about four projects, I think now. So I think maybe that would be the thing that we would probably look at maybe making open source, but otherwise we're not too secretive. So if anyone sees anything that like, hey, I really wanna know how to do that, then you can let us know and I'm sure we can help you out. Cool. More questions? Anyone? Okay, over there. If you have a question, by the way, you can already hold up your hand so then the person with the mic can see you and get to you. Hello. Hello. Thanks for a great talk. Cheers. Just a question on multi-language. Yeah. You know, it's quite important maybe in these regions and it doesn't have standard support. Yeah. You mentioned it a bit. I guess it could be a difficult area, you know, but all these things. Yeah. I just wondered if you, do you have any insights, you know, sort of going forward or in the future, if you would do something similar, you know, connected to multi-language particularly? Yeah, I think the biggest thing is to bring it in from the start. I know we've done one project where a client sort of later on decided, oh, actually it would be nice to have this multilingual and it was a bit of a nightmare, like this project, no, because we luckily knew from the very start that it would have to be, but I think from my experience with working, like I think every project we've done except for one has been multilingual. It really pays off to start from the beginning knowing it's gonna be multilingual and really thinking about making all your strings are translatable so you don't have this nasty surprise when suddenly you're like, why is this thing in English? Why isn't it coming up in whatever language I need it to be? The other thing that we found with the client and that's maybe been the biggest struggle for them is the interface with WPML because they do so much as a plugin, which I kind of always feel sorry for them because they're just trying to do so much that the interfaces can get very complex and very tricky for people who are not maybe so tech savvy to understand. So, I mean, I don't really know how to get around that. I guess for us that's generally we use polylang but of course with WooCommerce you have to use WPML basically but we've at least found from our experience that clients prefer polylangs interface because it's much more user friendly and much simpler to understand. So, if it's ever possible to get a simpler interface then I would totally go for that so, yeah. Okay, we still have time for a couple of questions anymore. Okay. No. Thank you very much, Thomas. Thank you.