Creating This Website
When our company rebranded to lilikoi agency, I was excited to be the point person on the development of our new website. While the website is fairly simple, there are a few capabilities that presented unique challenges to the design of both the front end and the backend. Here were some of the requirements that presented the greatest challenges to our team:
- Fully fleshed out individual user profiles that are organized by team and reflected in the URL structure
- An interactive pie chart on the homepage.
- Creating a lightning-fast website that scores over 90 for Google PageSpeed (at the time of writing) and still has all the bells and whistles to delight our users.
Firstly, that URL structure. Like any growing company, new team members are joining us all the time (and occasionally are moving on to new ventures). On our previous site, team member profiles were centrally maintained and updated by the web team. These were fairly simple profiles: just an image or two, a title, and bio. With this website, we really wanted to highlight the unique personalities in our ohana and give everyone the opportunity to showcase themselves. However, there was no way our little web team would have time to manage 40+ complex & unique profiles! So we needed to give our fellow team members the ability to edit and manage their own personal profiles.
This site, like the majority of our client’s sites, is built on WordPress. A great benefit to WordPress is that it is already intended to be a publishing platform, with all sorts of tools for personalized author/user profiles right out of the box. When it comes to user managed content, scalability and security are big concerns (even for an internal platform like this). When visualizing the user journey, I wanted there to be one singuar place team members could edit the information on their profile and one place that they could add posts, with none of the other admin concerns being visible. Part of this is for security, but it’s also so that users won’t be confused or lost in the robust admin panel.
Normally, you would simply customize the author archive page so display the extra features needed (certifications, job title, etc) and changed the edit-profile admin to all those changes to be made. Easy peasy!
But the URL structure caught us up. Since our company is all about SEO, we wanted breadcrumbs that brokedown root-domain.com/team/team-member. That middle “team” level of organization hung us up. WordPress doesn’t really let you create taxonomic heirarchies for user that are reflected in the URL structure for author archives. There are ways to rewrite the URLs for individual links, but that would not be scalable. I tried to find an elegant work around, but ended up settling with a hybrid system. There is a taxonomy for team members: they are tagged by their team and that tagging allows employees who are members of multiple teams to display on multiple team pages.
However, there is also a custom post type (“profiles”) that acutally sources and displays the information. These pages contain virtually nothing in the WP backend. They just have titles, children pages, and parent pages. But by accessing the author of the page and how it’s tagged, the single and template pages for the post type will generate fully fleshed out user profiles. Eventually we may be able to remove this intermediary step, but right now the WordPress “author” behaves too differently from a post in order to be made hierarchical.
Interactive, Responsive Chart
The next major challenge was the fully interactive pie chart on the homepage. This was a special ask and took a fair amount of care when it came to wireframing, mocking up, and writing the JS to handle it. It’s based off of Chart.js but I know my amazing teammate Dizzy did a great deal of custom work to get the interactivity to function as expected on mobile and desktop (it’s fully responsive, by the way. No shuffling visibility for desktop and mobile).
Need for (Page) Speed
Lastly, speed presented a major challenge. Anyone involved in development knows the constant battle to shave half a second off your load time. Additionally, our requirements explicitly stated we needed to hit a 96 PageSpeed score on Google PageSpeed Insights. This is tough in large part because PageSpeed Insights creates a score based on a single session actual speed, which is highly variable.
But we did it, even with the Chart.js and video hero and AOS animations. And there were a number of strategies used to create it.
- Responsive ImagesResponsive images make a bigger impact on page speed than using WebP. In as many places as makes sense, images are loaded responsively. We also lazy load and optimize images, but responsive images took a lot more initiative in development.
Obviously, there are other things we did while coding to reduce the load time, but those are the highlights. I highly recommend this article from Backlink.io on what actually impacts page speed and when. It helped guide decisions when optimizing this site.
Want to talk marketing with Martha?Back to the Web & SEO page