Finally, custom post types in WordPress 3.0 !

The rumour has it that WordPress 3.0 will have custom post types built-in.  These are excellent news!  This means that 90% of all web development companies will be able to drop their own, complex and ugly in-house built systems and switch to WordPress development.  And while WordPress code isn’t the prettiest thing you can find, it’s still better than most of that code that will be dropped soon.  And it’s small, which is also an improvement.

If you are not familiar with the concept of custom post types, these are basically your average posts + custom fields + theme and plugin support + steroids.  In short, these are beautiful.  It doesn’t really matter what your blog is about – cooking, political news, movies, or technology – you can always think of a way to make posts better than they are in the default installation.  For example, cooking recipes can have a section on ingredients, cooking instructions, and serving instructions.  You can have your theme support those sections and display them in a consistent and beautiful way.  Now you probably wouldn’t even bother.  You’ll do your best with built-in post editor and maybe, if you are half-insane, you’ll play with custom fields.  But that’s too technical, complicated, and not even remotely convenient.  You can try one of those few plugins available, but chances are you’ll either come across a limitation, or a plugin won’t work for you at all.  With WordPress 3.0′ custom post types your chances are better.

And why did I mention web development companies?  Because that is exactly what so many of them do – build web applications that work with custom object types (cars in automotive shops and rentals, real estate items, products with online shops, etc).  A lot of work is put into defining those object types, building searching functionality, promotion bits, nested categories, integrating image galleries and contact forms, and such.  Needless to say, most of this functionality is already available in WordPress, either built-in or via a plugin.  Custom data types though weren’t.  And now that custom posts will make it into WordPress, most of the average small company’s needs will be so much easier to take care of.

This is a much needed and long awaited bit of functionality and I am very excited for it to finally make it.  These will cause a new wave of activity around WordPress, and we’ll see more and more sites built with it.  Awesome!

Build for the mobile

I just had a revelation. An enlightenment, if you will.  You know how it happens – you think about a solution to a problem for a really long time.  Then you don’t think about it anymore. At least not consciously.  But your brain is still crunching.  You can feel it.  But if the solution is still not found, then get used to that constant crunching and ignore it.  And then you even forget it. And then, some time after, there is a Big Bang.  A huge flash in your head.  And it’s not the solution to the problem yet.  But it’s a sign and a reminder that your brain is still working on something you have long forgotten you had to solve.  That’s what I just had.

Being involved with a lot of web development, I was trying to figure out how to go about all those mobile devices.  Mobile Internet user base is growing fast and even today it is so big that it can’t be ignored anymore.  Gladly, most mobile devices run full blown web browsers with CSS and JavaScript support.  Some can even do Flash.  So it’s not like web development for mobile devices is something completely different from web development for desktops.

And yet, there are differences.  For the near future, these are the differences that I can think about:

  • Mobile devices have smaller screens and that’s not going anywhere.  Even if supported resolutions get higher and higher, the physical size of the screen won’t match the desktop screen any time soon.
  • Mobile devices have handicapped input.  Flip-out QWERTY keyboards are quite usable now and handwriting recognition is getting better by the day.  But mobile device is not and probably will not be as convenient for input as desktop computers.
  • Mobile devices have less processing power.  They get more power, but while they do so, desktop clients do as well.  And so the difference is maintained.  With more and more functionality being pushed out into client side, processing power is an important issue.
  • Mobile devices have unstable connectivity and higher bandwidth costs.  Again, with all 3G networks expanding globally and more and more free WiFi hot-spots installed everywhere, the connectivity problem is getting partially solved.  But it’s not going to be solved completely any time soon (coverage, higher costs, battery life are just some of the reasons).

While there are probably other things you can put on that list above, even the ones I have there are enough to consider a different approaches when developing for mobiles.  And why should we consider them at all?  Well, here is an image that actually triggered that big flash in my mind that I spoke about earlier (shamelessly borrowed from Paul Kedrosky blog post).

Mobile Internet Graph

You (of course I mean “I”, “we”, “they”, and “you”) cannot ignore mobile devices anymore when building web sites and applications.  So, how should this problem be approached?  And now for that revelation, enlightenment that I mentioned earlier in the post:

Build for the mobile device first, then extend for the rest.

That’s not a new approach.  It’s something that has been used and recommend before.  It was just phrased differently.  It was along the lines of : limit resources in your development environment and you’ll get a much more efficient and resource aware application.  If a developer has only 512 MB of RAM on the machine he uses to write and test his code, chances of that application being much more effecient on a 4 GB server are higher than of application written on a 4 GB machine. ([*] citation needed)

If you build your web site or application for the mobile device, you’ll ensure most of these:

  • It works well with small screen sizes and lower resolutions.
  • It requires the minimum of input from the user.
  • It has exactly the right balance between client-side and server-side processing.
  • It supports a whole lot of browsers, even most of those browsers don’t exist on the desktop.
  • It has at least some optimization in terms of download size, client-side caching, etc.

And when your web project works on the mobile devices, it will be much easier for you to check for extra resources in the client’s browser (higher resolution, better browser, etc) and enhance behavior with more bells and whistles.  You’d probably won’t want to do this yourself anyway.

I think adding additional bells and whistles would be much simpler and faster, then removing and reorganizing things in the application that has been built for the desktop browser and now needs to support, or at least behave nicely with mobile browsers.

I would be very surprised if you actually read the post all the way down to here.  And just to thank you, I thought I should surprise you.  Most of the above post just came out from the top of my head, has no research, measurements, or supportive data.  It’s not even something I have discussed with someone else yet.  So, I suggest, you take it with the jar of salt, jar of pepper, and a pint-sized bottle of red hot chili sauce.

"Browser facts" from Microsoft

Google Blogoscoped brings to our attention Microsoft’s Browser Comparison chart.

MS Browser Comparison Chart
MS Browser Comparison Chart

This is an excellent marketing campaign.  I am a big fan of using humor in the advertising, and this is a good example of it.  Everyone who has every tried to build a web page knows how horrible the state of the modern browsers is, and how even more horribly standing out Microsoft Internet Explorer is.  It’s so horrible that it is even hard to make it funny, but this time Microsoft succeeds.

Just to balance it out a little bit, here are a few random charts that I picked from Google Images search results for “web developer time chart“.

Breakdown of time spent on web development

Frontend web development

Time breakdown of modern web design

Web technology behind Cyprus presidential elections

Cyprus is preparing for the presidential elections, which will take place this coming Sunday – February 17th, 2008 – and then another Sunday after that – February 24th, 2008. Unfortunately, most of the information about the elections is in Greek, so there isn’t much point in linking to it or quoting it.

Anyway, I came across this post in Linkbox blog, which links to web sites of some candidates, as well as the main web site of the elections.  Being a curious web worker, I wanted to see which tools these web sites use, and how well they use them.  Here are my findings.

Continue reading “Web technology behind Cyprus presidential elections”

MIME type of uploaded files in PHP

Today I came across something that rather puzzled me at first, seemed irresponsible and such, but was cleared later, upon reading the manual.  When uploading files in PHP, variable $_FILES stores a bunch of information about each file.  One of those stored bits is the MIME type of the file.  I was puzzled with how easy it was to trick PHP into setting a wrong MIME type.  However, documentation clearly says that:

The mime type of the file, if the browser provided this information. An example would be “image/gif”. This mime type is however not checked on the PHP side and therefore don’t take its value for granted.