Month: June 2011

While perusing around the web yesterday (after sifting through my email post-vacation), I came across this Ars Technica article discussing the new Firefox upgrade timeline. It actually follows a similar upgrade timeline that WordPress adopted after WordPress 2.0 was released.

The new policy outlines a 3-4 month window for new major releases with limited security updates for releases outside of the current stable release.

The Ars article goes on to describe the angst that has come out of the corporate community as they have been lulled into a process of having to test new releases of software to ensure compatibility with their internal firewall’d webapps that have, in no small part, been created for a specific browser – usually Internet Explorer 6 or 7.

Browser Stagnation Caused IT Stagnation

A few years ago, the stagnation of browser support was broken as Firefox and Opera started a race to implement CSS3 features that were not necessarily status quo, as a result of Internet Explorer, and were not even blessed as part of an official spec. The browser makers just started doing it.

Notably, some of these browser-specific “add-ons” to CSS dealt with things that had been desired but only usable with browser hacks: rounded corners, opacity, etc.

Apple came on the scene, particularly with iOS (then iPhone OS), and put a tremendous amount of development efforts into WebKit. WebKit is a browser framework like Gecko, the framework that Firefox and the old Netscape are built on was. Apple’s take on WebKit was Safari. Google followed suit with Chrome awhile later, also built on WebKit.

What we end up with is a browser war with higher stakes than the famed Internet Explorer-Netscape war of the 1990s. We also see a lot more innovation and one-upmanship… something that can only be good for consumers.

The Ars article describes a tenuous balance for enterprise customers. That balance is the need to support internal firewalled applications while giving users access to the public web. The money quote from the article sums up the balance nicely:

The Web is a shared medium. It’s used for both private and public sites, and the ability to access these sites is dependent on Web browsers understanding a common set of protocols and file formats (many corporate intranet sites may not in fact be accessible from the Internet itself, but the browsers used to access these sites generally have to live in both worlds).

[…]

If developers could be sure that only Internet Explorer 9, Firefox 5, and Chrome 13 were in use on the Internet, they would be able to make substantial savings in development and testing, and would have a wealth of additional features available to use.

But they can’t assume that, and so they have to avoid desirable features or waste time working around their absence. And a major reason—not the only reason, but a substantial one—is corporate users. Corporate users who can’t update their browsers because of some persnickety internal application they have to use, but who then go and use that same browser on the public Internet. By unleashing these obsolete browsers on the world at large, these corporate users make the Web worse for everyone. Web developers have to target the lowest common denominator, and the corporations are making that lowest common denominator that much lower.

As someone who has worked on the web for more than 10 years and who has also worked in Enterprise, I agree.

I remember when I worked for the Navy and the Navy-Marine Corps Intranet (NMCI) was in deployment. It was a massive headache for everyone involved because the assumption with that contract was that systems could uniformly be tied together and standardized. By my understanding, they finally achieved that last year, but not until after being years late and hundreds of millions over budget.

I don’t know the final deployment as my contract with the Navy ended back in 2004. I know that proprietary systems were in place that were designed to a function and not to a standard. When standards were introduced as necessary requisites for any system in that eco-system, the implications were huge.

This is the world we live in today where, as the Ars article points out, browsers that must live in a world of compatibility and still access the public web drag the rest of us down.

Outsource Your Shit and Focus on Your Core Business

But Ars already makes that point. I’m not making it again except to highlight the validity of their thoughts. My point is more intrinsic to startups, small businesses and entrepreneurs and I make it delicately as it has, in some ways, countered some of my thoughts in the past.

Why should you worry about building applications to a function when you can build them to a standard? Or better yet, why should you build from the ground up to a function when you can use external, cloud-based services built to a standard.

Take Microsoft’s just-announced Microsoft Office 365. Now, I don’t know anything about this product so don’t take my commentary as an endorsement in any way. We use Google Apps at WP Engine (another good example of exactly what I’m saying here).

In Office 365, you have a common piece of line-of-business software (Microsoft Office) available for a subscription and hosted in the cloud. This eliminates IT Administrators requirement for testing on the internal network. It’s on the web! Everyone has the web! And it doesn’t need (and in fact, cannot work) with non-standard browsers. And you don’t even need Microsoft’s browser to use it.

Suddenly, IT Administrators along with Microsoft have saved the Enterprise tens, if not hundreds, of thousands of dollars in man-hours testing and re-resting for OS compatibility. And suddenly, IT Administrators along with Microsoft have taken the chains off users to have freedom of choice in their browsers (which, by the way, is more than a pie in the sky idealistic thing… it’s also a cost-saving efficiency thing). And also suddenly, Microsoft has released the web to be able to thrive and not be retarded by corporate requirements.

This kind of thing makes perfect sense. Why re-invent the wheel? Why put resources into something you don’t have to? Why not let a third party, like Microsoft or Google, worry about the compatibility issues in line-of-business software.

After all, your company isn’t in the core business of building these applications. You are in the line of business of doing something else… building a product, a social network, a mobile app, a hosting company, etc. Your software should not define the cost of doing business. Your people and your product should.

Out of morbid curiosity, I decided to run all of those posts through a word cloud generator and see if there were any trends that could be seen. Of course, it’s my writing so there are obvious tendencies and biases, but it was fun to see anyway.

One thing I did to make the results better… I removed the words WordPress and WP. Also, several of the posts had my name in it so I figured it would be better not to include that either.

WordPress 2.0

WordPress 2.1

WordPress 2.2

WordPress 2.3

WordPress 2.5

WordPress 2.6WordPress 2.7

WordPress 2.8

WordPress 2.9WordPress 3.0WordPress 3.1WordPress 3.2

WordPress 3.2 will be released soon (at the time of this writing, it is in RC1 which essentially means it is done and being tested). This is an exciting release as it marks the first release that drops PHP 4 dependency. For years, WordPress has opted to play to the lowest common denominator while hosts have taken their sweet time arriving at PHP 5.

Of course, this may mean nothing to you, depending on your technical knowledge of the underlying language. However, it has limited the amount of innovation that could be possible using the more modern version of PHP 5.

The focus for this release was to slim down redundant code that had been added along the way to employ PHP 5 techniques in a PHP 4-compatible fashion. In addition, a focus was placed on slimming down code all along the way to provide a more efficient codebase. Eliminate, eliminate, eliminate! More Red than Green – a reference to the way changes are recorded visually where red is code elimination and green is code addition.

Regardless, the approach to PHP 5 adoption has had a positive effect. Approximately 12% of the web is powered today by WordPress, whether self-hosted “.org” sites or Automattic’s WordPress.com and other hosted WordPress sites.

As I have done eleven other times before, today I bring you the Ten Things that, in my opinion, you should know about WordPress 3.2.

Twenty-Eleven

One of the big things that was discussed internally around the time when WordPress 3.0 was released over a year ago was the need to keep the default theme fresh. To that end, for WordPress 3.0 did away with the old Kubrick theme and replaced it with the fresh and semantic Twenty-Ten theme.

Yes, you can see how naming a theme Twenty-Ten in 2010 setup the opportunity for a Twenty-Eleven theme in 2011. And there is that opportunity for a new theme called Twenty-Twelve in 2012, but let’s not get too far ahead of ourselves.

Twenty-Eleven visually is not a huge departure from Twenty-Ten. It still uses much of the same visual layout that Twenty-Ten did. The new theme, however, is greatly different behind the scenes.

Note: This blog (along with all of my blogs) are running Twenty-Eleven right now.

Users of Twenty-Eleven have the opportunity to select a one-column or two column layout for their blog from inside the WordPress Admin. The two column layouts can use a sidebar left or sidebar right variant.

Additionally, Twenty-Eleven also offers a dark and light color scheme. My photoblog, for instance, uses the dark format while this blog uses the light format.

Finally, as with Twenty-Ten, the theme allows for custom header images (or no header images) and backgrounds. Because of the professional nature of this blog, I’ve opted to use no header on this blog and my personal blog utilizes a custom header image.

And of course, as with all things WordPress, no one says you have to settle for what Twenty-Eleven offers out of the box. In fact, it is encouraged that you use Twenty-Eleven as a parent theme that offers all of the benefits of the default theme while putting your own spin on it with a child theme.

Distraction Free Writing

While I write this post, I am using the successor to the Full-screen mode that has been in WordPress for some time. Full screen mode, in my opinion, never really was well adopted but it has been championed in the past by bloggers who focus on efficient workstyles, or Getting Things Done (“GTD”) approach to work.

The ability to shut out all distractions so as to focus on the task at hand is hugely important. WordPress core developer Mark Jaquith has said for years that his vision for WordPress was that it would become a tool that got out of the way of people and their writing. It’s not about WordPress. It’s about writing and the experience should be such that you should never have to think about what tool you are using to do that.

With Distraction Free Writing, you have just that. By clicking on the Full Screen (in HTML writing mode) or the new icon for DFW in the toolbar of the visual text editor, the blogger finds themself on a plain off-white canvas with minor tools along the top of the screen to assist in basic formatting. If you leave your hands off the mouse, even these fade away allowing you to just write in a pleasant, serene environment.

This feature is probably my favorite in WordPress 3.2 and usability/writer-facing features are rarely my favorite as a developer. I generally prefer new APIs and developer tools. However, this feature wins hands-down.

Minor Overhaul to Administrative UI

It’s been several years since WordPress has undergone a major Admin overhaul. There have been tweaks along the way, but by and large the administrative interface has stayed true to what it evolved into (with much research and usability testing) in WordPress 2.7.

There is not a drastic overhaul in WordPress 3.2, but it is the larger than a few tweaks and color scheme modifications. In WordPress 3.1, the Admin Bar (which I’ll talk about later) came into being and in 3.2, emphasis has been put on placing more commonly accessed functions into it as opposed to the main UI.

As a result, familiar things (which were often used for blogs in Multisite mode) such as the “Favorites Menu” have been removed to the Admin Bar. The Quick Access menu that allowed Multisite Super Admins quick access to the “Network Admin” has been relocated to a less-than-obvious dropdown in the upper right. Hint: The dropdown menu can be accessed by clicking the “Howdy Aaron” link, where “Aaron” is your username.

Other aspects of the new interface are mainly aesthetic. Menus are where you’d expect them. Features are where they’ve always been. Plugin developers who have built UI for their plugins are still safe as long as, as usual, they are using the WordPress best-practices, i.e. using the same HTML formats and structures used in core.

More Determined Move to the Admin Bar

As mentioned before, the Admin Bar has become the focus of a “Command Center” approach. By default, quick actions like Adding a new post or editing a page or getting quick access to the dashboard of other Multisite sites are loaded into quick menus in the Admin Bar.

This is also where the philosophy of plugin development that provides quick access to features should be. A good example of this is the Purge Cache functionality in W3 Total Cache. Where this has been in the Favorites menu inside WordPress, it now will have to move to the Admin Bar. This seems like a more natural place to me anyway. Other plugin developers should look at their code to ensure that they are compliant with this approach.

PHP 5.2.4 and MySQL 5.0

I mentioned the new system requirements at the beginning of this article. This shift to PHP 5 has been a long time in coming and was done deliberately to time with WordPress hosting on PHP 4 dipping below 10%. In other words, it is more than likely your host is already on PHP 5.2.4+. However, you should verify this if you’re not sure.

With the adoption of PHP 5.2.4, there is also a bump in the requirements for MySQL. Now WordPress requires MySQL 5.0, another hurdle that is not very hard to overcome but should be verified if you’re not sure.

Ryan Duff has created a quick and easy plugin that can be installed to ensure compatibility with WordPress 3.2.

For Newbies, a Better Help Menu on Each Page

For some time, WordPress has included a contextual “Help” menu in the upper right of many of the screens in the admin interface. However, with WordPress 3.2, every page has a help menu. Not only does every page have a help menu, newbies can get detailed contextual assistance for each page. Veteran users already know their way around, so this will be less than helpful, but for n00bs, the guidance lowers the barrier to entry.

Up until WordPress 3.2, upgrades were performed by downloading the entire package and applying it over the existing install. While this was fine, it took a lot more time due to the larger package size. This new version will enable future upgrades of WordPress to be done incrementally making the process much faster and efficient.

Code Efficiency enhancements

A huge emphasis was placed on core efficiency in this release. Many of the updates that have gone into this release have been major refactoring of code as well as the removal of legacy (and now unneeded) PHP4 compatibility code.

When I write these articles, I like to look at a diff file of all code changes between the last major release and the current. I was blown away by the amount of PHP4 compatibility code that has been axed.

Additionally, a lot of effort has been placed on database optimization. Many queries have been made more efficient. These things are less notable for smaller sites, but for large sites and hosting companies (such as my company, WP Engine), these types of optimizations add up in orders of magnitude!

File System API

Another optimization that has been made (getting the clue that this release is all about streamlines?) has been in the code that handles upgrades and automatic installs of plugins. When the original code was written, it was written to find what methods were available to write to the filesystem. This was because WordPress does the best it can to be as compatible as possible with as many server configurations as possible.

Some of the more obsolete (and unnecessary) transports have been done away with in favor of Streams. Though streams existed in PHP 4.3 (WordPress’ former system requirement), the upgraded requirement now allows us to do so much more with file transfer, handling and writing.

But I don’t want to get overly technical right now.

No IE6 Support

We all knew Internet Explorer was dead. Well, most of us. Believe it or not, there are still folks (mostly in government and enterprise organizations) where IE6 is still in use. While WordPress has always endeavored to be as compatible with as many configurations as possible, just like file handling replaced by Streams and PHP4 going the way of the Dodo Bird, IE6 can die in a fucking fire too. Oops. Sorry, kids. No more IE6 support.

Automatically approve parent comments

Finally, a longtime nuance has been comment approval. Comments have always been a one-to-one relationship with approval. You approve one comment at a time. And while that’s normally fine, what if you have nested comments and you approve a child comment but not a parent comment? Then you have a weird hierarchy that may not make a lot of sense.

In WordPress 3.2, now when you approve a comment that has an unapproved parent comment, the parent comment will also be approved. Many people have asked for that and now it’s here.

BONUS: Credits Screen

But wait… There’s one more thing. Every release, hundreds of people participate in the development process by writing code, contributing patches, discussing ideas in IRC and on Trac. That doesn’t even begin to acknowledge the testers, translators, and documentation writers who contribute their time free of charge.

Now, in the footer of the WordPress Admin, you’ll find a Credits link that shows everyone who has contributed to this release. Good job, guys! (I’m one of the contributors).

Like many other industries, journalism has undergone a vast paradigm shift in the last decade. Like advertising, the music and film industries, marketing, public relations and virtually all other professional fields, journalism has had to adjust to a new “immediacy” brought about by the Internet.

Now, by all reports, most people get their news from online sources and, while “online sources” are often venerable traditional media sources like the New York Times and the Washington Post, more often than not, blogs have become major sources of breaking news, and exclusive reports.

In fact, it was Pakistani IT specialist Sohaib Athar, now more famously known by his Twitter handle @reallyvirtual, who unwittingly live-tweeted the Osama bin Laden raid while Libyan rebels send on the ground status updates where traditional journalists have limited or no access. (Andy Carvin of NPR, known as @acarvin on Twitter, has become somewhat notorious for his months-long curation of such tweets out of Libya, Egypt, Yemen and other Middle East hotspots).

There is no denying that the social tools available today have changed the face of journalism. Yet, despite these boons, it troubles me that basic principles of journalism seem to be consistently ignored.

At the end of the day, the practice of journalism (as with any industry) will evolve (and always have) with the tools and technology of the day. However, though practices may change, principles should never change.

One such principle is fact-checking. No matter who you are, or what era you’re in, fact-checking is rule number one in journalism. Don’t report until you have three independent sources is a good rule of thumb that is often ignored.

Case in point. The Wall Street Journal‘s All things D[igital] posted an article the other day titled, “Confirmed: Twitter Plans to Announce Photo-sharing Service This Week“. By all accounts, and history bearing witness, All Things D has been a reliable source of technology news since it’s inception. Founded by media moguls Walt Mossberg and Kara Swisher, it later became part of the WSJ family and has maintained a high level of journalistic integrity and excellence for years.

But something troubles me about this article. With a headline like this, it seems strange that this paragraph would then be included in the article:

I am indeed aware that D9 is the conference put on by this very site, but was not able to get sources to confirm the image-hosting announcement on the record. Twitter spokespeople did not reply for a request for comment on the matter.

Notwithstanding, everyone seems to agree that this play has been a foregone conclusion for a long time. And TechCrunch did write a story speculating on the service. But even in that news announcement, there was no real substance with Alexis Tsotsis concluding the article with:

I’ve got no details on what exactly the photosharing URL shortener will be if any (Twitter has owned Twimg.com for a long time) or what the Twitter for Photos product will look like. Just that it’s coming, soon. And if they’re smart they’ll put ads on it.

No sourcing. No fact checking. No confirmation.

While the need for speed is certainly required in today’s immediate, persistent news cycles, it bothers me that articles are being written claiming confirmation when no confirmation exists and that articles are being written from a speculative perspective (no issues there, just call it that!) and being held up as fact.

Though the Twitter news ended up being accurate, I plead with All Things D and all other internet publications to do yourselves and the public a service and stay the main tenets of journalism. Respect is at stake.