We work on the Internet and are constantly consuming information. There's a lot of it out there. We'd forget it if we didn't write it down someplace…
Visual Lizard's blog covers everything from web standards to the muppets, from php to comic books to music, just about anything we find interesting
We've been working with a new client recently. Their site has been having issues with being slow, so they've asked us to look into what can be done to make the site perform better. We've been diagnosing issues for them and we've made some recommendations. They're happy for us to follow up and work through some of the issues that we've found.
One of those issues had completely stumped me for awhile, and when I couldn't figure it out immediately I set it on the back-burner as something to revisit when I had some time. Well I was looking into other WordPress sites this afternoon and I decided to take another look at their issue.
The Problem: A contact form was set up to allow the public to contact them with questions and requests. For some reason the public submissions were creating blog posts in draft mode for every submission to the form. The form still sent the email, and the submissions were still stored as specific entries should the need arise to review a specific entry if the initial email were to be deleted. But that additional draft post was a bit superfluous and was not required. Nobody on their end was checking on these posts either. I mean why does the information need to be stored in two spots?
I spent an hour or two trying to find a configuration setting in the Gravity Forms plugin that would be causing this problem. Was the plugin doing it on purpose? Was it a setting?
I've never made a secret of the fact that I am not a fan of WordPress in general. I personally find the system to be a bit of a wild frontier of plugins and themes. My co-workers and I agree that the base WordPress system can be a very useful small scale website management system. But when the sites start to get bigger and more complicated, then the more brittle that system can become. This isn't the fault of the WordPress developers. It has more to do with quality control for those out there who make plugins for WordPress. Some plugins are very good, and the developers of those plugins have taken time to build something of quality. The problem is that there are also those out there who don't. A combination of good quality plugins combined with even a single below standard plugin can cause major problems when trying to keep a website's security and functionality up to date. But I digress.
So, like most coding and website problems that we need to deal with where we have not created the code, I Google'd the issue I was seeing. Low and behold, this issue is a well known one related to Gravity Forms. The plugin itself is well built and if you've read through the features, the issue here is not really an issue. Rather, the individual who was creating the initial form used the incorrect type of field.
When creating a form for a website or web application, there are several categories of form fields in the Gravity Forms plugin.
After reading about the issue, I returned to the configuration of the form and took a closer look at what field types had been added to the form. Sure enough, the large textarea field was configured as a Post Field, not the standard Paragraph (textarea). I ran a test with a plain textarea field, and the result? No extraneous draft post. The submission still appeared as a form submission, and all of my test info was still received, but there was no longer a duplicate draft post cluttering up the database.
This is one of the most satisfying parts of my job. When I figure out a problem and find a solution. Mostly I do this with the help of my co-workers, but sometimes finding the solution myself makes it that much sweeter.
I like working as a web developer. My job is to take graphic design for a web environment and translate it into a working interactive interface that allows the user to read, view, listen to, and interact with the creator's content. A slick interface with animation, interactivity, and vibrant imagery can be very engaging.
There are times however where we sometimes see that this level of complexity is not really required, and can in some cases take away from what the user is actually looking for. Working in this industry for more than 25 years, we see the trends come and go and the one thing that seems to remain consistent is that a simple straightforward presentation of content is always preferable to slick, colourful designs filled with animation.
I would say that I am somewhat biased in this opinion. I have a strong sense of wanting to cut through the fluff and the slick paint job to get to the heart of the content.
We've always advised our clients that it is important that the design shouldn't get in the way of what their audience is after. We ask our clients to take the perspective of who will be visiting their website or web application. Why are they visiting? What are they looking for, or what do they need to accomplish? Once they can answer those questions, we can start on the construction.
The reason we push our clients in this direction is because sometimes they get caught up in the intricacies and politics within their own organizations. They feel the need to push forward an agenda for the stakeholders. However that perspective can backfire for those stakeholders if the audience of users can't find the information they are after.
Recently we had a client with a new website administrator that was looking at their current content and realizing that the content did not represent the audience they were looking for. This wasn't an oversight, it was more about the evolution of the organization's purpose over time. The initial purpose of the site was to inform the public about the organization, its purpose, and its presence in the community. This involved information about public consultations, the history, and eventually construction.
Now that the organization is established, the purpose of the website has changed. They are now more focused on the services it provides to the community. Therefore the site architecture needs to change to better highlight those services. While the historic content of the site may be interesting, it is no longer the focus. A change in structure can also dictate a change in design.
If the focus of the content changes, the design may need to change in order to better present this new dynamic. Where a flashy design with a focus on big ideas was needed to catch the attention of the community as a form of marketing, the new focus may need to be more subtle and full of contextual content for the new audience. Substance over marketing.
Getting back to what I was originally getting at here. With this kind of change in focus, sometimes a more simple design makes more sense. Back to basics, so to speak. A simple layout of copy with minimal graphic design and imagery. Get the contextual point across without all of the figurative icing. And by working in this way, we also end up designing and providing content that is accessible to everyone by default.
As I said before, I am somewhat biased. I don't like ads. I don't want to see them cluttering up my viewing experience on a website, application, or social media. I understand the need for marketing, and I do appreciate good design in marketing, but I could do without seeing it, and I would safely guess that I am not the only one.
I would always advise keeping the design simple and keep marketing subtle. I watched Ready Player One again last night and there is a scene where the corporate villain is talking about filling up to 80% of the player's field of view with advertising in order to make a profit for the shareholders. This resonated with me when I look at web and social media interfaces today. I didn't like the idea in the movie, and I don't like it in reality.
When your website's marketing and initial purpose has been successful, remember that you are now building and writing for an established audience. Use that knowledge to power through your re-design meetings and keep all the stakeholders focused on serving your audience. You will end up with a better project, better content, a more accessible site, and an ever increasingly loyal audience.
Recently one of the projects I've been working on is to assess the accessibility of a number of sites and to provide feedback to the client as to how accessible those sites are under the WCAG Guidelines at w3.org. I also recently found a link we had shared earlier this year on our own site relating to how w3.org had recently updated its site design. As a result, here I am writing an article on Accessibility.
I am not a person with disabilities. I don't really know anyone specifically that has disabilities. That being said, part of my job is to build websites that should be accessible to people of all abilities. This means thinking outside my own little world of being able to interact with websites as a fully able-bodied person. Recently I have been using tools that assess the accessibility of websites. These tools have opened my eyes and have changed how I think about the development and design for the websites we build.
The Web Accessibility Initiative (WAI) is a resource that until recently I only consulted occasionally when the need arose. I have had some time this week to fully look at some of the items that should be standard reading for any web designer or developer. The rules and recommendations found at the WAI may sometimes seem counter productive to a slick design for websites, but in actuality they force designers and developers to rethink their understanding about the website's or web application's audience. Not everyone interacts in the web environment in the same way. We need to remember that when we're developing our web projects.
As a developer, my specific job is to translate a design into a functional interface. I get significant enjoyment out of doing that. What I had not fully realized until recently is how significant that underlying coding can affect how a person interacts with the interfaces we create. Colour, contrast, and structure play a more important role than just setting up a visual interface. For people with disabilities, those elements of a design and development process determine whether that interaction is helpful or impossible (or somewhere in between).
We've developed our own Content Management System (CMS) over the years, and one of the things we're most proud of is that we've set it up to build out our pages and functionality with accessibility in mind. There are still things we can improve on (and we continue to do so), but we've done a pretty good job of making accessibility a priority. We also advise our clients to keep accessibility in mind when they are supplying content, and we make ourselves available to provide advice on best practices.
Accessible interfaces can be hard to implement. Functionally, we can do it. The difficulties come when a design is provided that is by its nature not accessible. The design may not take into account contrast requirements, or they have definite ideas on how interactive elements should be presented. We do not want to get in the way of those creative ideas, however we do need to be able to say no. Accessibility is no longer just an aspiration, it is now, in some cases, required by law.
During the time we've been involved with these accessibility assessments, one of the primary issues we've found is that certain prolific CMS platforms are very good at the very root level of accessibility construction for web pages, but many of the custom plugins that are used to extend the functionality are very poor at maintaining the level of accessibility required to meet the legislative standards.
We're not saying that all of these plugin developers are creating poor code. The more reputable plugins have been developed with accessibility in mind. The problem there is that the plugins environment is sometimes a bit of a Wild West. The root platform developers want to make it relatively straightforward to extend their platform, but that means there is little to no standardization required for plugins to be approved. As a result there are some pretty terribly coded plugins out there and the average person can't tell good from bad.
Some highly advanced sites we reviewed were developed with custom code. We would expect that the custom development would follow at least the minimum accessibility standards that are required today. Surprisingly we found dozens of accessibility errors and alerts that could easily be mitigated by running some simple accessibility testing.
During our development of sites and web applications it is our standard practice to run our pages through automated tools to check for deficiencies before we prepare to launch to the public. We use the WAVE WebAIM tool to provide us with a report on how our underlying code stacks up to the WCAG 2.1 standards set by w3.org.
We will continue to endeavour to make sure our own CMS lives up to the accessibility standards set out by the W3C. We will also continue to provide accessibility advice to our clients to help them put their best foot forward in providing their information to people of all abilities. We want to continue to help our design partners be aware of accessibility during design development so that any accessibility design issues can be addressed preemptively.
Not everyone interacts with the online world in the same way. If we remember that, the world becomes a better and more inclusive place.
PHP 8.1 required. Improved typehints across the framework. CakePHP now leverages union types to formalize the types of many parameters across the framework. Upgraded to PHPUnit 10.x New enum type mapping support in the ORM enabling more expressive model layers with improved type checking. Table finders with named parameters, providing more expressive query building APIs. Added time-only Time type and greatly improved Date and DateTime support via chronos 3.x. Support for PSR17 HTTP factories was added.