Webmasters Gallery

In this episode of The Smashing Podcast, we’re talking about Web Platform Baseline. What is it, and how can it help determine your browser support policy? Drew McLellan talks to expert Rachel Andrew to find out.

Show Notes

• Mei Zhang on LinkedIn
• Mei on Medium

Weekly Update

• How To Boost Your Design Workflow With Setapp written by Rachel How
• Designing Sticky Menus: UX Guidelines written by Vitaly Friedman
• Solving Media Object Float Issues With CSS Block Formatting Contexts written by Gabriel Shoyombo
• Design Patterns Are A Better Way To Collaborate On Your Design System written by Ben Clemens
• How To Deal With Big Tooling Upgrades In Large Organizations written by Joran Quinten

Transcript

Drew: Shes a web developer and technical writer and editor. Shes currently working for Google on the Chrome team where shes a staff technical writer and content lead for web.dev and developer.chrome.com. Prior to Google, she spent 20 years as a freelancer and business owner and shes written almost countless books and articles where she excels at taking complex technical subjects and making them more readily understandable. Shes also an experienced conference speaker, able to deliver a technical talk to teach an audience about CSS layouts or a keynote to inspire them drawing from her wealth of experience developing for the web. So we know shes an experienced technical writer, teacher and developer, but did you know she once taught a Canada goose to make a bourbon cocktail? My smashing friends, please welcome back Rachel Andrew. Hi Rachel, how are you?

Rachel: I’m smashing.

Drew: Welcome back to the podcast. Its been a couple of years and theres been a change of day-to-day role for you.

Rachel: Yes, yes. I guess last time I was here it was mid pandemic and I was still editor-in-chief of Smashing Magazine and yes, these days I’m over at Google on the DevRel team with my content team sort of helping to get good docs and information out to our developers about things on the web platform.

Drew: So still in the realms of helping people learn about the web platform and assisting their busy lives, trying to keep a pace of all the new technologies and developments?

Rachel: Yes. Yeah, its kind of a perfect role for someone who spent most of their life sort of explaining things to web developers. So yeah, its great and within a really great team of people who were very dedicated to talking about all this new stuff.

Drew: So speaking of new developments and also Google, last week was Google I/O 2023, which is always an exciting time for us tech nerds because there are all sorts of announcements and updates from Google. With Google being such a large contributor to the web platform, it then becomes an exciting time to see whats been worked on for the web in particular and see what might be coming out next. I feel like we’re in a place with a web platform where its continuing to develop a fantastic pace at the moment.

Rachel: Yeah.

Drew: Those of us who have been working in the industry for a while remember the years when nothing was added in terms of browser capabilities, I mean sometimes years at a time. You were working on the web back then. Was it frustrating that things weren’t getting added or did it just make it easier to keep up?

Rachel: I think it was frustrating. You know, when we had, we had five years between IE6 and IE7 so that was kind of five years that the web platform just basically stopped because so many people were using IE6, although there were new other browsers around you couldn’t really use all the new stuff that they were putting into the browser because the majority of people coming to your website were in a browser that didn’t support it. So I think it was very frustrating because thats a very, very long time, especially when IE6 had all sorts of bugs and issues as well so that we weren’t getting fixes to things.

Rachel: It wasn’t even new features. We were dealing with problems, like bits of your content disappearing for no apparent reason. So yeah, it was frustrating, but it was very stable. Buggy but at least the bugs that we could list them, there were websites that listed all of the IE6 CSS problems, so you’d hit one and you’d be like, oh yeah, thats that. I know how to fix that. So we all became pretty expert in dealing with browser bugs basically and knowing what they were.

Drew: I remember things like Peekaboo, was it Peekaboo bug was that era.

Rachel: Yes.

Drew: And what was the website that listed them, listed them all? I can’t remember its name now, but the list of known bugs just got longer and longer and longer over time to the point where it became difficult to find the one you were, the particular bug you were experiencing because the list was so long. We were in a place back then where the dominant browser, which was Internet Explorer at the time, was the browser that was seeing the least technical innovation but that doesn’t mean there was no technical innovation because there was a broader ecosystem, but was it ever possible to use new bits of CSS that were appearing in things like Firefox? Is that something we could do when the dominant browser was so far behind?

Rachel: It was pretty hard. I mean, I think all the ideas of things like polyfills and also there was a lot of us kind of pushing the progressive enhancement story as well and saying, look, its fine, your website doesn’t need to look the same in all browsers. I think I’ve been saying that for most of my life at this point. And that was a big thing at the time because people were just sort of A/B test in the browsers, you know, there was no… you’re sensing off to your client and they would just open it in another browser and be like, “Oh no, this is wrong ’cause its three pixels out on this other browser.”

Rachel: And that was very, very common. People would talk about pixel perfect and what they would typically mean is it should be exactly the same as the PDF or whatever that you were working from or the Photoshop file and all of the browsers that they were aware of, or at least both browsers typically. So I think it was quite difficult to push the web forward at the time, you got quite a lot of resistance and you’d often have to just do it anyway and hope you’d get away with it quite a lot of the time.

Drew: We don’t seem to see that so much these days where clients or anyone really is looking at a web experience side by side in two different browsers and saying, oh, they’re not quite the same. Is that because browsers are much more standardized now and they do look the same or have the expectations changed, do you think, because of so many devices that we’re looking at, the fact that mobile devices and tablets and so many different screen sizes that has that expectation gone away?

Rachel: Yeah, I think its a bit of both, isn’t it? I think the web browser is how we do everything these days and its less of a separate bit of software, its just kind of how you use your computer and a lot of the time and I think theres less of an awareness of, oh, we should be checking this for someone who isn’t a developer, we should be checking this in the different browsers. Far more likely, I think, would be someone saying, “This doesn’t work well on my phone.” ‘Cause they’ll get the email saying, oh look at the new site, and they’re probably on their phone when they get that email and they’ll open it on their phone and then they find, oh, somethings overlaying something or its hard to get to something because of a toolbar or whatever.

Rachel: So I think its far more likely that a client is going to be coming back with that kind of problem. Maybe they’ve got an older version, an older phone that they’ve not updated and its got an older version of software on it or whatever than doing that kind of desktop A/B testing that used to be really common, even with a fairly non-technical client, they would’ve been told by someone that they should make sure it works in these browsers and so they would be doing that checking.

Drew: Yeah, I mean clients would come along to those of us who are building sites for them and they would say, right, we need this site built and it needs to work in IE6 or it needs to work in IE7 and they’d have these very definitive browser versions that things had to work in. And now between, as you mentioned, between IE6 and IE7, there was a multiple year gap, so that constraint from the client could have, it could massively impact your sort of choice of technology or design, couldn’t it?

Rachel: Oh, absolutely. Yeah, I mean that was just sort of fairly standard when you were building sites and at the time I was building sites for clients that would be on the spec for the site would be which browsers that you had to support and you would be expected to test it in those browsers and if it worked in those browsers, that was all good. That was the line that you were following.

Drew: Yeah, I guess even things, even that things were pretty limited. It was a fairly easy decision to make to say these are the browsers that we’re supporting. Its got to work in IE7 for whatever reason.

Rachel: Yeah.

Drew: It was fairly clear cut, but these days I don’t think I could even tell you what version of Chrome or Firefox or Safari I’m running or if thats the latest, I’m presuming its the latest, but its not so clear cut and straightforward now, is it?

Rachel: Right, yeah. You don’t even notice that the things update. They just update and you don’t realize if thats a major version or just some say security release thats come out that you need to update to. I don’t think most people know which features landed in which version of a browser. We used to know. We used to know exactly what was available in each browser, so it’d be like, “Oh great, this project is IE8 and therefore I’ve got, I don’t know, display table” or something that landed in that browser.

Rachel: We used to know. These days we don’t know. I know I spend all of my time documenting this stuff and writing about whats new in the web platform and even so, I’m fairly hazy. If you said to me, “Oh, what was in Chrome 113?” And I’ve just done the work on that, I’d be like, “Err, was that in that one or was that in the beta?” So the average developer then you’re not going to be able to keep track of all that stuff. Theres so much stuff landing all the time.

Drew: So it makes the situation quite difficult, doesn’t it, when you might have sometimes contracts with people you’re building stuff for and certainly expectations that theres going to be a level of browser support but its not, if you don’t know what versions things are and they move really quickly, it can be really difficult to pin down to a targeted browser version. And this is, I believe its the crux of the problem thats addressed by one of the big announcements at Google I/O. How do we figure out whats safe to use?

Rachel: Yeah, and so this is something we’ve been thinking about actually for as long as I’ve been at Google is we’ve been thinking of this top pain point that we hear from developers that they struggle to keep up with the web platform and they struggle to know what is safe to use, what is okay to roll out in production without worrying about it. Typically developers will be building for the latest versions of a site and then suddenly they’ll realize that, oh, this is broken over here and they just don’t, they didn’t realize that and to actually figure out the browser support involves going kind of property-by-property, feature-by-feature to say, can I use our MDN and looking at the compatibility data. Its all out there, but you have to do that on a feature-by-feature basis.

Rachel: And so we’re kind of thinking about this issue and it always comes up, we talk to a lot of developers and it always comes up as the top problem and so we’re thinking about how we can resolve that. And thats what kind of came to this idea of, well, can we create this line and say that everything thats passed this line has interoperability, is kind of safe to use without worrying about it. And thats where this idea of Baseline came from, to have this kind of moving line that includes all of the features that are interoperable and don’t have any major standout issues. And thats what we’re calling Baseline.

Rachel: And the whole project is its not just a Google thing, this comes from the Web DX community group. So we’re working with other browsers and other people on defining this and kind of coming up with the feature groupings so that we can try and create this clarity for developers that they’ve got a sort of line where they can say, they can look at that and say, oh yes, this thing is in Baseline and therefore I know its going to work everywhere in the most modern browsers.

Drew: So instead of saying this, we’re supporting these particular browsers, you’re saying this is a core feature set thats common across all the currently available browsers. This is a safe set of features and its that set that I’m going to be developing for compatibility with.

Rachel: Right, yeah. And that sort of takes that requirement to figure out each individual feature for, and also because we get partial implementations of stuff all the time on the platform and its like, so the kind of feature grouping part of this, it is the big piece of work really to actually identify, does the feature completely work everywhere because sometimes there will be support for things. I think one of the things that, an obvious thing that people understand is the gap property in where in Flexbox and Grid and so on. Now you could test for that. You could test for where the gap was supported and a browser would say yes because it was supported in grid layout even when it wasn’t supported in flex layout and therefore there was no way to check for this. And it was quite confusing for people if they were just doing that test. So I think theres these sort of groupings of things is also quite useful. So the things that are in Baseline are things that do work as a feature, even if that does actually involve various moving parts.

Drew: Yes, because theres been a trend from the sort of latest CSS specs to be, whats the word, sort of unifying some of the properties isn’t there rather than-

Rachel: Yes.

Drew:span> … rather than having individual properties that do the same thing in different context, using the same-

Rachel: Right.

Drew:span> … keywords across different uses.

Rachel: Yeah, so things like alignment, fragmentation, we’ve got these specifications that deal with sort of alignment across all of the different layout specs, which is great because it means that say if you want to switch from a flex to a grid layout or whatever, all the alignment stuff should work in the same way, but does mean that we potentially get these partial implementations and thats quite difficult to understand. So yeah, I think its things like that and so that theres an awful lot actually goes into the creation of this sort of feature set grouping and we’re not all the way there yet. We’re hoping to get most of CSS and JavaScript done by the end of the year because its actually quite a job just to figure out how things all fit together.

Drew: So its almost like instead of targeting a version of any particular browser, we’re targeting a version of the web platform. We’re saying-

Rachel: Yeah.

Drew:span> … look at the web platform as it is here today, these are the things that are universal, that are reliable to use and thats what we’re going to support. And anything that falls out of that boundary included because the implementation might be patchy.

Rachel: Right, yeah. It might need a bit more care. And its not saying to people, oh, you can’t ever use these things, but if you know its not in Baseline then maybe theres some things you need to think about there and it might be fine for your project or it might be that it has a good fallback or its something that is polyfillable but those are things that you do need to think about on a case-by-case basis rather than just, this should be fine to use.

Drew: I think most of us are familiar with sites like canIuse.com, which you mentioned briefly before. Is this just replicating information that already exists or is it different from can I use?

Rachel: I think its different in that, so something that can I use does, and also the MDN BCD data, they work very much on a sort of feature-by-feature basis. They don’t actually cover all of the web platform. Theres definitely, certainly Can I use has made some decisions in terms of how to group certain things. I have a long standing open issue to split out fragmentation from multicar for example, because they’re bundled together, making multicar look harder to use than it actually is because there are fragmentation bugs in there.

Rachel: So they’ve done some of the same stuff, but what we haven’t got there is this sort of full view of the platform and this idea of this is within Baseline, this is out, you still have to go to each thing and make those decisions. Ideally we’re hoping, I mean as MDN are using Baseline on feature pages, they’re rolling that out at the moment. Its probably saying that we’re hoping that Can I use, we’ll also be able to use and say, “Oh, this feature is in Baseline” as well as that more fine grained data.

Drew: And how do you make that decision to say that yes, this, not only is this supported but this is widely supported enough that we can include it in Baseline. How do you make that distinction?

Rachel: So at the moment we’re going back the last two major versions of browsers and theres been a lot of debate about that. As you can imagine. Its something thats great to [inaudible 00:17:38]. The fact is I think the line will always be wrong for if we say this is the line, two versions back, a lot of people are saying, “Oh, you should use minor versions of Safari” because we’ve seen some massive features going in doc releases because of the way that Safari do their versioning because obviously a main version of Firefox and Chrome, thats every month we’ve got a new main version. And so thats obviously up for debate. Some people are saying we should go further back. Other people are pointing out the fact that just because Chrome has updated, all of the browsers are derivatives that use chromium, they might not have updated. So I think the line will always be wrong, I think.

Rachel: But what it does give is this sort of stable view onto things. And the other thing that we’re planning to do as part of this is to have these kind of moments in time. So at the end of the year we’re going to say, right this cut is where we are at that point is going to be Baseline 24 and that will be a static line. That will be whats in Baseline at this point in time. And then in a years time we’ll do Baseline 25. And I think an interesting thing then will be the difference between those two points because I think a conservative web team could say, “Right, I am sticking with Baseline 24” even though maybe they’re well into 25, we’re sticking with this.
But the things between those two lines then I think become the things that you might want to make judgments on rather than having to look at the entire web platform and say, “Oh, can I use this? Can I use that?” And say, “Well, we’re going to use this yearly cut of Baseline.” And then the things that came after that that are in Baseline as it moves forward we’ll take a look at and see, oh, I can polyfill that or this is fine as a progressive enhancement.

Drew: It puts me in mind slightly of things like Ubuntu Linux distribution and their long-term support releases that they do.

Rachel: Right.

Drew: They’ll say, “This is the one that we offer long-term support. Its stable, its reliable to use.” And so you might adopt that and that doesn’t mean that you wouldn’t necessarily install a couple of key extra, more frequently updated packages or whatever, but you know that the system that you’re working with is sort of frozen in time and supported and is a known quantity going forward.

Rachel: Yeah.

Drew: I guess those who work in very regulated industries who sort of frequently go under contract with customers or suppliers, whatever, to say they’ll provide compatibility with certain browsers as it is at the moment. Surely this would be a very welcome change because these are actually more concrete measures that support can be tied to and its a stability thats more in line with the stability of a binding agreement than an arbitrary version number that some nerd in Silicon Valley might attach to a build of a browser.

Rachel: Right.

Drew: So you can say our platform is targeting Baseline 24 and you could keep that way for three, four years maybe.

Rachel: Yeah.

Drew: And then review it and update.

Rachel: Yeah, I like that. I like that stuff, yeah, the idea, this is a sort of stable thing and I think that that yearly release will become, I think, quite important. So I think I can see libraries and frameworks and so on tying themselves essentially to a stable release, one of the yearly cuts and then moving on. And I think it should be really interesting as well being able to see, well actually how has the platform moved on between those two yearly points? We don’t really have a look at that at the moment. I mean you could work it out, but it’d be quite a lot of work. It’d be nice just to be able to see that and see how things are changing.

Drew: I always enjoy a list of features that are included in whatever. Heres things that you can use that you won’t, perhaps weren’t aware of. And I can see how a big list of Baseline features might highlight different things that an individual developer might not be aware of that-

Rachel: Yeah.

Drew:span> … have arrived on the web platform and are ready to be used.

Rachel: Yeah, I mean the awareness is a big thing. I mean, I’ve been doing, me and a colleague as well have been doing talks, whats new on the web platform type talks and typically introducing things that are interoperable. And every time there will be people saying, “Oh, I never knew you could do that”, or “I never knew that worked. I thought that was an experimental thing.” And then realizing that its actually a feature thats in all engines. And I think that thats very, very common. So I think thats the other sort of side of this is that it also raises awareness of features that now are interoperable, that people have got an idea that the web platform moves incredibly slowly.

Rachel: I think particularly people like us who’ve been doing this for a long time and remember those days. And so people are very surprised, you know, you still see people saying about a new feature, “Oh well it’ll be five years before I can use that.” And yet you’re looking at things like container queries and cascade layers. All of these things landed cross browser very, very quickly, which is great. And I think thats a story that this can help tell as well.

Drew: So this was a big announcement from Chrome at the big Google I/O conference, but you mentioned its not just a Google thing is it, there are other parties involved. So who is deciding whats in the collective Baseline? What parties are involved in this?

Rachel: Right, yeah, so I mean obviously we partnered very closely with Mozilla and MDN in launching this. So that actually during the developer keynote we launched this on web.dev and on MDN at the same time on a select number of pages because we haven’t got a full feature site yet. But it was nice to actually show what it would look like rather than it being a kind of theoretical thing. And also MDN published a blog post about it too and their thinking. But yeah, the work has been done within the Web DX community group and that group has representatives from all of the browsers and various other people including interested developers.

Rachel: Anyone can join that group and be part of those discussions. So thats where we’re also asking people to go and comment on this stuff rather than, I mean people are very welcome to come and talk to me about it, but in terms of getting sort of information out there and discussed by the wider group, raise issues on the Web DX community group site because thats where the people are who are making the decisions. And at the moment its just fantastic to be getting the feedback into that group so that we can actually see is this solving a problem, what problems maybe we’ve missed and be able to talk about that.

Drew: So its a broader community effort, but it just so happens that the major players Google, Mozilla and everything are putting a lot of time and effort into it and really backing it as an idea.

Rachel: Yeah, yeah. And I think thats something that as DevRel, you know, as developer relations, thats kind of what we do. We try and bridge the gap between browser engineers and spec writers and the developer community. And so I think thats something that we can do as DevRel for the web is to actually bring forward these things that we think might help and see where we can take them.

Drew: Now I’ve heard about the Interop 2022 and now 2023 initiatives. Does Baseline relate to Interop at all? Or maybe you could talk us through that where it fits in?

Rachel: Yeah, I mean its kind of the same group of people certainly as Google who are involved with those projects. So the Interop project takes a set of features that if its based on web platform tests, so it takes a set of features that have some sort of interoperability problem. So it might be that they don’t work in one or more browsers or they have sort of bugs that are causing pupil problems. So we’ve got this set of features and then over the year all of the engines work to implement or fix those things. So we’ve kind of got a score, a scoreboard where you can go and look and see how everyones doing.

Rachel: So the Interop project works to fix known issues, either make things interoperable or fix books and things that look on paper like they work, but have some sort of problems. And so that project is getting more things essentially into Baseline. So they’re linked in that way and they’re a lot of the very similar people are working together on those from the browsers. So I think in terms of the relationships there and the fact that Interop did bring, for the first time, all of the vendors together in this sort of common goal to make the platform better, theres definitely a link there in terms of this is what we care about. Whereas Baselines kind of from the other side, its saying, well, okay, what is there? What is interoperable? What can we already use? So yeah, hopefully things like Interop will help to add more things to Baseline as we go along.

Drew: So it is basically just identifying things that could potentially go into Baseline, might be nearly there, and then swarming on those features to get them across the line and get them interoperable and usable on the platform because they’re seen as important or significant in some way.

Rachel: Yeah, and I mean we know that that developers aren’t going to use things in general unless they are available across all engines. So its kind of in everyones interest to work together to get to that point because then people use the stuff that we’re building so that, yeah, its said so they kind of work very well together. And I think its just this sort of spirit of collaboration and trying to make things better for developers.

Drew: We’ve talked about how developers might target, in past, a browser version and now we’re saying would target Baseline, but it works the other way around, doesn’t it? If the frameworks and the tools that we are using as dependencies in our projects, they can also declare that as a level of support. Is that right?

Rachel: Yeah, absolutely. I think thats something that we’d love to see how a framework or whatever you could say, everything that is used by this framework is Baseline or is Baseline 24 or what have you. Thats going to give a lot of clarity to developers to not then need to fish around in the framework and find out what they’re doing to make sure ’cause if you’ve got to do a certain level of browser support in your project, you need to make sure that everything you use also has that level of browser support so that it could definitely make that a lot clearer.

Rachel: And I think also things like publishing articles. One of the things that frustrates people, and I know as someone who writes and edits a lot of content, is if people get halfway through an article and then they find something that is experimental or is so new or only works in Chrome or whatever, thats really frustrating because you think, oh, I’ve found the thing that helps me solve my problem. You’re working through it and then you’re like, oh, thats not coming ’til next year. And so have been able to put on an article, everything in this article is in Baseline. That gives you a lot of confidence to go forward. So I think theres lots of uses for this out in the community and thats something we really hope will happen, that just to give that kind of clarity to developers.

Drew: Its that last section of an article, isn’t it? You’re reading along about some interesting technology and then it comes to the section of how you might work around it for the browsers that don’t support it.

Rachel: Yeah.

Drew: I thought-

Rachel: Exactly.

Drew:span> … we were into a good thing here.

Rachel: Yeah, ’cause when you’re searching, you’re searching to solve a problem, things come up. Its very frustrating if you realize that its a year away or other browsers have said we’re not doing that or whatever, you know? So yeah, I think theres a lot of opportunities for clarity for people who are writing and for developers of libraries and frameworks to actually just make it very obvious to developers what the status is.

Drew: And things like WordPress themes for example, or any of these sorts of things where you’re taking somebody elses code and making it part of your project to know that what level of support in terms of web functionality is in that is invaluable. I guess it would make sense for things like tools that any tool that gives you code to embed into your site, be that a Stripe checkout or a live chat widget or any of those sorts of things, I guess it would make sense for them to declare their state of compatibility too.

Rachel: Yeah, yeah, its just kind of a shorthand. It saves you having to do all of that investigating for each thing that you use. And we know that every website these days has tons and tons of third party stuff in it. We’re not all sitting down with Notepad anymore and carefully crafting our websites. So I think anything that makes that easier and allows people to show the status of things is really helpful.

Drew: It actually is a really simple concept, isn’t it, to say heres the set of features, they’re well supported, we’re giving it a label, we’re documenting it. Its actually so simple, its really rather genius I think. Its some amazing work thats been done there by everyone involved.

Rachel: Yeah, I think it speaks to a lot of what I’ve thought about over many years in terms of that kind of clarity. And thats always been my thing is making things clear to people, making things seem straightforward rather than trying to make things complex. And so I really love being able to be involved with this and bring it forward.

Drew: The HTML spec for example has a process for an element or an attribute to be deprecated. So things get removed from the spec as they become obsolete or they’re replaced by a newer specification. Is it possible for features to drop out of Baseline once they’ve been included?

Rachel: It could be possible. Its one of the things we’ve talked about a lot. I think really the devil will definitely be in the detail with all this stuff. And thats one of the things is well what happens if something essentially gets broken? Maybe one engine does something which causes a problem with something. There is a possibility that yes, we’d have to remove something. Thats definitely something we’ve talked about. I mean hopefully browsers aren’t going around breaking stable features, but it is a possibility or something might get deprecated although we tend not to fully remove things from the web platform very often. Its more that we say, “Yeah, maybe don’t use this,” but there is a possibility that something that is in Baseline could start to have a problem because of something that one of the engines does.

Drew: I guess then thats one area where these sort of yearly cuts as you’ve described them, become sort of quite useful in that something might have appeared in Baseline 24 but then in Baseline 30 it might be gone and there is a way of having a distinction there.

Rachel: Yeah, and it would also highlight that stuff I think a lot more clearly than we have a way of doing at the moment because I think hard to know what things have actually been deprecated on the platform. A lot of things that are deprecated are things that are only in one engine and therefore would never have been in Baseline in the first place. But yeah, it is possible as things move forward that that would happen and it would make it clearer.

Drew: And such as the way of the web, we do deprecate things, but as you say, they don’t ever go away really.

Rachel: Yeah.

Drew: We don’t-

Rachel: I was just saying maybe don’t [inaudible 00:33:42].

Drew:span> … tend to remove things, you know, can still use the, I’m guessing you can still use HTML font tags because we don’t break things once they’re standardized.

Rachel: Yeah.

Drew: Even though nobody would ever recommend using them, they’re still going to work in your browser because sites have been developed to that standard and the browser-

Rachel: Yeah.

Drew:span> … will continue to support it. I guess, in a way, theres Baseline forms a little bit of a positive pressure. If a feature does get broken, then the fact that it was in Baseline and the whole community is relying on it being there is a factor in prioritizing what gets worked on by that particular maintainer of that browser engine. They’re going to see that, no, this is important, we need to fix it pretty quick.

Rachel: Yeah.

Drew: So hopefully its a sort of positive pressure in that regard. There seems to be so much really in development and coming to the web platform. Are there any particular things that you’re really looking forward to seeing becoming interoperable in the coming months?

Rachel: Yeah, I mean theres a bunch of interesting stuff. I’ve always been interested in the things that look at things that developers are already doing. So they’re using JavaScript to do it, or what have you, and then having them built into the platform because obviously things that are built into the platform we can build in things like accessibility and also performance. Things that tend to perform an awful lot better if they’re a built-in feature as opposed to being JavaScript on top. So theres sort of interesting stuff from the open UI group. The next thing that is about to land in Chrome is the Popover API. And of course popovers are something like everybodys building all the time.

Drew: Yeah.

Rachel: And I think a lot of these open UI things are very much those sorts of features that pretty much every developer, every front end developer has built on numerous occasions. And every front end developer has tried to solve the accessibility issues and the performance issues and the sort of weird bugs that come up when they interact with other things. And so the fact that these are getting actually built into browsers, I think, is very exciting because it just, its a bunch of work you don’t have to do and its probably going to have better accessibility and so on than most people are going to be able to manage for themselves and it gives something to build on top of as well, you know, can add things to them.

Rachel: So yeah, so I’m excited to see Popover and in a similar sort of vein is the work on scroll-driven animations because thats a thing that people like to do and is very hard to do well, you know, having things that animate on scroll and that, again, is something that is coming in. It should be in Chrome 115. So it’s, again, its these things that we’re doing on the front end of the web and we’re actually able then to build into the browser. I’m always very keen to see those ’cause I think they solve a lot of problems.

Drew: Yeah, definitely. I mean anywhere where a developer has to mimic something that you think is native browser UI and you’re trying to build it yourself, there are so many places to go wrong, aren’t there?

Rachel: Yeah.

Drew: If you’ve ever had any of your work through an accessibility audit, you know that its things like modal dialogues and all these sort of things that constantly will contain flaws that need to be addressed because theres just so many things to think about in terms of keyboard focus and clicking away and all these different subtleties that you need to make sure that you take care of, that is, as much as anything, as much as it being bad for accessibility, if you get it wrong, its a massive waste of time for all us developers doing this all ourselves over and over again when it just makes sense. Most apps will have some sort of modal or popover functionality. So yeah, it makes complete sense for it to be part of the platform implemented by the browser vendors in a way where its accessible and its just a good solid layer to then build on top of in terms of styling and yeah-

Rachel: Yeah.

Drew:span> … it makes total sense. Its a exciting way to see the platform go.

Rachel: Yeah and I think, because the other thing with everyone building their own thing is that a lot of people don’t build their own thing, they rely on a third party thing and quite often things people are relying on are actually really old and they haven’t been updated to, they might have issues with accessibility or whatever and they haven’t really been updated for more modern browsers. And so its sort of, I think the more that people can use whats built into the browser, the sort of better experience that the end user of the site is likely to have.

Drew: So your team at Google maintains a bunch of resources to help developers keep up-to-date with the web platform. What are those resources and where should people go to look and find things? What would they expect to find there?

Rachel: Yeah, so we’ve got web.dev and developer.chrome.com are our two sites that DevRel own. It used to be, back in the day, when I sort of arrived, there was a real mixture of things on each site and a sort of thing that was commonly said was that Chrome were using web.dev to pretend things that were only in Chrome were stable APIs, lets say I don’t think anyone ever intended to pretend that. I think there was just a slightly disorganized content strategy. So as kind of part of the preparation for Baseline, because I wanted to make sure that we could be clear because if we’re talking about developer clarity, its pretty bad if all of our stuffs in a mess. I started moving content. And so now, certainly all the newer content, there may be some older stuff that we haven’t tracked down, but the newer content, if you go to web.dev, you should really be seeing stuff about stable APIs.

Rachel: So things that are interoperable and also things that are coming onto the platform. I do a sort of whats new on the web platform that includes some new stuff from all engines. So that kind of looking at what the broader landscape is and also things like our best practices. So things like about performance, which while some of the tooling is Chrome-only, raising the performance of your site, it is going to help in all engines. So thats whats there on web.dev. So thats kind of the practical side of things. You’re building a website, you want some advice. Thats what we’re doing there. And I try very hard to make that about the web, not about Chrome and thats the sort of content there.

Rachel: But obviously we are a team thats supporting Chrome and supporting the things that Chromes releasing and so we do that over on developer.chrome.com. So thats going to be your new APIs. You want to find out about popover thats landing, there’ll be an article about that soon. So all the things that Chrome is doing for the web, essentially you can find on developer.chrome.com. So that will be experimental things or Chrome-only things, things that are Chrome-only for now, all that stuff is there. And I hope that brings a bit of clarity to our content and that we’re not trying to pretend anything. We’re just trying to be clear about what we’re doing and how well supported it is.

Drew: Great. So we’ve been learning all about Web Platform Baseline. What have you been learning about lately, Rachel?

Rachel: Theres always something interesting to learn about. I’ve done a couple of things. I’ve been learning Python because its a language that I, for whatever reason, never learned. I’ve learned various languages over the years, but I do less web development these days and more kind of comparing of data sets and Python is the language that a lot of that stuff is done in. So its quite fun to learn new language anyway and its useful for the sort of stuff I tend to find myself doing these days.

Rachel: And I’ve also been thinking a bit about the whole generative AI space and in particular as a content lead, how do we prepare our content to make it more useful to those kind of models because theres a lot of stuff about asking questions of a chatbot and so on. And so I’ve been kind of just starting to read around that subject a little bit and start to see, well, if we’re preparing content, how can we be making that more useful for that kind of thing and that interaction?

Drew: If you, dear listener would like to hear more from Rachel, you can find her on the web at rachelandrew.co.uk where you’ll find links to her socials, her writing and numerous other projects. And you can find her writing regularly about the web platform at web.dev. Thanks for joining us today, Rachel. Did you have any parting words?

Rachel: Let us know about Baseline. Comment and raise some issues, or just join in the chat on the Web DX community group, on the GitHub repo there. We’d really like to hear what you think. This is, we’ve been talking about it internally for a long time and so now we’ve got it out there and I think the work starts now and the discussion with the community starts now. And so we’re all very, very excited to read the feedback and find out what you think.

Resources

• Baseline landing page on web.dev: https://web.dev/baseline/
• Blog post and video detailing our motivation: https://web.dev/introducing-baseline/
• “Baseline features you can use today” I/O talk: https://web.dev/baseline-features/
• Section of Google I/O developer keynote that launched Baseline: https://www.youtube.com/live/r8T0SnwHRNI?feature=share&t=2340
• The MDN announcement blog post: https://developer.mozilla.org/en-US/blog/baseline-unified-view-stable-web-features/
• The WebDX Community Group: https://www.w3.org/community/webdx/
• The feature set repo (also a good place to raise issues if you have questions): https://github.com/web-platform-dx/feature-set

The choices you make when selecting a typeface have more impact on your design than almost any other decision, so it’s good to have some options at hand.

For many, living on campus during college is an integral part of the university experience. Social engagement and academic sharing by living on campus enable students to enrich this period of higher education. Thanks to on-campus residence, students can access multiple educational extras including seminars, conferences and lectures, libraries, sporting activities, and university clubs. Communal living permits students to form lifelong friendships with peers and form closer relationships with faculty members.

Fortunately, residential technological advancements are not just limited to private residences, apartment complexes, or hotels. Now universities are integrating technological solutions into on-campus dorms to improve comfort, efficiency, and security.

Security is one of the principal concerns for parents when children leave for university. Violent crimes and mass shootings experienced across the nation at schools and on college campuses have shocked and worried families sending sons and daughters off to college.

Access Control for Increased Student Safety

Technological advances now permit the use of fobs, keypads, keycards, and mobile entry credentials. Keyless door locks now eliminate the need for students to carry keys or keycards. Doors can be opened using biometric scans or credentials in a smartphone app. This increases property protection, impedes unauthorized access, and significantly reduces the need to change locks because of lost, stolen, or misplaced keys. 

Access to common areas such as fitness centers, student lounges, study rooms, or pools can be equipped with secure entrance technology facilitating controlled entrance to all areas within on-campus housing facilities.

Technological security access systems also provide several other benefits such as logging who enters and exits a building and facilitating rapid entrance thanks to automation. 

Anomalies such as repeated use of entry credentials can be quickly identified and verified alerting university officials if access credentials have been stolen, cloned, or shared.

Cloud-based access control systems permit remote management from anywhere so that doors can be locked and unlocked at any time from anywhere eliminating the risk of students being locked out and vulnerable. 

Stolen credentials can immediately be disabled so that they cannot be used by bad actors. Credentials granted to service providers and maintenance professionals can be deactivated once tasks have been completed.

Security Video Monitoring

Campus security has always been a priority at educational institutions, but today’s generation of students has grown up in a world where video recording is the norm everywhere. This facilitates the use of video security monitoring within and around dormitory buildings. While privacy does remain a concern, pathways, parking lots, entrances, and exits that are a part of university housing facilities should all benefit from video security surveillance cameras with these areas benefiting from proper lighting. 

Now school video security monitoring systems integrate AI. This permits universities to use automation to monitor potentially suspicious behavior in real-time. Causes for worry can be identified rapidly with alerts sent to security personnel facilitating immediate intervention. Emergency responses become proactive instead of reactive. This greater level of monitoring helps to create a safer environment for students.

University dormitory administrators are also able to identify occupancy rates and times as well as usage patterns. This information can lead to better use of housing resources such as water and electricity increasing efficiency, reducing waste, and saving money.

Security video monitoring systems can integrate biometric facial recognition to improve access control efficiency and increase housing security. These systems can also be programmed to send security alerts informing residential managers and security personnel of a need for immediate intervention should unauthorized entrances be attempted, or suspicious behavior be detected.

Cloud-based video systems can permit security personnel or residential managers to view video feeds from school security camera systems remotely using mobile devices and video analytics can send notifications to security staff and local authorities.

Dorms Are Smarter

Thanks to greater connectivity, the IoT – Internet of Things together with machine learning algorithms and AI are able to collect massive amounts of data and analyze it in real time. Residential managers and building administrators can improve property management and services offered. For example, heating and cooling systems can be better managed thanks to data collection and analysis of energy consumption and occupancy patterns. Smart lighting for increased security can be tailored to meet traffic flow. Automated rapid access controls reduce building entrance time and security procedures are improved thanks to data collection and analysis.

Data collection and analysis through IoT also allows for quicker maintenance and upkeep. Smoke, carbon monoxide, and fire detection sensors can alert authorities and first responders immediately. Heating and cooling systems can signal malfunctions in real time so that repairs can be addressed promptly.

Improved Connectivity

Students require better, faster, and more reliable Wi-Fi connections along with cellular signals. Apart from completing coursework, greater reliability in connectivity also permits students to remain in contact with friends and family members, alleviating parent worries. 

Campus dorms are now boosting connectivity with better networks and routers. Students benefit from stronger signals for personal needs but so do security processes and personnel. Better connectivity permits those responsible for security and safety to benefit from monitoring without interruption and to use remote security solutions such as lockdowns should the need arise.

Alarm Systems

While alarm systems are regularly used for smoke, fire, and carbon monoxide detection, student security does not end with these three threats. Alarm systems can notify students and administrators of unauthorized accesses or break-ins, intrusions, broken glass, gunshots, and dangers in general.

Cloud-based alarm systems send out mobile alerts in real-time and offer the possibility to program automatic lockdowns or evacuations when called for. Internal and external locks can be managed to contain specific threats to a limited area within the dormitory.

All Things Considered 

Security technology now aids administrators and college security personnel in providing a safer environment for university students. Parents can feel better about their children being away at college. Thanks to technological advancements being adopted within university housing, students enjoy a better-quality residential experience. Safety and security are increased allowing students to enjoy their university experience while focusing on their studies.

Featured image by Adrien Olichon on Unsplash

The post How On-Campus Housing Security Is Transforming Thanks to Technology appeared first on noupe.

If you work in software development, you probably know a thing or two about using and maintaining third-party packages. While third-party tooling has its fair share of downsides, there are plenty of advantages as well. The efficiency you get from code that someone else has already written speeds up development and is hard to deny. Sure, there are all sorts of considerations to take in before plopping code from a third party — accessibility, technical debt, and security, to name a few — but the benefits may make taking on those considerations worthwhile for your team.

Upgrades are also part of that set of considerations. Usually, your team may treat this sort of maintenance as a simple task or chore: upgrading dependencies and (automatically) validating that all of the features keep functioning as expected. You probably even have automated checks for keeping all package versions up to date.

But what if the third-party tooling you adopt is big? I mean big, big. That’s common in large organizations. I happen to work for a fairly large organization that leverages big third-party resources, and upgrading those tools is never as simple as running a package update and moving on. I thought I’d share what’s involved in that process because there are many moving pieces that require ample planning, strategy, and coordination. Our team has learned a lot about the process that I hope will benefit you and your team as well.

Some Context On My Organization

I work for Jumbo Supermarkten in the Jumbo Tech Campus (JTC), which is a department of over 350 developers working in agile teams on a range of digital products that help facilitate our core grocery and e-commerce processes.

We have a variety of responsibilities, where 70% of the work is allocated to the primary objectives for each team, and the remaining 30% is dedicated to anything a team wants, as long as it is beneficial to the JTC, which is very useful if you want to deliver value outside of your own team.

When we look at maintaining tooling and packages, balancing the goals of each team with the goals of JTC means that teams effectively maintain their own codebases while also collectively maintaining internally shared codebases that serve as the tooling and foundation of our applications.

Centralized Code As A Bottleneck

To build our applications with consistent standards, we rely on an internal design system and the component library we call Kompas (Dutch for “Compass”). We have built this system ourselves and rely on Vue to render our components and build interactions. Kompas is a hard dependency for virtually all of our applications to ensure uniformity.

This project was not allocated to a dedicated team. Instead, we adopted a strategy that introduced plenty of guidance to allow all front-end developers to contribute. Any developer can add new components to the library as well as features to existing components and keep everything in sync with the designs.

Teams normally work on business features since product owners love delivering customer value. The way we set up our process would allow a team to, in one sprint:

• Make the required change in Kompas,
• Have it reviewed by peers from both inside and outside a particular team,
• Publish the latest version of the component library, and
• Use that version in that team’s own application to deliver to the end user.

We can only do this with automation on repetitive processes — linting, formatting, quality assurance, testing, visual comparisons, and publishing — in order to provide enough room for developers to contribute to the process. Our component library is very much a living document of our design system, with multiple minor releases and patches a week. With semantic versioning, we can keep our own applications up to date easily and with confidence.

For bigger undertakings, such as setting up visual snapshot tests, we established temporary working groups alongside our existing teams that we called “front-end chapters” where members join on a voluntary basis. In these meetings, we discuss what needs to be done, and in the available 30% of free time we are allotted, the members of these teams carry out the work and report back to the chapter.

As you can imagine, we’ve spent a lot of time and effort ensuring the quality and making it a reliable part of our landscape.

This all began when Vue was in Version 2. That’s the version we baked into Kompas, which means we effectively forced our whole application landscape to follow suit. This worked perfectly for us; people could focus on their team’s needs while leaning on the support of the entire front-end chapter that works on Kompas.

Following the Vue ecosystem that we introduced, Vuex and Nuxt became part of our environment. And then Vue 3 was announced, and it was a massive breaking change from Vue 2! With the announcement, the end-of-life date for Vue 2 was set for December 31, 2023. We still have some time as of this writing, but the news had a massive impact that cascaded throughout our organization.

We Needed A Strategy

We needed to upgrade Vue from 2 to 3. The first thing that we needed to figure out was when we could reasonably start the process. To assess and strategize, we formed a small virtual team of developers consisting of members from various teams so that multiple perspectives were represented.

We figured that there would be a period of time when we would need to support both versions in order to allow time for migrating between teams. It would be nearly impossible to orchestrate a monolithic release. Thus, we prefer gradual incrementing over massive sweeping changes. On the other hand, having to maintain two versions of Vue for, basically, the same business feature presented costs in time and complexity.

So, in order to execute this process as responsibly as possible, we set out to figure out when we could start, taking into account the longevity of maintaining two codebases while getting early experience from upgrading. We started to map the different tech stacks for each team and plotted out potential bottlenecks for the sake of making the process of our work as widely visible as possible. At this time, our organization had a very flat structure, so we also needed to get internal stakeholders (i.e., product owners, architects, and managers) involved and convey the effect this upgrade would have on teams across the board.

Creating A Map

With our starting point set, we move on to establish a direction. Not having a dedicated team did pose some challenges because it meant that we needed to align everybody in a democratic way. This is, in Dutch culture, also known as polderen:

We try to find consensus in a way where everybody is equally happy, or unhappy, about the final direction.

And this can be challenging in a department that consists of many cultures!

One thing we knew we could rely on was the published best practices from official Vue resources to guide our decision-making process. Referencing the documentation, we did notice opportunities for incremental upgrades. The release of Vue 2.7 (Naruto) was really helpful in the sense that it backported features from Vue 3 back to a Vue 2-compatible version.

We also noted that in our landscape, not all applications were actually using Nuxt. A stable release of Nuxt 3 would be a prerequisite for those applications to even be considered for migration since the Vue major version is tightly coupled with the Nuxt major version. Luckily, some applications in our landscape are standalone Vue apps. These are ideal candidates for the first Vue 3-compatible components.

But first, we would need to have components that were compatible with Vue 3.

The Big Divide

By this point, we were confident enough to get to work. We had a plan and clear strategy, after all. The first order of business was to make sure that our component library was compatible with Vue 3, preferably while minimizing duplicative efforts.

We found a really nice way of doing this:

We created a new workspace called “Kompas-next” next to the regular components folder, which was scaffolded out using Vue 3. Then we imported the components from the original library.

This only works because:

• The backported features in Vue 2.7 allowed us to move closer toward the Vue 3 composition API (among other things).
• The component syntax between Vue 2 and Vue 3 isn’t radically different anymore.
• Vue Demi allowed us to convert components, one by one, to be compatible with both versions.
• We made sure that Kompas-next runs isolated tests to ensure stability.

We did have to slightly modify each and every component to adapt to the new standards. We’ll get to that process in a minute.

That said, we were able to publish two versions of our component library: one that is compatible with Vue 2 (Kompas) and one that is compatible with Vue 3 (Kompas-next). This, in turn, meant that the teams that did not have Nuxt as a dependency could potentially start migrating!

Getting Organized

Up to this point, most of the groundwork had been done in a relatively small team. We were in charge of the investigations, communication, and alignment. But we still needed to get stuff done — a lot of stuff!

With every developer being able to contribute, we came to an agreement that fits with the way everybody was already contributing to the component library:

If you touch a component that is not yet compatible, convert it to be compliant with both Vue 2 and Vue 3 using Vue-demi. Add the existing component with tests to the imports of the Kompas-next folder.

Having communicated this strategy early in the process, we immediately saw the Kompas-next library growing. The Vue core team has put so much effort into closing the gap between the two versions, which made our lives much easier.

Feedback From Early Adopters

The teams that were not blocked by a Nuxt 3 release could spend their time migrating their complete app to Vue 3, providing feedback along the way on how we were setting up our packages and converting components.

Seeing the first applications using Vue 3 was a milestone we could all be proud of since we managed to reach it together, collaboratively, and with a united strategy. The strategy worked for us because it closely resembled the way we were already working.

There were indeed some components that were not migrated using this strategy, which indicated to us that they were stale in terms of development. We reasoned that “stale” equals “stable” and that it would be perfectly fine to migrate them by manual assignment and distribution since we can expect it to be close to a one-off migration per component.

We also started to add Vue 3-specific capabilities to our component library, such as our own composables. I think that’s a nice testament to the investment and adoption by our front-end chapter.

With the component library now supporting Vue, we cleared a significant migration hurdle in our organization. We enabled teams to start migrating to Vue 3, and we encouraged new applications to use the latest standards. As a result, we could start thinking about a deprecation path for our Vue 2 codebase. We were cautiously optimistic and aligned the end-of-life date for Kompas with the same date for Vue 2: December 31, 2023.

So, yes, we are not yet finished and still have work to do. In fact, we had…

Two (Minor) Elephants In The Room

To support communication between micro-applications that run on our e-commerce domain, we had resorted to using Vuex in the past. We used to register stores globally so other applications could dispatch actions and retrieve a shared state. This is now gradually being migrated in the sense that we are replacing Vuex with Pinia for internal state management.

For cross-app communication, we are in the process of decoupling Vuex as an external interface and promoting the use of custom events tied to a specific domain. This prevents us from locking ourselves out of future state management tooling.

We are also in the process of preparing our Nuxt applications to be cleared for migration as well. Within our e-commerce domain, we’ve been building specific modules that take a lot of overhead out of our hands: They handle tasks like setting meta headers, security, and analytics. These are being rewritten to use plugins rather than modules. The impact of this breaking change is smaller because it is limited to the teams that use these modules. We see that these teams are using a similar strategy, albeit on a smaller scale, to organize and structure the tasks at hand.

Looking Back

I believe we have a few key takeaways from how we upgraded (and continue to upgrade) from one version of a large third-party resource to another within our large network of teams and shared codebases. I believe the lessons we learned are relevant beyond Vue and can be applied to the processes of other large organizations migrating between versions of a core piece of architecture.

Let’s review what we learned:

• Ensure the transition period is clear and as short as possible.
• Facilitate breaking the work down into small steps that progress iteratively and solicit feedback from those involved in the process as early and as often as possible.
• Onboard key stakeholders to make sure your team has ample time and resources to do the work.
• Define a strategy that fits with your organization’s culture.
• Foster a collaborative mindset and establish clear communication between teams.
• Celebrate wins, even the smallest ones!

The Work Is Never Done, Really

As I mentioned earlier, maintenance is a never-ending piece of the software development process. As Vue creator Evan You stated in the State of the Vuenion 2023, Vue plans to ship more frequent updates and releases. This will keep impacting our work, but that’s okay. We have a plan and blueprint for future releases.

We’re not there yet, but we now know how to get there!

Further Reading On SmashingMag

• How To Maintain A Large Next.js Application, Nirmalya Ghosh
• Moving From Vue 1 To Vue 2 To Vue 3: A Case Study Of Migrating A Headless CMS System, Lisi Linhart
• Optimizing A Vue App, Michelle Barker
• Why Web Application Maintenance Should Be More Of A Thing, Darren Beale

Corporate leaders and hiring managers are being pressed to exhibit tremendous patience, creativity, and determination right now. As of May 2023, the U.S. labor market is experiencing a serious glut of job seekers. According to government statistics, there are more than four million positions than there are available workers. In other words, it’s still very difficult to get people to even apply for advertisements, let alone fill seats.

There are countless reasons for the labor shortage. The Great Resignation (or Migration, as some call it), has certainly affected recruitment efforts. When people know they’re needed, they’re less likely to accept the first job they’re offered. And though mass resignations are expected to drop by the end of 2023, they’re still happening. Another factor has been a change in the way professionals want to work. When Slack conducted a survey on virtual work arrangements, 94% of respondents said they wanted remote options. That’s a hard sell for some companies and in specific careers like healthcare and manufacturing.

Of course, this doesn’t mean you’re without choices if you have openings to fill. You just need to acknowledge your biggest recruitment challenges and then find ways to bypass them. To help you start, consider the following hiring conundrums and how to overcome them.

Challenge #1: You can’t find qualified applicants.

You post on all the same job boards that have worked like a charm before. But your results? Well, they’re not exactly what you want. You keep getting hits from candidates who don’t even have the basic skills or experience you need. That’s a problem, because you can’t wait forever to build out your dream team and start to scale.

The first strategy to take if you’re in this boat is to consider hiring people overseas. As long as the work can be done anywhere by the right person, you’re good to go global. The only potential snag is that you’ll want to plan ahead. Bringing aboard employees from other countries requires a knowledgeable partner’s legal and financial savvy. For example, Oyster offers automated global hiring management assistance for its customers. Join forces with a global employment platform like Oyster and you won’t have to worry about being compliant with foreign regulations and rules. You’ll just get to expand your talent pool while mitigating your risks. 

The second strategy is to try novel recruitment methods. You might want to search for potentially qualified people on LinkedIn and send them a “cold call” note. Or, you could try smaller, niche job sites like those aimed at minority worker groups. Even if you get just a few more hits than usual, you’ll be ahead of where you would have been.

Challenge #2: You lose tons of candidates throughout the interview process.

It’s happened again: You’ve found some amazing applicants who’ve submitted their resumes. As your hiring team looks over all the candidates’ information, you get pretty excited. Why wouldn’t you, when you have so many possibilities? Yet by the time you reach the one-on-one interview stage, most of those candidates have gone elsewhere. The result? You have to start the process over again — and you’ve lost lots of time.

If this challenge sounds far too familiar, you probably have to take a look at your hiring journey. Many corporations have made it very time-consuming to move applicants through the hiring process. They’re not trying to be difficult, of course. They want to make sure they don’t end up with a bad fit. Nevertheless, their hesitation winds up hurting them in the long run because candidates don’t want to wait. According to Indeed, the average after-interview response time from company to interviewee is 24 days. Even if you’re in that sweet spot, consider moving more quickly.

With so many jobs available, high performers will take the best offer they get. Even if you can only shave a few days or a week off your hiring, you could see instant improvement. Be sure not to scale back too much, but do consider where you can tighten everything.

Challenge #3: Applicants don’t have the skill sets you want.

You’ve been advertising some positions for weeks. You’re getting resumes, which is good. However, you’re not getting anyone with all the skill sets you want. Although you’ve made requirements clear in your advertisement, you’re not seeing those requirements reflected in applications. What gives?

The answer may not be one you want to hear, but it’s one you need to consider: Your bar may be too high. In other words, you’re trying to get a unicorn employee. Do unicorn employees exist? Perhaps in some universe, but your chances of seeing one may be lower than you presumed. Consequently, you’re better off looking for someone who can be trained on the skill sets you want.

Think of this as a switch to hiring based on a talent’s potential. You’re seeking someone not with all the qualifications intact but with the characteristics to learn. It’s not a matter of lowering your standards, though. You’ll need to set up a training plan for the person you hire. That’s okay and may actually make you a more appealing prospective employer. More than six out of 10 workers would trade their loyalty for the opportunity to upskill on their company’s dime.

Challenge #4: Diverse candidates just don’t seem to be interested in working at your company.

Diversity, equity, and inclusion (DEI) have become an important part of the mission of many companies. Yet it’s hard to foster support for DEI initiatives if you’re not hiring people from historically underrepresented populations. If you’ve seen no uptick in the diversity of your candidates, you may need to make some changes.

Initially, look at your job description. Are you using biased language unintentionally? Your advertisements and postings could sound perfectly reasonable to you but be a “turnoff” to diverse candidates. Even using terms like “rockstar” or adding gendered language to your job postings could be having an adverse effect. Now may be the perfect time to review everything you’re posting to spot any unintentionally biased or coded phrasings.

Next, revamp your worker sourcing. Look for untapped candidate pools that focus on Black candidates, Latinx candidates, veterans, LGBTQ+ applicants, and job seekers from other diverse communities. You may even want to consider advertising on specific diverse platforms or to social media groups. Done well, this can boost your application numbers representing more diverse talent backgrounds and abilities.

Recruiting isn’t the easiest task in the world, that’s certain. However, it’s possible to refine your processes so you can fill positions more dependably and with great people.

Image by yanalya on Freepik

The post 4 Common Recruitment Challenges and How to Overcome Them appeared first on noupe.

Having the ability to envision a tastefully designed website (i.e., the role creativity plays) is important. But being able to actually build it more often than not depends upon the tools available, including recent developments and improvements in web design tools and resources for designers and agencies alike.

True collaboration to create or maintain a design system is really important to making superb product design, but working with other humans is always tricky. The collaborative nature of a design system can have a lot of pitfalls. In its best form, it is the product of close alignment between developers and designers, but it doesn’t always happen that way.

Some painful memories:

• A brilliant designer I worked with made a gorgeous new set of elements and examples for the company to use, but the other designers in the company ran into many situations where it was more expedient to just copy and remake (i.e., detach) the component. The design system was used less and less since contributing to it was always a lower priority than working on a product opportunity.
• A developer I worked with built the design system components such that the padding in every text input, button, and so on always had to be the same in every layout, leading to awkward results when (for example) a button included double-byte characters, only icons, or just longer labels.
• I did a lot of work on variations of nested components (button bar, toggle buttons, segmented controls) that were designed to use the same style properties as base components (like a button), but the developers I was working with made brand new components for each that didn’t. So, I had to document and specify the many, many identical sets of style values for many, many sets of slightly different components.

The list goes on. I’m sure you have your own examples.

Getting Aligned

I’ve worked in many kinds of teams, in large companies and start-ups, where these collaboration issues kept getting in the way, even (or especially) with very talented and smart individual contributors. Getting aligned with my teammates doesn’t happen automatically or just because we go to lots of meetings. In fact, it’s very easy to start a project together and get pretty far into it before finding out we all had very different ideas about what we were doing. When it comes to complex questions of re-using an existing component vs. making something new or how to stay on the same page without blocking each other, alignment takes practice for any team.

The method for making design systems I’ll talk about probably works best in environments where you are a sole designer (or among a small number of designers) on a cross-functional team, including front-end or full-stack developers, led by a product owner. You might collaborate with other designers in other teams, but this is your “first team.” In this context, you have a lot of freedom but also a lot of responsibility.

You need an idea for nurturing the design system that doesn’t depend on organizational mandates or a specific “process” and one you can apply yourself. After all, a design system is a product with users, and we know how to balance the user’s needs with product opportunities, right? (Yes!)

The approach described below is not common or widely used, but in my experience, it has solved many team collaboration problems, including:

• Eliminating the “hand-off” step: a truly perverse mini-waterfall built into many relationships between designers and developers.
• Ensuring that all designers and developers contribute to the design system as a part of regular product work.
• Connecting design systems to product impact: measurably speeding things up by making more reusable elements and modules in design and development.

A New Use For An Old Idea

What has worked for me in these kinds of teams is a twist on an old idea: design patterns. Elsewhere, design patterns are described as “a toolkit of solutions to common problems” (Refactoring.Guru) or “description or template for how to solve a problem that can be used in many different situations” (SourceMaking). My favorite definition of the concept is from The Timeless Way of Building:

“Even the most complicated, sophisticated things are defined by a small number of composable patterns.”

— Christopher Alexander

You probably don’t think of your own design activities as a “pattern-making” practice, but the idea has a lot of very useful overlap with the practice of making a design system. The trick is to collaborate with your team to find the design patterns in your own product design, the parts that repeat in different variations that you can reuse. Once you find them, they are a powerful tool for making design systems work with a team.

Design Patterns For Design Systems

To see how, first, let’s get specific about the definition of “design pattern” in our product design context. Let’s call a “design element” a small isolated component like a “button,” “chip,” or “card,” and let’s describe a design pattern as a reusable combination of elements for a purpose, a larger module that can do some product experience work on its own.

The elements are the focus of the design systems in most companies I have worked at, and creating them is important and a lot of work. I am sorry to say, however,

Having a good set of elements doesn’t help you get the value out of a design system, save you much time, or by itself ensure designers and engineers are aligned.

For this reason (and the availability of great existing elements from Tailwind, Bulma, Skeleton, or of course, MUI) I have de-emphasized them in my own work, often just restyling elements created by others. The elements are important, and you do need a set that everyone uses, but they don’t do the work of implementing a feature or valuable experience.

You might be thinking that many of these systems do come with combinations of elements, like the “pre-built components” that MUI ships with for a “Data Grid” or the “blueprints” in the Salesforce Lightning Web system for a “List Builder.” Are these the patterns that can help us?

Unfortunately, they are not. These are patterns for sure, but they probably aren’t useful as-is for you. Your product has its own needs. You can use them as a starting point, but in my experience, it takes longer to rework them into something that solves the problem.

To be useful for you, a design pattern has to come out of and express some reusable part of your particular product experience — those parts of the design you find yourself making again and again.

Here are some examples of these useful, product-specific design patterns in products:

• A tile in a TV app, which people use to browse things to watch in lists. This is sort of a “card” pattern, but not really! Every streaming service has its own particular kind of tile and includes different content and controls that suit that product best.

• A dashboard meter in a data-visualization app like Google Analytics. Again, this is sort of a “panel” pattern, but not really! Each part of the dashboard might have different kinds of meters, with titles, category labels, “big numbers,” charts, text snippets, or filtering controls, and the number of elements in a meter varies by app.
• A tree view in a social genealogy app that lets users see relationships between people in a way that adapts for display on small devices. Some products focus on researching your family, others on visualizing relationships.

In each of these cases, designers and developers made their own product-specific patterns. Those patterns are valuable because once a team has defined them, the next project that the team does gets easier. They develop and grow a kit of parts that save them time (and that they can polish and refine). The patterns, not the elements, are the heart of this (better) kind of design system.

Taking this a step further, I would say that a lesson from these patterns is that

All designers and developers can make their design system better and more effective by focusing on patterns first (instead of the elements), making sure that each is completely reusable and polished for any context in their product.

Pattern work can be a fully integrated part of both getting some immediate work done and maintaining a design system.

Design Patterns For Collaboration

This kind of design pattern activity can be a direct path for designers and developers to collaborate, to align the way things are designed with the way they are built, and vice-versa. For that purpose, a pattern does not have to be a polished design. It can be a rough outline or wireframe that designers and developers make together. It needs no special skills and can be started and iterated on by all. And collaborating on this form of a design pattern makes it possible for designers and developers to work in parallel.

That’s all pretty abstract. It’s easier just to try an example.

A Design Pattern Story

Let’s say that we’re on a team together, working on an app called “WeTrip.”

The product opportunity comes from the reality we have all probably dealt with: when a group of people or a family travels together, they usually have a lot of trouble deciding what to do or where to eat.

This app makes group travel easier by giving people an easy way to propose and vote on the plan for each day. Instead of having to have long conversations that feature such sentences as “I dunno, what do you want to do?” travelers have a tool so people can have less trouble with the logistics of a vacation or a trip.

The app has some seed funding, but in order to survive needs some “minimum viable” version of itself to prove that it’s something needed and valuable. Everyone on the team wants to get going! Nobody wants to be waiting for a design.

The designers, engineers, and product people all meet and pick the names of some basic objects and their properties. They start with a “Person,” someone on the trip who votes on places to go together for a meal or sightseeing. They sketch things out on a whiteboard.

This is their first pattern.

They move on, describing things like a “Place,” a location someone wants to visit.

And an “Occasion” pattern, a time the group will do things together like eat, and so on.

The process can work with a physical whiteboard, shared document, collaboration app, or whatever. All that is important is that everyone participates so they are aligned and get the details they need to start work.

With this rough outline, they can see that some of the parts of these patterns are elements they can pull from existing design systems.

They decided to use some restyled MUI elements. Those have defined properties (named attributes of a component, like “color” or “content”) already and will be a nice shortcut. They pull them into Figma (their design tool of choice) and development (a React web app with the MUI library as a dependency). They add some of these MUI elements and their standard properties to each pattern.

For each pattern, they create a page in a shared Notion document that everyone can edit and update. They start by adding properties from the MUI elements they’ve chosen.

The team combines the properties from the MUI elements with others they’ve sketched out and flattens the properties a bit. They group the properties so that it’s clear what is most important and secondary.

The Figma component will have a different variant for each important property (like activity or actionsAvalable). And each of the element properties will become part of the component in development, of course. In this way, the design and development are aligned — not necessarily completely the same in every detail, but in the ways that matter, moving in the same direction.

The team talks about more ideas for each pattern. Adding properties doesn’t mean they will appear in the final design, just that an idea could be part of the experience, so it’s a low-stakes conversation where final decisions don’t need to be made.

After going through the same process for the “Place” and “Occasion” patterns, the designers and developers have a lot of what they need to make progress. They have agreed on the names of things and what the important properties are. The patterns are defined in a form that the whole team can see and edit, and they start work.

An engineer might stub out a “Person” component like the one below while a designer is sketching it out in Figma with no bottlenecks.

Of course, the engineers figure out that there are some properties they need that they missed at first, like a presence property for a user (after all, in order to know how to show a user notification, it helps to know if that user is using the app right now or a notification would be better). They add that to the document and message the rest of the team.

At the same time, the designers are fleshing out the patterns, using the MUI Figma library where possible, and adding new components where needed. When the team sees the addition of a presence property to the Person pattern, they decide to make a presence indicator and group it with the primary elements. As long as they are keeping the simple pattern document up to date, there is no handoff or waiting around.

Sometimes there are big questions to resolve about the experience. But that is the occasion for the next meeting about what the primary views in the app should be.

The team meets again and comes up with a “People” view (a list of people on the trip, with their status), a “Schedule” view (with a list of occasions and the plan for each day), and a “Proposals” view (to see and propose places to go) — more design patterns. For this pattern documentation, one of the product owners wants to use a wireframing tool instead of an outline (as in the previous example). That’s fine. Pretty much anything works to describe patterns as long as it shows elements and groups (and it’s what a team likes using).

In these patterns, lists of Person, Occasion, and Place patterns are nested inside of each view. It becomes clear that there will have to be two versions of a Person pattern in the app, so the property is added to that pattern.

As they work, if an engineer gets a little ahead of whatever design work exists, they can either use standard MUI components or add a proposal to the patterns document. And designers can add new components if the design starts to need them. All parties are able to make changes without blocking each other.

Organizational Needs

Now, I should pause here to note that there are plenty of teams where this kind of pattern definition is not the primary product definition activity and where other stakeholders (engineering managers and so on) have a say in how the design system is built. Not all teams are small and have as much ownership. Even in larger companies, however, I believe design patterns can be very useful and help make a case for development work (since they show how the design system is helping teams get things done). But in those contexts, design patterns may be small parts of other organizational processes and not as important overall.

In this small team, the struggle to justify time on a design system is for a different reason: there’s a great temptation to put it off because everyone wants very badly to ship something sooner, and it feels “extra.” But every member of the team also knows that the minute they want to iterate on their product, that work will be easier if they have created a design system, and so they keep their good practice going.

Putting It All Together

Once the patterns are established as a way for the entire team to collaborate, final designs and views come together more quickly (because the entire team was able to start together and finish together). The visual design happens at the end rather than being a bottleneck before people can start work.

Integrating Patterns In Product Planning

As working with patterns becomes more established and mature, patterns can be broken out into separate repositories and polished on their own, either as a separate library in Figma or a set of modules in development. If a team gets larger, there might even be an official owner for each pattern who handles bugs or polishes details.

Each pattern properties list can be turned into an API once a module is trustworthy to use in new design and development. In the WeTrip example, the scrolling list of places for today is reused in a search results view when it’s added later.

Since patterns are by their nature only the reusable parts that save designers and developers time, patterns can make working on the design system something with a hard-core product improvement impact. Re-use can be captured as a key metric and a factor in prioritization. The amount of reusable work being generated can be tracked automatically in design and development tools (much like test coverage).

If the reuse of patterns becomes common enough that it needs careful management, patterns can become part of a federated module build process (like what is built into WebPack 5). In short: patterns lend themselves very well to being part of the toolchain of many modern development processes.

Your Turn

I imagine that there are many teams that already practice some of these concepts in the collaboration between design and development, and I am very eager to hear about that! It has been a happy improvement as a method for myself and the people I have worked with, and I would love to hear your stories.

For others, I hope this has been a good introduction to a vision for you and your team of an alternate reality where you can seamlessly collaborate on design systems without as many pitfalls. I wish the best to you and your team as you find your way to such harmony and a happy design outcome!

Every month we gather together a selection of the most exciting websites from the preceding four weeks.

Bob: Hey, Rob! What do you do?

Rob: I have a brand of my own. 

Bob: Oh, what’s the name?

Rob: It’s called “X”. 

Bob: Okay, where can I find it?

Rob: Here, at this address. 

Bob: Umm, I meant which social platform…

Moral of the story: If your brand is not on social media, your brand practically doesn’t exist to your audience. 

Besides, Data Reportal said that 75% of web surfers use social media to research brands. 

So, if you are reading this thinking about how to get more inbound sales for your brand – maybe, it’s time to tell your audience that you have a brand.

Whether you’re a seasoned marketer or just starting out, it’s crucial to understand how social media can help you build brand awareness and grow your business.

Wondering how you can do that? 

Well, then, you’re at the right place. We will not only tell you why you should use social media for brand awareness, but you will get a perfect roadmap to do that. 

Let’s dive in!

Why Should You Use Social Media for Brand Awareness?

Brings your brand to the spotlight

There are almost 300,000 new brands issued every year – what are the chances of your brand surviving now? 

Almost, none if it’s out of your audience’s sight. 

But, social media, if implemented with the right strategy, can bring your brand to the spotlight of its ideal audience. 

From vertical videos to scroll-worthy carousels and even some longer text posts and trending hashtags – you get the chance to express your brand voice & reach out to potential customers by just hitting the “Post now” button.

The easiest part? You don’t even have to sit and post each content every day. There are a number of social media automation tools available out there where you can schedule all your months in one go! 

Lets You Connect with a Wider Audience

Remember the heart of Iron Man’s suit (without which he couldn’t function)? 

The scenario is pretty much the same when it comes to your brand. It cannot function without its heart, i.e. its ideal audience.

And when your goal is to build brand awareness – this is even more evident.

On social media, you get to have a real-time conversation with your audience, reply to their comments, and even slide into their DMs (in a non-creepy way, of course!).

When you evolve as a responsive & interactive brand on social media – you can foster trustworthy relationships with your audience, build a community around your brand’s presence & even establish yourself as an authority. 

Builds Your Brand’s Personality

Without a unique personality, your brand is just a name out in the cloud. However, with social media, you can establish a unique brand identity, get creative and even play a little humor. 

It is your brand’s personality that can help you stand out from the crowd and leave a long-lasting impression on your audience’s mind – which will keep them coming back!

Have you seen how Sephora does it?

Source: Instagram

Even though Sephora’s business model is all about beauty and wellness products worldwide – they go steps further in their socials and features tutorials to influencer collaborations and more. 

And guess what? That’s what differentiates Sephora from other brands in the same niché! 

If you still haven’t figured out a personality for your brand or are confused about it – try out social listening tools like Hootsuite to know how your competitors are doing it.

If you’re just starting out and do not want to invest in a premium tool right away, there are many Hootsuite alternatives you can go for – that get the job done without the pocket pinch. 

Reduces revenue investment 

Compared to other paid channels of brand promotions, social media is quite cheaper – and that too, without compromising on the benefits you can reap. 

In fact, there are a number of brands that have built such a great social media presence that they don’t spend a single penny on paid ads or promotions. And are still successfully generating leads!

Not only will you save on your investment budget, but your sales cycle will also be comparatively shorter – because you have already educated & nurtured your audience on your socials. 

Boosts Your Brand Credibility

Okay, you have a brand. So, does the 3 million other founders – how will your audience know if it’s credible?

Well, there are ample harder ways to get it done – let’s talk about the easier one then; which is – promoting user-generated content on your social channel. 

When the mass audience sees your customers giving positive feedback about your brand,- there won’t be any room for second thoughts. The feedback can come in many formats – from vertical shorts to written reviews, and even static before and after images. This is called customer retention marketing which prevents any sort of customer churn.

Your Roadmap to Using Social Media for Building Brand Awareness

Go for Value Over Anything Else

Social media works much like Newton’s third law of motion – “To every action, there is an equal and opposite reaction“. 

You give your audience crap, you get crap back. 

You give value to your audience, you get rewarded with engagement/sales. 

So, create content that doesn’t only resonate with your audience’s pain points – but also ensures they are reaping value from it.

Because your audience will only remember your brand when they get something of value from you.

If you still aren’t sure whether your audience is finding your content engaging enough, try using the best social media analytics tools to track your social media curve. 

Say It With A Compelling Story

Who doesn’t love a good story? So, why not leverage the same for your brand! 

It’s your chance to develop a compelling brand narrative that’s clear, concise & resonates with your ideal audience. 

What’s best – if your brand really has a solid story to tell, like ‘rags to riches’ or something similar. Make sure your audience sees it and knows about it! 

Engage, Engage, Engage

Source: Twitter

It will be an amateur move to consider that your ideal audience is seeing or interacting with your content. 

No matter how great the hashtags are or how aligned the content is, almost half of your audience is not even aware of it. 

So, how do you reach out to all your audience?

Well, that’s where engagement comes in. 

Make a list of your ideal lead profiles and start engaging with them every day – or at least twice every day. 

You can comment on their posts, reply to their stories or slide into their DMs (but not in a creepy way!) – all these will ensure that you always stay at the top of your audience’s mind.

Collaborate with Influencers

If you thought influencer marketing was just for B2C – we are sorry to break your bubble – because B2Bs have a similar share in it. 

And partnering with influencers is a great way to boost your brand’s visibility on social media. 

Go ahead, and find influencers in your industry who have a moderate to huge following and an engaging audience – and collaborate with them to create content that resonates with your audience & promotes your brand.

Takeaway

Now, you get it? 

While other channels like blogs and podcasts still work great for building brand awareness – social media brings you faster in front of your audience. 

And, for your brand to survive the hustle & bustle online and still bring in revenue – there’s no alternative to building brand awareness on social media.

Featured image by Loc Dang

The post The Role of Social Media in Building Brand Awareness appeared first on noupe.

Conversion rate optimization (CRO) denotes strategies to persuade website visitors to become clients. What influences customers’ shopping behavior? In the world of B2B SaaS, you need to present a product that serves the following primary purposes:

• enhancing business performance;
• solving common pain points;
• increasing sales;
• reducing costs;
• providing a team with the needed capabilities that are easy to comprehend.

But even having the best and most useful product doesn’t guarantee conversions. You need to succeed in the challenging CRO process, improving the user experience on the website and removing any barriers on the purchase journey. For example, online store owners follow eCommerce UX design best practices to achieve it. What can a B2B SaaS company do?

A great customer experience begins with understanding the path a potential buyer follows when interacting with a brand. It involves all of the company’s points of contact with a prospect. Ideally, these paths should be well thought through from many perspectives: UXUI, sales, and marketing, to name a few.

By investing time in conversion rate optimization, a company can pave the optimal way for a potential client to buy more. In this article, you’ll find out what software as a service (SaaS) companies can do to increase their website’s conversions.

1. Analyze Your Landing Pages

B2B clients need more time to convert compared to direct consumers. They avoid impulsive purchases, so having a good landing page with essential information about the product is a must for a B2B SaaS company. These are pages intended to trigger a particular action:

• subscribing to an email newsletter;
• signing up for a demo version of the software;
• opting in for a trial period;
• buying the tool.

So they should be powerful in marketing terms. Here are some pointers for designing a landing page:

• Let people sign in with a single click.
• Use a strong copy, with headlines and subheadings defining your unique value proposition (UVP).
• Include engaging elements, such as videos, to tell about your product more.
• Highlight the benefits for a potential business client (not only the features of the product/service).
• Reduce doubts and increase trust with social proof (testimonials, achievements, awards, partners, etc.).
• Personalize communication with pronouns and tailored content.
• Remove the website’s navigation from a landing page to double the conversion rate.

FreshBooks increases the number of conversions by stating the ability to cancel subscriptions and not to insert credit card data. It also displays product ratings and reviews. At the bottom of the page, there is a Frequently Asked Questions section and product benefits for businesses, helping prospects decide.

Screenshot taken on the official FreshBooks website

2. Give an Idea About Your Product with a Short Free Trial

Gaining awareness of your product and stimulating interest in it typically constitutes the first step in lead generation. That’s where the opportunity to test the software becomes of the utmost importance. If you neglect this step, most consumers will skip your product and turn to your competitors. As most SaaS companies provide an opportunity to run the product for free, you need to follow their suit.

In light of this, work on improving visitor-to-free trial/freemium conversions. It includes offering a complete product for a brief period (a trial) or providing a minimal, non-time-limited version of your product (freemium). So customers will need to either pay for the service after a certain period or complete access to all features without any limitations or watermarks.

A case in point is MailChimp, a marketing platform for small businesses. You can utilize the tool for free, but it’s limited to 2,500 monthly emails sent, one user, and some advanced features.

Screenshot taken on the official MailChimp website

People need to understand the tool fast. Ensure a smooth onboarding process. Let consumers complete their tasks and get to grips with the software to encourage them to purchase it for a longer time. The bottom line is that the product should solve customer problems before the end of the trial. That’s where the following tips may help:

• display the value of the products with the help of metrics and reports;
• instill a sense of urgency when the trial is coming to an end;
• follow up with those who don’t subscribe to discover reasons for abandoning the service.

3. Use Clear Calls-to-Action

Suppose you’ve convinced visitors to subscribe or buy. Where should they click to get the desired solution? To encourage visitors to stay on a website and submit a contact form with an inquiry or download a whitepaper, include the CTA to catch their attention immediately. While it may seem obvious, organizing the CTA is a critical step on the CRO list. Take this information into consideration when improving CTAs:

• These can be links or buttons, leading people to other sales funnel stages. 
• They may differ in prominence, with the most important being highlighted.
• As clicking the button denotes conversion, you need to place them front and center on your pages.
• The wording should be understandable and give clear directions.
• Generate FOMO by advertising innovative features or limited-time deals.
• CTAs should be concise, stating the product value in several words.

Look at how DocuSign emphasizes CTAs by increasing their size or spacing them out. This strategy is especially successful as there are minimum elements in the above-the-fold area.

Screenshot taken on the official DocuSign website

4. Cut Down on Your Lead Form Fields

Analyze your website forms. Is all information necessary to initiate the first contact with your company? Stick to the minimal number of fields. Allow users to complete them in a couple of seconds. Ask for the essential information only and make it up to clients whether to insert some details. For example, asterisks above specific fields will denote their importance. You may either hide the rest in accordions, remove them, or leave them without any marks.

Zoho enables prospects to sign up by inserting an email address, password, and country. But there is a quicker path. You can use a Google or Microsoft account to access Zoho CRM.

Screenshot taken on the official Zoho website

The fewer fields you show, the higher your chances of converting people into customers. If it’s necessary to collect such information, try separating forms across several pages. According to statistics, choosing multi-page over single-page forms can increase conversions from 4.53% to 13.85%.

In most cases, successful conversion in B2B SaaS will involve starting a conversation with your sales team, not purchasing. Keeping that in mind, you need to reduce the effort of making an appointment.

5. Practice A/B Testing

What should you pay the most attention to in terms of marketing? Your messages. AB testing gives a great hand at determining which elements, phrases, and layouts bring back a higher response. As such, using tools such as Visual Website Optimizer and similar, you can test the components on your landing pages to get an insight into customer behavior. These include calls to action, color schemes, texts, and visuals.

Such variation test campaigns allow for splitting your audience and showing them different options. For instance, you can build a hypothesis on the wording used for sign-up forms or even the subject lines of your newsletter send-outs.

As the business grows, you may conduct polls and surveys or analyze heatmaps to gather user feedback on your business. Implement the results on your touchpoints, including the website, app, social media, email, etc. It can involve making minor adjustments like changing the look of your landing pages or adding CTAs that are simpler, clearer, and more effective at boosting conversion rates.

You may find out what works best by comparing the results of gathered data like the number of clicks, downloads, filled-out forms, etc. You can also discover the bottlenecks that need fixing and underperforming solutions to replace. This way, your marketing efforts will bring back a more effective resonance.

By analyzing data of this kind, you can optimize the customer journey map and build stronger relationships with your clients. Not to mention that such an approach saves marketing resources and gets a better return on investment.

Major Takeaways

B2B SaaS companies should start optimizing their websites and solutions for conversions by analyzing customer psychology. What do people seek when inserting specific keywords in search and landing on your page? Leverage website analytics and tools to determine their interests and pain points.

We’ve described several ways to enhance conversion rates and sales, such as:

• organizing landing pages;
• adding a free version of the software to evaluate it before buying;
• improving CTAs, their position, color, wording, and so on;
• simplifying the registration process;
• finding the best variant with the help of A/B testing, website analysis, and heat mapping.

Generate high-quality content and ensure website usability. Attract the target audience and solve people’s problems. If you follow these pieces of advice in addition to the CRO best practices, you will get more qualified leads for your B2B SaaS business.

Featured image by Stephen Phillips – Hostreviews.co.uk on Unsplash

The post 5 Best CRO Tips for B2B SaaS Websites appeared first on noupe.