This new version of the popular browser from the Mozilla team includes a host of slick features, including a smart location bar that finds sites by keyword rather than just URL, easy bookmarking with tags, platform native look-and-feel, support for color profiles in images, private browsing (and other security enhancements), location-aware browsing, downloadable fonts, and even better support for Web standards.

But for me the most exciting improvement is the performance enhancements. Firefox 3.5 uses less memory, renders pages faster, and takes advantage of the new TraceMonkey JavaScript engine to provide a massive speed boost to Web 2.0 sites.

With IE 8 and Safari 4, we have now been blessed with three major new browser releases in 2009. That’s three reasons to stop using IE 6.

Earlier this year, I asked a class of college students to rate their familiarity with about 15 social media networks that have gained traction in the past year or two. It was an unscientific, five-minute survey to gauge their awareness.

Some answers were expected: Most students were very familiar with YouTube, blogs and Flickr. And Facebook, of course, is huge.

Other findings were more insightful: Twitter awareness was very low. RSS was barely on the radar. Social bookmarking knowledge was virtually nonexistent. Wiki familiarity wasn’t much better.

My informal survey is consistent with a recent study that only 22 percent of 18- to 24-year-olds use Twitter. In contrast, 99 percent of young adults have a social network profile.

This doesn’t mean that young adults will never use Twitter, wikis and other tools. Instead, the findings challenge the convenient assumption that adding social media to your marketing efforts will instantly create a connection with younger audiences. 

In a post to the journalism community, Amy Gahran emphasized the importance of knowing your audience and where they already lurk:

It’s always easier to join a conversation than start one from scratch. This is especially true in social media. Whoever you want to connect with online, chances are that some of the most influential people in those groups already have their favorite social media hangouts: Facebook groups or fan pages, community sites, Twitter hashtags, LinkedIn groups, and more.

Social media remains a great way to engage, connect and converse – assuming your messages, networks and audiences are properly matched.

As I blogged about last December, online savings tool SmartyPig, in conjunction with Iowa-based West Bank, lets users save money online for specific financial goals such as weddings, trips, college funding, cars and presents.

“In one of the worst financial markets in years, SmartyPig has managed to grow largely through word of mouth of its customers. It harnesses the microblogging site Twitter to communicate with users, and it has a fan page on Facebook,” says co-founder Jon Gaskell in an interview published in San Antonio Express-News.

Will SmartyPig stay on course with its meteoric deposit growth? Or will it see a run-off of deposits as users reach their goals?

In an email to NetBanker blogger Jim Burene, Jon Gaskell replied, “Fifteen months after launch, our data suggests that a vast majority of our customers are staying focused on their predetermined goals and the deposits are “CD-like” in nature.”

As I wrote back in December, if bankers didn’t have enough to worry about, this example should be another wake up call about the huge fight for deposits moving online, and the increasing impact of social media on banking.

With a run-rate indicating $500 million in deposits by the end of this year, 15-month-old SmartyPig appears to be living up to its virtual piggy-bank name.

We have processes in place to prevent untested source code from making it into a demo environment.  So why don’t we do the same for CSS?  Or JavaScript?  Or JSP pages, and so on?  The root cause is the lackadaisical attitude toward the view layer or client executed scripts.  We don’t consider it to be “code.”  I am trying to change that mind set.  My philosophy is If It’s In The Code Base, Then It IS Code…

That philosophy was derived from a real world experience, which I encountered in my early days as a software engineer.  As part of an Agile development team, we had periodic iteration meetings, in this case every week.  During these iteration meetings, we would demonstrated each Task completed in an environment that was separate from the local development environments.  At the end of business the day before an iteration meeting, the most current build was pushed out into the demonstration environment.  While the developers could continue to work, the only tasks considered complete were the ones that were in the code base at the time that the build was pushed.  If it didn’t make it into the source repository, then it wasn’t completed for the current iteration.

It so happens in this instance that a certain web page was not formatted as expected.  The developer noticed this, and quickly made the needed change the morning of the iteration meeting.  And because no “code” was changed, they were able to get it snuck into the demonstration build.  Unfortunately, while the change did indeed correct the formatting error, it also broke several other aspects of the application.  In this case it duplicated a form element that was being bound by Spring into a Form Backing Object.  The property editor was not able to convert the array of values that it was now getting into a single value that the FBO required, and so the functionality was broken.  And it broke right in the middle of the client demonstration…

As the Lead Developer on this project, it was my responsibility to prevent stuff like this.  I take full blame for letting the change in.  But I was sucked into the By the way, I moved some stuff around in the JSP.  But don’t worry, I didn’t change any code.” trap.  Now I know better.  These days when I hear someone tell me that they didn’t change code (just some CSS), or try and sneak a “cosmetic only” change into a build or release, I simply remind them that CSS (or JSPs, or HTML, or JavaScript, etc) is code, and needs to be treated as such.

If It’s In The Code Base, Then It IS Code…  Keeping this mindset can prevent a lot of unexpected application failures during demonstration (or even worse, the product release).  Don’t fall into the trap of thinking that it isn’t.

For the past 4 months, Flo TV, a subsidiary of Qualcomm, has been patiently waiting for analog TV signals to go dark, as Qualcomm spent $500 million to acquire those analog frequencies once used broadcasters.  Flo TV will be using the old frequencies to broadcast live TV signals directly to mobile phone customers.  Around 20 broadcasters are providing content to Flo TV, including ESPN, NBC, CBS, MSNBC and MTV to name a few.  Current market penetration has already given Flo TV 60 million potential customers.  Of course, with most new technology rollouts, there is a catch or two.  First, it’s only available to Verizon or AT&T customers.  Second, only nine models of phones are currently able to receive the signals.

To increase mobile device compatibility, Flo TV president, Bill Stone, told The Business Insider that his company is working on a phone add-on accessory.  This potentially would take advantage of the iPhone 3.0 accessory API and bring Flo TV signals to Apple’s new iPhone 3GS.  In a related interview with Beet.tv, Stone says plans are also in the works to bring Flo TV signals to automobiles equipped with rear-seat video screens.

Remember all those predictions of video content being delivered live or on-demand, anywhere, anytime on any device?  It looks like we’re just about there.

We’re all sick of seeing emails that we didn’t ever express interest in receiving. A company somehow got our email address and we will forever get emails about finance options, or winning the lottery…or worse. Most marketing companies want to see their email marketing accomplish something; bring in a sales lead or give the customer some sort of special offer that will in turn benefit the company.

A great way to get a better return on your marketing investment is to invest in the right customers, one good way to make sure of that is to have opt-in and unsubscribe options. After a customer signs up to receive emails, the best practice is to send out an opt-in email which informs the customer that he or she has signed up to receive emails from your company and to confirm that subscription. Also, be sure there is an unsubscribe link on each email so that a user can opt-out of receiving emails if they are no longer interested. This will ensure everyone on your list truly does want to receive email materials from your company.

However, don’t go overboard with the marketing. Infusionsoft also states that a study has shown that “65% of men and 56% of women define spam as ‘email from a company that I have done business with that comes too often.” In other words, even if the content is relevant, the customers can perceive it as spam if they are bombard with campaigns or information.

In short, to keep your email investment as profitable as possible, a good rule of thumb is to keep the email lists current and only send materials that keep your customers interested but without overwhelming them. 

While Immersive Media’s concept isn’t much of a departure from your typical first-person platform game, the effect of using true video can immediately be felt.  This is obviously meant as just a proof of concept and not even a full demo, but the combination of 360-video with timeline-based game play is something that definitely deserves note.  Too often the use of video is limited to flat static rectangles in a Flash environment.

Last year’s surge inPaperVision 2.0 production (and, I guess we should acknowledge away3D) allowed for much more interesting use of video.  Still, the implementation generally resembled a 3D object onto which a movie was being projected. A step forward, indeed, but the speed with which the application of the technologies became mainstays on sites like FWA proved that interest in web treatments that fluted the traditions of basic interaction was ravenous (examples 1,2) .  As always, marketing strategy, user experience, end-user hardware, and yes, even budget are some of the largest elements to consider before agencies can create these types of web experiences.  All the more reason to take pause when examples like this push the envelope.

See their fullscreen demos of the technology here.

The first two mistakes arise when the team leader misunderstand the difference between estimated hours and estimated “bigness”. The last mistake arises when the team leader gets too granular in the estimation process. Remember, in planning poker, we estimate at both the story level and the task level. When estimating stories, we estimate in “bigness”, or relative effort. A story that is estimated at a 5 is slightly more than twice the effort of a story estimated at a 2. Each story can then be broken further down into tasks. Tasks are estimated in ideal hours. That is, a task that is estimated as an 8 will take approximately 8 man hours to complete. (OK, technically an 8 means that it will take more than 5 hours but less than 13, but that is a topic for a different blog…)

Mistake #1
The team leader presents the team with a series of user stories, and instructs the team to estimate each story in ideal man hours instead of bigness. This is usually accompanied with some explanation of how the project is rather small and doesn’t warrant breaking it down into tasks. The problem here is that by definition user stories are high level descriptions of what the user wants the application to do. Applying hours to a high level story is wrong because it is trying to apply a granular estimation unit to a broad estimation item. Estimating user stories in hours gives you a false sense of accuracy because you are applying a precise measurable unit (hours) to a level that is not as precise. What if you wanted to know how far it is from Fargo to Minneapolis?  If I told you that it was approximately 235 miles from Fargo to Minneapolis, that would be a decent estimate. Of course, there are many different possible starting points in Fargo, and even more possible ending points in Minneapolis. It could actually be 220 miles, or it could end up being 250 miles. But 235 is still an accurate estimate because we don’t expect it to be that precise when measuring in miles. Now what if I told you that it was 14,889,600 inches from Fargo to Minneapolis. 14,889,600 inches is equal to 235 miles. But because I am presenting it in a much more precise measurement, it creates an illusion of preciseness. Think of it this way - the more broad the estimation item, the more broad the estimation unit. And who ever told you that there is such a thing as a project that is too small to be broken down into tasks? They were lying to you.

Mistake #2
The team correctly estimates the user stories in “bigness,” but then the team leader takes a predetermined budget and allocates a proportion of the budget to each user story based on the bigness estimate. This time we usually hear some excuse about how the client only had X to spend, and we have to fit the project into that budget. OK, I understand that clients often work on fixed budgets, especially in the current economy. But trying to force an application into a smaller budget tends to create, well, crappy applications. And crappy applications end up costing the client more in the end, between support cost and lost opportunity cost. Instead of forcing the entire application into the predetermined budget, what we should do is use the estimates to figure out how much the client can afford. By prioritizing the user stories with the client, the project manager should be able to give them a reasonable estimate of what can be done for the budget given. This also helps the client plan for future budgets, giving them a reasonable estimate of what the entire project will cost.

Mistake #3
The team correctly estimates the user stories in “bigness.” And the team lead correctly moves on to breaking the stories down into tasks and estimating each task in ideal man hours. Unfortunately, they do it for every single user story. Hove you ever been in an estimation meeting that takes eight hours? I have. There isn’t enough pizza and Mt Dew in the world to make meetings like that fun. Breaking every singe user story down into tasks and estimating the tasks may be fine for small projects (like two or three user stories), but for larger projects, we are creating more work than we need to. And again, it gives us an illusion of a level of preciseness that doesn’t exist. Instead, after the user stories are estimated, pick a representative sample of stories and break them down into tasks that can be estimated into hours. If you have 25 or so user stories that range in “bigness” estimates from 2 to 20, pick four or five of the 8’s and 13’s and estimate them. And then take the story with the smallest hours per bigness ratio, and apply that ratio to the non-estimated tasks. Add the hours for all of the tasks together (estimated and non-estimated), and you have the lower range of your estimate. Then take the story with the largest hours per “bigness” ratio, and apply that ratio to the non-estimated tasks. Again, add the hours for all of the tasks together, and you have the higher range of your estimate. Remember, when providing estimates at the initial estimating session we are trying to be accurate, not precise. A ranged estimate of overall work is more accurate. I can honestly say that when estimating projects this way, I cannot remember a time when the final project cost has not fallen somewhere within the initial ranged estimate. Talk about accuracy!

Estimation tools, like planning poker, are only as good as the way that they are used. Look out for these three common mistakes, and your estimation sessions will yield much better results!

Apple is a company that knows how to sell quality. They have never postured to be a price leader, and it is seldom that price is their primary weapon. However, having a a new 3G S model gives this innovation company a good reason to offer the “old” model at $99 without compromising their brand premise. That’s half the price of the new Palm Pre, and it takes some of the enticement out of Blackberry’s current two-for-one offer. In addition, the old 3G is really a new iPhone when you pair it with the new 3.0 iPhone software that will be available in about 10 days.

Most of the business press seems to be gaga about the newest iPhone. However, the real story is that Apple is just as innovative as a marketing company as they are as a products company. The $99 iPhone 3G demonstrates that clearly.