Big changes are coming to Twitter links. In a post just published on the Twitter blog, the company has announced that it will soon be using its official link shortening service t.co to wrap all links shared on Twitter. Starting this summer, every time you share a link through either the Twitter web client or a third party, it will be be wrapped in a link with the format t.co/******.
So what does this mean for the Twitter ecosystem? Twitter VP Product Jason Goldman says that the feature serves three purposes. First, it’s going to help Twitter crack down on spam, as they’ll be able to accurately monitor the distribution of each link. Second, it will allow users to better understand where links are going (more on that below). And third, it will help Twitter with analytics, which is related to its Promoted Tweets. Goldman says that Twitter is pre-announcing the feature (which is currently only active with three accounts) to give the developer community a heads up for what’s ahead.
This didn’t come as a surprise — back in March, Twitter began routing direct messages through a new link shortening service as an anti-phishing mechanism. It didn’t take long for users and developers to question whether the service would soon be broadly launching a link shortening service, and Twitter confirmed that it would in April.
Still updating

Twitter Advertises URL Shortener as Phish Poison http://bit.ly/9Gf2m7
Twitter's URL shortening service, t.co, is being advertised as a way to avoid stumbling into phishing scam. Shorteners make it easier to microblog, but they also make it easier for grifters to blind their online marks.
"A link converted by Twitter's link service is checked against a list of potentially dangerous sites. When there's a match, users can be warned before they continue."
T.co, according to Twitter, will also enable metrics, to determine how many times a given link was clicked.
"Eventually, this information will become an important quality signal for our Resonance algorithm--the way we determine if a Tweet is relevant and interesting."
Users are free to continue to use their shortening services of choice but all links within Twitter will be wrapped in the t.co holster.
Out of the box, the service will available to developers. This summer the company plans to roll it out service-wide. Given that all links in Twitter will be auto-shortened, it could have a tangible effect on start-ups that provide this service.
Discuss
Back in September of last year, Google unveiled an early look at an interesting (and rather hilarious) new project: Chrome Frame. What it does is take Microsoft’s Internet Explorer browser and basically turn it into Google Chrome via a plug-in. Today, that plug-in has progressed enough that Google is graduating it to full beta status. “We think it’s really stable,” engineer Alex Russell tells us in noting the move to beta.
To use Chrome Frame, all a user has to do is go here and install the plug-in on either IE6, IE7, or IE8 running on Windows 7, Vista, or XP. For developers, it’s even easier to target these users: they just have to include a meta tag in their sites’ code and their pages will start to render in IE (with Chrome Frame installed) just as they would in Chrome itself.
“A bunch of big sites are using the tag,” Russell says. One that he singled out was WordPress.com. Anyone who visits a WordPress.com blog on IE with Chrome Frame installed will see it rendered in the Chrome-way — this includes TechCrunch.
So why would a user install Chrome Frame rather than just install Chrome itself? Well there are a few reasons, but the biggest may be that their place of work requires that they use IE for things such as an intranet. Or maybe they just prefer the configuration layout of IE. Chrome Frame doesn’t alter that at all, it simply makes webpages render as they would using some of the more modern web standards that IE doesn’t yet support. For example, you can watch YouTube videos in HTML5-compatible formats in IE with Chrome Frame.
When I asked about IE9, the latest build of Microsoft’s browser, Russell notes that it’s still more of a cut-down shell at this point so it’s hard to know if Chrome Frame will work with it. More importantly, he cites Microsoft’s much-improved adherence to web standards with IE9 as a reason that Google may not need to have a version of Chrome Frame for IE9. But again, it’s too early to tell.
“The goal of Chrome Frame and crhome is to push the web forward. It’s so that everybody can build their page once,” Russell says.
I also asked about mobile browser support for something like Chrome Frame, but Russell said that was more difficult. Part of the reason is that mobile devices are still constrained by memory (and lack of plug-ins), but he also notes that pretty much all the mobile browsers besides Microsoft’s are using WebKit or moving towards it, ensuring they’ll be standard-compliant. And in the mobile browsing world, Microsoft is a small player, not the force it is on the desktop.
Now that it’s in beta, Russell hopes that the move to a fully stable release will be pretty quick. While Google doesn’t count Chrome Frame users among the 70 million active Chrome users, they’re basically brothers from another mother. And Mama Microsoft can’t be too thrilled about that.

Facebook’s popular new social plugin, the Like Button, has been having some growing pains this week. The new feature, which lets users share web pages back to Facebook with a single click, is already live on more than 100,000 web sites after it launched in late April, including big ones like CNN.
The button stopped letting users share information back to Facebook sometime on Monday, judging by the ongoing bug tracker entry. Facebook put up a note by the next day notifying all developers of the problem, then got the plugin working again on Wednesday.
But there have been ongoing issues. Shared links have still not been appearing in users’ news feeds and walls in the last couple of days, and the bug report has been reopened. Facebook engineer Jerry Cain has most recently said that the latest fix has just gone live.
Today at the WWDC event in San Francisco, Apple CEO Steve Jobs took the stage for his keynote address. During it, he gave some key stats about three key pillars of Apple’s recent strategy: the iPad, the App Store, and the new iBooks store.
First, the key iPad stats:
Next some iBooks stats:
App Store:
Jobs also used the stage early on at WWDC to take his first shot at Google. He notes that the developer of Elements for the iPad recently emailed him to let him know that he earned more money in the first day of sales for the iPad than he did in 5 years from Google ads on his periodictable.com site.
Jobs also highlighted something that Apple has begun pushing recently thanks largely to its war with Adobe: HTML5. “We support two platforms at Apple,” Jobs said — HTML5 and the App Store. “Apple’s browsers are in the lead in supporting the HTML5 standard,” Jobs noted.

It is arguable that there is no goal in web design more satisfying than getting a beautiful and intuitive design to look exactly the same in every currently-used browser. Unfortunately, that goal is generally agreed to be almost impossible to attain. Some have even gone on record as stating that perfect, cross-browser compatibility is not necessary.
While I agree that creating a consistent experience for every user in every browser (putting aside mobile platforms for the moment) is never going to happen for every project, I believe a near-exact cross-browser experience is attainable in many cases. As developers, our goal should not just be to get it working in every browser; our goal should be to get it working in every browser with a minimal amount of code, allowing future website maintenance to run smoothly.
In this article, I’ll be describing what I believe are some of the most important CSS principles and tips that can help both new and experienced front-end developers achieve as close to a consistent cross-browser experience as possible, with as little CSS code as possible.

This is one of the first things you should be thoroughly familiar with if you want to be able to achieve cross-browser layouts with very few hacks and workarounds. Fortunately, the box model is not a difficult thing to grasp, and generally works the same in all browsers, except in circumstances related to certain versions of Internet Explorer (more on this later).
The CSS box model is responsible for calculating:
The CSS box model has the following basic rules:
Some important things to keep in mind for dealing with block-level elements:

The box model as its displayed using Firebug in Firefox
For experienced developers, this is another no-brainer. It is, however, another crucial area that, when fully understood, will cause the light bulb to appear, many headaches will be avoided, and you’ll feel much more confident in creating cross-browser layouts.
The image below illustrates the difference between block and inline elements:

Here are some basic rules that differentiate block elements from inline:
white-space, font-size, and letter-spacingvertical-align property, but block elements cannotFor multi-column layouts that are relatively easy to maintain, the best method is to use floats. Having a solid understanding of how floats work is, therefore, another important factor in achieving a cross-browser experience.
A floated element can be floated either left or right, with the result that the floated element will shift in the specified direction until it reaches the edge of its parent container, or the edge of another floated element. All non-floated, inline content that appears below the floated element will flow along the side of the element that is opposite to the float direction.

Here are some important things to keep in mind when floating and clearing elements:
Most of what I’ve discussed so far has to do with CSS coding and layout principles. This principle is more related to habits and preferences of most designers. Although we might hate to use IE6 and IE7 in our everyday internet activities, when it comes time to build a client project from scratch, one of the best things you can do is test your layout in those browsers early in development. You might even want to open up a standalone version of IE6 or IE7 and just start your development in that browser.
Of course, you won’t have access to tools like Firebug, but generally for CSS (especially early in development) you won’t need Firebug. It’s much easier to get a layout working first in IE6 and IE7, then fix for other browsers, than to do it the other way around. Waiting until late in the development process to open up IE6 and/or IE7 will likely cause some, if not all, of the following problems:
I wouldn’t expect developers to use Internet Explorer this aggressively for personal projects, web apps, or other non-client work. But for corporate clients whose user base is primarily on Internet Explorer, this tip could prevent a lot of headaches while getting things to work properly, and will definitely make a cross-browser experience much more likely.
Sometimes viewing IE’s problems as “annoying bugs” can create unnecessary negativity, and can hinder development time and future maintenance. Dealing with IE is a fact of life for designers and developers, so just view its problems as you would any CSS issue — and build from there.
If you’re going to start with IE in your development, or at the very least check your layout in IE early on, then you should understand what things Internet Explorer (usually versions 6 & 7) has problems with, or what its limitations are.
A detailed discussion of every possible problem that can occur in Internet Explorer, and a list of all of its CSS compatibility issues is certainly beyond this article. But there are some fairly significant inconsistencies and issues that come up in relation to IE that all CSS developers should be aware of. Here is a rundown of the most common problems you’ll need to deal with:
display: inline will often fix thismin-height, or max-widthdisplay property (e.g. inline-table, table-cell, table-row, etc.):hover pseudo-class on any element in IE6 except an anchor (<a>)There are many more bugs, issues, and inconsistencies that can arise in Internet Explorer, but these are probably the most common and most important ones to keep in mind when trying to create a cross-browser experience. I encourage all developers to do further research on many of the issues I’ve mentioned above in order to have a more accurate understanding of what problems these issues can cause, and how to handle them.
As already mentioned, creating the exact same experience visually and functionally in every browser is possible, but unlikely. You can get the layout and positioning of elements close to pixel-perfect, but there are some things that are out of the developer’s control.
Discussing all the differences and quirks that occur with form elements across the different browsers and platforms could be an article in itself, so I won’t go into extensive details here. A simple visual demonstration, however, should suffice to get the point across.
Take a look at the image below, which displays the <select> elements on the Facebook home page, as shown in 5 different browser versions (screenshots taken from Adobe’s Browserlab):

<select> elements appear differently in different browsers
Some form elements can be controlled visually. For example, if the client requires that the submit button looks the same in every browser, that’s no problem, you can just use an image, instead of the default <input type="submit">, which, similar to <select> elements, will look different in different browsers.
But other form elements, like radio buttons, textarea fields, and the aforementioned <select> elements, are impossible to style in a cross-browser fashion without complicating matters using JavaScript plugins (which some developers feel harm the user experience).
Another area in which we can’t expect pixel-perfect designs is with regards to fonts, particularly fonts on body copy. Different methods have sprung up to help with custom fonts in headers, and the recently launched Google Font API will contribute to this. But body copy will probably always look different in different browsers.
With typography, we not only face the problem of font availability on different machines, but in some cases even when the font is available on two different machines, the type will look different. Windows ClearType, for example, is available on IE7, but not on IE6, causing the same font to look different on two different versions of IE.
The graphic below displays screenshots from A List Apart on IE6 and IE7. The grainy text in IE6 is more evident on the heading than in the body copy, but all text displays a marked difference between the two browsers (unless of course the text is an image):

A List Apart’s typography compared in IE6 and IE7
Ever since I started using a CSS rest for my projects, my ability to create a cross-browser experience has greatly increased. It’s true that most resets will add unnecessary code to your CSS, but you can always go through and remove any selectors that you know will not be a factor (for example, if you don’t plan to use the <blockquote> tag, then you can remove reference to it, and repeat this for any other unused tags).
Many of the margin- and padding-related differences that occur across different browsers become more normalized (even in troublesome HTML forms) when a CSS reset is implemented. Because the reset causes all elements to start from a zero base, you gain more control over the spacing and alignment of elements because all browsers will begin from the same basic settings.

A CSS reset as shown in Firefox’s developer toolbar
Besides the benefits of producing a cross-browser experience, a reset will also be beneficial because you won’t use as many hacks, your code will be less bloated, and you’ll be much more likely to create maintainable code. I recommend Eric Meyer’s CSS reset, which I’ve been using for quite some time now.
If you’re having trouble getting a particular CSS property to display correctly across all browsers, look up the property in the SitePoint CSS Reference to see if it has any compatibility limitations. SitePoint’s reference (which is also available as a hard copy (though not as up to date), includes a useful compatibility chart that displays browser support for every standard CSS property.

SitePoint’s Compatibility Charts for CSS Properties
Each compatibility chart is accompanied by a fairly detailed description of the bugs that occur in different browsers, and users are permitted to add comments to document new bugs that come up and to provide further explanations on complex CSS issues.
Using this as a guide, you can narrow down the possibilities, and can usually determine whether or not a CSS issue is due to a browser bug, or due to your own misapplication or misunderstanding of the CSS property in question.
While there is so much more that could be discussed on the topic of cross-browser CSS, the principles and guidelines I’ve introduced here should provide a foundation to assist CSS developers in creating as close to a consistent cross-browser experience as is currently possible. Cross-browser CSS is an attainable goal, within reasonable limits.
But, as an epilogue to this article, I also would like to concur with those promoting the use of CSS3 with progressive enhancement, and encourage developers to push new CSS techniques to the limits, even doing so, where possible, on client projects.
The principles I’ve introduced here should help developers create a beautiful and intuitive experience in IE, while providing an extra-beautiful and super-intuitive experience in the more up-to-date browsers. That’s a cross-browser goal that is definitely worth striving for.
© Louis Lazaris for Smashing Magazine, 2010. | Permalink | 4 comments | Add to del.icio.us | Digg this | Stumble on StumbleUpon! | Tweet it! | Submit to Reddit | Forum Smashing Magazine
Post tags: CSS
The Principles Of Cross-Browser CSS Coding
- Rob DianaThe Principles Of Cross-Browser CSS Coding - Smashing Magazine
- Rob DianaSharing: The Principles Of Cross-Browser CSS Coding http://bit.ly/9oB6z6
- Rob Diana
As web designers and developers, we often overlook printed marketing materials.
But on occasion, they can come in very handy: at conferences, when we meet face-to-face with clients, or when we happen to run into someone we might want to do business with. Having business cards is a great way to promote yourself in the physical world.
Of course, since web design is a creative field, you’ll want your business card to serve as a sort of mini portfolio that displays your skills. You should put the same time and energy into designing your business cards that you put into designing a website.
And the skills necessary to design a business card can be easily adapted from those that are required to design a website. Read on for more information about how to design your business cards.
Standard business cards are 2″ x 3.5″, in either vertical or horizontal orientation. Horizontal is more traditional, but plenty of people and companies now opt for vertical layouts.
There are a few benefits to the standard sizing, the primary one being that it’s generally less expensive because it’s common. The other big benefit is that it is immediately recognizable as a business card, and will fit in standard business card holders.
But just because business cards are traditionally a 2″ x 3.5″ rectangle doesn’t mean you can’t deviate from that size and shape. With modern printing and cutting techniques, virtually any size and shape can be used for your business cards.
Die cut cards are particularly popular. Some opt for a traditional rectable, but with rounded corners or some kind of cutout shape within the card.
Others opt for an entirely custom shape, often reflecting their logo or a company theme or mascot. Just remember that anything too complex is likely to get bent or otherwise misshapen, which may defeat its purpose.
Here’s a great example of a die-cut card, with letters cut out of the card itself.
Over-sized and under-sized cards are growing in popularity. Over-sized cards are often die cut custom shapes. Like die-cut cards, over- or under-sized cards can make your business card stand out from those of your competitors.
Folded cards are yet another option. You can choose to have the fold along the long or short side of the card.
The best option generally depends on the purpose of the folding parts and the orientation of the card itself. With a vertical-oriented card, you may want the fold along the short side, and with a horizontal card you may want it on the long side. But again, it depends on the overall design of the card.
The vast majority of business cards out there are printed on paper cardstock. Cardstock comes in a variety of weights, textures, and colors. Card stock weights are calculated a bit differently than text-weight paper.
A pound weight of card stock is calculated based on the weight of 500 20″ x 26″ sheets, while text weight paper is calculated based on the weight of 500 25″ x 38″ sheets.
Card stock is any paper with a weight of between 50 and 110lbs. It’s also sometimes referred to by points or mils, which is the thickness of the sheet in thousandths of an inch. So a 12 pt. card stock is .012 inches thick.
In addition to the weight of the paper, you’ll also want to consider paper color. Most business cards are printed on either cream or white paper. But virtually any color can be used. Ask your printer for options as they likely can get better deals from certain manufacturers.
The paper texture is also important. Decide whether you want your paper to be smooth or rough, matte or glossy, or anywhere in between. Your printer can likely give you samples to see what they have available. Alternatively, check out your local office supply store to see what they have on hand.
Coatings
While many business cards don’t bother with any kind of coating, you may want to opt for an aqueous (water resistant) or UV-protective coating. Either of these options make your business card more durable, but they do add to the cost.
Specialty Materials
While most business cards are printed on paper, there are a growing number of specialty cards that are printed on other materials. Plastic and wood seem to be the most popular, but there are also examples of metal business cards. Plastic cards are available clear, opaque, or frosted, and are even available in different colors, and aren’t significantly more expensive than good quality paper cards. Even wooden business cards have come down significantly in price, with single-color cards starting as low as $35/100.
Here’s an example of a business card made from wood, with a custom shape.
Embossing
Embossing is done by applying heat and pressure to create a raised area on a piece of paper or cardstock. Embossing is generally done without applying any ink to the raised parts. A logo, monogram or other image are all commonly embossed on business cards.
Embellishments
Depending on your budget, you can add virtually any embellishment you want to your business cards. To get an idea of some of the types of embellishments widely available, check out your local scrapbooking supplier. If you’re willing to put in a little elbow grease on your own cards, you can often pick up supplies in these shops. Alternatively, check with your printer to see what types of embellishments they might be able to handle (it will vary widely between printers).
A creative card design with hair pins as embellishments.
There are a variety of printing methods out there. There’s also a wide variety in the quality, look, and cost of the different printing processes. The most common process for commercial printing is offset, though unless you’re getting a very large quantity of business cards printed, it can be cost-prohibitive because of setup fees.
Digital printing methods are probably the most common ways to have business cards printed. Among digital printers, some use inkjet technology while most others use laser printers. Digital presses are usually more cost-effective for shorter print runs due to lower setup costs.
In addition to the common processes above, there are a few other options out there. Letterpress is a great choice for a card with a higher-end look and feel. Because printing plates with raised letters are pressed into the paper, the end result has indentations for each letter or printed image.
These are best limited to cards with only one or two colors, as each color has to be printed separately. Most letterpress shops are small, often using antique platen presses. The cost per card is high, especially for smaller quantities, but the end result gives a custom, bespoke feel.
Letterpress is often associated with more traditional designs, but it works well with a modern design like this one, too.
Engraved cards are also an option. Engraving is most often seen on wedding invitations and other social stationery, but it is an option for business stationery, too.
Engraving involves using printing plates that are engraved with metal gravers or acid etched. The printing plates are inked, and the ink fills the etched or engraved lines. Dampened paper is then printed using great pressure, to ensure it will absorb all of the ink from the plates. This results in a heavily-inked, sometimes raised effect. Thermography printing is sometimes used to achieve a look similar to engraving at a much lower cost.
At the absolute low-end of the scale are self-printed business cards. If you’ve ever set foot inside a stationery or office supply store, you’ve probably seen the pre-scored sheets of business cards you can buy to print your own cards on your inkjet or laserjet printer.
If your card is very simple, preferably black and white, and you have no budget, then printing your own cards can be acceptable. One trick, though, is that instead of buying the pre-scored business card sheets (which will have tell-tale remnants of perforations along each side), buy good-quality cardstock and a paper cutter. Use the templates for laying out your business cards, but then cut them apart yourself to eliminate the perforation marks.
Now that you have an idea of the options available for creating your business cards, it’s time to get down to actually designing those cards. You’ll want to take into account the style of your current marketing materials, including your website, as well as the image you want to portray to potential clients.
These business cards offer a great example of how color can be used in your design.
Your color choices can have a great impact on the type of printing process you can use, as well as the cost of your printed piece.
A standard, 4-color process is common with both offset and digital printing. While opting for a single-color business card on these types of presses can sometimes save a bit of money, it often has no effect on the cost of the project (especially with digital presses). By contrast, a one or two color design can be much more cost-effective with a letterpress or engraved business card, as each printing plate has to be custom-made for each color.
If your website and general style are minimalist, stick with a minimalist card. Pay close attention to typefaces and color and less attention to images and embellishments. With a minimalist design, you might consider using a more expensive printing technique like letterpress or engraving, especially if you’re only using one or two colors.
By contrast, if your style is more artistic or extravagant, have your business card reflect that. Go with a four-color printing process and really let your personal aesthetic style shine through. Be as creative with your business card design as you would be with your website designs.
Experiment with a few different card styles and designs, and then get estimates for how much each one will cost you to have printed at different quantities. Since business cards can range widely in price from only a few cents each (or less) to well over a dollar or more, your budget will likely have as great an effect on the final design as any other factor.
Remember that your business card’s primary function is for prospective and current clients to be able to access your contact information. The information you provide on the card is vital to how effective it will be.
But some designers and business people have a tendency to include every bit of information they can think of on their business card. Because of their smaller format, business cards are a prime case of less is more.
What you choose to include on your business card is highly dependent on the design and how you’re most-often contacted by clients. In the simplest incarnations, a business card might only include your website address. This can work if your domain name is your name or your company name, but otherwise it’s only likely to be confusing.
At a bare minimum for most cards, you’ll want to include your name and your company name, what you do, and your basic contact information (phone, email and website address). Other information you might consider including:
You may opt to include your logo, a background image, or some other complementary graphic. Alternatively, you might decide you only want text on your card (possibly on a colored paper background). Look at your other marketing materials and website and emulate their look and feel when it comes to graphics.
For anyone with a background primarily in website design, print specifications can be a bit foreign. There are certain things that are vital in a printed file that are either irrelevant in a digital file or can be fudged quite a bit. But if you try to do that in something that will be printed, you’ll end up with a card that’s a mess and way less professional-looking than you might have hoped for.
DPI is one of the most important things to remember when you’re designing a printed piece. Your business cards should have a resolution of at least 300dpi for any images included. Fonts should be embedded rather than converted to images for the crispest edges. You’ll also need to factor in a bleed if there’s color or images that run right to the edge of the card. Bleeds can be more expensive, though that will depend on your particular printer.
Each printer is going to have their own preferred specifications for your files. Check with them prior to finalizing your design to make sure you’re working within their guidelines. Some printers might want your original artwork files while others want PDFs made to particular specifications.
Others might be able to accept an EPS or TIFF file, though in those cases you’ll want to use an even higher resolution file (600 or even 1200dpi), since your fonts won’t be embedded.
Below are fifty examples of excellent business card designs to inspire you and give you ideas for your own business card designs.
Written exclusively for WDD by Cameron Chapman
How do you design your own business cards? Which designs do you feel have a more lasting impression? Share any other comments below…
If you find an exclusive RSS freebie on this feed or on the live WDD website, please use the following code to download it: S5zX2K
Yesterday during my talk at the Augmented Reality Event in Santa Clara, California, one of the questions I brought up was whether or not QR codes continue to be used because of their association with AR. Should we prolong the use of these large black and white codes in order to help users and customers identify augmented reality experiences? This morning, during his keynote before the second day of the event, Bruno Uzzan, CEO of AR titan Total Immersion, announced the creation of a logo the company hopes will become a standard for identifying AR applications.
Dubbed, AR Plus (or AR+), the logo is designed to be a beacon that will signify when an interactive augmented experience has been implemented into an application. In the same way standardized USB or DVD devices brand the same logo on their devices and products, Total Immersion hopes AR developers will place the AR+ logo on their products.

Uzzan's keynote this morning focused on the creation of standards within the AR community - a popular topic at the conference so far. Uzzan says the time is now for standardization for augmented reality because major technology players are considering AR experiences, and a lack of standards may temporarily keep them from adopting the technology. He believes standards are what the community needs to breakthrough into the mainstream.
"With the new AR+ logo, the industry can give consumers, developers, brands, and others a consistent framework for encountering and understanding augmented reality solutions," said Uzzan in a press release Thursday. "There's a sense that the AR industry has grown up too fast, that it has at times felt like the 'Wild West.' Today, the industry consists of multiple players, multiple platforms and easier access to AR. The new AR+ logo affirms that we're working with a new human interface, now going mainstream."
The benefits of standardization, Uzzan said, include stability and compatibility across platforms for AR experiences. Large downloads and poor quality have deterred users from using augmented reality in the past, and standardization will streamline development, providing higher quality to the user experience. The AR+ logo, he says, is a suggestion open for discussion, and a first step toward standards for AR.
AR developers can download the AR+ logo by visiting Total Immersion's site where they can also find guidelines for the logo's use.
Discuss
Several articles have come out recently criticizing Google for their recent policy, removing the Windows Operating System from their currently approved list of OSes that employees can use. One might expect that I would be against this move, considering the recent criticism I’ve given of Google employees deleting their Facebook accounts. I think this situation is different though, and I actually support it. Of all companies, I think Google is most prepared to make such a move and I think we’ll see a lot of innovation come as a result.
Companies Have Tried This Before
Several years ago I worked for BackCountry.com as an engineer. While there, our engineering department had a policy, making Linux and open source tools the default, while only allowing other operating systems (including Mac OS X) on an as-needed basis. We found this saved us a ton of money, and, as engineers it made sense because we were able to completely alter the systems we were writing on as we needed. It also made it so we could completely duplicate the server environments we were developing for on our local machines if we needed to.
We decided while there to take this to another level, and while I was there we started to push this policy throughout the company. We got a lot of push back, and it took us, as engineers and developers, to help out the rest of the company as they adapted. We started using Zimbra for e-mail, Bugzilla for bug tracking, and everything we could do we tried to do with open source tools. We saved a ton of money.
There was one fatal flaw to this, though. Where we were not an engineering-specific company (our bottom line was probably our buyers, who secured really good deals on outdoor gear, or even our customer support team, where we preached “We use the gear we sell”), we simply did not have enough resources to keep this going and be able to support it all whenever the company had a need that open source software could not solve. The main benefit to open source software (which security is only a minor benefit) is that, as developers, you can get in and alter the software if it doesn’t meet your needs. Then the code you altered could be shared with the rest of the world and others that also might have that need. That’s a great benefit.
However, not having resources to constantly do that whenever there is a need means you’re always going to have weaknesses in your systems, and those systems are likely to fail. I think that became a problem for BackCountry.com, because I heard that shortly after I left they were forced back into a closed-source, Microsoft-backed Exchange system, which probably means back to Windows for most employees. The simple fact is Microsoft, when it comes to Enterprise systems, can’t be beat. Exchange is by far the best e-mail system there is out there. Linux pales in comparison, and has always had problems competing against Exchange and the desktop. Not to mention general user experience and understanding of the OS by a mass audience. Most companies don’t have the time or money to devote resources towards replacing these COTS systems.
Why Google is Axing Windows
So one would think that making a similar move by Google may be prone to similar risks. Google’s hacker culture I’m sure has developers begging to be on Linux or Mac OS X, and higher executives wondering how they’re going to get along without Windows. There’s one thing different about Google though that completely sets them apart from any other company out there that might try such a thing: Google’s base is developers. Not only that, but Google has a vested interest in creating an operating system that works.
My guess is that Google is using “security” as a front to put a jab up against Microsoft, hoping others might try to make the same decision. Google is hoping that the bad stigma Microsoft has had in the past regarding security (Windows 7 is actually pretty secure) might dwell in the minds of others considering similar decisions. However, I bet the real reason is that this will force all employees, in this hacker culture, to truly understand what they’re missing when there are no Exchange servers, when there are no Active Directory databases, and when Executives can’t use the operating system or tools all their colleagues at other companies are using.
Google wants their employees to hurt from this. When you make a hacker culture that actually has a monetary benefit (Chrome OS) to fix problems that arise as a result, problems get solved, and people stop being lazy. I expect that as Google makes this move we’re going to see a much higher rate of bug fixes and User Experience enhancements on Chrome OS and Linux, and possibly even Android. I expect better user experiences on the server. I expect finally an e-mail solution that works up to par with Microsoft Exchange, and a directory services solution that works up to par with Active Directory.
I argue Google Axing Windows as a company is a good thing! I hope it’s only temporary, or on an “as needed” basis so employees that need to create Windows clients that interact and drivers that work together with Google devices, that the company can still understand and work with such devices. Yet at the same time I think doing everything they can to challenge employees to truly understand the weaknesses their new operating systems and web services provide will challenge the thousands of developers working them to produce solutions. While I think security is a lame excuse and PR ploy for Google to remove Windows from their network architecture, I still think this is one of the best things the company has done in a long time.
Google’s move here could be the best thing to happen to Linux, and the open source enterprise world, in a long, long time.
RegularGeek post: Survey Says: Developers Think Testing Is Failing http://bit.ly/d8z7VX
[Direct Link]Apple to Flurry: Kiss Our Data Good-bye http://bit.ly/d8zE5l
Much of the great mobile data we analyze comes from analytics firms, among them Flurry, which entices developers to use tracking codes within mobile applications that its software captures and sends back to the company. Flurry then uses the data to provide detailed information on, for example, which handset makers have the most market share or what platforms have the most apps. Based on comments made by Steve Jobs last night at the All Things D conference, however, when it comes to the iPhone, that practice is about to undergo a major change.
When asked about handset analytics, Jobs specifically mentioned Flurry by name:
“Some company called Flurry had data on devices that we were using on our campus — new devices. They were getting this info by getting developers to put software in their apps that sent info back to this company! So we went through the roof. It’s violating our privacy policies, and it’s p***ing us off! So we said we’re only going to allow analytics that don’t give our device info — only for the purpose of advertising.”
The situation has Jobs upset for at least two reasons: First, companies like Flurry (and developers that use Flurry’s services) don’t have to wait around at a bar to find out about the next super-secret iPhone — by collecting device data through installed software, analytics firms can glean Apple’s future hardware and software plans in advance. Secondly, there’s no simple opt-out method for consumers, who may not even realize that their device-specific data is going to a third-party.
Flurry’s VP of marketing, Peter Farago, told Om via email that that Flurry is changing practices in light of Apple’s position — and to some degree, has done so prior to Jobs calling out Flurry last night. Indeed, on May 13, Flurry announced a Privacy First Initiative “aimed at increasing consumer privacy standards in mobile application data collection and targeting.” Clear opt-out messages, non-granular geographic data and data deletion are among the new privacy activities that will take effect this summer.
That may help stem Jobs’ anger for now, but it wouldn’t surprise me if Apple continues to further clamp down on third-party analytics activities. Flurry says that it will comply with Apple’s wishes and no longer provide aggregated usage statistics, but if that’s the case, it will lose one of the most valuable pieces of its current offerings.
Related GigaOM Pro content (sub req’d):
How iAd and the iPad Will Change Mobile Marketing
Disclosure: The GigaOM iPhone application uses Flurry to track application usage metrics.

Two months after its launch, there are no shortage of RSS readers for the iPad. But I’ve tried most of them, and still find them all lacking in some way. In fact, the one I’m still using the most is not optimized for the iPad at all — Reeder. As we noted back in March, with the 2.0 launch, Reeder finally brought an excellent RSS app to the iPhone. And shortly, it will be bringing an iPad-native experience as well.
The app was submitted to the App Store for approval three days ago, the developers noted on Twitter. That means we should expect it any day now. It will be a separate app from the iPhone version and will carry a new, slightly higher price, $4.99. But judging from the pictures below, and one stellar preview from MacStories, it will be worth it.
Below, find some screenshots of what it will look like. One nice touch is that sets of feeds can be drilled into using the pinch gesture, similar to the way you unbundle pictures in the iPad’s photo app. It’s also worth noting that if you have a blog and want one of the big favicons to appear, you should put a 120×120 apple-touch-icon.png file on your server.








Electric Cloud, a leading provider of software production management solutions, completed a survey of software development professionals (developers, testers and managers). One of the major leads in the results was “the majority of software bugs are attributed to poor testing procedures or infrastructure limitations, not design problems.” Obviously, I was going to keep reading. Granted, the quote was a little overstated, but there were some very interesting points in the survey results.
So, what did they find? First, “Fifty-eight percent of respondents pointed to problems in the testing process or infrastructure as the cause of their last major bug found in delivered or deployed software.” Now, let me translate that. A major defect is typically a problem in software that causes the application to crash, save data in an inappropriate state or display information in an appropriate manner. As a general rule, if a major defect is found after the application is deployed into production, it is a failing of the testing process. When I say testing process, I am spreading blame around. Developers did not have appropriate unit tests, QA did not have the appropriate test plans and the management team likely did not have the appropriate people or hardware allocated to the project. Essentially, major defects are the fault of the entire team and should not be occurring.
There were two pieces of very bad news for the software industry. Only 12 percent of software development organizations are using fully automated test systems. This is a damn shame, but there are also some good reasons for this. Automating user interface (UI) testing is extremely hard, time consuming and extremely fragile. So, it does not surprise me that fully automated testing is rare. Thankfully, less than 10 percent are only doing manual testing and no automation. Another major issue was that 53 percent of respondents said their testing is limited by compute resources. Given how cheap hardware is anymore, this should not be an issue. However, limitations of the hardware environment continues to plague the industry. I know people want to buy a decent server for testing, but sometimes a simple desktop machine that costs less than $500 will suffice, especially if it is a UI automation machine. I understand we all need to control costs, but the money on hardware is nothing compared to the amount of man hours needed for manual testing.
People not in software development may wonder why all of this talk about defects and automated testing matters. Well, the survey had a really good point about this. 56 percent estimated that their last significant software bug resulted in an average of $250,000 in lost revenue and 20 developer hours to correct. Lost revenue is always a big deal, but do not underestimate the cost of developer hours. Let’s assume that the cost of a developer is $800 per day or $100 per hour on average. 20 developer hours equates to $2000, which does not seem like a big deal. However, there is also the testing time required, about 30% of development time, adding about $600. There is also management time required which for defect resolution is fairly high. Add in another 25% of the development time for each management person involved, typically a development manager, a QA manager and a VP/Director level person. The management team will typically cost more as well, about $125 per hour, which adds $725 per person, or $2175. There are also the operational costs of deploying the corrected application into a QA environment and the production environment. This is about 3 hours at the same rate as a developer, so we add another $1800. This brings our total cost, $2000 + $600 + $2175 + $1800, to $6575 plus all of the stress that goes with the fire drill. There is also the potential opportunity cost of delaying other projects because of the people required to fix this defect, but opportunity cost is hard to quantify without a specific context. All of this may not seem like a lot of money, but for a smaller departmental budget it could be very important. Also, compare the $6575 to the cost of the desktop PC that could have been used for automated tests that find that defect. This defect could have cost 10X the cost of the hardware.
A lot of people are probably agreeing with me in terms of the costs, but disagreeing with my simple “just add testing” idea. Typically, the problem is that basic automated testing is not easy. Good automated testing is hard. Automated web testing is even harder. However, automated testing is not expensive. There are a bunch of free tools available that many of your developers are probably familiar with. Some of the tools are useful for unit testing, others help with testing with a database and there are others that help with web testing. Another issue that keeps getting raised is that it is too hard to get 100% test coverage. I am not the first person to say this, but do not even try to get 100% test coverage. Developers do need a significant level of unit test coverage, probably above 90%, but acceptance tests and integration tests do not need that much test coverage. One of the best parts of testing is that once a defect is found, you can write tests for it. That way you ensure that if all of your tests pass, you have fixed the defect and it should not recur in the future.
So, there is nothing really stopping you from a solid testing plan. If people and opinions get in the way, then you can point to some of the information in the survey. If management says that writing automated tests will cost too much, ask them if it costs more than $250,000.
Related posts:
(A note from Harry: Here’s a “letter to the editor” from Kevin Miller, CEO of Scotland-based RunRev. His company makes a HyperCard-like development platform; one of its investors is Mike Markkula, who funded the creation of the Apple II and later served as Apple’s CEO.)
In recent weeks, there has been much speculation about the impact and overall effect that Apple’s decision to change the rules regarding its iPhone SDK has had on the software developer community. Given the growing debate, I feel I need to outline our thoughts and observations on the matter.
Apple’s move prevents developers from using a range of software development tools, among them RunRev. We believe that Apple would benefit greatly from an iPhone/iPad only development tool that is more productive than Objective-C, JavaScript, or C++ and honors the HyperCard legacy still present on today’s Mac platform. Although we’ve made our case directly to Steve Jobs, including offering a native solution that performs perfectly and supports 100% of the device APIs, he rejected the proposal and made it clear that he has no interest in allowing revMobile on the iPhone or iPad. It seems, however, that this ban is on a case by case basis, as games developed on the Unity gaming platform are still being accepted and sold in the App Store. In this case what’s good for the goose, doesn’t necessarily apply to the gander.
While there is a financial cost there is also a principle at stake here for us, as well as for many of our customers. Polling amongst our Mac-orientated user base suggests that many developers are outraged by Apple’s decision and do not believe that they should be dictated to regarding their choice of development tools. We are grateful for the support of our customers, who rather than switch development tools plan to switch platforms and develop applications on alternate platforms such as Google’s Android.
Apple is the standard by which many of us measure innovation and ingenuity. RunRev has always enjoyed a good relationship with Apple based partly on the fact that Mike Markkula is one of our investors, and our historical ties to the HyperCard legacy. In a recent article, we learned Hollywood media giants Time Warner and NBC Universal have informed Apple that “retooling themselves to support the iPad would be ‘expensive and not worth it’ citing the popularity of Flash on the web.” They are not alone. We may be a small voice, but the weight of our customers’ opinion can only add to the crescendo of views that believes Apple is doing a huge injustice to its loyal developer user base. We believe that Apple must listen to all the voices, not just the big players.
We are strong believers in Apple. Our hope is that during the upcoming WWDC Steve Jobs will listen to the smaller voices of Apple’s loyal developer community, and return the company to its open approach–fostering a plethora of innovation and ingenuity we have come to expect from the Apple community.
Turn by Turn Augmented Vision Coming Soon with Wikitude Drive http://bit.ly/cgDSdf
Augmented reality (AR) developers Mobilizy, makers of the Wikitude World Browser, are close to releasing their latest creation, Wikitude Drive, an app that combines AR technology with turn-by-turn driving directions. The app works by taking live video of the road captured by a smartphone mounted on the dashboard or windshield and super imposing the direction data onto it. The company announced late last week that beta testing with 2,000 volunteers had been concluded, signaling that the company may be close to publicly launching the app on the Android marketplace.
As the company points out, taking your eyes off the road to look at a 3D map on your GPS device can be dangerous. With Wikitude Drive's directions (provided by Navteq) placed onto a live video of the road, the dangers of glancing at an illustrated map are reduced. To get an idea of how the app works, check out the video below released by Mobilizy last week showing some road tests.
As you can see, the app quite skillfully places the directions on the live video of the road, but the size of the path and arrow still leaves a large blind area for drivers. You can also see the directions jitter a bit when the car is in a tunnel, a problem with the GPS signal weakening in the tunnel. What this also tells us is that the app is not yet able to take advantage of the live video feed as much as it would like to.
Due to platform limitations, the app cannot digest the live video and map the directions more accurately to the road. While it does a fair job of guessing where the road is, the ability to process the road and run it through image recognition technology would make it much more accurate. Mobilizy says they are working on an iPhone version of the app as well - a platform that will soon support live video processing with an upcoming OS update.
With Wikitude Drive, users can quickly switch to a traditional elevated 3D map view by touching the screen, but which perspective will drivers use? Depending on the price of the app, Android users may download the app for the basic directions to save some money. The other common concern with these apps is what happens when a phone call comes in while providing directions? Can users easily answer and call and continue to receive directions? Or will they be interrupted and forced to later relaunch the application?
Either way, Wikitude Drive seems like a great use of augmented reality and a logical next step for the platform. Mobilizy says it plans to integrate the Wikitude World Browser, and it's database full of points-of-interest, into Wikitude Drive in the future. Combine this type of direction capability with GM's idea for an augmented reality windshield and a fascinating future of cars with heads-up-displays could be just around the corner.
Discussnew open source project lets developers put contextual menu on right click in google maps, pretty cool http://bit.ly/apKEBI
[Direct Link]RT @atul: Apple: Steve Jobs Is Your Mommy, Daddy and Personal Savior - Advertising Age - The Media Guy http://bit.ly/aSdwFB tip @techmeme $AAPL

Is the new Digg the Twitter of News? (Scripting News). http://r2.ly/zcft
Liz Gannes has written an intriguing story about the new version of Digg coming soon, saying it aspires to be "The Twitter of News." This is very interesting. The Twitter of News?
- Dave WinerThe Twitter of News?
- Rob Dianasolid piece by @dwiner on Twitter/news/Digg correlation. http://www.scripting.com/stories/2010/05/28/theTwitterOfNews.html
- Om MalikRT @patrickodowd: RT: @om: solid piece by @davewiner on Twitter/news/Digg correlation. http://www.scripting.com/stories/2010/05/28/theTwitterOfNews.html
- Om Malik
If you’re using Twitter’s Search API via the api.twitter.com sub-domain, you have a week to switch to search.twitter.com, according to a post from Twitter’s Taylor Singletary. The endpoint being removed has not been officially supported by Twitter, though other supported calls use the same sub-domain.
Singletary writes:
The only endpoint you should be using for search operations in the Twitter
API today is http://search.twitter.com — it doesn’t require user
authentication or OAuth — simply identify yourself with a user-agent that
is unique to your application.
It’s important to note that Twitter is not taking away any functionality from its API. It is merely making clear what could be potentially confusing to developers. Twitter’s main API for authenticated commands, such as fetching timeline data and creating new tweets, will continue to be operational on api.twitter.com. The change only affects developers using the search API from the unsupported sub-domain. The confusion could have come when Twitter moved to a versioned API, because the search API is not versioned.
Singletary also had some good developer tips for making the best use of the Search API:
Many users of the Search API are better served by using the Streaming API.
If you use the search API to track the tweets of specific users, hashtags,
or simple keyword queries, it is highly recommended that you use the
Streaming API instead.You shouldn’t issue the same request to the search API more frequently than
once every 20 seconds — if you issue the same query more frequently than
that, you’re in danger of getting blacklisted. In addition, if you find
yourself repeating the same query frequently, be sure and make use of the
since_id parameter on subsequent requests — without it, you put undue
stress on the search infrastructure and will also be in danger of
blacklisting.
The Search API is bound to put significant stress on Twitter’s servers. That’s likely the biggest reason for having search on its own sub-domain. Engineers are able to have search servers tuned to its specific needs, without needing to support the authenticated calls.
Sponsored by
As the market for location-based services continues to grow, it's becoming increasingly important for these companies to have access to correct location data. Placecast helps developers to ensure that their location databases are accurate. The service also allows developers to exchange data with other services that might have slightly different data sets. After looking at the data sets of its 200 customers, Placecast found that the average fault rate for the location data sets is about 8%. Location databases that include a high proportion of user-generated content, however, had fault rates that were often as high as 40%.
Placecast wants to be the "Rosetta Stone" for developers that work with location data. The company's MatchAPI helps developers to create a single database with location data, even if they are getting their data from multiple sources and have to interact with multiple data sources. The MatchAPI disambiguates and deduplicates addresses by identifying all the different ways that users (and other databases) can identify an address. This is especially important if an app allows users to create their own locations. If you are using a location-based service that often shows multiple names for the same venue (often with slight variations), you know how distracting these errors can be.

Currently, there is no single location database with perfectly accurate information that all of the different vendors can access - and that's probably a good thing, as it allows developers to use the databases that suit their needs best. If Placecast's data is correct, however, an error rate that ranges from 8% to 40% is simply too high for consumer products that want to guide people to the right location in the real world.
DiscussMillions of Incorrect Listings Plague Location-Based Services
- Sarah PerezMillions of Incorrect Listings Plague Location-Based Services
- ryanRead more of this story at Slashdot.
We are hard at work on MonoDroid -- Mono for Android -- and we have created a survey that will help us prioritize our tooling story and our binding story.
If you are interested in Monodroid and in participating on the beta program, please fill out our Monodroid survey.
Here is what you can expect from Mono on Android:
We are still debating a few things like:
We are currently leaning towards using VS2008/2010 for Windows during the beta and later MonoDevelop on Linux/Mac.
Like we did with MonoTouch, we will bring developers into the preview in batches of 150 developers, please enter enough information on the "comments" section if you want to be in the early batches.
RT @chippy: RT @intel: iPhone to Netbook porting resources available for developers @Intel AppUp Center store http://intel.ly/kXuU
[Direct Link]
Twitter To Begin Wrapping All Links With Official t.co Link Shortener
- Chuck Reynolds