Learning on the Job

I’ve been the receptionist here at Algonquin Studios for more than six months now and I have to say, working at a technology company when you don’t have the same level of technical knowledge and understanding as your co-workers can prove to be pretty challenging.  Fortunately, it can easily be informative and rewarding as well!

If you’re at all like me, you’ve experienced the complete confusion of overhearing a conversation and not understanding a single aspect of it. Obviously, at a company that develops custom software and web sites many of my fellow employees discuss their code and designs frequently, and although I sometimes get lucky with lunchtime discussions that revolve around the most recent Bills game, fantasy football, or the NHL lockout, I often feel lost just listening to them when the topics veer back to HTML, database design, or requirements analysis. And, of course, technologies are always changing, so as soon as I think I might  have a good grasp on something, it changes, or gets “improved,” and I feel like I’m back at square one.

But, the flip side of this coin is that for all of my confusion there’s an opportunity to learn.

One of the best things about Algonquin Studios is that it’s a company of technology consultants. While I’m certainly a competent computer user – I can download music, install new hardware and software, and surf the internet with confidence, knowing I’m not going to get a virus – working with developers and designers who spend their days, not just staring at a screen, but actually interacting with our clients, having real conversations with them, asking the questions that get to the root of their problems, and then buckling down to develop the right solution for that problem, means that I’m in the enviable position to pick the brains of people who can really break things down for me and explain them clearly and simply. I can ask questions about things I don’t understand and gain better understanding of constantly evolving technologies. And, since I’m a pretty fast learner and I like being able to share new things with others, I enjoy being able to take the knowledge I gain here and pass on to my family and friends.

I think it’s important to remember to keep an open mind, not just about new technologies but also about your own ability to understand them and use them in your daily life. And it’s equally important to find people who are willing teachers. Fortunately, at Algonquin Studios, my inquisitive spirit is complemented by a group of really helpful technology experts!

 

Page-Level Container Discussion for HTML5

This post originally appeared on my blog.

HTML5 logo — I am the 'alt,' not the 'title' As I started down the path of my first HTML5 web page I spent a good deal of time trying to understand the sectioning elements of HTML5 — nav, article, aside, and section — as well as the major structural elements such as header and footer.

Trying to find the container to wrap the content of my page turned out to be the hardest part of the process.

Are We Talking about a Content Element?

Some elements more obvious in their intended use than others, but I felt that there was no specific element to denote the main content of the page. I struggled with trying to figure out whether my content should be in an article, a section, or even just a div.

Apparently I am not alone. Even folks on the WHATWG mailing list were asking the same question. And then I saw this feedback from Hixie:

The element that contains “a website or a blog entry’s main content” is
body, as far as I can tell.

It seemed like that was the end of that. Clearly he had considered it and felt that there was no issue.

But in the past week on both the WHATWG mailing list and the W3C HTML Working Group list this topic has resurfaced. And there are some good arguments in its favor.

Why Should We Get a Content Element?

One argument is that developers are already coding a solution to this, often by specifying a div with an ID of “main” or “content.” In this scenario, the concept of paving the cowpath, where HTML5 is intended to reflect how developers actually code web pages, comes into play. If it’s already appearing in code, perhaps formalizing it can allow for consistency in structure and semantics. This is, after all, how we got nav, aside, and others.

Another argument centers around ARIA use for accessibility. Since elements like header and footer have built in ARIA roles, developers who care about accessibility want an element with a similar built in role for the main content. Currently, these developers put role="main" into the div or other element that wraps their page.

The argument in favor of a content / main / maincontent element is then a matter of demonstrating an existing pattern and an end-user benefit, in this case in the form of accessibility.

Why Shouldn’t We Get a Content Element?

The flip side of this argument is that we’re just creating another element to add to the tag-soup that developers are already contending with in HTML5. Evidence today shows us that 95% of the pages that use ARIA ultimately use role="main" properly. Those pages that use ARIA at all only make up 1.3% of a 10,000 page poll, however.

Those users who understand and want to provide accessibility are already doing it with ARIA. Adding a new element may help get more developers to accidentally support accessibility, or it may confuse the issue if its use isn’t restricted to one instance per page.

What Might This Content Element Look Like?

Steve Faulkner proposed a new element, maincontent, on the W3C HTML Working Group list yesterday, pointing to his own draft to start discussions. Ostensibly he concatenated the commonly used IDs of “main” and “content” that already exist in the wild when naming this element.

Where it goes from here is anybody’s guess. Discussion is happening on both lists, but with all the other activity and the push to start to wrap up the specification it may get pushed out. Perhaps this time next year there will be a solid proposal with well-formed arguments on both sides, but I wouldn’t expect to see a new element by then.

Related

Code Reuse: a Blessing or a Burden?

In the world of development, coders are constantly faced with the problem of creating efficient code under a very tight deadline. The idea of Code Reuse, simply the use of code created by another developer, has been a staple concept in the world of programming since the start of development. Whether it is an open-source library or code written by a stranger on a frequently-visited forum, every developer has utilized code reuse at one point. Code reuse definitely has its place in development, but should we rely so heavily on this model?

The first thing you need to think about before using someone else’s code is, “Do I have the right to use this code?” It’s becoming commonplace to see a lawsuit based on one company stealing code or concepts from another. But, beyond the legal reasons against using other’s proprietary code, there are also the ethical obligations that everyone should consider for leaving this code alone. No developer wants their own work to be stolen, so it’s also their responsibility to not steal code that doesn’t belong to them.

Not all code is proprietary though. There are entire communities that revolve around open-source libraries, made to benefit everyone. Here at Algonquin Studios, we have a monthly meeting during which all of the developers get together and talk about the technology they either are working on or want to work on. Our last meeting was based around third-party solutions and not “reinventing the wheel.” If there are solutions to your problem already in existence, why should you waste the time of your employers and clients?

I agree with the idea that if a proper solution exists, there is no reason to recode the solution. The fine line lies with the word “proper”  though. Too many times, I’ve seen a complex solution to a problem be reused in many places it shouldn’t. Usually the solution gets a “band aid” so that it works within the scope of the new problem but this just evolves as more closely-related problems emerge and eventually the coder ends up with inefficient code that barely solves the problem. The world of development has  begun to rely on third-party libraries and frameworks and other people’s code so much that they sometimes have no original code in their project and there needs to be a happy medium between quality and speed of development. Sometimes it’s worth it to rewrite an entire procedure that isn’t quite getting the job done. Sometimes you have a completely unique problem that someone else just hasn’t encountered before.

I still go back the “don’t reinvent the wheel” idea. If you can use other code that’s available and satisfies the problem in an efficient manner, then it’s a good solution. We all need to realize, though, that wheels come in different sizes and shapes. You wouldn’t want to put a hamster wheel on your car, nor would you want tractor wheel in your amusement park instead of a Ferris wheel. In the end, code reuse is a blessing to developers. Being able to create rich software at a fraction of the time spent is a very powerful tool. The developer just needs to learn when it is appropriate to reuse code, and when they should develop a solution specific to their problem.