We held our 16th annual web design and development competition in Louisville, KY the last week of June. We provided mandatory training to all competitors so they had a better understanding of the process involved with web design and development these days. Obviously a lot of work by many individuals was necessary to make this happen. We sincerely appreciate the efforts by our on-site team and our judges. We could not do this every year without you.
Our on-site team
Many thanks to the team who was onsite and provided assistance to competitors in using our “web contest in a box” solution in addition to the training. They also conducted interviews and reviewed the process competitors used to complete the work order. This team was present the entire week (they took time from their “day jobs” in order to be present for this event). We can not thank them enough!
Separate competitions were held for high school students (Wednesday, June 26) and post-secondary students (Thursday, June 27). Judges reviewed materials provided by competitors. The materials were placed on a secure web server after each competition so judges (from other states) could review the efforts online. Judges had to meet tight deadlines as all entries needed to be reviewed and submitted before 8 a.m. Friday so that awards could be handed out on Friday evening. We are one of 103 separate competitions at SkillsUSA Nationals.
Comments from Judges
We asked judges to summarize their comments and are sharing them here. We also provided a synopsis of these comments at our contest debriefing on Thursday afternoon (after the post-secondary competition was finished – those comments were for the secondary school entries the previous day).
Overall, judges were glad to see that the antiquated practice of designing with tables is finally not being utilized by any of the teams. This was the first year we observed this (yes, some schools still seemed to have been teaching this ancient approach as late as last year). We organized these comments into major areas. These are summaries of what was observed. As standard practice, we never call out specific tams (either positive or negative). We have also been asked to never publicly share the web sites developed by each team (this is why there are no screen captures of the winning work).
We also saw that no viruses were provided on the materials submitted. Having selected files uploaded to our local server and allowing most of the code to be written directly on the server using Theia likely helped with this.
The first header on the page should be h1. Headings should be correctly stacked and should represent the logical structure of the page.
Meaningful images should have alternate text associated with them. This text must be meaningful. The alt text “photo” is not meaningful.
Link text should be provided (and should be longer than just a few characters – remember some have muscle movement disabilities). Look in terms of the overall user experience as well and do not provide conflicting or confusing links.
Decorative images should be marked up appropriately so there is no confusion.
There should be sufficient color and contrast between background images and text visible on the page. Yellow text on a yellow background image is nearly impossible to read.
Form control inputs should be labeled. Remember that assistive devices rely on this information to properly present the form to the viewer who needs visual assistance.
Graphics and Type
One should use colors which compliment what the customer desires. If they are selling grilled cheese, use colors which support their efforts.
Some teams did a nice job on the overall design. These sites flowed well and made proper use of white space.
Contrast was also mentioned by these judges. If you overlay text on a background image, make certain to use a color which allows the text to be read easily.
It was also mentioned that fonts should not overwhelm visitors. It is also wise to limit the number of fonts used on a site to a few (perhaps 3 or so).
Programming and Code
Don’t use outdated approaches. Judges saw an instance of the <center> tag this year. How long has that been deprecated? Use CSS for any styling; HTML is for the content and structure of the page only.
Judges also reported that some tags were not valid. For example, there was a <t> tag and a couple of other tags which are not supported in any browsers. We suspect these were typos; this is why it is so important to check your work before you submit it.
Meta tags should be used properly. Make certain o also specify the doctype and the language of the page (preferably EN-US).
Indent your code for clarity of reading. If you have a lot of indenting, use spaces, not tabs. The latter will force the code off the screen (or to wrap) when viewed by the judge).
Judges were glad to see use of modern CSS features (such as flex) including transitions and text effects.
A number of teams did not seem to have a solid understanding of how to read an API using the modern approach (fetch). We encourage everyone to review this practice. This is also why we provided working examples on the local server that all could see when they accessed the API via their browser. Most modern web sites rely on reading APIs for many things. We wonder if this is being taught in most schools these days?
Companies look for passion these days. The person asking “why should we hire you” is looking for detailed examples of your passion. Perhaps you like to write great code; provide specifics. Perhaps you like to help others; again, provide examples that demonstrate your passion.
I you are asked how the site will help the company achieve their goals (and you don’t seem to know what the company goals are), ask. Remember interviews are a two way street. If you don’t know something or understand, ask clarifying questions to help you better understand. Then, provide details as to how the site will help the company.
Remember this is a team competition. Interviewers are looking for examples where individuals work as part of a team. Although you don’t need to finish each other’s sentences, it is important to identify which specific skills each member has (and discuss how they compliment).
Process [updated Nov. 25, 2019]
We evaluate the initial intuitiveness of the wireframes, sitemap, and other planning documentation from a client’s perspective who isn’t an expert in our domain. We understand that this is a short contest and we are only asking for low-fidelity deliverables and account for this generously. It is important to understand that these deliverables are an important communication tool with a client so we should be able to look at planning & process deliverables and, to a limited degree, find the ‘signposts’ that anchor UX. We should be able to, at a glance, and even in low-fidelity, be able to understand content areas from images.
We ask the teams to explain their plan. The thought process behind the choices is very important. Why did they choose that content to be first, and thus the highest priority? Does that choice align with the client’s spoken briefing? Does it tie back to any marketing efforts or UX principles? If they choose to have a blurb of text somewhere, have they given thought to the real content they intend? Is this a paragraph or a few sentences? If they say they want an image somewhere, did they think about what type of images they wanted? An illustration, a photo, why?
This is 2019 and the tipping point has long come for mobile. Most websites will see higher traffic from mobile than desktop. Did they have deliverables for mobile? Unfortunately, few teams have given this any thought either during explanations or in specific deliverables and are missing out on a lot of potential points. If they have deliverables that show a plan for mobile we evaluate reflow and content flexibility? If they plan for a paragraph on desktop, have they accounted for the extra space it will take on mobile? For planned images, do they understand responsive images and file size for faster download or that different images can be used for aesthetic purposes to keep focus on what the image is meant to convey.
We state during the briefing that sitemaps are an opportunity to plan the breadth of the entire site while we only ask them to detail wireframes for a few specific pages. We are looking for appropriateness for the client in additional pages and content the client’s website will need. We evaluate the explanation and justification for those specific pages. What was their thought process? Did it align to any client’s stated goals? Do they understand SEO and searcher intent in even limited capacity? Do their explanations indicate they have given any thought to the client’s goals?
In all of their explanations or in follow up questions we look for an understanding of how to measure success. The bar is appropriately low here; they are not expected to know what a KPI is, but there should be some evidence to thoughts given to testing and measuring success through usability testing and/or analytics.
While they are working and well before the deliverables are evaluated, we are looking to see the teams interact with the client. We make a bit of a to do that the planning phase is an opportunity to communicate with the client. Few teams attempt to interact with the client in any way and elicit feedback. All too often, after the initial client briefing, no one talks to the client until we evaluate the deliverables. Which unfortunately aligns all too often with the real world of frustrated clients we have encountered who say they haven’t heard from the freelancer they paid for weeks and then the developer gets frustrated when the client wants changes so late in the process. Needless to say, there are points left on the table when teams don’t interact with the client at all.
Overall, we saw significant improvement in the efforts by competitors this year. We also saw that advisors/ teachers were asking more specific questions so they could better prepare students for the work force (and for the competition next year). We hope readers find these comments useful. If you have questions, please ask in the comments below.
Executive Director and Chief Evangelist
World Organization of Webmasters (aka WebProfessionals.org)