Crafting Seamless Experiences: Leveraging Single Page Applications for WordPress Integrations
Hey, guys. Hey. I'm good. All right. Thanks for the introduction. Hopefully, this microphone is put in the right direction here.
I'm too short for electrons of this size. I'm going to stand up to the side a little bit if the camera's going to let me allow. Yeah. My name is Ross.
I'm your token Australian 2:30 p.m. speaker. Apparently the three of us up on stage, which is pretty amazing.
It totally see us turn 23. So I'm going to be talking to you about my journey of making single page applications and the challenges that we had and how we overcame those challenges. Specifically, we were implementing them into WordPress environment. So hopefully this will be of value to you.
So I as get a feel of who was in the room, so who would be a complete beginner, Is it a beginner like a WordPress user? How many of those would there be? Just say but none perfect at intermediate? Who would who identify as an intermediate? Okay. Who would be a hardcore developer in WordPress? Okay, so the majority so who here knows what single page application is? Okay, let's cool Berlin's Who here is Australian? I'm not that nice, right? Clearly at home then I'm alright. The firstly I just wanted to kind of make clear is that I am not first and foremost a WordPress developer, I am a software developer and kind of business analyst is probably the best way to describe my team doesn't work directly in WordPress, but we do work with our sister business house Digital, who does 100% WordPress and we have a lot of crossover projects. So moving along, it's going to help if you housekeeping's that I just wanted to get through first. If you didn't nurse in Australian, we generally like to take the piss wherever we can.
Taking the piss is definitely different to taking a piss. It's just the translation. It's making light fun of usually ourselves and Mr. Muhlenberg just tweeted I think a couple of weeks ago that he wanted more art at WordCamp, so I thought I'd answer that call and instead of using stock images in my email slides, I've got some age generated stuff. So this is apparently in Australian writing a kangaroo, which is, yeah, there's a few more to come, but that's just a taste. A second thing is reminder I'm Australian, so not only do we have a bit of an accent that you might have picked up on, but we pronounce some things differently.
So as a bit of a public service, I thought that we would just get a few things out of the way ahead of time. How do you guys pronounce this? We pronounce it case. Okay, so it's this this case.
So I'm going to say this a few times, most likely. Hopefully you don't get confused. Sorry. How do you guys pronounce this? All right, Well. Oh, we got a mixed result. They said that again.
Who is that niche or niche? There's no T in there. We said niche. So it just just heads up this one. Oh, this is a mixed one. I was expecting this. All right.
So we said we said data, and he picked us for analysis. It's actually pronounced EMU. You could add a Y in there inexplicably, but we get to choose how I pronounce it. So. All right, let's get to the good stuff. So I mentioned before that my team and I develop custom software applications mostly for very niche purposes where there's no existing off the shelf platform already available. So usually that has some very sort of, I guess, requirements that are, that are we workflows that are very unique, that sort of thing.
And that is there's nothing that suits them. So we've developed completely custom solutions. We use frameworks like Laravel and Vue.js to deliver that. But the concept of space isn't unique to these technologies.
So super page applications you can develop in React and a number of other JavaScript frameworks as well. But the examples and cases I'm going to be using today do messages that framework. I was going to have this slide just say I hate WordPress, but I thought they might be like riots or something and then like kicking off stage and I thought it was prudent that I change it. But the key thing that I just wanted to have everybody take away from this slide is that I think there's a lot of situations where people try and use WordPress and they probably should not say that Who thinks that medical information should be stored inside WordPress, for example? Anybody hoping to like search somebody out of the room using some like fire information or that type of stuff, sensitive information should be sort of probably not right? Yeah, that's the main thing. I just want to sort of sort of communicate. So I guess the question here is so so why not WordPress? I mean, there's the obvious one, right? So the obvious one is security.
If you're going to be storing sensitive information in there, unless you have the budget of NACER, unless you have the budget of the NSA like that, you really shouldn't be storing this sort of stuff in the platform and the next things that I just wanted to go through is, is the performance. So who here loves from mid-table who think, Oh, really? Yeah. Okay, let's talk after the mid-table, in my opinion, is absolutely terrible.
I think it's one of the biggest limitations in WordPress and it's holding the platform back. But I mean, in WordPress you can do custom tables. You even put those tables in different databases if you want.
But ultimately, if you're working with large datasets, if you're working with stuff that's you want to be secure, that sort of stuff, I think that's storing things in custom prototypes and so forth is always the best sort of solution. And then there's the flexibility side of things. So the querying sort of aspect of WordPress is is very limiting.
And if you really want to be storing in data in the, in the best possible way slots normalized and you've got discrete data, then I'm not too sure that WordPress is the best solution on that front as well. So you can use CBT, you can use taxonomies, you can even have relationships between them. This fantastic plugins like pods and so forth allows you to do that, but yeah, from flexibility standpoint, particularly for a lot of our use cases, WordPress is not always the best way to store that type of information.
So is everybody on the same page with me about why we may not want to use WordPress for storing sort of this type of information? Come the question becomes like you might be sitting there going across like if you go into all this trouble making these sort of fancy back end systems for people and custom software and and so forth, why the hell are you just making them a custom website and first of all, like I'm a terrible web designer, but and I'm a terrible designer and just in general, but there's a lot more that goes into sort of coding a website than than just doing the actual technical coding itself. So I'm not an expert in that area. But more importantly, I think we need to sort of consider these types of things. So there's an expectation that things are in WordPress, right? What what's the percentage now? 60 plus percent, What is it, 65% of CMS is a WordPress customers generally, if they're coming to us, they're generally asking for or coming to our Web press agency. They'll be asking for WordPress solution the shelf.
So it's definitely expectation that if you're building something these days that it will be on WordPress for the most part. The other aspect of it is that most of most of the customers, at least that we deal with, still want to be able to control like the design and so forth on the website. And frankly, we were talking with some folks earlier and everybody is moving towards this aspect of just designing directly within WordPress from the beginning. So being able to use things like the new sort of block builder, particularly with 6.3 you just released,
use use page builders having all that sort of flexibility, we're not going be able to do that sort of stuff for a customer in a in a custom solution. So it just doesn't make sense to try and reinvent the wheel. And then the maintainability aspect of it, this is pretty broad, but at the end of the day, the WordPress backend is becoming pretty ubiquitous. We would kind of having discussions over the last year or so that it's it's almost a life skill these days, like it's an expectation for in some instances people just know how to update content on a backend. So it just doesn't make sense for us to be creating tools to be, particularly if you're updating blog posts, if you if you're creating blog posts, they should be stored in WordPress. It's just the way it is. But everybody agree.
So the point is, but it is more artwork for you if you want these apparently these platypuses, the AI is just as confused about what platypuses are and how they function as the rest of the world. I think the way they're playing Jenga has been a roulette and then as well. But hopefully that gives you a little bit of background in what I do and how I do it and why I do it and that sort of stuff.
But let's talk about the actual case study that I wanted to go through today. So this particular customer is a collective giving circle. They are a membership based charitable organization that manages a grant pool each year, and the members themselves are actually the ones that get to vote about where the money goes and where the membership grants go at the end of the year, which is, which is pretty cool, right? But the challenge that they have is that it's got so much admin overhead, so they need to manage the members and then we're using a third party CRM for that.
They do manage all of their donations that are incoming and they had a specific donations platform that they were using for that, for taking the donations on a regular basis. Then they have an email marketing platform, they had a zillion Microsoft Excel spreadsheets floating around, and then they also have their website, WordPress, and they were trying to connect it all together with this API and it was just creating way more work for them than it was actually saving, frankly, to try and connect all this stuff together, to fix up all the issues that they had as a result of Zapier not doing its thing directly. And so, yeah, I mean, the challenge that it has, they wanted to drastically reduce the number of volunteer hours that were getting expended on on managing all of this stuff. And they also wanted to give a good experience overall to their members and hopefully retain more members and and grow their member base. And just in general, they wanted to give up, I guess, an overall good experience, particularly on the website and any sort of digital communications that they were interacting with or digital assets or interacting with. So the name of the organization is 100 Women.
If you Google them, you'll probably get a U.S. organization which is not related to them whatsoever. So if you are going to stop them, make sure you put the word Australia on the end of it.
If anybody wants a website lead, you can go and check out the US guys for that. They they need a website. Just send. Hopefully that was as diplomatic as I could be.
But yeah, as you can see that they came to us, they needed a solution for making sure that whatever we built was going to integrate delightfully with a new WordPress website that was getting built. We accept that the challenge. Is there any other fans who really No one watching them? You know, you will get this reference and she's I'm so confused. All right, so how could we have built this thing? No, skipped ahead.
But how how could we have built this? If we wanted to be comfortable, we could have used one option, which was iframes, right? Who? Who loves iframes? Perfect. I've got thing. I've got my message across. But terrible for responsiveness. Questionable. So I guess design flexibility is just not right. You don't have access to the document object model inside it.
They're fantastic. Second option we could have done is built additional API endpoints on our custom software. Then we could have had some sort of code base or plug in inside WordPress and communicate it that way and then presented whatever interface we needed on the front end of the women website. That doesn't sound like fun. We don't really want to be managing multiple code bases, I guess unnecessarily, and then we would have to manage all the API endpoints as well. It would just be a nightmare in my opinion.
And we had a long term vision for where we were going with with this customer and what they were going to need down the track. So if we were just building a single kind of contact form, then API would make sense. But that wasn't the case. We could have built the entire thing in WordPress, right? That was an option. I took some explaining why that wasn't an option before we could have built everything. Well, some of these forms and gravity forms where we just wouldn't be able to have the business logic.
I guess, and smarts in the system that we kind of needed or wanted and that become more prevalent when we look through the things in the letter slides. The other option is just and this is very common with SAS products, is that you just simply put it on another domain, right? So the problem with that is it's just a terrible user experience for for most of the people involved. So if you are sending somebody off site, for an example, some of these space that we're building a fairly minor things like just simply taking a single donation.
So who likes being directed off a site so they can put in their credit card details, make a donation, be redirected back onto the site? Who Everybody loved that we didn't want to go down that route. So through an admin and we use this space. So just I mean, it sounds like a lot of people didn't know what space were, but I just wanted to quickly give a very top level sort of overview of how they function. So when you have a traditional client, a traditional website, so the blue section over here is your traditional website, you type in your web address browser, which is the client, but it is often gets or requests, I guess that that website service sends back a document. And then if you decide that you want to change page or you want to interact with it in some way, then it's essentially another request. And then you get back an entire extra page that you then register to the.
So the browser does everybody kind of understand basic how browsers work. You have to hopefully that word, press conference, everything. That's how that works. So this is a slightly different the initial sort of page request is there obviously, but any subsequent sort of requests are typically done in some form of JavaScript and most of the time it's returned in some sort of JSON format, but not always. But the point here is that you're able to navigate around the SBA without having to have page refreshes. And this particular architecture is just has a lot of benefits.
But it's the biggest one is that it's just significantly faster. If you have used an SBA before. Well, the disclaimers that are just one of the point, as the SBA is absolutely terrible for SEO, most crawlers won't be able to crawl them. So don't go. Trying to put actual useful content into SBA is most of the time when we use all of the time when we're using SBA as they are being used in situations where it's we just simply don't care that it's not being indexed.
So we don't do not care that the donation form is not being indexed. We we don't even want the member portal backend to be indexed. That seems ridiculous. So from, from, from a lesser perspective, it's kind of a non-issue. So I guess the point is here, don't on create a blog interface I guess that is built on an SBA architecture disclaimer to and this is kind of something that was brought to my forefront yesterday is that SBA is can be pretty terrible for accessibility and most of the issue comes as a result of of the fact that if you could imagine that you that you don't have vision and you're attempting to browse around an SBA and it is changing what is in the document object model, but you're not being brought to the place in the form that you would expect to be brought.
Then it can be very, very confusing. So if you click the next button to move on to the next page, for example, then if you're not brought to the top of that page or you're not, you're not even told that you have changed a page, then that's incredibly confusing for a lot of people using screenwriter's and so forth. So just to show that if you are going to implement them, try and make them accessible, please make them accessible. We did a bit of accessibility testing last night and surprisingly as other better than I thought they were.
So we're going to be talking with some of the accessibility folks that hopefully suffering and getting them tested out. So that'll be cool. All right.
So I mean, this is basically how SBA is implemented. It's super, super simple. This is what we hand off to WordPress kind of division, I guess. So it's a run through what's he is not very much, but you have a container which is just a div.
Generally that container will have a unique identifier on it. And then the second part of it is just a single JavaScript file that will render all of the hitched email and go and get all of the other required assets and it'll render it inside that div container. So SBA is can be full screen. A lot of them are full screen.
They are the actual thing that you're looking at in the browser in 100% of the ones that we use before, we actually embed them inside pages because they're generally not an application in and of themselves. They are to say a particular I guess, portal or a component I guess of the the overall solution. And you'll see that on a few slides.
I think I've covered everything there. So let's have a look at some of the results. So this is a screenshot from the Become a member. So this is if somebody wants to become a member of women, they would click on the big purple button at the top there and this is what they would be shown. There's actually some text above this, but we removed it for the screenshot purposes, but the not sure where I put my pointer, I was expecting to be walking around so I put my pointer down.
But the area that is around that form there is actually the rest of the website. In this particular example, it's using the elemental and the that div that I showed in the previous slide is simply just put into that position. This is a very basic two page form and you might be asking yourself, why the hell are you using a space to to build a two page form? This doesn't make any sense, but there's a lot of good reasons for it. In this particular instance, we're doing a lot of things like checking if this user might already be a member. For example, We don't want people signing up twice to be a member.
It is looking at how they found out about 100 women, for example, in that particular field is something that is managed in the in our CRM. And there's a lot of business logic also for you to go further down, which you can't. There's a lot of business logic around the types of memberships that are available and how they get sort of how they sign up for them and what the rules are around them and so forth.
So we could do something like this in gravity forms, but we couldn't quite get 100%. We would need to say, have graphic forms go off and sort of pull from API endpoints to do all of the things that we're doing on this form during the signup process. This one's even simpler, frankly. It's women. As I said, they're a collective giving pool. They they get membership fees and then they all vote on where that money is going to go.
But people need to actually apply for the grant, those grants themselves in the first place. So this is kind of the first step of actually applying for that grant. And this is a custom system which manages all of the the the grants.
It's just one component of the backend system that was built for them. This is just the front end interface where they put in a single email address. It will generate a unique token and then send them an email with a unique link which they can use to even stop their application or even continue an existing application.
And obviously to achieve that, we would need to have integration with the back end. So that would be another API, End Point if we had to do that with gravity forms. So this is the actual application process itself. There's eight tabs here.
There's a lot of stuff here that it's asking for, but once again, there's so much business logic in here that what we could do it in gravity forms and visually it's possible to do in gravity forms, but we just wouldn't be able to have the same types of smarts that that we have. Or if we wanted to, we would have to do a lot of gravity forms kind of programing unnecessarily. This is a screenshot of inside that member portal and it has all the things that you would expect inside a member for before we can change the details, you can change your membership level, all that sort of stuff. But the key thing to kind of have a look at here is that we have a navigation sort of portion at the top of the screen that that is outside of the SBA.
And I'm going to get into a little bit more details very soon about how we kind of achieve that. But it's an example of where you would want to you would want to show, I guess, a logout button If you logged in, you don't want to show that logout button if they're not logged in, you don't really want to say the navigation if they're not logged in as well. And if that happened to kind of log into the member portal and browse around the website, you need some sort of mechanism to allow them to get back inside the member portal as well, right. If they're still logged in as far as the browser is concerned.
So what were the challenges that we had? You can enjoy this artwork as Kermit. I don't know if you guys have seen the name of of of this. Why is my code working? One of the issues that we had was just by virtue of how Esper's work most of the time, at least in Vue.js, they add this little hash
to the end of the URL, which is a bit of a pain. They asked us in our particular in this use case, it wasn't an issue because it only appeared on the pages where the space is present. It doesn't really matter if you go into the member portal page and there's a log in there and this happens to be a hash in the URL. But we have had we do have another implementations where we have forms, for example, that are on the home page and we've had to find workarounds for how to remove that hash.
So that's something that's just on the Vue.js framework. It wasn't a huge issue, but it's just something to kind of keep in mind if you are planning ahead to use this type of tech. I guess the second thing that we had a problem with was caching. And it's in particular, it's not necessarily caching of the content or the delivery of what's coming by the SBA.
It's more the delivery of that JavaScript file itself. So by default, WP rocket and all the other caching plug ins and even say Cloudflare will case that JavaScript file, which is fine. But when we're doing fast iterative, I guess changes to our backend systems and we're having to deploy sort of push pull regularly, it's it's a pain in the ass having to sort of clear classification, clear internal sort of site as well. So just keep it in mind.
We actually have it not just for ease of use but the main you guys are not going to see that is not how I met your mother fans. But I mean, we did have some major challenges. So they're not major challenges, but that's what it's the reason people are here today, I guess. So how do we make this sort of appeal visually seamless? That's that's kind of the key.
So for the end users and one of the big sort of keys that is the access asset aspect of it, we found the best sort of approach to this is with in our space, just simply not trying for any cost whatsoever. Let the website itself determine that. And in our particular case, for the most part, 90% of the design that you saw there is actually being, I guess, rendered from the sea assessors already defined within an element of button designs, come across all the phone fields, come across in the same designs, a lot of the padding and so forth between fields looks, looks good.
There should be some tweaking as you sometimes inevitably have to do, but for the most part we just need to make sure that we had sort of unique identifiers and classes and the relative sort of components, I guess, and just made sure that it was structurally good from a semantic perspective and then handle things in in WordPress. This is just an example of how it also shows on mobile. So once again, we're showing the member area sorry, the markup, which is a kind of read on any of these screens. The my account button is, is showing obviously when when the logged in logged out button shows and they're logged in and they've got a member log in when they're not logged in, pretty simple stuff. Right.
And we found the easiest way to manage this was in our actual SBA is to store a very deliberate variable in the look of storage, which essentially just has a token. And when the token is present, it just means users logged in. That means that we can just use basic JavaScript or jQuery in this case to determine when they're logged in and then just hide and show each of the elements when we need to. So it's pretty simple sort of stuff. One of the biggest things that I see so from a security perspective, one of the biggest benefits that we have is the Laravel framework itself. So we don't have to worry as much about things like fuel injection, other types of vulnerabilities is because the framework just takes care of it.
But one of the biggest sort of security risks that I think is an issue in this type of implementation is just making sure that we have best practice course policy. And so those who don't know what that is, it's just a policy that defines who is able to embed and use that application on their website. So we obviously don't want people just being able to grab our code, punch it into any website, and that would be a recipe for disaster.
You have all sorts of phishing problems going on and yeah, the sky's the limit in terms of what you could do that. The thing is, in some situations you may want that being able to be embedded. So there's a lot of companies that just use this type of technology. So HubSpot, for example, they have as part of their standard form sort of set up is an SBA. It runs a piece of JavaScript, it produces a form and you're able to embed it on your website. So in this situation, it makes sense, which we haven't done for time here.
But the question we asked it like, did this implementation work? And I would say that it did. We were able to deliver a solution that works seamlessly with the women website and we'll be continuing to sort of use these in future and just some examples of how we're starting to use those. We've implemented a number of sort of back end portals for our customers now using this technology because we think it's sort of the ideal technology to use to implement those. Even sort of basic contact forms, as I said, do make sense in some instances to use them. If you're doing lead capture and you are having that come into a custom developed backend system, then once again we can implement all that great business logic, while also filling out the form and provide the customer with the best possible experience. And then we're also in the process of further fleshing out capabilities of the right management systems for a couple of clients now.
So which is pretty fantastic. So that reaches the end of my talk. I got some socials, there's not too much there, but if you want to check with me, go ahead. That wraps up today's presentation. Thanks to us. Some summary questions.
So, so is it safe to say that you're you don't pass? I still would rather I of this site that you showed in the partner side, there's some kind of a plug in to that exact section of JavaScript. And then Laura, the whole actual application. And then with that being said, agree that that right view will show you. Also, as far as I how the requirements interact with the work that we're doing, touch to work with, and if so, yes, you are correct.
So we're implementing this, this code in all of those places. So in the donations page, in the membership signup page, and there's there's probably about I can't remember them, all of it on my head, but there's about ten different sort of SBA that we have implemented so far on the site. But yeah, they the website itself is billed 100 100% in WordPress except for these spaces that appear in various locations. And then the the Laravel side of things doesn't communicate back to WordPress at all.
It doesn't really have a need to because most of the important information is stored within the backend system that we have got some software solution that we have developed that can answer the question. Yeah, I have a follow up question, which is it's great that we don't need a scalpel to do that long, Let's say. Did you consider just going down the same road or did you did you kind of look for any factor to go down this road because you're going a structured application and you don't you need all the overhead of a website. Is that part of the problem with that? Why not? Yes. So so the question mainly is this
why don't we build the entire thing in Laravel is that our large approach? So why not say, Oh, mainly because our team is just more familiar with, with Laravel, That's the, that's the main. So the and, and frankly, at least in the, the non Microsoft realm, Laravel kind of has in terms of PSP frameworks is by far the largest market share. So we just we've there's a clear winner in that space and we're there so yeah so any other questions guys. Cool.
Okay. How do you say because yes that's how stuff like that, hopefully that will work. But it's a fascinating, slightly multifaceted space and workflow flow is not ideal, I'll be honest with you, But that's often always the case, right? But in this particular case, we actually set up the staging URLs, which, to be honest with you, they were just in the last site.
There wasn't really any sort of risk of them being on the life site because they're in obscure URLs and there's no data. The database itself was a staging environment for our software application, but the pages that they were on were on the live site. And then yeah, so we just fixed up all the styling on those, on those pages essentially, and, and then pulled all that styling across. So in the files. Yeah, of course they were private pages. Just correct.
And the other questions guys. Yes. What was that. Sorry about taking this. Oh taking the PCs is, is very different. So having a PC so having a piece for those who don't know is urinating somewhere and, and taking the piss is just generally, I don't know, joking around like yeah, yeah.
This is taking and then having that one. Yeah. It's, it's a great, it's, it's very clear.
I don't understand why there's a communication barrier to having some of this. Oh yeah. You can also have some peace. Does anybody know what that means and compounds it. It means you drinking. Yeah.
Is there any other questions related to the presentation? I'm happy to say other questions to one at the back. You know, this is the other stuff. Yeah. So the question is, will we're using any sort of member management system on WordPress? And the answer is no. So and that's one of the keys. Like we could have gone down the route of using something like member press or myriad of other sort of solutions for managing members, but we just didn't want a million users. Now
WordPress backend. So yeah, we obviously one of the solutions that we looked at at the beginning and weighed up the pros and cons of doing that, we could have taken something like member for us off the shelf. It was highly customized. It built all the, the, the pitch, pay for the business logic and try to build the solution entirely inside of WordPress. But in this particular instance, we just decided not to.
So hopefully that answers the question. Yeah, cool. Yes, definitely. Yeah. 100% of them use VJs because they they have to for the for the single page application kind of technology.
But the way that they render to the pages is entirely HTML. So when a single page application does eventually render the page after the page loads, the document object model is updated entirely so screen readers can effectively read it fine. No doubt you can do much more complicated space in the examples that I've given today.
And and there's I was grilled by the accessibility team yesterday about how they didn't like single page application. Say I was sweating while I was going through that process. But it turns out the way that we've implemented these for the most part is reasonably accessible.
So yeah, hopefully that kind of answers the question. So any other questions, guys? How far? I don't have a time. Me, my 45 minutes brilliance.
You know the questions. Yes. If you could change one thing about WordPress to make it more readily scalable, more friendly to space, I don't know. The thing is, SBA is a kind of a technology that you could implement into any platform, frankly. And I don't think there would need to be anything that would need to change about WordPress itself.
I'm just kind of thinking on the on on the fly here because most of the challenges that we had, ones that were related to kind of CSS and so forth. So as long as you see this as is is is good inside the WordPress platform, sorry, kind I yeah, I guess if we saw our development team as sort of filling with bootstrap which yeah, so we started off kind of rendering all the bootstrap classes to the to it initially and it was just a dog's breakfast. So you know, we had to go through and remove all of that sort of stuff.
But that's not a foreign WordPress at all that yeah, I'm not sure if I can come up with any sort of changes in general. I think if WordPress could somehow work out a way to move away from the the mid-table, that would be fantastic. But apart from that, no thanks. So hopefully that's is the question.
Any other queries? I thought I saw a hand but then it was a microphone and said cool. All right. Well I think that wraps this up, guys. Thank you very much.
2023-09-04 06:27
