The 2014 Illinois Web Design contest was held in Springfield on April 4, 2014 (with a briefing of participants on April 3). This represents the 14th year I have supervised this contest. Many thanks to Jonathan Worent for his help in the supervision of this contest and for portraying the hypothetical client. As we have done before, the focus of this contest dealt with the process of designing a website (along with demonstration of a solid understanding of core web technologies). These days, anyone can create a website [there are numerous tools to assist]. However, demonstrating you understand the requisite business processes to develop a site centered around the user experience is not as easy. As we have done in some earlier competitions, we also focused on web accessibility this year. As always, we strive to help participants understand what practicing professionals encounter on a daily basis. For those who are interested in observations gleaned during this competition… Before delving into these observations, I thought it might be helpful for readers to understand the various tools employed by participants. These included:
- Adobe Dreamweaver (CS 6 and Creative Cloud versions)
- Adobe Brackets
- Adobe Photoshop (CS 5, CS6, and Creative Cloud versions)
- Adobe Illustrator
- Microsoft Visual Studio 2010
- Sublime Text 3
In this competition we focus on web design (and the underlying technologies – HTML, CSS, and JavaScript). We do not focus on server side technologies (we remain vendor neutral, but not vendor agnostic) as there are just too many variants (from .aspx pages written in C# or VB to ColdFusion, PHP, Ruby, Python and other alternatives).
I commend everyone who participated (whether in the high school contest or the post-secondary contest). The fact that you took the time to travel to Springfield, Illinois and devote a couple of days to competing says a lot about how passionate you are about these technologies. We observed a high level of professionalism and a desire to learn and improve. We see improvements in those individuals who return from one year to the next. We held a contest briefing on Thursday night and a debriefing immediately after the contests on Friday. There were a number of great questions asked as well as a number of excellent points regarding feedback. In the past we helped participants with time management. This year, we didn’t and we recognize that this is desired. We will adjust the contests next year for this.
We observed that everyone had documentation [licenses] for the software they were using. We also did not encounter a single virus this year. We commend everyone on their efforts at professionalism.
We also observed a number of insights during the interview process. Several additional questions were asked which teased out more information from the “client.” We also observed that several teams developed a number of insights as to what the client was asking for and the overall desires of the site. We did observe that some teams did not have any questions to ask (I recommend always having additional questions – this is the main way you learn more about the desired outcomes). We also observed a few instances where individuals talked much too long (repeating themselves). I attribute this to nervousness, but do recommend that everyone practice interviewing as well as making a short presentation (as to why they should be hired). Think in terms of an “elevator speech.” Consider that we board an elevator and you have less than 2 minutes to sell me on why I should hire you. Be concise as well as have specific points that you can do better than anyone else in the world.
I was impressed that the majority of code submitted was written using HTML5 and CSS-3. It is amazing to see how much penetration these enhancements have had over the course of the past couple of years. Since we did not allow Internet access, there were problems with validating code. This is to be expected (given you only have 6 hours to meet with the client, develop your wireframes, style tiles, and code the site (or a few pages of it).
I would recommend the following areas for improvement in the future.
First – include comments in the code. Yes, there is an argument that code should be self documenting, but one still needs to know who wrote the code, when, the purpose and so forth. Some were great at this and even included proposed colors. Other teams had no comments at all.
Next – be careful of what you type. We saw many instances where a simple typo was replicated time and again. For example <a href=”another link” <link</a>. Note the error < instead of >. This was then duplicated over and over.
Also, be careful that your links point to the proper location. This can be easily overlooked when adding @font-face. As we mentioned at the contest briefing on Thursday night, it is important to check your work as many times as possible. We do realize there were time constraints and this was taken into account when the sites were reviewed.
Since the site was for a hypothetical organization which focused on helping others help themselves, one should pay particular attention to accessibility concepts. We saw a number of images with no alternate text. This should have been included (as it helps screen readers). We also saw that tables were used for layout. This is 2014 and no one should use tables for anything other than tabular data. We have lots of capabilities with CSS. If you are being taught to design with tables, it is imperative you have your instructor contact me as this is simply outdated and wrong.
We saw that some teams had not been exposed to the concept of wireframes and style tiles. These approaches are used in most professional shops these days. We do hope that those who had no exposure to these concepts communicate with their teachers and ask that this be included in their program of study.
We observed a few instances where inline styles were applied in addition to linked CSS stylesheets. This approach should be avoided. It is preferred that all CSS be linked for ease of maintenance. It would appear that some tools generated this (and it was not removed). For example the class was named .style42 (we strongly recommend descriptive names for all classes and identifiers).
We also observed a number of things done correctly. For example, the semantic nature of HTML5 was properly employed by several teams (using elements such as article, section, nav and so forth). We also saw that several teams coded a lot of CSS (although they may not have had time to finish all of it). They developed a structure which could easily be completed. We saw the use of reset.css (and coded by hand) to make browsers display consistently. We also saw creative uses of JavaScript to dynamically display additional content. I recommend that those who took this approach also test in multiple browsers (or list which browsers were used for testing in the comments). The sites were reviewed in IE, Firefox, Opera, Chrome, and Safari. Differences were observed as the code was displayed in these browsers.
We noted that many teams gave serious thought to multi-screen environments (from desktops to tablets and smartphones). Some incorporated a significant amount of CSS to accomplish this. We also saw this in the various wireframes we reviewed.
Overall, those who judged these sites commented on how much was accomplished in such a short time. Again, 6 hours were allocated from meeting with the client until there were actual web pages developed. Congratulations to all who participated. We do hope you enjoyed the competition. We also hoped you learned a little and reinforced that you already know quite a lot. I look forward to your comments. We also hope to see the first place teams (for both secondary and post-secondary in Kansas City in June).
Loading ...
