Historically, it hasn't been very often that I've been able to tip my hat to Microsoft for open web innovation. Today though is one of those times that I get to do so. John Allsopp, one of Microformats's biggest supporters, mentioned today that Microsoft's designer/developer community, Mix Online, has developed a IE toolbar called Oomph.
Oomph, much like Operator in Firefox, pulls microformatted information from a page and allows the user to make use of this data by offering options like being able to export contact information, map addresses, and add events to your calendar.
That would be enough in itself to get my attention...Microsoft has not typically been the most open of companies, and despite Gates' declaration that the web needs Microformats, they really hadn't done much to advance its' use. Seeing their developer community get behind Microformats with the toolbar and a couple of nice Microformats articles is very encouraging.
However, there's more to this story. In addition to the IE toolbar, a cross-browser Javascript implementation of Oomph was created. The toolkit, which makes use of JQuery, provides the same functionality of Oomph no matter the browser being utilized.
What's so wonderful about the way the Oomph toolkit functions is that the useful data is all right there in the browser window. Without the visitor leaving the site, they can grab a vcard of your contact information, see a listing of upcoming events, or make use of Visual Earth and view a map of a location.
This is, I think, a fairly major move. The beauty of Microformats is how easy it is to make your content more meaningful, and more useful. By providing similar data in a specific format, it significantly decreases the effort necessary to extract that data, and then use it. Having a cross-browser implementation of a script that makes use of this data to enhance its' functionality is really a nice feature and a great way to show off the value of using Microformats.
What's best is that since the toolkit makes use of Javascript and CSS for the effects and layout, we can modify the functionality and appearance for usage on our own sites. Technorati already offered services to help us extract contact information or event information, but the Oomph toolkit expands upon that functionality and allows us to offer even more enhanced options for visitors.
All in all, I am very pleased by this development. Microformats is such a valuable technology that is long overdue for mainstream implementation. It's nice to see yet another big supporter coming through to help it get there. Along with Technorati's tools and the fantastic Optimus Microformats transformer by Dmitry Baranovskiy, the resouces are in place and it should be interesting to see the ways these tools are utilized to provide a better user experience for visitors.
Monday, October 27, 2008
Sunday, October 19, 2008
Font Equality for Everyone
One of the areas that web design is lacking in, is a way to reliably provide beautiful fonts for our designs. There's a very limited amount of fonts that are actually safe to use on the web, because not everyone is a designer with lots of nice fonts installed on their machine. Sure, with font stacking we can help ease the pain a bit, but it's still a small amount of people that will see the fonts we intend, with everyone else getting boring alternates.
There are a few solutions currently being utilized across the web. The simplest, and also probably the worst option of them, is to use background images to display our custom fonts. This is not very ideal at all...every time we want to change the text on the site, we have to edit the appropriate background image. A couple less "needy" options are sIFR and FLIR. In both cases, Javascript is utilized to deliver the text in our desired font. sIFR uses Flash to make this happen and FLIR uses PHP. But we are still relying on Javascript to load the fonts onto the page, and there is some performance loss.
Thankfully, we are close to being able to make use of a CSS rule that makes font use so much simpler. The newest versions of all major browsers now support the @font-face rule, which gives us a lot of power over the fonts we can use in our sites. Unfortunately, some of them don't play too nicely yet. Firefox 3.1 and Safari both implement the @font-face rule very well, but IE only supports EOT fonts and I've found Opera 9.6's support is a bit unreliable. However, in the name of progressive enhancement, there's little reason why we can't start making use of this rule to improve our sites now.
The beauty of the @font-face rule is both how simple it is, and yet how powerful it is. The @font-face rule includes the rule and the font description like so:
The font description is made up of the what are called font descriptors. Simply put, they follow the same format of typical CSS style declarations. The most basic font description is composed of a font-family declaration and a src declaration that points to the font we will be using, like so:
The url can be either remote or on your own site. However, for maximum browser compatibility, your font should reside in the same place as the page using it. Firefox, for instance, does not allow using fonts that don't have the same origin of the page. Instead of using a url, we can also use a local path ( local(font-path) ) that would point to a font located on the user's computer. We've now set the way for us to make use of the Benjamin Franklin font in our site.
Simple and easy. Here's where the fun stuff comes in though. Remember how those declarations, like the font-family declaration above, are called font descriptors? That's because they describe the declaration that can be used to trigger that font use. Admittedly, that might not be very clear, so let's extend our example:
In the example above, we changed the call to the font being used if the font-weight is bold. If the font-weight is anything but bold, then the Benjamin Franklin font is used. If the font-weight is set to bold, then the Hansa font is used. If you have Safari or the Firefox 3.1 beta you can take a look at the code in action. (NOTE: The only reason I was using two different fonts here is to make it obvious that the font is changed based on the font-weight. A more subtle example would be to use a variation of the base font, like a bold version.)
Descriptors give you significant power over the fonts you utilize. Instead of relying on the browser to fake a bold or italic version of the font, we can provide the more professional looking actual italicized, or bolded, version of the font, greatly improving the appearance of our design.
I highly encourage taking a look at the W3C's information on the @font-face rule and playing around with it a bit. There's some great examples of some of the powerful ways you can make use of the @font-face rules including an interesting example of redefining the basic serif font-family. Remember, for full functionality you'll need to either get ahold of Firefox 3.1 or Safari.
Keep in mind that not all fonts are meant to be used in this way. Some font providers encourage you to make use of their fonts freely, other's don't. So make sure you're allowed to make use of the font before embedding it on your site. Both fonts used in the examples, Hansa and Benjamin Franklin, are designed by Dieter Steffman who graciously allows his fonts to be freely used on the web.
Also, while there is a lot of power and control offered with the @font-face rule, still use it with some level of restraint. There is some time involved in downloading the font, so you should probably stick to using this method for headlines only...not body text.
There are a few solutions currently being utilized across the web. The simplest, and also probably the worst option of them, is to use background images to display our custom fonts. This is not very ideal at all...every time we want to change the text on the site, we have to edit the appropriate background image. A couple less "needy" options are sIFR and FLIR. In both cases, Javascript is utilized to deliver the text in our desired font. sIFR uses Flash to make this happen and FLIR uses PHP. But we are still relying on Javascript to load the fonts onto the page, and there is some performance loss.
Thankfully, we are close to being able to make use of a CSS rule that makes font use so much simpler. The newest versions of all major browsers now support the @font-face rule, which gives us a lot of power over the fonts we can use in our sites. Unfortunately, some of them don't play too nicely yet. Firefox 3.1 and Safari both implement the @font-face rule very well, but IE only supports EOT fonts and I've found Opera 9.6's support is a bit unreliable. However, in the name of progressive enhancement, there's little reason why we can't start making use of this rule to improve our sites now.
Simply Powerful
The beauty of the @font-face rule is both how simple it is, and yet how powerful it is. The @font-face rule includes the rule and the font description like so:
- @font-face {
- }
The font description is made up of the what are called font descriptors. Simply put, they follow the same format of typical CSS style declarations. The most basic font description is composed of a font-family declaration and a src declaration that points to the font we will be using, like so:
- @font-face {
- font-family: "Benjamin Franklin";
- src: url(BenjaminFranklin.ttf);
- }
The url can be either remote or on your own site. However, for maximum browser compatibility, your font should reside in the same place as the page using it. Firefox, for instance, does not allow using fonts that don't have the same origin of the page. Instead of using a url, we can also use a local path ( local(font-path) ) that would point to a font located on the user's computer. We've now set the way for us to make use of the Benjamin Franklin font in our site.
- h1 {
- font-family: "Benjamin Franklin", serif;
- }
More Than Meets the Eye
Simple and easy. Here's where the fun stuff comes in though. Remember how those declarations, like the font-family declaration above, are called font descriptors? That's because they describe the declaration that can be used to trigger that font use. Admittedly, that might not be very clear, so let's extend our example:
- @font-face {
- font-family: "Benjamin Franklin";
- src: url(BenjaminFranklin.ttf);
- font-weight: all;
- }
- @font-face {
- font-family: "Benjamin Franklin";
- src: url(Hansa.ttf);
- font-weight: bold;
- }
- h1 {
- font-family: "Benjamin Franklin", serif;
- font-weight: bold;
- }
- h2 {
- font-family: "Benjamin Franklin", serif;
- font-weight: normal;
- }
In the example above, we changed the call to the font being used if the font-weight is bold. If the font-weight is anything but bold, then the Benjamin Franklin font is used. If the font-weight is set to bold, then the Hansa font is used. If you have Safari or the Firefox 3.1 beta you can take a look at the code in action. (NOTE: The only reason I was using two different fonts here is to make it obvious that the font is changed based on the font-weight. A more subtle example would be to use a variation of the base font, like a bold version.)
Descriptors give you significant power over the fonts you utilize. Instead of relying on the browser to fake a bold or italic version of the font, we can provide the more professional looking actual italicized, or bolded, version of the font, greatly improving the appearance of our design.
I highly encourage taking a look at the W3C's information on the @font-face rule and playing around with it a bit. There's some great examples of some of the powerful ways you can make use of the @font-face rules including an interesting example of redefining the basic serif font-family. Remember, for full functionality you'll need to either get ahold of Firefox 3.1 or Safari.
Keep in mind that not all fonts are meant to be used in this way. Some font providers encourage you to make use of their fonts freely, other's don't. So make sure you're allowed to make use of the font before embedding it on your site. Both fonts used in the examples, Hansa and Benjamin Franklin, are designed by Dieter Steffman who graciously allows his fonts to be freely used on the web.
Also, while there is a lot of power and control offered with the @font-face rule, still use it with some level of restraint. There is some time involved in downloading the font, so you should probably stick to using this method for headlines only...not body text.
Wednesday, October 15, 2008
Book Review: Mobile Web Development
Who Wrote It?
Mobile Web Development is written by Nirav Mehta, the head of Magnet Technologies a software development firm in India. He blogs about a variety of business and tech topics at www.mehtanirav.com.
What's Covered?
Mobile Web Development covers a wide variety of topics related to...guess what....mobile web development. Nirav does a fantastic job of introducing a wide variety of technologies needed to begin mobile web development including sending and receiving SMS and MMS messages, optimizing your site for mobile devices and using AJAX on the mobile web.
The book, from Packt Publishing, takes a very solution-based approach. Each chapter, with the exception of the first and last, has a very specific task that it is concerned with accomplishing. Usually, I'm not too awful fond of the format. It often feels like such books aren't teaching me a topic so much as giving me snippets of code I am comfortable with manipulating.
This book, however, is an exception to that rule. Each chapter, in addition to accomplishing the task at hands, takes the time to explain the possible solutions to the problem, and their pros and cons. The result is that once you've finished the book, you have a nice foundation of real working knowledge that will allow you to immediately get started with mobile web development. For those of us that may want a deeper understanding of the technologies, there are plenty of nods towards resources that will provide that information.
Should I Read It?
The book is intended for people with at least a basic understanding of CSS, Javascript and PHP. In particular, there is a fair amount of PHP code, so you should probably be comfortable with looking through it.
The book manages to cover a surprisingly large amount of information for being such a brisk read. The truth though, is that at least in the beginning, the basics of mobile web development are quite similar to the basics of web development, and you'll be pleasantly surprised by just how easy it is to get started.
One of the things I enjoyed most about Nirav's approach to the book is the emphasis on the user. Keeping the user in mind is always important, but particularly when the user needs to get the information quickly and needs to do it with a very small amount of screen real estate. Each chapter makes sure to mention how a given solution can help or detract from the user experience, ensuring that you have the understanding necessary to make good decisions that will benefit your users.
One Minor Complaint
The one and only issue I have with the book is that the editing could have been a bit better. Don't worry though, the editing is no-where near bad enough to confuse you. There's just a fair amount of a's and the's that are AWOL. Like I said, not enough to cause you trouble understanding the information, just enough that you'll notice.
Final Verdict
Mobile web development is one of the most important new avenues for web developers to pursue. The amount of people making use of mobile devices to get their information on the run is growing very quickly. Minor editing issues aside, the book was a great introduction to getting started with these technologies. I would highly recommend picking up the book and giving it a thorough reading. It's surprising how easy it is to get started in the mobile web, and after reading it you'll have a solid base of working knowledge to allow you to start creating your own mobile web content.
Great...Where Do I Get a Copy?
Subscribe to:
Posts (Atom)