PNG vs. GIF

In order to render the best quality icons for your widget, you’ll need to upload your icons in PNG 24 format with alpha-transparency blending. If you know what this means, you can skim through this article, read the section on sizing, and get back to work on your widget. If you don’t, please read through this tutorial and complain to the management if you haven’t figured it out by the end.

Below are four images that show the difference between what you can do with the alpha channel capabilities of the PNG format, and what you can (or can’t) do with the anti-aliasing capabilities of the GIF format. Note that the two examples on the left blend seamlessly with the background, while the images on the right break abruptly.

PNG 24: Alpha channel against a transparent background.		GIF: Anti-aliasing with one color (white) removed against a transparent background.
PNG 24: Image with an alpha channel against a colored background.		GIF: Image anti-aliased against a white background on top of an unintended background color.

Now that you see the distinction between the two image formats, you’re probably wondering why anyone would use the GIF format when PNGs are so much sexier. The answer’s easy: Not all devices support the PNG format, so the fallback is GIF.

Problem? Nah! Fortunately for you, the exceptionally talented and hard-working Blueprint rendering team here at Yahoo! Mobile has solved this problem for you. They’ve built an engine that renders your icons as PNGs on devices that support them, and as GIFs on the devices that don’t. It even anti-aliases the GIFs against the various background colors on page headers, section headers and placards.

So, the bottom line is: Figure out this PNG stuff, upload them with your widget, and you’re square. Upload GIFs and you’re… wait, bad analogy –you know what I mean.

*If you want to know more about alpha channels and anti-aliasing, please read the addendum at the bottom of this article.

Working with Branded Assets

Are you building a widget for an established company? If so, then you can often find a logo in PNG, EPS or PDF format on the Press section of the company’s website or from a designer within the company. If nobody gives you one, keep asking. They’re bound to have it somewhere. Once you have a good source file in one of these formats, it’s pretty easy, using an imaging program such as Adobe Photoshop, to convert them while retaining the alpha information and resize them to the correct sizes needed for your widget.

Logo Creation from Scratch

I’ll go over the process of logo creation using tools many people are familiar with, Adobe Flash and Adobe PhotoShop. If you’re not familiar with these programs, you should probably just give-up now and hire a designer. If you’re stubborn, however, you can download trial versions from their website at Adobe.com and labor through the following instructions.

First, I’ll create a piece of vector art in Flash, then render it into a high-resolution PNG file for further manipulation in Photoshop. Working with vectors is an excellent way to get a high-quality image that scales without losing quality. You can draw your icons at a high resolution, then scale them down to get a good idea of how they will look at various sizes.

Step 1: Draw your logo

Open a new Adobe Flash file and start drawing your logo. It’s important to remember that your logo will eventually be contained in a small square, so you’ll want to leave out extremely detailed features or text that will be unreadable at small sizes. A good technique is to draw a square box on a layer of it’s own, lock the layer, and then draw your logo inside it on a new layer above. Then, when you’re finished, you can simply remove the underlying layer before exporting your image.

Here is an example of a logo I created in Adobe Flash for my moBar widget that can be scaled down to look good at any size.

Step 2: Export your image

Once you’ve created your logo and are happy with the way it looks at various sizes, you’ll want to remove the background box and any other artwork (such as the scaled-down copies you just created) and export the image. You do this by selecting File > Export > Export Image from the menu.

Once you name your file and select Save, you’ll be presented with a dialog box that looks something like this:

Don’t worry too much about the Dimensions of the image at this point, but you’ll need to make sure that you select Minimum Image Area from the Include dropdown and select the Smooth checkbox.

There you have it! You’re PNGing, baby! Almost there!

Step 3: Sizing Appropriately

Now that you have your PNG source file, you can start resizing your icon to the various sizes needed by the Blueprint rendering engine. It’s important to note that although you only need to upload one 90×90 icon for your widget, it’s good practice to create as many sizes as possible so that you have some control over what gets rendered at each size. Those smart and conscientious Blueprint engineers I told you about earlier, have identified 19 different sizes of icon that various devices will display, so if you want to ensure that your icon is going to look how you intended, you can create each of these sizes and upload them with your widget.

In some cases, if you have a logo that looks good at say, 52×52 pixels, but terrible at 12×12, you may want to consider using entirely different artwork at the smaller sizes. If you don’t have the time or patience to create all 19 sizes of logo, don’t worry, the Blueprint renderer will take the closest size match that is bigger than the size the device will display and scale it down to the appropriate size for that specific device.

It’s always a good idea to include at least these four sizes:

90×90, 52×52, 34×34 & 16×16.

If you’re paranoid, however, you can include them all (believe me, it’s fun):

90×90, 70×70, 68×68, 56×56, 52×52, 46×46, 44×44, 40×40, 38×38, 34×34, 30×30, 28×28, 26×26, 22×22, 20×20, 18×18, 16×16, 14×14 & 12×12.

Step 4: Resizing in Adobe PhotoShop

Now that you have your source file and know the image sizes you want, you can start working in PhotoShop. I recommend taking the following steps.

1. Resize your source file to a perfect square. You do this by selecting Image > Canvas Size in the menu, then adjusting the height or width in the dialog to match the larger of the two sizes. In the example below, I’ve changed the width to the same size as the height and left the anchor at center.

   

2. Now you can start resizing. My tactic is to create the same number of duplicates of the image in Adobe PhotoShop as I’ll be making icons. You can do this by going to Image > Duplicate in the menu. It’s a good idea at this point to give the same name to the duplicates as the names of the final images you’ll be saving.

3. Once you have all your duplicates on the stage you can start resizing them. It’s important to remember that the final icons will need to have at least one pixel of transparent space around all edges of the image. What I found works best is to resize each duplicate to exactly two pixels smaller than the final target size, then go back and resize the canvas to the actual export size. So, you would resize your 90×90 image to 88×88, your 34×34 to 32×32, etc., then go back into the Canvas Size dialog and resize the canvas to the same size that you named the image while setting the Anchor in the middle of the box. This will ensure that you always have one pixel of transparency around the final icon.

4. So, the steps are as follows:

   1. Go to Image > Image size in the menu, and resize the icon. (e.g. 88×88)

   2. Go to Image > Canvas Size and resize the canvas. (e.g. 90×90)

   3. Go to File > Save for Web and Devices and save as a PNG 24 with the Transparency checkbox checked in the controls on the right of the dialog.

   4. Save your file, making sure to name it with the underscore and size convention. (e.g. olive_90×90.png).

Follow the same steps for all your icon sizes and you’re almost there. Remember, you need the one pixel of transparency around the edges of the image, so that the Blueprint renderer can do a better job of resizing your icons for various devices.

Below is an example of what a 90×90 icon will look like when finished. I’ve blown it up to immense proportions, so you can see the detail.

90×90 olive icon at 300%. Note the 1 pixel of transparency around the edges.

Step 5: Using separate artwork for smaller logos

Again, using separate artwork at different sizes can be critical. Let’s say your icon is a hippopotamus. That’s a cool icon, and it may look great at 52×52, but anything under 34×34 looks like something that came out the back of a hippopotamus. One idea would be to use just one part of the larger image, such as the head of the hippo for your smaller sized icons.

This is a common problem with icons that contain logotype. An icon containing text is always unreadable at small sizes, so it’s important to have an alternate strategy.

Step 6: Submitting your icons

Now that you have all your icons and are ready to upload your widget, you’ll need to make sure you put them in the resources/images folder of your widget and name them appropriately. You can name your icon whatever you like, but it must contain the size information in the name. The format is this: olive_52×52.png, olive_34×34.png, olive_16×16.png, etc. Just make sure you also add the correct name to the nodes of your config.xml file before uploading. The default is “icon”, but in this case, it would be: olive.

Step 7: Brag

That’s it! You’re finished. Once your widget is active in the gallery, you can show all your friends what a great icon maker you are. Congratulations! Now go have drink, and don’t forget to tip one up for the Blueprint team!

Cheers, -T

More on Alpha-Channels

Alpha channels contain transparency information on a per-pixel basis, which is important for blending images into underlying backgrounds. Think of each pixel containing four channels; red, green, blue and alpha. By blending the first three channels you obtain color, while the fourth channel determines the transparency of the pixel. Transparency is especially important for the edges of your icons, which will be rendered against various color backgrounds. The only image format containing an alpha channel rendered by modern browsers is PNG (Portable Network Graphics), but unfortunately, not all browsers, especially mobile web browsers, support the PNG format, so in Blueprint, your PNGs will be converted to anti-aliased GIFs on the devices that can only render GIFs.

More on Anti-Aliasing

Anti-aliasing is a process of blending foreground pixels into background pixels without retaining the alpha information, thus creating a gradient of colors between the two layers. For example, anti-aliasing a black image against a white background, or visa versa, would result in a gradient of gray pixels between the two colors. This works great if your image is going to appear on the intended background color, but terribly if it ends-up on a different color. It’s still common to see GIF images on web pages with a halo around them, due to being displayed on a background unintended by the original designer. The GIF format does not support alpha channels, but instead supports full pixel transparency. This means that you can’t have color and transparency in the same pixel. Anti-aliasing against the correct color will yield great results, but if the image appears over the wrong color, you’ll have a choppy halo around the image.

Delivering on Yahoo! Mobile’s promise of globally accessible products, a few weeks ago we released Yahoo! Go 3.0 in 6 new countries. Germany, UK, France, Spain, Italy and Canada can now get a fully localized Yahoo! Go 3.0 experience in their native language. Yahoo! Go asks the mobile user to select their country when they use Yahoo! Go for the first time. This country information means that developers can build widgets with local awareness. The country and language information is included in a page request sent by Yahoo’s mobile application server.

• Accept-Language
  This HTTP header contains the RFC 4646/4647 language code. For a US user this language code is mainly “Accept-Language: en-US”. For a German user the header would contain “Accept-Language: de-DE”. Yahoo! Go also supports multiple languages in the one country. For instance, in Canada, the user has the choice to choose between Canada/English (en-CA) and Canada/French (fr-CA).

• Geo-Country
  This header contains only the country setting as an ISO 3166 country or UN M.49 region code. A sample header would look like this for Canada: “Geo-Country: CA”.

This language and country information can be very useful to you when deciding which language, or what type of content your widget should offer. Especially if you offer default values in your widget (like default currencies, cities or formats) you can now provide a better user experience by showing country and language specific content.

For our friends in other countries, we have not forgotten about you! We continue to work hard to roll out Yahoo! Go 3.0 to new countries and new devices, so stay tuned to this blog for the latest updates.

Au revoir, Auf Wiedersehen, Adios, Ciao, until next time!

A few days ago saw the Mobile Widgets team at the CTIA Wireless show in Las Vegas where we spoke to mobile developers, operators and publishers about the Yahoo! Mobile Developer Platform. Apart from Yahoo’s announcements regarding the revolutionary new Yahoo! oneSearch 2.0(tm) featuring Yahoo! oneSearch with Voice, the Mobile Developer Platform area also attracted a lot of attention at the Yahoo! booth. We heard many questions from developers and publishers about our Mobile Widget approval process and thought many of you might have the same questions. We thought we’d answer one of the most frequently asked questions here:

Q: Does Yahoo! have a Mobile Widget approval process before the Widget goes live in the gallery?

A: Yes, there is an approval process. Here it how it works:

• You start developing a Widget using the Blueprint SDK. Once you are ready to test it, you simply put together a zip package and submit it on the Test Widget page. Immediately after uploading, your widget will appear on the carousel in our Java client, or on your “My Widgets” page on the mobile home page (you must be signed in to view it). It is only visible to your Yahoo! account - no one else can see it during this phase. You can submit your Widget for testing as often as you like, but generally you don’t need to submit again unless you need to change your images or aspects of your configuration file.

• Once you are done coding and testing, you submit the zip package via the Submit Widget page. Once uploaded, the Yahoo! Mobile Widgets team can see and test your Widget. Our goal is to ensure that your Widget works, is not broken, does not contain offensive content and complies with our Yahoo! Mobile Widget Developer Terms of Use. These terms can be viewed and need to be accepted before you upload your Widget. The approval process is very straight forward and should not take longer than a couple of days. If we have any questions regarding your submission we will get in touch with you via email. Once your Widget is approved you and the rest of the world will be able to see it in our Mobile Widget Gallery, both in Yahoo! Go 3.0 and through Yahoo’s new mobile home page.

As always, if you have any questions regarding Mobile Widgets, Blueprint or the Yahoo! Mobile Developer Platform, please feel free to ask at the Yahoo! Mobile Developer Group.

Happy coding!

In recent weeks, we’ve spent a decent amount of time trying to improve the developer experience when a widget encounters errors. This applies both when submitting your widget as well as when your widget experiences issues at runtime.

Submission

Now when you submit for either test or real gallery submission, we give you a much better targeted error message. For example, if your identifier is not formatted properly, we’ll tell you exactly that. If your icon is not present in your bundle, or the Images folder is not there, we tell you in simple language.

Runtime Errors

Now, if your widget fails to parse due to it either being malformed XML, or perhaps you are using the language improperly, we’ll give you a much nicer error message pointing to the exact line where the error occurred. It should be much easier to locate the issue and fix it now.

Debug Options

You can now see the source of Widget pages that you submit for Test submission. At the bottom of your page, you’ll see an option which is automatically added so you can view your page source.

We’re hoping this will help you make much faster progress writing your widgets by not having to waste your time tracking down what our error messages actually mean.

If you still see errors that seem to be vague, or got you stuck for a while because it wasn’t telling you what you thought it should be, please let us know on our Developer Group site.

In the next few weeks, we plan to make a few changes to our language and introduce at least one new element. I’ll post here when these changes are ready for you to use and enjoy.

Well, we said a while back that we’d be ready for developers to start playing with Blueprint in a few weeks, and here we are. It’s time!

The Floodgates Are Open

Today we’ve opened up the beta versions of our Test and Submit pages on our Mobile Developers Site.

Now you can test your Widget on our development test servers to see the flow of your Widget, as well as look at your Widget’s presentation including layout, fonts and images. Once you are ready to distribute your Widget to Yahoo’s large mobile audience, submit it to the Widget Gallery so people can find and use your Widget.

Updated Blueprint

We’ve also updated the Blueprint Developer’s Guide with our latest additions and tweaks to the language. Some of the syntax has changed since the developer preview, but the same underlying principles are all still there. There’s also an SDK available for download, described below.

As mentioned above, this is all considered ‘beta’ right now. This means we’re trying to shake out our bugs and get a few remaining things into place. We wanted to make sure developers had access to this as soon as possible rather than waiting for perfection, so please forgive us if there are a few hiccups along the way. This way we can gather feedback and turn any necessary changes around quickly so we can all benefit from a strong 1.0 release.

While you are developing your snippets and widgets, please let us know about issues you run into by posting in our Developer Group. We’re looking to smooth any wrinkles around the whole test and submit flows, as well as issues with the language, etc.

Under Construction

During this beta cycle, we’ll be adding to the language over the next few weeks. These additions shouldn’t affect anything you write in the meantime. However, be warned that there may be cases which cause us to change the core language so we can get things right before we consider the language final. We’ll certainly try to keep these to a minimum, and we’ll try our best to do it in a compatible way. For example, we’ll try to deprecate one tag or construct in favor of the new, better way, and give you a few weeks to adjust your widgets before we remove the old, evil way. You could choose then to make the change immediately and update your server code, or wait until later.

Whenever we decide we are ready to call this final, we’ll be sure to communicate this to you as well as give timelines when the last remaining compatibility shims will be removed to give you time to react.

Once 1.0 is final the plan is not to make any changes to the language other than adding extensions to existing syntax.

The SDK

The downloadable SDK contains the Developer’s Guide, but it also has a sample Widget, a sample Snippet, an example Widget, and a blueprint.php file to help you emit Blueprint XML on your servers. We use it in the sample widget we include. It’s in its primordial state, but it’s an easy way to get a jumpstart on producing correct Blueprint XML. You may use the blueprint.php file as you see fit (change it, delete it, extend it). Feel free to also push patches back to us that we might choose to include in our version.

Please be sure to read the README file in the SDK as it has a lot of information about how to put your Widget together, setting up your server environment for serving Blueprint, as well as notes about known issues in this beta.

We’ll also be adding a Blueprint Demo Widget to the Widget Gallery for developers to see how all the different elements of Blueprint render on a device. Look for that to appear ‘real soon now’.

What’s Left?

We’re still working hard to finish some elements: Filter Menu, View Menu, Map, Search Box and some others. These will be rolling out over the next few weeks. You’ll see the full set of what we’ll have planned in the Developer’s Guide.

Over the next few weeks, we hope to be blogging about specific Blueprint topics. These might take the form of how-tos. For example, forms is one that probably needs explaining if you’re not familiar with XForms. It’s a little different that what you might be used to in HTML.

We’re really excited about finally opening this up to developers and we can’t wait to see all the cool stuff you end up writing. It’s never been easier to get developer content onto a mobile device and it’s just going to keep improving over the next few weeks and months. Stay tuned!

Today we’re proud to announce the first preview of the Yahoo! Mobile Widget Platform.

Mobile has always been a hard nut for developers to crack. So many different types of devices, operating systems, and capabilities. How do you cover them all?

Here in the Yahoo! Mobile team we’ve dealt with these problems day and night (literally), trying to build a great mobile product for consumers that addresses all these different challenges. During the development of our mobile products, we’ve built an awesome platform and a language that helps us solve a lot of the traditional mobile developer problems. Now we are opening it up for all developers.

This is a huge deal. Anyone will be able to write a Snippet or Widget and deploy it across hundreds of phones, potentially reaching millions of customers you never could before. We take care of the hard part and let you focus on what you do best: content.

The new Blueprint language (currently in preview form) allows developers to start building mobile widgets easily and quickly using straightforward XML. You can also build a simple mobile widget with RSS Instead of Blueprint if you like.

To be fair though, you won’t be writing any first-person shooters or 3D cube effects with this language (at least not yet). Our goal in this first release was breadth, not depth. We wanted to make sure developers could get onto the most devices possible. As we move forward, devices will get more powerful and the baseline will get higher. As this happens we’ll also start to increase our depth.

This stage of our platform and language is just the beginning. We already have our roadmap planned out. While this first release relies on developers to serve their Snippets and Widgets remotely, the next generation will run directly on the device and get at the more powerful features of today’s cool new phones.

Not only do developers benefit from this platform, but so do users. Users are able to customize and personalize their Yahoo! mobile experience with your Widgets. We’re leveling the mobile playing field by giving all developers and publishers equal access to our large audience of Yahoo! mobile users, so the only thing you need to worry about is building a mobile widget users will want to keep on their device.

In the coming months we’ll be releasing many more exciting tools for developers to create even more powerful and innovative mobile widgets. This blog will be the go-to place to learn about new developments as well as tips and tricks on how to build Snippets and Widgets.

We will also be establishing a forum to allow you to connect with other developers using the platform, as well as some of the engineers that created it.

We will soon open up the floodgates to allow you to start creating, testing, and submitting your creations to our Gallery. We’re moving fast and furious to get this stuff to you, so there might be a few speed bumps and hiccups along the way. We apologize in advance, but trust us, the end result will be well worth it.

• The (very excited, but tired) Yahoo! Mobile team