My Reports & Responses to User Testing Acceptance
My response on server configurations:
Hi D,
For the global elements, using include files make sense, but it is also too heavy-handed to rely on PHP or ASPX for these tasks.
For caching, not just images, but also HTML, JS, CSS, PDFs, DOCX, XLSX, PPTX, Font Files, etc. It is good that your server optimizes images for the web before they hit the sites, but furthermore, it should serve responsive images (small size for mobile, medium size for tablet, and large size for desktop). All the codes should also be compressed for optimization.
For the quotes on CDN and failover, I defer to my supervisor who will also have the final words on caching strategy and the server configurations for the global elements.
Thank you for your response and patience.
My response on Service Worker:
In our initial meeting, we asked for Service Workers API and M had agreed to implement it. The test page shows no registration and the pages do not work offline.
I am surprised to learn that your company had never implemented Service Workers. Registering the entire site would be too much, but just a handful of important pages such as PeopleFinder, Admissions, Course Offerings, etc. would be doable.
Getting a quote to implemented Service Workers is above my pay rate. I defer to my supervisor.
My response on no JavaScript:
As I had mentioned in our initial meeting, we would like our site to be built with progressive enhancement; therefore, our site should work even without JS to accommodate all type of users. JS should enhance the user experience and should not hinder basic functionality. The HTML pages provided are not working with JS turned off. Please fix this issue.
We received many complaints in the past that our site didn’t work with Javascript turned off. They didn’t want JS pop-up ads. They didn’t want JS third-party trackings. These are valid points; therefore, we had to make our site work without JS. Of course, we had to use JS for things like table sorting and such, but the tables still work without the sorting functions.
Our standard practice doesn’t depend on technologies. Our standard practice is to make our website as accessible and usable as possible. Our mission is to provide an inclusive, not exclusive, experience. We use JavaScript as an enhancement, not a requirement. If users have JavaScript turned on, they will get the enhanced interactive experience. If they don’t, they are not excluded from our content. The new test pages rely heavily on JavaScripts. Even if users have JavaScript enabled, they would also be blocked from accessing the website if JavaScripts failed to load.
As I had pointed out, we received complaints about our current site not being accessible without JavaScript and we had to rework our codes to make it work without JS first. It was easier for us to recode our site because we built everything from scratch and not relying on any frameworks that depended heavily on JavaScripts.
As a developer, I understand this is a daunting task, but my responsibility is to report the issues. My supervisor will make the final decision on how we should proceed.
My response on tables not display in full:
On large screens, especially desktops, the table should display in full and not cut off. This limitation will cause accessibility and usability issues. It’s my supervisor call.
My response on variable fonts:
Since Montserrat is a huge family. Using static fonts wastes too much bandwidth. Please switch to VF fonts.
Not just loading, but also adding extra fonts that we might never use. I am pretty sure we will never use hairline and thin weight or bold italics and black italics. Right now you are loading 18 font files. With variable fonts, you only need 2. You can cut down 16 files. VF is much more flexible. You can choose an infinite number of weights. For instance what if I want the text to be thinker but not too bold. With static fonts, I can choose either 400 or 500. With variable font, I can choose anything between 400-500.
My response on indicators for linking to documents:
This issue is reported by our IT Accessibility Expert. I concur with her and strongly recommend that we have an icon indicator for each linking file type to improve accessibility. We currently apply this practice on our current site. I defer to my supervisor if we need to continue this practice or not on the new site.
My response on header issue with nav links wrapped:
UI is best set in a sans-serif typeface. If we were to choose another sans serif, I wouldn’t keep Montserrat. Using 2 sans-serif typefaces would cause confusion. Furthermore, it would make us looks amateurs. If you want to keep Montserrat, we would need to find a different solution for the nav, which is to move it to the top.
That’s just my suggestion. My supervisor will make the call.
My response on layout options:
I am not seeing any layout options for the main text area. Is it always main content on the left and sidebar on the right? Is there a full-width option? Is there a split 2-2 option? 1-3 option?
We did talk about flexible layouts with Brad. We even showed examples.
I defer this to my supervisor.
My response on site performance:
The point of performance score is based on internet connections, images, assets (css, js, etc); therefore, the goal is to optimize for the sites for these circumstances. It is not related to your CMS, but definitely related to front-end development.
I have all of these issues written down for the record. I pointed out the problems and made the suggestions. I don’t have the power to make the final decisions. If the site wouldn’t work as expected later on, it would not be my fault.