Skip to main content

the web professional test - part ii

I'm of the mind that those of us who are Web professionals should be tested as part of qualifying for our jobs. Just as writers and others are.

The days are over (in truth, they never really started) when it worked to equip the inexperienced with WYSIWYG editors and turn them loose on the Web.

Web professionals need to perpetually cultivate a broad and in-depth skill set. If you are not motivated to do this, you quickly become a technological coprolite.

And while the specifics depend to some extent on the size and composition of the Web team, the more you can offer, the better.

So in addition to the usual interview questions, here is how I would test:

1. Build a relatively simple database and accompanying Web interface. (Skills: database/dynamic programming skills and good programming hygiene.)

This is critical. I need to know these things: Do you understand different types of databases? Do you know how to build one? Do you write well constructed, nonmessy code? Comment in a way that is helpful? Use a framework? Document? Treat everything you develop as potentially reusable? What is your grasp of database and programming security?

2. Turn a non-Standards Compliant Web page into a compliant one and explain what you did and why. (Skills: Understanding Web Standards and putting them into practice.)

Along with being able to create Standards-compliant Web pages that are well constructed and semantic, do you understand the importance of all this? How do users benefit? How does the site benefit?

3. Evaluate a Web page that has problems with usability. Recommend improvements. (Skills: Recognizing and addressing usability issues.)


Because a site can validate but still have myriad usability issues.

4. Write the content for this Web page. Edit the content of this other Web page. (Skills: Writing, especially for the Web.)

Anybody who writes and publishes code should also be able to manage the written word. It's inevitable that Webmasters' and programmers' writing makes its way onto Web pages, into Web applications, into documentation, into reports, into important e-mails. We've all seen bad examples of this sort of thing.

5. Case study: An internal client comes to you and asks you to build "a new Web site" highlighting her department. She wants it to have its own "look and feel" plus a lot of "pizazz." So that it stands out from the rest of the departments' Web pages. She needs this new site within the next week and a half. Write up a plan for how you will address this request. (Skills: Web management and governance.)


This scenario trips up the inexperienced and unskilled. It's about deciding when a "new Web site" is a good idea and when it's not. It's about maintaining the integrity of the existing Web presence. It's about managing expectations. It's about thinking rather than reacting. It's about saying "no" when it's appropriate.

..........................................

Expectations are changing. Users and organizations are getting tired of laboring along with unwieldy Web interfaces cobbled together by the unskilled, wielding out-of-date and misused technologies. This is quickly causing those who work with the Web to sort themselves out into two groups:
  • Those who don't stop self-educating.

  • Those who can't. Or won't.
Webmasters, Web developers, Web coordinators, Web administrators - whatever you want to call us - are supposed to be professionals. The role needs to be treated as a professional one by all concerned: Leaders of organizations. Peers. Clientele. Other IT workers. Especially ourselves.

Popular posts from this blog

Plone Advocate Andreas Mantke to Lead Site-Administration Workshop at 2012 LibreOffice Conference

I just published this article at plone.org on Andreas Mantke, a deputy member of the Board of Directors of the Document Foundation for LibreOffice . Mantke led a workshop for new Plone site administrators in the LibreOffice community during its annual conference last week. See the full article at plone.org/news/andreas-mantke-to-lead-site-administration-workshop .

the case for incremental redesign: part i

Consider the dashboard of your automobile. Aside from a number of extras that have crept in over the decades, it's essentially configured the same as the dash of the car you drove as a kid. In fact, the design of the automobile's critical controls hasn't significantly altered since the Model T Ford. It's worked for more than 100 years, and we love it.