![]() This extra step meant more developer support and coding, which did not meet our primary business requirement. I used Advanced Custom Fields in the past but only those within defined pre-built templates: You could modify an image or text easily, but in order to create custom page layouts and change the structure of the page or reorder elements, you would need to change your WP page template. We opted to use WordPress as the base platform due to the massive user adoption, open-source framework, and wealth of resources available. The components would need to provide us with the ability to produce flexible custom page layouts as content creators, but would also prevent us from writing “bad” or inaccessible code. Defining our WP Page Builder Tech Stack:Īfter assessing the popular WP page builder options, we determined we would have to build our own components from scratch. ![]() Moreover, there were several accessibility “deal-breakers” with a lot of the technologies we explored. If another layout builder allowed us the ability to directly control and build the code ourselves, it tended to restrict our flexibility and design options. If one visual builder allowed for a ton of producer flexibility to create custom layouts and templates, we couldn’t access or modify the underlying code. One of the main issues we encountered was a balance between the ability to create different content types and access to the code itself which would provide us with complete control of our site. I evaluated multiple popular page builder platforms in the early stages of this project to see if they met the accessibility requirements of this project but quickly found that the dominant publishing platforms failed to meet all of my core requirements outlined above. Needs to be responsive, cross-browser friendly, and fast loading.Have full access to underlying code structures.Must provide common/global components that can be edited and will update the entire site where that component is used.Must have an easy-to-use form management system with page-level editable configurations that integrate with Hubspot API.Must provide non-developers/engineers the ability to create, build, modify, edit, and publish a variety of layouts.The last thing we wanted was to end up in a situation in which we found a significant accessibility issue that we were unable to resolve because we couldn’t access the code. In order to achieve this, we would need the ability to edit/modify all the various code layers. Accessibility aside, I found it challenging at times (putting it lightly) to get Elementor to work well across browsers and devices. I wanted the efficiencies of a modern WordPress page builder (like Elementor, Divi Builder or Wix), but the code output had to be clean, fast, mobile-responsive, cross-browser compatible, and fully accessible. At the top of the list was ensuring our marketing team had the ability to create a wide array of page types (product, landing, form, info, educational, etc.) and easily customize layouts. I started the technology selection process with a couple of non-negotiable business and technology requirements. This is Topic 2 in the Website Rebuild Series – View the Series Overview Here.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |