 Hello, hello again. We're here, this is IndieCommerce 2.0, building a reimagined e-commerce platform for independent booksellers using Drupal. We'll be talking about the project, showing some of the stuff that we did, and just kind of getting updated. I'm Albert Hughes, I'm a technical project manager. I started building websites in 2000. I found out about Drupal in 2007. I've been using it professionally since 2008. I've worked at organizations like the University of Texas, Dementia's Grizzlies, and now I'm a technical project manager at Lullabot, where I lead teams, distributed teams, on large-scale Drupal projects. Hi, I'm Geeta Nathan. I'm a senior e-commerce manager with the American Booksellers Association. I joined there as a part-time developer in 2004, and I'm there still. I am very passionate about independent books sellers and local businesses in general. And I love my job, so I continue to stay there. And I got introduced to Drupal in 2008, and here I am, this is my first presentation at DrupalCon. So what is the American Booksellers Association? It is not-for-profit trade organization for all the independent bookstores across the country. We try to support the success of independent bookstores through programming, events, education, technology, advocacy, and everything else. It was launched in 1900. Today we have about 2,200 members across the country, and this includes a diverse group of members, and if you have ever seen a bookseller anywhere, you know how loud they can be. Two booksellers, and they'll have 10 different opinions, and that's the kind of membership we have. And IndieCommerce is the e-commerce platform that ABA developed for the independent booksellers. It was designed and developed mainly for a bookseller. So it has some unique features that would match the business model of booksellers. And it is connected to a database of more than 14 million plus book titles, and it is an additional source of revenue for these booksellers. Looks like on the journey, 100 years after ABA started, you all started to support booksellers, not just in the brick and mortar stores, but online as well with bookstores. Could you tell me about that? Yes, it was in 2000 that ABA decided to start its first e-commerce platform. It was a legacy platform. We built it in Java, and we had about 80 sites right at the beginning. And in 2008, we moved to Drupal 5 with Overcard, and we had about 100 sites. We used a multi-site install of Drupal 5, and in 2010, we upgraded it to Drupal 6, again with Overcard. And in 2014, 15, we moved to Drupal 7 again with Overcard. And it was at that time that BookSense was rebranded, and we called ourselves Indie Commerce, which is commerce for independent bookstores. And that was our first engagement with Lollabar. They helped us do the migration from 6 to 7. And in addition to the main platform that we had, we also created a second platform, which is like a much simpler version of the e-commerce platform. So we had two platforms, both in Drupal 7 and Overcard by 2018. And in 2020, the pandemic happened. Online sales went up by 800%. And just on the Indie Commerce platform, we had about 23 million unique visitors that year right after pandemic because stores were closed and all their businesses moved to their website. And we had about 110 million in online sales. We were still on Drupal 7 and Overcard. 2020, as most businesses did, we didn't have time to do anything else. We were just managing the platform, keeping the sites up, helping our member bookstores survive during the pandemic. And we had requests for many websites, many of our members joined. And we were at about 441 Indie Commerce stores and 123 Indie Lights, which was like the kind of the max at that time. And then we resulted in 2.0. We called it the Indie Commerce 2.0. Why did we go with 2.0? During the pandemic, we didn't have time to think about anything else, but we knew Drupal 7 End of Life was coming and we had to move away from Overcard because it had stopped support a long time ago and we had to move to Drupal Commerce. And the pandemic played an important part in our decision. So the website traffic had spiked. The commerce online customers went through the roof. There was an increase in the website usage, both by the bookstore staff, the admins because the stores were closed, the staff had to retrain every staff in the bookstore because online business was the only business they had at that time. So there were more eyes on the website. And that means we got a lot of feedback and a lot of future requests from our members. And at around the same time, unfortunately, a lot of the small business websites were being sued for ADA non-compliance. And so kind of the pandemic highlighted some of the existing issues with our platform. And the requirements and needs also changed. Like for a bookstore owner, they wanted a cost effective ADA compliant and unique website. For the bookstore staff, they wanted more intuitive admin interface and also the possibility to automate any processing, order processing and shipping of orders. The bookstore customers wanted an easy way to do checkout on the websites. And for us in the indie commerce team, we wanted a more scalable platform because we did manage through 2020, but it wasn't a very easy experience. So we didn't want to be in the same position in the future. So we wanted a much scalable platform. We wanted to look at all the key features with some fresh eyes. And also we had two platforms which was hard for us to maintain. And we wanted to combine the two into one. Yeah, why Drupal? What was the decision for you all to stay with Drupal? That question came back again many times. For us within the team itself, it was like why not? We have used Drupal successfully for 15 years. We didn't see a reason to move to another platform. And it was cost effective. With Drupal and Drupal commerce, we were pretty sure that we could create this unique enterprise level e-commerce platform for bookstores. And we had a lot of Drupal internal expertise because we've been using Drupal since 2008. Although, but our membership and the board of directors, they were not happy with Drupal, which we will look at later, why? And so we had to convince them, but we were able to do that. And we decided to stay with Drupal. Okay, and then why Lullabot? I know you could choose different agencies to help you all or you could do it internally. Why go with Lullabot to help you all out? And so we had to build a new platform and we decided it was going to be Drupal. So we were looking out for some Drupal agency. This was a massive project. We were a small team. We are totally just developers and since admin, we are just four of us and a project manager. We have a support team, but that's different. And we also needed fresh pair of eyes. And we were building this new platform. We also had to maintain the T7 platform, which had close to 600 websites on it. So with both together, we needed to look at Drupal agency. And we had previously worked with Lullabot before. Myself included and my senior developer and since admin, we were part of the team that worked with Lullabot in for the six to seven migration. So it was an easy decision for us to make this time. So we started with the discovery phase, which was the phase one. And as every discovery phase, so we decided to survey and Drupal, sorry, Lullabot team. It was Andrew and Sally. They came on board to do the phase one for us. So we surveyed, we had two sets of end users. So you have the bookstore staff and you also have the customers. They all have, both have different needs. When you look at the bookstore staff, you have the owners, the content creators, the order managers and the marketing managers. And the customers, you have some new customers, stores picked up a lot of new customers during COVID. And they also have the long loyal, long-term customers. So we took a survey of both groups of end users. They also reviewed the two platforms that we had and Andrew and Sally put together the recommendations document. And that's where Albert came in to take over the phase two. Cool, yep, that's when I started. I received this document about two weeks before the kickoff. It's the IndieCommerce Drupal 9 Discovery document. I used it then and throughout the project as like my playbook and my blueprint as we rolled into the project. I called this the IndieCommerce 2.0 pregame phase. And during the pregame, I wanted to do four things. One, I wanted to study the discovery documents. I knew, again, we had designs, there was a data dictionary, there was the survey results, there was recommendations on how we should do things or how we could do things in Drupal 9. And so I wanted to study the documents and make sure I understood what information I had available to me as we rolled into the project. And then two, I wanted to understand the goals. In the discovery document, there were some very specific outline goals that IndieCommerce wanted to achieve with the project. So I wanted to understand who these goals served, how did we get to these goals so I can understand so that we can do our best job to meet them. And then three, I wanted to analyze the recommendations. There were plenty of recommendations of how to do things and what we needed to do. But I wanted to understand what additional questions I needed to ask and what answers we still needed to obtain from the ABA staff. And then I wanted to know the project. As Geetha mentioned, we're not just serving ABA, we're serving the bookstores and not just the bookstores but the bookstore customers, specifically the ones who are purchasing books online. We also weren't just building a website. So this wasn't a project where we were building one website, we were building a platform or a base that hundreds of sites can be built from. So again, I wanted to study the discovery documents, understand the goals, analyze the recommendations and know the project. Right here, this is a store called Novel. It's in Memphis, Tennessee. They are a member of ABA and they also had a website on the IndieCommerce platform. So during that pregame phase, this store happened to just be five minutes away from my house at the time. So I wanted to go in there and put my eyes on an actual store, a physical store that we would be working with or working for. And then this store here is a bookstore in Houston, Texas called Murder by the Books. And they really, that's when I learned that a lot of these independent bookstores have niche focuses. This one was specifically about murder mysteries and things like that. So I was able to really get a good feel of the customers that we wanted to build this platform for. So the kickoff, it was June 29th, 2021. And I remember that week because it was, every, we was all remote. It was still close to pandemic, but we were getting out of it. But the kickoff happened remote. I was living in Memphis, but happened to be in Houston this same week. We were looking for homes. So I'll never forget this week because we actually found the home that we're living in now. And then during that kickoff, we learned that it was gonna be August 22 when we anticipated or we estimated that we would have a site to be able to be on IndieCommerce 2.0. We also were working with quarterly SOWs on this project. So we knew it would be at least a year, but we were working with quarterly SOWs, which I think gave us the opportunity to refocus our priorities at every quarter. So before each quarter, we would meet and then figure out, okay, what do we really need to prioritize? And it also allowed us to bring on team members that we needed for that particular quarter at that particular time. And then the project team, it was a globally distributed team. We had people in Canada, UK, Peru, Spain. At one point, someone was in Japan, Colorado, Florida, Texas, and Virginia, I think. I hope I didn't miss anybody. But that's what we were working with. And we started off the project. When we first started at the kickoff, it was me, Andrew, Sally, a designer. And then a few weeks later, we rolled on three back-end devs and then we rolled on two front-end devs and two quality assurance engineers on the project. For communication during project management, we had a shared Slack channel, one shared Slack channel with all of our project team members both on the ABA side and the Lullabot side. And in that channel for the description, I wanted to put our mission so it'll be upfront for everyone, which was developing a new IndieCommerce platform that current members will migrate over to, make money from, and love to use. Another thing we did for communication was we created a project wiki, or I wanted to have one document with all of the important information in one place. We had things like, what is ABA? What is IndieCommerce? The name, title, and link to company profile for all of the members on the team, links to documentation, all the deliverables that was outlined in all of the SOWs. And just one place that when people onboarded or people wanted to get information, you could go back to get up to speed. And then our meeting cadence. We had weekly meetings. After the kickoff, we started by having a daily sync. And then after a couple weeks, some of the developers were like, hey, I don't think we need to meet as much. So we scaled back and we end up settling on a good cadence of Tuesdays, Thursdays, and Fridays. Tuesdays typically, and this was Tuesday, Thursday, and Friday mornings. They could be anywhere from 15 minutes to an hour. On Tuesday, we really focused on like, what are our plans to do this week to get to Friday? Thursdays was just a check-in and sometimes we would schedule discussions after that meeting and then Fridays were typically demos. And then I would send out a weekly update, mostly on Fridays, sometimes on Mondays, but on Fridays, it would be, what did we do this week? What are our goals and what do we plan to accomplish next week? Any important information, like who's gonna be out of the office, any additional meetings that we wanted to set up, or any deadlines. And then when it came to organizing the work, we didn't follow any specific product methodology, but we wanted to do something that was tailored to the actual project. And so out of those quarterly SOWs, we'd outline certain features and those features would be turned into epics. And then over the course of those quarters, we had monthly phases. They would typically be four to five weeks. You would have three phases per SOW. And in GitLab is what we use to manage our issues. They have a roadmap feature. So you can lay out the estimated dates for your epics against the timeline and create that graphic you see up there. And then all the work broke down into issues. So we broke down the epics into certain issues. If there was a bug that arose, an issue, if something came up in conversation that we wanted to dive deeper into, we would create an issue for it. And you see this other screen is in GitLab as well. They have issue boards that you can customize. So we use that to manage and track the work. And we really used weekly iterations, which were like weekly sprints. So this is all the work we wanna do this week. We work all week, demo it on Friday and start it again. And at any point you could go back in the system and look at what phase, what week and see what we accomplished. And then this is a high level structure. I think Sally Young set this up for us, one of our DevOps engineers. At a high level, we had our local development was standardized using DDEV. GitLab is where we had our code repository for any merge requests opened in GitLab. We used Pantheon's multi-DEV environments. So when a merge request was open, we'd have a URL that we could share that people could QA look at and review. And then once all the code was ready to go, she laid the baseline foundation for us to eventually have automated deployment scripts where the code from GitLab could then get sent out to all of the individual hosted bookstore sites that's happening now. The Drupal themes are stuck in the early 2000s. That's one of the survey respondents that we received, the initial survey. So for our stores, so these are independent booksellers and they fall in a wide range. We have stores that are big enough they can have their own tech department and they have tech people who can handle it. And then at the other end of the spectrum, we have stores who are just run by a couple of staff and handling their website is just one additional work that they have to do in addition to everything else they do during the day. But at the same time, they wanted unique websites which reflect their store location, their brick and mortar store and also maybe have their branding on the website. And they wanted to be able to do that quickly, easily. And the themes that we offered, we created two themes and they liked it but it wasn't enough for them. And some stores, they went ahead and they hired freelance developers, Drupal freelancers to create a custom theme for them. We supported that, but in the long run, it was just too hard for us to keep up those themes up because those freelancers would leave and then it would fall on us to maintain those. So all they needed was a simple, unique website and easy to manage. And that was the first requirement and let's see how much that was handled. Yeah, again, those problems that Geetha was mentioning was in the IndieCommerce 1.0 platform. So we wanted to come in at 2.0 and try to improve that process. We wanted visual designs that allow for customizations but with guardrails. We wanted to be ADA compliant out of the box and customizable options without the need of a developer. We started off with Figma designs. If anybody in here familiar with Figma, awesome. I really liked it. We were able to collaborate, provide feedback and refine those designs when we first received them. So when the front end developers rolled on, I actually had one of them go through all the Figma designs and make comments of what may impact us developing that as part of a Drupal theme. What do we need to tweak? What do we need to refine to make sure that it can be ADA compliant? Things like that were very valuable in being able to capture and do that process. Right in Figma, know exactly where as that collaborate with ABA, collaborate amongst ourselves and get from this. Then we created some additional designs and like for the remainder of the site. And then we landed on these homepage designs. And our approach going into it was we were gonna develop one theme that was customizable. And so getting into that, one of the first things we did for these stores is create a design settings page. Anybody familiar with the module config pages? Okay, I think the original approach, we were looking at maybe having a node to capture this information. But we looked at config pages which allows you to create like fieldable pages specifically for settings. So we created a design settings config page and then with certain features on this design setting. So if you see here, that main screen is a color picker and inside of that picker, bookstores can choose their primary and secondary colors and then there's a checker against the color for ADA compliance. So if they pick one and it's not compliant, they'll get an X and they'll know that's the case. They also have the ability to choose their own fonts, logo, upload a logo, upload the favor con, upload a image for their email header. And then we gave them options to choose different header options. So three different header options, they had a dropdown and then one tweak that we added, shout out to our front end developers, Adam Vaughn, Adam actually came up with this, where you can have a visual representation of what that header would look like. So if they selected a different option, you can see like a outline of what the header option looks like. And so that was a way to get a design settings page in front of the bookstore. And then you can see here, these are like what those options look like. So if you're focused more on like your brand, it's probably the bottom option. If you really want search, the middle option. And then if you're more social and you want a top, your social icons to show in the header, then we had an option for that. And then this is a little demo of actually how that looks in working. Right here, changing the color options. We show where they actually fit, maybe fill. That's what that looks like. Okay, cool. And then this is the font options. One of the tweaks that we tried to do, a lot of places, if we couldn't solve it, solve like admin UI thing with code, we definitely paid attention to the help text and different things within the admin interface to guide the stores to things properly. The visual as we change the head of, you can see what the head of does. So the next one is the getting them on board. So the process that used to be is, a member would want to get a website from us. They would come on board. We will create a website for them. It would be basically an empty website and maybe some books listed on the homepage. We would hand it over to them with a link to some help docs and we have an excellent support team to help them through the process. But still, when they received it, it was overwhelming for them. They didn't know where to start and what should be done before, what is the first step? What is the second step? And that was very confusing. And sometimes it took them like two to three months just to get the basic configurations on their site. So the whole onboarding process was tedious and that was one thing we wanted to address. One to help our stores and also to help our support team so they can have stores onboarded soon and they don't have to spend too much time training them. And sometimes stores get frustrated, they would just leave. If it is hard for them to use, they're just gonna leave. So we want to avoid that and help with the onboarding process. So again, save time and effort for indie commerce staff and bookstores. One of the things we did to address that for onboarding was we leveraged the tour module in Drupal. I'd always seen it, but I'd never used it. So this was the first time I used the tour module and we created like a custom tour. So the first time that a store logs into the website, they get a tour that takes them through this admin dashboard that we also developed. Also at the top of the screen, I think it's better here, when a site first onboards, they get this site alert at the top of the screen that takes them through the configuration steps. So step one was to set your site settings. So there was a site settings page as well. And then when you actually do that page and save it, you see on the configuration side, a little check mark gets made by each link. And then a new site alert for the next step shows up at the top. And then once a store gets through all the configuration steps, that menu moves towards the bottom of the page. And so this is kind of a way to help stores understand what options they have, where the options are, and then guides them and incentivize them to see this message and get their site set up. This is that actual tour. So step one, welcome to IndieCommerce. Then you can configure your site, know where that's at, know where, how to create your content, know how to manage your site. Here's where you manage all your commerce settings. And then you get started. And then you can see here, if you look at the top, it's gonna say take the next step to set up your site. You click edit site settings. And then you get the ability to edit those site settings. And then get the next step pulled up. I think we show that, let me show that real quick. If you have two, one thing you may wanna notice is all the default values were filled in. So that was a big plus. So when the stores received their site, although it was empty, they had some default content in it so they knew exactly what goes in there. So they were able to quickly replace the default content with the content that they need to put in. So that was like a major help for them. Just knowing what to do, in which order to do it, and what information goes with. And with the help text right under that, it was an easy process. We don't have a help tag yet for this platform. We still have almost 50 sites on the platform using the site, without the help tag. So that goes to saying how well this admin interface works. ABA has done a great job of making a feature rich website available to independent booksellers. And just as important, they've made it relatively easy to set up and easy to use. It's also ADA compliant. That's from Rossi Bound Co-op in Massachusetts. Again, this is something that some of you may have already heard. And so Drupal is too difficult for non-experts to modify. If you migrate to an easier to use platform, we would support that. This was a survey respondent. And this is like the group of members that we have who didn't want to do anything with the Drupal site because of all the complexities. They took one look at it and they know this is not like WordPress. This is not like Shopify. So let's just go there. So this was like a major thing that we needed to address in different levels. So for example, basic things like a content type. To create a new content, they had to, Drupal menu was confusing for them. Why do I have to go through so many steps just to create a page? And the most interesting thing that other, businesses won't feel is the term book page, which is a content type in Drupal. For a book seller, a book means something else. It's not a content type book page. So something very basic that people don't think about. We had to explain to stores, no, that is different from the books that you sell on the site. That's a different content type. And then you have the content types and the product classes. So you create a product class, a content type gets created. They couldn't connect the two. So there's a lot of Drupal terminologies that we needed to remove and just show them an admin interface that meets sense to them. I think one thing from the project that stuck out to me is, like I've been using Drupal. I love Drupal for its flexibility and all the things that it can do. But we have to realize that a lot of times the people we're building these sites for, they necessarily don't want all of the flexibility of Drupal. They want flexibility for what they want to do and what it needs. So we really wanted to focus on using Drupal to build a system that they can use versus giving the indie bookstores a Drupal site. And I think with IndieCommerce 1.0, in looking at it and logging in, that's really what it was, is they had a Drupal site, they could create views, they could create blocks. But for an independent bookstore who's focused on selling books, that could be very overwhelming. So a lot of things that we tried to do was pull back the Drupalism stuff and then kind of give them a IndieCommerce 2.0 experience. And so that came with the goal of make site administration easier to use for staff. And one thing we did, we leveraged Claro. We had the ability to have some amazing developers who knew a lot about Claro to join our team to help us with this. And we created a custom admin dashboard that put what sales upfront, the orders to make it easier for stores to see what orders that they needed to process. They could manage all of their content, create content, and configure their site all from one screen. And I think we walked through that here. So if you see right here at the top, this is a custom admin dashboard when the site users log in. At the top, you can easily see what revenue, completed orders, product sold, and then it had a filter where you can see those same metrics the past seven days, past 30 days. And that's also permission specific. So if you don't have permissions to see those sales, you don't get that. I just passed by, but there's also a block for orders. So site admins can easily log in and see the orders that needed to be, the new orders that came in, orders that were in processing, and orders that were payment pending. And then with the sidebar menu, we really paid attention to try again, take away the droop of words, use words that bookstores understood and put it front and center in one place where they can get to all of these things. So again, all of the commerce settings in one menu block, all the places where you can configure things in one block, all the things where you can create new types of content in one menu block so that stores can quickly get to the things that they needed to get to right here. And then on the admin interface side, when you're on these forms, when you're creating pieces of content, we really tried to pay attention to the terminology that was used in health techs. We really tried to find ways where we can enhance just the experience of an admin to understand what they needed to create. And the right blocks, as Albert explained, they are also controlled by the roles. So there are three different roles. You have the main site admin who has access to everything, and you have the content creators and the order managers. So the content creators wouldn't see the configuration because they're not supposed to touch that. Only the site admins can see the configuration. And just as this plan, we just showed a little bit, but we utilized the recurring events module as well, which has been very helpful for bookstores who wanna create monthly book club meetings and reoccurring events. So, and then a lot of the commerce stuff, and we'll look at it here in a second, but we were able to really build upon it and customize it specifically for bookstores. And then, yeah, along with the dashboard, we also have the left admin menu that was customizable that contains those same menu items, and that menu travels with the admin throughout the site. So if they were looking at the front end, they can still quickly administer content right there from that left side menu. And then this gets us to the homepage. So we wanted to make the configuration and setup of a homepage very simple. So we didn't use layout builder. We didn't use anything fancy. We tried to keep everything in one content type we created called homepage. One other advantage of this being a content type is stores could set up multiple homepages, maybe it's for Christmas season or a certain holiday, and then they can already have it preset up, make it active, and then that would be their new homepage. Some of the features that we wanted to bring to this homepage were ADA compliant slider. We wanted the ability for stores to highlight images and get to certain pieces of content, whether that's highlighting a book club meeting, whether that's highlighting a new release, to use a CTA feature, icon navigation, image roles, and product list. Let's look a little bit of that. You know that. Yeah, this is just a clip of the homepage. So the homepage is an important page for our members, like any website that's where customers are going to land. So they like, they have excellent images, but they just didn't have a way to just save them on the homepage on the D7 site. They had to create a block and then a couple of steps they had to take. So we made everything easier on this platform. So the CTA blocks and the image roles were excellent tools for them to quickly add the images and also the alt text are required. Any place where an image is uploaded, the alt text is required. It's part of this. So they don't have to worry about it. They have to put it in to save the images. I don't know if you all saw those two blocks, but that was another example of some things that we did in the admin for the CTA blocks. You could actually see which placement, hold on one second. So right there, you can actually see the placement of each item of how it would look in the CTA. And then we also expanded the disem customization to focal point in the crop module where we also provided examples of like, or options for a crop for each position. So if you were like, CTA number one, there's a crop where you can use the crop to crop for that specific size. So I thought that was a really neat feature that we were able to add to give that visual representation from the admin dashboard of how things would look. So that was the admin, they're adding the CTAs. You could also add product list, which was, I think previously when you added product list, you had to use a view in any commerce one and they would create a new view for every product list, a new block. And then this is after the site, that's the slider at the top. That's the CTA images below that. The icon row where they can choose from a preset list of icons, image row, so they can promote different features throughout the bookstore and then these are the book list. Content type we wanted to address was the product list. So for a bookstore on the homepage, all they're looking for is to display some books and they like to change it every week. Like for example, we have every Tuesday is the date when new books get published. So on Tuesdays they would upload their this week's new releases and they may have some bestsellers, like the New York Times bestsellers if they want that. So they like to, their requirement was to be able to create the book list easily, display it on the homepage and have a nice display. Like the only way they could do it was using views. Yes, as a developer we love the views, but stores cannot use it. And just to customize it and even to make a display that looks like a carousel, it was really hard for them to do it. And they do it on one page, they have to create another view for another page and sometimes it's so hard that they forget to update their pages and they may have this week's release for two weeks because they don't have the time to change it. So we wanted to make that an easier process for them. So we kind of updated the whole product list on 2.0. And product list, the cool thing about that is you could use an ISBN, like any ISBN from any book and just add it to the product list. You'd also have a multiple, like a long list of ISBNs and do a book upload from the product list node. We also leverage config pages again for e-commerce settings. So instead of a store needing to go to commerce in the menu, drop down, go over, if anybody has used commerce, we put all of the settings in one place so that a store could go to one page and then edit all of their payment methods, all of their shipping types, their tax settings, their checkout settings. We had where stores can insert all of their custom message text. So when, what shows on the screen after a customer checks out, what's the text that goes into an email. All of that is in one screen on e-commerce settings where a store can modify. And we did the same thing for a fulfillment settings page because at bookstores, they have a lot of fulfillment rules. Some of them do wholesaler fulfillment. Some of them only do like local store inventory. And so anything around fulfillment, we kind of did the same thing where we were able to put everything all on one screen. So this is a feedback that we got. This is Malik Books in California was the one that we showed the homepage. So using the 2.0 platform was really a stress-free experience. The admin interface was one of the easiest systems I've ever used. Everything was truly simple. This is a kind of feedback that we are currently receiving from stores who are using the new platform. This is a complete contrast to what we were receiving before for our old platform. So all the work that we have done is definitely paying off for our members. And this is another store-fined framework shop which is actually on our old platform. And now they are on the new platform and they are comparing the two and they can easily tell the difference in how easy it is to set up this 2.0. Next thing we'll look at, we wanted to improve the cart and checkout experience for new customers. With the cart and using commerce, we could talk a long time for the customizations and the things we added to it, but we wanted to make sure you can have guest checkout, in-store pickup, paid store payment methods, multiple payment methods, gift receipts, customer comments, where a store could send a customer a comment from the order screen, as well as a customer can send a comment to the store during an order. Automatic promotions, gift card adjustments, looking at that checkout process real quick. So the highlighted thing that you see there is actually coming from our book database system. So the availability of the book, that's the key data that a store needs to show their customers. So we are integrating our IndieCommerce 2.0 with our book database system. It has stock information, it has availability information, and that is available to anyone who signs into our platform. That is part of the website that they get. Guest checkout. Something happened during, while we go through that, something happened during COVID that many of our members stores got new customers. They didn't want to create accounts. The loyal customers knew their stores very well. So they were fine with creating accounts, but the new customers did not want any account or nothing on their website. So we didn't have guest checkout before, but we added guest checkout on this. Yeah, I think one thing you'll see right at the end of this video too is we still made the option for a store to convert that guest checkout user to a site user by after checkout still having the ability to sign up as a user as an option. I think you'll see that right at the bottom of this screen. So it can still create their account. Next one. Then we wanted to improve the order processing experience. So the site where stores are processing their orders. I'm gonna go right to the screenshot to see. This is a lot, but to customize it, we customized the order screen. So we created things like order tags, which was something custom. Again, you can search by payment method, shipping method, order status, tags, payment status. If it's a gift card or not. And then on the actual order, if you see right there stock information, this is something that we did specific at Wardo. Sitting right here actually was the person who did this, but it's actually pulling in from the warehouse, the book distributor warehouse to say how much stock is available at the warehouse. So as the store is processing the order, they can see in real time how many books that the actual warehouse has on hand. We also added like on the side, there's some fraud prevention stuff on here. Again, you can go to tags, you can look at different order activity with all the messages from customers, to customers, and just everything in one screen. And then we talked briefly about the book database system. I think that's actually the magic behind what IndieCommerce provides is because any bookstore can sell up to what 14 million plus titles. And we're tapped into the database and what we did was the books actually don't get imported into the system into a certain time. So if you would need to go to a page by ISBN. So if you go to any book with ISBN, the URL, it automatically imports the book into the site's database. So it's like optimized to only import the books on the site that either the site wants or the customer is one of you. So if you go to a book, if you add it to the cart, if you add it to a product list, or if you do like a import through categories, you can pull those books into your site. We're also integrated, we did integration with Libro FM, integration with Kobo for eBooks. Again, you saw where that Ingram warehouse data about stock was there as well as different point of sale systems. In order to eliminate the need to get, use embed codes from newsletter services, we created like an integration where you can use the API key and then select like from that, which like contacts bucket in one of those particular constant contact or mailchimp. And just by filling out the settings, you would then have a form that then fed into these platforms without needing to have an embed code or use that from anywhere from those sites. Again, we integrated with authorize.net, PayPal, Square, taxjar, stamps.com and pirate ship. This again, just talking about the ways books are imported. When a page is visited, when a book is added to the cart, when a book is added to a product list, and when a book is imported by a category. So lessons learned, the value and importance of an outsider's perspective. We knew that's always the case, but this just proved that it's important because we know our business, we know our members. But, and we have a very close, unlike I don't know about other businesses, but we have a very close relationship with our members and our clients. Some are very friendly. So sometimes we don't think the right way. We have to get somebody else's perspective and that was definitely important. And trust and respect between two teams that has helped us move forward. We have worked with the team for almost two years now. I've worked with Albert Moore and I've worked with some of my own colleagues at ABA. So it is the trust that helps us get through some of the difficult things. And we didn't agree all the time, and that's fine. One thing I say on that, I think the outsider's perspective also goes both ways. I think as developers and like on the Lullaby side, we need the client's perspective a lot of times to make certain decisions. Cause we may be thinking this is how we've developed something in the past. This is how we would typically develop it. But getting the client perspective is like the outsider's perspective in the development, on the development side. And then I think with the trust and respect, I think we really built that by looking at the project as one team. So we were all on the same team moving towards the same goal. And I think that helped to foster that trust and respect. And the next screen here is mostly from the developers team from RN, the sysadmin and the developers. So the code review, the QA process, the local dev and the CI workflow. For us, we did not attempt any of this before because we were a very small team. Code review was not possible. If we had three developers, two people have to review one person's thing. If one person is out, then there's no code review there that way. So it was hard for us to do, so we never did it. But once we got into the process during this project, then we still continue to do it. Because once we are there, we knew how to work that into our workflow. So that's definitely a plus for us in this whole experience. The local dev, so they're able to set up a local dev with content in it. So that means they can easily fix bugs or they can create new features. And it's also so much easier for us to onboard a new developer. Because now they have everything they need to start working. The CI workflow, we went from a multi-site Drupal install to individual installs. And we knew that was going to be a major change for us. But having the CI workflow, shout out to Sally, it actually made things easy for us. So now we have, I think, about 60 stores on the platform. And we can launch any code updates in like 10 minutes across all the 60 sites. And we are not worried about doing it for 600 sites in the near future. And I think the last activity policy. Okay, the release management, and the release management, again, it goes back to, so we have to, our custom has been, our members ask for something, we have to do it right away. We have to fix bugs right away. So we were not able to use the proper release management. So there was always a stress around releasing code because it happened. The only day we didn't do a code release was a Friday. Any other day, we had to do it. But with the release management, I think it gives everyone some peace of mind. So we have a preset pre-release date and some time for QEA to come in and test it. And then we have the release date. I think it sets the expectations for us and for our members, and that's a good thing. And project management, what Albert talked about, the ethics and faces with the project this huge, breaking it into small chunks and addressing it like one week at a time or one month at a time. Actually, it's helping us. We still have a long way to go. The platform is ready. We still have close to 600 sites to migrate. So I'm hoping that the project management is gonna help me for the next few months as I get all those migrated over. Awesome, and I think that last one was be prepared for roadblocks and delays. We know in our projects that's gonna happen. And so the thing that we have to make sure to remember is be prepared for them. And then sometimes not only just be prepared, but how can you maybe use them to your advantage? So sometimes a delay or a roadblock that may give you more time to do testing. Maybe you needed to slow down because you were moving too fast. It also allowed us to just kind of make sure we stayed on track and refocus, but always be prepared for those roadblocks and delays. A commerce team that helps with the whole project. We are distributed, so we never used to be in office, but now we are completely remote. We're distributed as well, but we were able to all get together. That's the team at last year's retreat for everyone who worked on the project. And then this was the team giving a toast to the end of the project. Because I think most of us was rolling off about that time. But it was a great time. We really enjoyed working with ABA. I enjoyed working with all the team members on both sides. And yeah, that was it. Yeah, yeah, if you have any questions, anybody have any questions? Okay, if you do. It used to be a policy of not having stores that are online only. But again, COVID changed so many things for us. And that was one of the things that many stores where came in. They saw the boom in online business and many people started their own online only stores. The reason we still don't encourage it is the fulfillment part of it. They're enthusiastic about getting their website and that works fine. But when they get orders, they struggle fulfilling the orders. So we try to kind of gauge what their capabilities are before we get them on board. ABA has a lot of online only stores. We just don't get them on our platform. I wanna thank everybody for attending. I appreciate y'all. Hope everybody has a great rest of DrupalCon.