Blogs

Recently, I’ve been doing more and more work on the build service that Nitobi has in beta, which allows users to submit PhoneGap application assets and download built binaries of their app for iOS, Android, BlackBerry, Symbian and webOS.

This week, Andrew and I are working on delivering full icon support for the supported PhoneGap Build platforms. Today we released Android support. Now, if the config.xml bundled in your application contains <icon> elements with different specified sizes, Build will make sure to use the appropriately-sized ones for Android devices with high, medium and low resolution screens.

Here’s a quick example config.xml from a static page I am running called the John Garrett Drinking Game (Canucks fans, you know what I’m talking about) - the code for this is also available on GitHub:

<?xml version="1.0" encoding="UTF-8"?>
<widget xmlns="http://www.w3.org/ns/widgets" xmlns:gap="http://phonegap.com/ns/1.0" id="com.nitobi.johngarrett" version="1.0">
<name>John Garrett Drinking Game</name> 
<description>
If you're watching a Canucks game, you need play this.
</description> 
<author href="http://www.nitobi.com" email="[email protected]">
Tim Kim, Ryan Betts, Fil Maj
</author> 
<icon src="img/beer_72.png" width="72" height="72" />
<icon src="img/beer_48.png" width="48" height="48" />
<icon src="img/beer_36.png" width="36" height="36" />
</widget>

The three specified sizes you see for the <icon> elements correlate to the three resolution levels supported on Android: 72 by 72 (or above) will be used for HDPI screens, 48 by 48 for MDPI, and 36 by 36 for LDPI.

Later this week we are hoping to land icon support for the rest of the platforms. Stay tuned!

Hey everyone,

First post as a Nitobian on my brand-spanking new blog, pretty exciting. It’s Christmas time and we can sure feel it in Vancouver - especially when the entire IT community around here decides to start throwing snow at each other. I guess we interpret the ’spirit of giving’ our own way, oh well. Anyways, today I’ve decided to post a little bit about some of the recent work I’ve been doing around the office. As you can probably guess from the title, it’s all about web site accessibility and performance.

Accessibility, for those that are unaware, is how easy something is to use for people with disabilities or alternative viewing approaches (can that be any more politically correct?). This can come as quite a shock for the average developer, but blind people use the internet too! The bottom line is, if your site is going to be mainstream then it needs to be screen reader friendly. On top of that, people with visual disabilities might turn off your stylesheets or view your web page in a high-contrast mode. With Dr. Johnson’s post as a guide, I tackled a recent Nitobi project with some pretty good results. However, until you actually use a screen reader, you have no idea how hard it is to get anything done in a browser with your eyes closed. Here are some of the biggest concepts I took out of redoing a website so that it’s screen reader friendly:

1. A screen reader reads a subset of HTML markup content in the order that it is coded on the page. Conclusion: don’t put your content DIVs in random order in your HTML and then use CSS to position them - that will confuse the fuck out of a blind person.
2. Point #13 from Dave’s post talks about putting an anchor tag at the top of the page to allow users to skip over content. I will reiterate this as this is absolutely essential! Just position it off-screen so users without a screen reader don’t see it.
3. Images are the devil, pretty much. Essentially, HTML elements all have some kind of semantic meaning associated with them that screen readers rely on. If you’ve got some kind of header or background image, use CSS instead of an <IMG> tag.

Last but not least: just grab a screen reader like the demo version of JAWS (yes, it’s bad and annoying, but what can you do) and try your site out yourself. You’ll probably be surprised. If you fear listening to JAWS spew out jibberish then you can also try a neat firefox extension called Fangs. It puts together a textual version of how a screen reader would dictate your site out for you, which probably won’t be as shocking as JAWS.

Performance is an issue all developers pretend to care about, and I’m no exception. In all seriousness though, there are a few simple changes that one can make to really improve site responsiveness, especially when it comes to caching. If I have to introduce anyone to YSlow, then… well, I don’t know. Basically, you need it. Not only will it audit your web pages for you and give you a letter grade reviewing your site performance, it’ll also get into the nitty-gritty of where your site is lacking. The tool is based on the Yahoo performance best practices. I’ve got two things to add:

1. Spriting. DO IT. I stumbled upon this fantastic online sprite generator that you simply cannot beat: you upload a ZIP file of your images, hit a button and it makes a sprite image for you AND spits out the CSS you need to select the right graphics. It has a variety of neat features like output format, transparency and spacing options, and allows to combine various formats into one. Genius!
2. JavaScript minification. This is already outlined in the Yahoo doc, but after asking around the great minds we have at Nitobi, Alexei was able to point me to an old post of his that shows off a minification algorithm comparator! How sweet is that! Not only will it minify JavaScript that you just paste into a text box on the page, but it will compare various compression techniques and spit out a report. Awesome.

It’s time for me to head out and get ready for Christmas. And by Christmas I mean owning some nubs at NHL 09.

Merry Christmas!

Fil