Hotgrafix Website Design

Quick Tip: Notable New Features in Dreamweaver CS5

hotgrafix.co.uk56 — Tue, 15 May 2012 13:14:31 +0000

If you’re a Twitter user, it was difficult not to be aware of Adobe’s CS5 global launch presentation. While they did an excellent job of promoting Photoshop and Flash, other applications, such as Dreamweaver, only received limited coverage. Nonetheless, take a look at some of the awesome new features in Dreamweaver CS5, slated to be released in mid-May.

1. BrowserLab Integration

Adobe, for some time now, has offered a helpful, and free, service called Browserlab. For those unfamiliar, Browserlab is a Live service that allows you to view snapshots of your website in a variety of browsers, not too dissimilar from Browsershots.org. Luckily, with CS5, this service is fully integrated into Dreamweaver, even allowing us the ability to stack multiple snapshots of our designs, from various browsers, on top of one another. This is especially helpful for those of us with pedantic attentions to detail.

“Preview dynamic web pages and local content with multiple viewing, diagnostic, and comparison tools.”

2. CMS Support

Perhaps the most welcomed and exciting new addition to Dreamweaver, there is now a “live view” option, when working on, for instance, templates for a variety of CMSs, including WordPress! This means that you can browse pages, populated with postings from your database, directly within Dreamweaver. How cool is that?

“Enjoy authoring and testing support for content management system frameworks like WordPress, Joomla!, and Drupal.”

3. Site-Specific Code Completion

This is something to be excited about. WIth this latest release, we now can utilize intellisense on site specific coding. For example, imagine being able to access the various WordPress functions directly from the intellisense pop-up? Pretty cool!

“Benefit from code hinting on nonstandard files and directories in Dreamweaver..”

4. Adobe Business Catalyst Integration

This new feature is being promoted heavily, and, while it might definitely prove to be appealing to some designers and non-programmers, I doubt our particular community will utilize this new addition. Essentially, it allows you to design and build websites with minimal coding experience.

“Leverage integration between Dreamweaver and the Adobe Business Catalyst® service (available separately) to deliver powerful online businesses without programming.”

5. Improved CSS Inspection

The Dreamweaver team has added a new feature which allows us to, after clicking the “Inspect” button, click on various elements on our page, and immediately view the applicable styling associated with that particular element. If you’re familiar with the Web Developer Toolbar, and Firebug, you’ll be quite familiar with this. Nonetheless, it’s a nice addition to have available from directly within the IDE.

“Visually display the CSS box model in detail, and easily toggle CSS properties without reading code or needing to use a separate utility.”

Missed the Launch Video?

If you didn’t catch the live unveiling, you can watch it here. So what’s the consensus? Has Dreamweaver finally come through for us? Will it take the place of your IDE of choice?

Attention Developers: NewRelic is your Secret Weapon

hotgrafix.co.uk56 — Tue, 15 May 2012 13:10:16 +0000

While the title of this article may sound like a cliche, hatched in the bowels of PR hell, I’m serious when I say that NewRelic is your secret weapon.

In this article, I’ll talk about the common aspects of web application performance, and then demonstrate how NewRelic makes it blissfully easy to manage.

In the nearly six years that I’ve worked at Envato – previously developing and managing the series ofmarketplaces and currently managing development of the Tuts+ blog network – I’ve used NewRelic to keep costs down, improve and debug performance problems from the small to the large, and avert potential catastrophes.

If you’re new to this topic, or don’t currently manage a website for someone in any capacity, don’t stress; this article will still be useful. You never know when this knowledge could save your bacon, and I’d wager it’s inevitable that it will – unless, of course, you decide to throw in the hypothetical developer towel and become an astronaut or rancher.

NewRelic in 20 Seconds

Before I launch into a reasonably long tirade on web application performance, it makes sense to quickly sum up what NewRelic is before you trundle off to Reddit or something similar.

NewRelic is a managed service (SaaS) that you “plug in” to your web app, which collects and aggregates performance metrics of your live web application.

The information it provides can help you find answers to questions like: Is my website slow? Who is it slow for? Where is it slow exactly? Do we need more, or bigger servers? What can we do to improve things?

These questions and their answers are oftentimes crucial to your web application’s success or failure. If you’ve never collected performance metrics from your live web app, you’re literally running while blindfolded; at some point you’re going to hit a wall!

Before I take you on a tour of NewRelic’s features, I have to define what web application performance is. Let’s get to it.

What Exactly is Web Application Performance?

Front-end performance is about “perceived” performance.

I like to split web app performance into two conceptual parts: front-end performance and back-end performance. While the two areas do indeed have crossover and affect one another, it’s helpful to draw a distinction.

Primarily, you can think of front-end performance as areas concerning perceived performance, such as how long a page takes to fully render to an end user. Variables that affect this type of performance include:

How large your HTML, CSS, JavaScript and images are
How many HTTP requests are sent to servers to fetch all of these assets
How they are organized in the page to affect perceived performance, whether or not a user’s browser has to re-download assets regardless if they’re the same or not.

I have only seen web applications and websites “fall over” as a result of mismanagement of the back-end.

Back-end performance involves some kind of programming language that runs your code (i.e. PHP, Ruby), and some kind of database server (i.e. MySQL). Generally, most web applications are assembling HTML documents to be sent to your user’s browser, and are made up of data fetched from one or more databases – or even one or more external service (such as the Twitter API). I also typically lump in server resources (such as CPU usage, memory usage, disk IO) into this category, as it’s the code running on your server (not in your user’s browser) that affects these resources.

Why is this distinction so important? Because, in my experience, I have found that a confusion between the two leads to useless effort being applied when trying to improve performance issues. I have witnessed work on the front-end performance of ailing websites when the actual issue has been the backend. On the other hand, I have watched people focus on back-end optimization when the problem has been on the front-end. It’s essential that you understand and appreciate the difference.

On their own, these two subjects can be rather deep and complicated, and it’s a topic for an entirely different series of posts. While I’m decidedly specialized in back-end performance, in all of my professional career, I have only seen web applications and websites “fall over” as a result of mismanagement of the back-end.

Three and a Half Approaches to Managing Performance

There are three ways in which people tend to manage the performance of their web applications:

Write code, deploy it, and hope for the best.
Write code, guess which areas will become bottlenecks, measure and optimize them up front, deploy and hope for the best.
Write code, measure the live application with something like NewRelic, then fix and tune as appropriate.

The first approach is 100% reactionary. If you follow this method, you will only know if your web app is failing or performing poorly when your customers tell you (if they ever tell you).

The second approach is considerably more mature; the developers are preempting problems and attempting to resolve them upfront. While this is admirable, the possibility of spending vital resources optimizing the wrong area, and the lack of ongoing feedback will provide few facts about what is truly going on in the live environment.

The third approach is the almost ideal situation. By monitoring a live web application, you’re able to review how various things are performing, based on what your customers are actually doing. You can write code and receive immediate feedback on how well (or not) it’s performing.

The Ideal Approach

The ideal approach is to follow the third and apply a healthy measure of the second.

It doesn’t hurt to consider performance up front; it is infinitely more useful to have true metrics. The old programming adage, “premature optimization is the root of all evil” may apply here, though, in programming, as in life, axioms are rarely anything more than half-truths.

Measurement & Management: A Balancing Act

There is no such thing as one true method to managing your web application’s performance.

No matter what anyone says (including me!), there is no such thing as one true method to managing your web application’s performance. Depending on your app and customers, there will be different approaches and techniques. Yet one thing remains constant: you have to measure.

So, what do you measure? Again, there isn’t one true list, yet there’ll always be a common number of metrics worth measuring. For example:

The number of application requests over time.
The wall clock time requests take to complete.
The CPU usage of your servers over time.
The hard drive reads, writes and utilization over time (known as Disk IO).
The number of database queries, and the time they take to run.
Queries run on your database that take over two seconds to complete (slow queries).
Incoming and outgoing bandwidth over time.

This list, while certainly not exhaustive, will offer significant insight into your web app’s behavior, especially if you’ve never monitored them previously.

Once you have this kind of data, the management of your web application is where all the fun begins. You may find that, once removing a bottleneck in your database (perhaps a few slowly executed queries), you’ll expose another as more server resources are freed up. It truly is a balancing act.

Ultimately, what successful management looks like is something like this: you may double the efficiency of that single server of yours, allowing you to delay purchasing a second. On a larger scale, you may cut your server farm down by a factor of 50%, and on a large enough scale, that can equate to serious money. On a lighter side, you may simply provide good quality of service to your customers with no sudden surprises.

NewRelic: Your Secret Weapon

Now that we’ve covered the “what” and “how” bits, let’s take a look at NewRelic. Once upon a time in software-land, you had to roll your own measurement into an app – if you measured at all (which can be as much work as writing your app itself). NewRelic allows you to simply plug in its agent to your Ruby, PHP, .NET or Python application, and begin collecting real data right away.

Thoughtfully, their product is split up into three core regions:

End user monitoring (front-end, the browser)
Application monitoring (back-end, your code)
Server monitoring (back-end, the servers)

Let’s have a look at each, in the order they were historically released.

The very first feature NewRelic launched was application monitoring. It tracks and reports on ‘Requests per Minute’ (aka RPM), average response times of these requests, and keeps this data for you to analyze. This is particularly useful for discovering trends in traffic over time (e.g. does my site get slower as our page views increase?).

Additionally, the “slow transaction traces” will provide you with a list of recent requests from real users that were disproportionately slow. Inspecting these allows you to drill down and determine why a request took such a long time, giving you the information you need to improve it.

End user monitoring will provide you with insight into how your site is rendering in the users’ browsers. It breaks the total time into chunks, based on things like network time (how long assets took to download), DOM rendering (how long your browser spend figuring out your HTML), image loading (as served by your web server or a CDN).

A neat feature of end user monitoring is that it shows you how well or poorly your application is performing for users in different countries. For example, perhaps 50% of your customers are based in the UK, while the other 50% are in the US. You might discover that front-end performance isn’t too great in the UK, due to the physical distance from your servers. Introducing a CDN or a server in the UK will improve their experience.

The best part of using NewRelic and taking action based on its data is that, once you’ve made any number of changes, you can immediately review if the changes have been effective or not!

The last piece of the puzzle, and the most recent monitoring NewRelic has introduced, is their server monitoring tools. I’ve always remarked that you must correlate your server’s resources with your web application response times to get a fuller picture of efficiency. You may have excellent response times, but you also may be needlessly sacrificing significant server resources to provide them.

I have seen apps with excellent YSlow scores, for instance, but absolutely no headroom for more traffic – even on significant amounts of hardware!

I hope by now you’re starting to see how valuable this kind of information is!

Installing NewRelic

You’ll need to at least be on a VPS and have root access for the PHP agent.

One of my only criticisms of NewRelic is that it’s not easy to install for some types of users. If you are a Ruby on Rails programmer, you’ll find it fairly easy, as it’s a simple Rails plugin.

If you’re a PHP developer and aren’t comfortable goofing around on the command line, you’re going to find it difficult to install, as it’s a PHP extension and requires a daemon to be installed running alongside your web server. However, some PHP cloud platforms, like PHPFog offer NewRelic integration out of the box.

This is unfortunate in my mind, as it’s a hurdle for most people. I hope NewRelic are currently looking to partner with more commodity web hosting providers, so that their product is more accessible to a wider audience. There’s literally no tool like it on the market at present, and they should be making it easy for all PHP developers to use.

If you’re using existing hosting, you’ll need to at least be on a VPS and have root access for the PHP agent. Being completely fair, to spin up a VPS from a provider like Linode, and installing Apache, PHP, MySQL and NewRelic is a short process, but it does requires some comfort and know-how in a shell.

The best way to get started using PHP and NewRelic is to use a tool like Oracle VirtualBox, install Linux, set up Apache and PHP and then install the agent. Then you’ll be able to use NewRelic in your local development environment, at the very least.

I personally haven’t had any experience with the Python agent, and I’ve heard third-hand that the .NET component is easy as pie to get up and running.

How Envato Uses NewRelic

Envato has been using NewRelic since 2008. We’ve used it in the following products with good (and sometimes interesting) results:

The Marketplaces

Initially, we discovered roughly three major slow spots in unexpected places in the marketplaces. We discovered what our highest trafficked requests were, and focused on optimizing them specifically. If 80% of our time was spent in one spot, making it twice as fast increased capacity and saved us from allocating more funds to hardware. We’ve spotted unusual traffic (such as spammers and hackers) allowing us to take precautionary measures sooner than later, thus improving the experience for our real customers. We use it daily to monitor the performance of all our new and existing code.

The Tuts+ Blogs

In 2009-2010, Envato’s blog network had serious stability problems due to a number of architectural problems. It was my job to step in and solve the issues. After performing an architectural analysis and a redesign of it, we plugged in the (then beta!) PHP monitor. We discovered many, many undesirable things!

20% of requests were hits to feeds (which should have been cached or sent to FeedBurner)
3 SQL queries were routinely taking more than 5 seconds to return results
Long-running WP-Cron tasks were tying up our web worker pool
404 pages were taking more than 1 second to generate!

Over the course of 2010-2011, we progressively sorted out the issues until they were, more or less, all solved. To this day, we still monitor the PHP blogs using NewRelic. And now, thankfully, the blog network is nice and stable.

The Tuts+ Premium Redesign

When we launched the Tuts+ Premium redesign, we used NewRelic to debug performance problems before the actual launch, on the actual servers they were to run on. This allayed any fears of disaster upon launch. We continue to monitor the site’s performance, using NewRelic.

Today, any important application at Envato has a NewRelic agent plugged in. It honestly has saved us heaps of time and money, and allowed us to provide quality of service to our users and customers.

Other Tools Envato Uses to Augment NewRelic

It wouldn’t be fair to not mention the other tools we use to look after our applications. We currently useScoutApp for finer-grained server monitoring (it supports user contributed ‘plugins’ so we can monitor specific services like HAProxy, Nginx, etc). We also use AirBrake which logs and aggregates our errors in our Ruby on Rails applications.

Lastly, we have rolled some of our own specialized, custom tools that check things like cache hits, backend requests, revenue, sign ups, notifications when a significant deviation from the trends occur. For example, revenue halting or dropping might mean our payment integration is broken; a change in sign ups means we might have been targeted by spammers creating ghost accounts for later use.

HTML5 is here: A Brief History on what is to come

hotgrafix.co.uk56 — Tue, 15 May 2012 13:08:33 +0000

This is that article you generally skip over. It’s the one where I don’t detail an ounce of code, but instead describe the important events that lead to what you now recognize as HTML5. Some of us find this stuff interesting, but, certainly, a history lesson may not be your idea of a good time.

…Wait – you’re still here? Let’s get on with it then.

We won’t travel as far back as the beginning. That’s an entire book on its own. Instead, we’ll rewind the clock to to the release of HTML 4.01, at the tail-end of the nineties.

What’s the Difference Between the W3C, WHAT WG, and HTML WG?

W3C – A community with the sole purpose of working to develop web standards.
WHATWG – Formed after various members of the W3C became agitated by the direction being taken with XHTML 2.0. They preferred a different, less drastic approach, where the existing HTML was extended.
HTML WG – Once the W3C finally recognized that XHTML 2.0 was not the future, they indicated that they wished to work with the WHAT WG on development of what would eventually become HTML5. They chartered the HTML WG for this purpose.

If that still sounds confusing, don’t worry; continue reading for the full story.

HTML vs XHTML

Right around the period that HTML advanced to version 4.01 (around 1998), the ground began to shift a bit. Developers started to talk about this next new thing the W3C was working on: XHTML, which stood for “Extensible Hypertext Markup Language.” This first 1.0 specification was more or less identical to HTML 4.01, other than the inclusion of a new MIME type, application/xhtml+xml.

Believe it or not, we’ve always been able to get away with omitting quotations around attribute values (mostly), and not self-closing tags. However, up until recently, it was widely considered to be a bad practice. For the youngsters among you readers, the reason why we viewed it as a bad practice is largely due to the popularity of XHTML.

Think of XHTML as your grandmother. When she comes to visit, she forces you to brush your teeth, stand up straight, and eat your peas. Now replace teeth, posture, and peas, with quotation marks, self-closing tags, and lowercase tag names.

Though I kid, mostly, we viewed XHTML 1.0 as a good thing – the next step. It required designers and developers to follow a set of standards when creating markup. How could that be bad? The irony is that, though we followed these new rules, the majority of us continued serving pages with the text/html MIME type, which meant that the browser didn’t really care how we created our markup. This way, XHTML could be opt-in.

So we were writing markup in a certain, strict fashion to pass XHTML validation that had zero effect or influence on the browser’s rendering. A bit odd, huh?

XHTML 1.1

This all changed with the introduction of XHTML 1.1 – a significant shift toward pure XML. With this release, the application/xhtml+xml MIME type was required. Sure, this may sound like the natural next step, in theory, but there were a couple glaring issues.

1. “Save to Disk”

First, Internet Explorer could not render documents with this MIME type. Instead, it would prompt a save to disk dialog. Yikes!

“I’ve also been reading comments for some time in the IEBlog asking for support for the “application/xml+xhtml” MIME type in IE. I should say that IE7 will not add support for this MIME type – we will, of course, continue to read XHTML when served as “text/html”, presuming it follows the HTML compatibility recommendations.” –Chris Wilson

2. Take No Prisoners

XHTML 1.1 was sort of like Professor Umbridge, from Harry Potter.

Secondly, XHTML 1.1 was sort of like Professor Umbridge, from Harry Potter: extremely harsh. Have you ever noticed how, if you leave off a closing tag, the browser doesn’t flinch? Browsers are smart, and compensate for your brokenmarkup (more on this shortly). While, these days, the community is beginning to embrace and take advantage of this truth, with XHTML, the W3C wanted to enforce XHTML’s stricter syntax. Though, up to this point, developers could get away with leaving off, say, the closing or tag, the W3C implemented a new fail on the first error system, known as draconian error handling. If an error was detected, the browser was expected to cease rendering the page, and display an error message, accordingly. Like I said: incredibly harsh for markup.

As a result, few of us ever used XHTML 1.1; it was too risky. Instead, we adopted general XML best practices, and continued to serve our pages as text/html.

XHTML 2

In their minds, the W3C was finished with HTML 4. They even shut down and rechartered the HTML Working Group, and transferred their focus to XHTML – or, at this point, XHTML 2.0.

XHTML2 was an effort to draw a line, fix the web, and right the wrongs of HTML. Though, again, this sounds fabulous, in truth, it angered much of the community, due to the fact that it was never intended to be backward compatible with HTML 4. In fact, it was entirely different from XHTML 1.1 as well!

Get where I’m going here? The W3C was essentially ignoring the current web, and the demands of its developers, in favor of a strict, potentially page-breaking XML approach. It simply wasn’t practical to expect such a huge transition.

XHTML2 was never finalized.

Fight, Fight, Fight!

(Okay, not as Fight Club as that.) Right around this time, the idea that, “Hey – maybe we should return to HTML and work off that” began to come up again. Work had begun on Web Forms 2.0, which managed to spark renewed interest in HTML, rather than scrapping it entirely for XHTML2. This notion was put to the test in 2004, during a W3C workshop, where the advocates for HTML presented their case, and the work they had already done with Web Forms 2.0.

Unfortunately, the proposal was rejected on the grounds that it didn’t fall in line with the original goal of working toward XHTML2. Needless to say, this rejection angered some in the group, including representatives from Mozilla and Opera.

The group consequently branched out, and formed the WHAT Working Group (or, “Web Hypertext Application Technology Working Group.”), after, for lack of better words, becoming pissed off at the way XHTML 2 seemed to be heading. Their goal was to keep from throwing the baby out with the bath water. Continue and extend development of HTML, via three specifications: Web Forms 2.0, Web Apps 1.0, and Web Controls 1.0.

The Two Golden Rules

This new group would embrace two core principles:

Backward compatibility is paramount. Don’t ignore the existing web.
Specifications and implementations must match one another. This means that the spec should be incredibly detailed (hence, the 900 pages).

“The Web Hypertext Applications Technology working group therefore intends to address the need for one coherent development environment for Web Applications. To this end, the working group will create technical specifications that are intended for implementation in mass-market Web browsers, in particular Safari, Mozilla, and Opera.” – WHATWG.org

Parser

Don’t underestimate how significant an achievement this was.

While XHTML 2.0 intended to enforce perfect XML, the WHAT Working Group instead took it upon themselves to document exactly how HTML is, and should be parsed. – a five year task!

Remember when we discussed how browsers do a great job of compensating for your broken markup? The interesting thing is that, before the creation of the WHAT Working Group, there wasn’t any specification that provided instructions to the browser vendors for how to deal with errors. This naturally leads up to the question: how did the browsers match one another’s error handling? The answer is through tireless (though essential) reverse engineering. Firefox, Safari, and Opera copied Internet Explorer’s implementation, and Internet Explorer reverse engineered Netscape handling.

Over the course of five years, the WHAT WG charted out what’s now referred to as the HTML5 parser.Don’t underestimate how significant an achievement this was. Today, all modern browsers parse HTML according to the guidelines of this specification. Though perhaps not as sexy as, say, canvas, the HTML5 parser is a massive achievement.

A Line in the Sand

As you might expect, an imaginary line was drawn in the sand. You’re either for XHTML2, or (what would eventually become) HTML5.

Rather than a consensus-based approach, where members debated and voted on what they felt was best, the WHAT WG took a bit more of a dictator-like stance, with Ian Hickson at the helm.

Wait – Dictator!?

Don’t we usually try to over throw these power mongers?

Don’t we usually try to over throw these power mongers? What’s the deal? I must admit, on paper, it sounds awful, doesn’t it? Does one guy determines the future of the web? We prefer this system? Politically speaking, yes, a dictatorship may be a bad idea. But, when you think about it in terms of the web, imagine how much more quickly things can get done. When a community is as passionate as ours, things tend to move very slowly, as debates continue on and on…and on.

“The Web is, and should be, driven by technical merit, not consensus. The W3C pretends otherwise, and wastes a lot of time for it. The WHATWG does not.” – Ian Hickson

While discussion certainly (and rightfully) takes place at the WHAT WG, ultimately, Ian Hickson has his finger on the button (unless the group and community strongly disagrees with a particular decision. At this point, he can either be impeached (not as Bill Clinton as that), or, more often than not, he’ll re-evaluate and reverse his decision).

That said, it’s certainly not ideal. The W3C has its slow and steady consensus-based approach, which many still prefer. On the other hand, while the WHAT WG moves at a quicker pace, there certainly are hiccups. Then, when you combine the two groups, things can sometimes get a bit muddy!

The `time` Debacle

In October, 2011, Ian Hickson removed the tag, and replaced it with a more general-purpose solution: . In his own words:

There are several use cases for :

Easier styling of dates and times from CSS.
A way to mark up the publication date/time for an article (e.g. for
conversion to Atom).
A way to mark up machine-readable times and dates for use in Microformats or
microdata.

Use cases A and B do not seem to have much traction. Use case C applies to more than just dates, and the lack of solution for stuff outside dates and times is being problematic to many communities.

Proposal: we dump use cases A and B, and pivot on use case C, changing it to and making it like the for machine-readable data, primarily for use by Microformats and HTML’s microdata feature. – Ian Hickson

Remember: you have much more control over the shape of the web than you likely give yourself credit for!

What he possibly didn’t realize was that much of the community did, in fact, use the tag. Further, they (myself included) felt that, though more flexible, the proposed tag was too ambiguous; has as much meaning as a , when it comes to semantics.

After a significant level of uproar from the community, the HTML WG announced that the change must be reverted. They gave Ian a short deadline to make the reversal. Though not without additional layers of drama, the following month, was reinstated.

This chain of events simply proves that, even though Ian has the right to propose these sorts of changes, the web community, as a whole – and, of course, the browser vendors – have quite a bit of control over the specification. There’s a difference between the spec creators, and the authors who integrate these new elements and APIs into their projects. If the authors don’t use them, they might as well be removed from the spec. Remember: you have much more control over the shape of the web than you likely give yourself credit for!

Sign up for the various mailing lists and be loud! Otherwise, folks like Ian won’t know if or how you use these new features.

“Is there any data showing how people actually use in practice? i.e. is it actually giving anyone any of its hypothetical benefits?” – Comment by Ian Hickson

The Shape of a Specification

While some may think that a small group of people determine the future of the web, that’s far from the case. Three factions receive equal weight, when it comes to specifications.

Spec Creators – Obviously…
Authors – People like us; if we reject (i.e. don’t use) a particular element or API, it might as well be dead in the water.
Vendors – Browsers have a huge amount of input into these specifications, many times leading the way.

If you’d like to learn more about the debacle, review the bug thread, and Ian’s Google+ post. They’re interesting reads, and aren’t nearly as black or white as you might think.

Back at the W3C…

Back to the W3C vs. WHAT WG feud. Well, it was less a feud, and more like two groups ignoring one another for a couple years.

As time progressed, it became clearer and clearer that XHTML 2.0 was not the solution.

While work at the WHAT WG progressed relatively quickly, work on XHTML 2.0 at the W3C was – how should I put this… – not going well (almost non-existent). As time progressed, it became clearer and clearer that XHTML 2.0 was not the solution (though it wouldn’t be fully dropped until 2009). In 2006, the W3C relented, and signaled that they were interested in collaborating with the WHAT WG on (what would be) HTML5. They chartered yet another group for this purpose: HTML WG, or the Hypertext Markup Language Working Group.

They intended to use the work of the WHAT WG as a basis for continued development of HTML. Weird, huh? Now we have two different groups: the W3C HTML WG and the WHAT WG. Technically, the W3C hadn’t yet given up on XHTML. Nonetheless, as part of the newly formed HTML WG, they renamed Web Apps 1.0 to HTML5.

“Apple, Mozilla, and Opera allowed the W3C to publish the specification under the W3C copyright, while keeping a version with the less restrictive license on the WHAT WG site.” – WHATWG.org

Today

These days, the WHAT WG and W3C collaborate with one another on HTML5. It’s a bit of an odd relationship, but somehow manages to function, thanks to an endless supply of incredibly passionate activists.

This article is an excerpt from my upcoming book on HTML5 and its friends. Stay tuned to Nettuts+ for more information on the release date!

Surprising Trends in the 2011 Web Design Survey

hotgrafix.co.uk56 — Tue, 15 May 2012 08:46:18 +0000

Back in November, we asked our Webdesigntuts+ readers and web designers all around the globe to participate in the 2011 Web Design Survey. The response was pretty amazing. Over 5,000 web designers responded and the majority completed the entire survey, sharing honest insights on how they work, how they design, and their feelings on issues in the industry. I spent the next three months pouring through the data, noting trends and patterns, and writing about what I found. The result was Web Design Confidential, a book published by Rockable Press and available to all our Tuts+ Premium members for free!Grab it in the library if you haven’t already.

In the mean time, I wanted to share just a couple of the surprises I discovered about our web design community. And there were plenty of surprises! Ever want to know more about how your fellow web designer works or what it takes to be successful? Read on!

It’s Not All About Designing Websites

We all get into this business to do what we love–make effective and well designed websites. That’s what anyone who gets into web design imagines themselves doing. Sure, there might be a little paperwork, but web design–that’s what we get paid to do, right? However, the majority of respondents reported a split in their duties:

The top response fell in the 26 to 50% range. That means half or less of the respondents’ time was spent working on actual web design duties. It’s not as drastic as it sounds–the second most popular response was 50 to 75%, and in many cases, much of the other duties that weren’t explicitly web design were still directly related to it (client meetings, research, etc). The responses also included freelancers and consultants who are frequently required to spend a lot more time on business management than the average employee. However, it’s an important reminder that a successful career in web design depends on more than just your skills with Photoshop and CSS.

Your Education Affects Your Happiness

It’s common in the modern web design community to disparage the traditional college education experience as out-dated and irrelevant, especially among freelancers and other ambitious professionals. The common argument is that you can learn much more about our industry by getting out there, practicing your skills and doing real web design than by spending four years in a classroom. The initial survey seems to back up that result:

Well over half of the web designers who responded found their formal education only somewhat or not at all relevant! That’s a pretty harsh statement against college education. However, things get interesting if you compare this result against another question: Are you happy with your career in web design? We used this question as the success indicator because, across the board, if you responded as happy you were much more likely to report positively on the rest of the survey. Look at what happens when we filter our results based on happiness:

The orange segments are responses by web designers who reported themselves to be happy and successful in the web design field. Designers who did not report happiness are in blue. Notice the inverted responses here. By far, successful web designers (the “happy” people) were more likely to have found their education highly relevant to their field. Designers unhappy with their work were more likely to view their education as unrelated.

There are two ways you can read this trend: either successful designers are just more optimistic people and therefore more likely to appreciate their education, or finding ways to appreciate and relate your education to your work is one small factor to your happiness. In light of all the data we collected about success in web design, I’m prone to the latter interpretation. Several times in the survey, it seemed that if you had a curious, agile mind and were open to new ideas and able to apply your previous experience (college or otherwise) to your current projects, you were more likely to be happy with your web design business.