Without any further ado please say hello to your new best friend when it comes to reading documentation about web: WebPlatform.org. Do you feel a little bit perplexed? Not sure if I am serious or just joking? Ask no more because I am dead serious :)

So here is the deal: Adobe, Apple, Facebook, Google, HP, Microsoft, Mozilla, Nokia, Opera, and the W3C have worked together to create a single point of reference for all sorts of documentation related to the web. The whole project is set as a Wiki because we need everyone to be a part of this: sometimes you only search for some API and sometimes you’ve spent a great deal of time figuring out how to use a new API and you are ready to share this with the world.

Here is a video that briefly introduces this project:

Remember: a single place for all web resources a web developer/designer needs and a resource that you can edit and enhance.

For more information check this post or the W3C press release, and make sure you go to WebPlatform.org.

This is a post about something that I’ve been thinking about a lot lately: What do we need as web professionals in order to become more efficient and, hopefully, happier when coding web sites or web apps?

The first thing you may hear as an answer to this question is “better tools”. While this answer can be backed up with lots of data I don’t think that this is the right answer. I started doing web sites in the late 90′ and back then Homesite from Allaire was one of the best HTML editors and my favorite tool. Soon after heavier tools have emerged. Almost fifteen years later we have pretty much the same tools: light-weight tools (vi, Sublime, and so forth) and complete IDEs (like Eclipse) with some others in between.

So you have to have lots of imagination to invent a new tool that doesn’t fit in the existing categories. If the answer is not a better tool than what is?

Well, let’s step back for a second and look at what the current web development process looks like. And to simplify a bit let’s consider these two types of developers (it is a stretch  but stay with me):

1. Newbies. People who just started modern web development. Contrary to what you may think these people are not necessary newbies in programming in general – they can be Java enterprise developers for example. What they have in common is that they have to find their way through a “million things” (tools, best practices, frameworks, libraries, browser inconsistencies, different JavaScript versions, different CSS versions, and so forth) all in the name of building a “simple” modern web site.
   It is amazing that the complexity involved in building a web page that runs across devices and browsers can beat the complexity required for building the back end for a website or an iOS app.
2. Veterans. These people know the best practices, they know the “cool” frameworks, they’ve found “the best tools”. And yet they are not necessarily without worries. Updating the JavaScript libraries and the dependencies is not that trivial for a live product, nor is making sure that each time you change something you properly test it (unit testing, function testing). At the end of the day, they spend too many cycles on things that are not “fun”.

As you can see the challenges one faces when doing web development are not only in the realm that a tool typically covers. I’ve seen at least two examples that showed me that the solution is not that far fetched and there is life after all :).

The first one is, hold your breath :D, PhoneGap Build. Trust me, I am not mentioning this because I work for Adobe. Everyone who does mobile developing using the native tools/frameworks for multiple platforms knows that is not a walk in a park. You need a Mac for iOS development/packaging, a Windows machine for Windows Phone, and different IDEs and so forth. PhoneGap Build handles this complexity and let’s you focus on coding the app using open web technologies. The packaging is done in the cloud.

The second one is even more interesting. This comes from Paul Irish’s presentation at Google I/O 2012. If you haven’t seen it, please do yourself a good deed and do it. Now. Pay attention to project “Yeoman” (this is presented in the second part of the presentation). The main idea behind this is that you should go from idea to prototype in less than 10 minutes. Under the hood it uses a bunch of tools/libraries (Compass, RequireJS, Jasminte, PhantomJS, etc) and tries to minimize the friction that you typically experience when using them by making the installation in a new site seamless and so on.

In conclusion I don’t think that it is about a better tool. It is about a better process and workflow that may integrate a number of tools, services, and scripts. And this “thing” should take care of as many things as possible automatically. The bright side is that there are signs that this is possible. It is just a matter of time as more and more bright people change their focus from building libraries and frameworks for doing X or Y to building better working environment for general web development.

Yesterday night I finally managed to finish something I’ve been planning to do for a while: change my WordrPress based blog theme to one that adheres to the “responsive design” philosophy.

After doing this I figured that it would be (potentially) helpful to write a post and urge others to make their blogs mobile friendly. Especially if you are running a WordPress based blog, it is not that difficult.

Why in the name of all HTML tags would you want to make your blog mobile friendly?

Well the answer is quite simple: because more and more people end up doing serious reading on their mobile devices. If you’ve been attending mobile conferences lately, you know that the days when we thought people tended not to use their mobile devices for anything serious are gone. People not only do complex task on their phones but they read too. And when the mobile phone is the only device at hand and you are stuck in some place without a computer you want to and you do spend time with your phone.

Now, a couple of years ago a colleague told me that I should take good care of my mobile users and add support for a mobile theme. This made me instantly anxious as (for no particular reason) I pretty much hated the mobile.somesite.com version of all sites. It always felt alien, remote, and a little bit fake.

Nevertheless I swallowed it and I added a mobile pack theme to my blog. Then I erased this from my mind. Last year, while reading a blog post on my phone I noticed that the blog looked almost the same as the desktop version and it was a WordPress blog. So, you can understand why I felt like yelling “Eureka!” as loud as possible.

DIY is something I like a lot but not when it comes to building software. I’ve done my share of libraries, frameworks, and code generators so I don’t feel that every now and then that I should re-invent the wheel just to prove that I exist.

This is why I was so happy to have a bunch of themes to choose from. Twenty Eleven, Responsive, and Blaskan made it on my short list. In the end I decided to go with Twenty Eleven.

Are we there yet? Not yet my son!

Once I was happy with my choice (the theme to go with) I started to tweak my blog a little bit more. Some of the changes were design related, others content related.

From a design point of view I wanted to change the font size. I felt that the default size, even on a desktop was a bit too small. As someone who has to wear glasses and uses  Cmd + “+” quite frequently to bump up the font size in the browser or mail client I thought that it would be something nice to have. So in the stylesheet I changed the font size from 100% to 105%. Why 105%? Well I tested various values on a bunch of devices and desktops and 105% worked the best.

Bumping up the text size for paragraphs and friends left me with the text size of the headers a bit to small. This was a bit strange because I was expecting to find another percentage based value. Instead it was hardcoded to 26 pixels. After some trial and error I ended up with 170% as the best value.

The final touch was to change to the maximum width of the site. The default option was 1000 pixels which I think is too small for today’s computers. I changed this to 1120 pixels and I was done.

That was the design. What about the content? From a content point of view I’ve done two things. First, I added some more widgets on the sidebar. By default the theme has two widgets: archives and site login. I wanted to have categories, blog roll, upcoming events, and about me.

The second thing I wanted to change was to take out some of the content in order to speed up loading and rendering. My eyes were firmly set on the social sharing features. I had a bunch of plugins for sharing the posts on Twitter, Facebook, and Google Plus. These plugins load a bunch of resources (images, CSS, scripts), which adds time to both loading and rendering. Especially on slower mobile connections this was painfully slow.

Now, making your blog content easier to share is a good thing isn’t it? It looks like online marketing 101. Well, I don’t think that this is always true. If your blog is a technical one and you write good content then you should trust that your users are perfectly capable of copying and pasting the blog post URL into a Twitter message window or Facebook page.

Conclusions

In conclusion, don’t be as lazy as I was in regard to making your blog mobile friendly in a responsive design way. Especially if you use the WordPress platform, things are not that complicated.

And while doing this take a look at your current content and decide if you really need all those little plugins that are adding weight and rendering time to your page.