Just a little Cooqy

Besides a few tweaks here and there, Cooqy has been pretty much running itself since my daughter was born last fall. This year, my free time away from Cooqy was used to provide consulting services, helping clients build Rich Internet Applications with OpenLaszlo.

During a recent period of vacationing and brooding, I have stumbled my way into a new idea for an online venture that I feel is worthwhile to pursue.

Cooqy continues to grow without requiring any of my time, other than to respond to the occasional server alert when Cooqy’s hosting provider does some maintenance that requires me to restart the server software. (Funny enough, this always seems to happen when I am out of town in an area with limited Internet access.) Help requests from users are few and far between, thanks to the reliability of the software.

I will be placing Cooqy on full autopilot now, so I can focus on building my next new thing I have named Qrowd. Cooqy was built from the ground up to not require much of my involvement anyway…my goal was to have an online service that just generates checks to my mailbox.

Cooqy reached a point recently where the server was receiving almost 10 million hits a month. It will be interesting to see how much further Cooqy can grow without my day-to-day involvement. I am hoping I can get Qrowd launched before Cooqy needs to be taken off of autopilot.

I will continue to keep a watchful eye over Cooqy. I am certainly not abandoning anything! I’m just the kind of crazy person who feels the need to have yet another ball to juggle in the air. Or are those machetes?

Wow, what a year so far! In early January, I started doing some consulting on the side to create Rich Internet Applications using OpenLaszlo. What started with one client has mushroomed into a dozen clients, growing to the point where I had to hire some part-time help. The projects have ranged from more e-commerce widgets like Cooqy’s, to a multi-protocol instant messaging widget and a video editing application. RIA’s are very much in vogue, as witnessed by Microsoft’s Silverlight and Sun’s JavaFX wanting to steal some market and mind share away from Flash.

I haven’t had time to attend to Cooqy until recently. Fortunately, Cooqy pretty much runs itself and keeps growing without too many hiccups. Cooqy has received a new website design and some overdue defect fixes to the widgets during the last couple of weeks. Creating the new HTML website design was another experience in multi-browser compatibility hell. I sure do hope I never have to work with traditional HTML/JSP/.NET website development ever again.

Sharp-eyed eBay sellers may have noticed recent changes to Cooqy’s pricing structure first introduced in late January. The pricing structure is intended to provide a throttle of the widgets’ usage on eBay.com web pages, because eBay doesn’t allow Cooqy to generate any revenue from eBay’s own web pages. I want Cooqy’s widgets to be used by enough eBay sellers on eBay web pages for marketing purposes, but not so much that the bandwidth and server expenses make it uneconomical. As it is today, the widgets can be used free of charge on eBay’s web pages for sellers with less than 500 items in inventory. The pricing structure may change again, depending on if Cooqy continues to remain profitable as it grows.

As fun as consulting on various OpenLaszlo projects has been, growing a consulting business wasn’t in my plans. I’m currently in brainstorming mode, searching for a new business idea to grab my passion. There are few restrictions on the new types of web applications that can be developed with RIA technology like OpenLaszlo. The challenge is to find an itch that everyone needs scratched.

I was surprised to read this TechCrunch story about an upgrade to SmugMug’s interface this morning, since I have SmugMug’s CEO Don MacAskill’s blog in one of my Protopage RSS readers and would have expected to read about it there first. I’ve been watching SmugMug due to my interest in Amazon’s S3 and EC2 web services.

SmugMug’s user interface for browsing photos is now done w/ AJAX. You can read about the changes and benefits (according to them) here. I decided to give it a test drive for myself here.

I was initially very impressed with the improvements. As I’ve stated before, AJAX makes a nice incremental improvement for legacy HTML web applications. I would go so far as to say SmugMug is a prime candidate for AJAX, since it is really not a web application needing RIA technology, but rather a traditional static hyperlinked website.

After playing around with the new interface for a few minutes, I started noticing that something wasn’t quite right…the performance was much slower than I would have anticipated for something as simple as navigating around photos. I really noticed this when I switched to a different browser…there was a noticeable lag when SmugMug’s photo navigator loaded.

I decided to take a peek under the covers using a sniffer program called HTTPWatch for IE. After clearing the browser’s cache again and reloading the photo navigation page, here is what I captured (click to enlarge):

What I have highlighted in blue is all the Yahoo’s YUI AJAX libraries and SmugMug’s own code that drives the presentation of the photo navigator. The approximate size of all these libraries is about 330KB. Add in the graphic elements and HTML itself is about another 50KB. So, without the photos that you want to view, SmugMug’s photo navigator is almost 400KB of code and graphic elements. Jeez!

For comparison, Cooqy’s eBay search engine weighed in at around 280KB the last time I measured. The amount of functionality within Cooqy is equivalent to a full-blown desktop application…Cooqy is immensely more functional than just a few fancy hovering semi-transparent navigation tools. My point is that SmugMug’s 400KB runtime is way out of whack for the delivered functionality.

I found it amusing to read about the tribulations the SmugMug team had in making the AJAX technology work across different browsers. I am always pleased to never have to worry about cross-browser compatibility issues when developing with OpenLaszlo.

I was a bit puzzled to read about their efforts made to preserve the browser forward/back button behaviors, as if the AJAX toolkits caused problems. Cooqy makes use of the browser buttons to navigate search results from the OpenLaszlo-generated Flash UI. Took me all of 5 minutes to get this operational, again with cross-browser support.

Not to take anything away from the website improvements SmugMug have accomplished, but is the penalty of a 400KB runtime and what appears to have been a long and intensive development effort really worth a couple of fancy floating semi-transparent navigation widgets?

I believe that just the photo navigation tool within SmugMug would have had much better results written as a small OpenLaszlo application. I believe the download size for such an OpenLaszlo-powered navigation tool would be less than 100KB. I also estimate that this tool could have been built in a few hours by one person, with the end result supporting all browsers.

If you would like to see an OpenLaszlo photo browser application for Flickr photos, take a look at the LZPix demo here.

Flash object embedding is a topic that is well documented on the web. This article does a nice run-down of the different techniques. Instead of re-hashing other people’s work in embedding Flash objects into web pages, I am concerning this article with the pragmatic considerations involved when distributing OpenLaszlo-generated Flash widgets. I say OpenLaszlo-generated, because I am focused on building “mini-applications” in widget form, not simple animated Flash ads. The distribution of widgets throughout the web means that you don’t have control over the target web page, unlike if you just wanted to embed a widget onto your own web page exclusively.

OpenLaszlo Flash widgets can be placed onto web pages with a number of different techniques. Selecting the appropriate technique depends on a number of factors:

1. Will the widget be used on web pages without Javascript support, like MySpace profiles?
2. Will it be likely that new parameters will be added in the future to extend widget functionality?
3. How important is it to avoid the extra click required in Internet Explorer to activate the widget?
4. What should happen when the user either doesn’t have Flash installed or has the wrong version?
5. Does compliance with web standards matter to you or your customers?

The easiest way to embed an OpenLaszlo widget is with the EMBED HTML tag. The tag is a nonstandard tag that is generally frowned upon by professional Flash developers. The upside is that no Javascript is involved and it is therefore most compatible with many social network web pages, including MySpace. The downside is that it requires an extra mouse click to activate the widget in Internet Explorer only.

Another approach is to use the EMBED HTML tag in combination with an OBJECT tag. This is just an incremental improvement to the naked EMBED tag that results in satisfying web standards compliance. The only functional improvement is that a message can be displayed to the user when the Flash player needs to be upgraded/activated.

OpenLaszlo itself provides an embed mechanism that relies on a Javascript library they provide. My recommendation, is that if you don’t want to use the EMBED tag method, skip OpenLaszlo’s Javascript library and use a third-party library SWFObject, which seems to be superior in terms of functionality and compatibility.

SWFObject is a 3rd-party Flash embed Javascript library that I currently use on Cooqy’s website. The primary functional benefit is that it resolves the issue of the extra click necessary in Internet Explorer to activate the widget. It also has the benefits of handling missing/outdated Flash players and of being standards-compliant across many browsers.

So far, neither the EMBED tag nor the SWFObject address the possibility of needing to add new parameters to the widget to support extending the widget’s functionality in the future. Once a user embeds the widget into a target web page, both of these techniques don’t allow the widget provider to alter the embed code. To accomplish this, it is possible to perform server-side scripted embeds via Javascript.

Widgetbox is a slick platform that allows widget developers to distribute their widgets very effectively and easily. For end users, Widgetbox is a nice widget directory that also makes it easy to grab new widgets for web pages. Widgetbox also provides end users with “widget panels” for grouping widgets on their target web page. You can try out Cooqy’s widgets via Widgetbox here.

As comprehensive as Widgetbox is, there are some downfalls. The biggest is that end users must sign up for a Widgetbox account to grab widgets. To the widget developer, this represents an undesirable barrier that may turn away some people. Another downside is that Widgetbox forces the creation of a “widget panel” on the target web page. This prevents end users from having total control over the placement of the widget on target web pages. This may be acceptable for some widgets, but e-commerce widgets like Cooqy’s require that the end user have total control over the placement and integration of the widget on the target web page.

For widget developers, however, Widgetbox provides insight into how to create dynamically-inserted widgets onto target web pages. Instead of providing end users with HTML code snippets containing an EMBED or SWFObject commands, provide end users with a single Javascript statement that is a script to dynamically construct the widget embedding. You can get a sense of this from looking at Widgetbox’s Javascript embed file here.

The only advantage gained by this approach is a layer of abstraction that allows freedom to alter the final embed statement after the widget is initially distributed. As a widget developer, if you are creating widgets of meaningful complexity it can be impossible to think of all the possible parameters and behaviors you will want the widget to be able to handle in the future. For example, Cooqy’s widgets are currently distributed via the simple EMBED tag. Had I known ahead of time, I would have liked to have provided an object id on the EMBED statement, to make it possible to identify the widget on the web page. This would allow the widget to invoke Javascript commands from Flash to communicate with itself…perhaps to dynamically resize the dimensions of the widget on the page.

Along with the flexibility of the technique comes the burden of keeping track of the widget’s parameters for all users of the widget. This necessitates some type of “widget wizard” for end users to configure the widget’s parameters. These parameters would then be stored on the server and associated with the specific user via a unique identifier that would accompany the Javascript statement.

The amount of infrastructure in the form of a widget configuration tool and database tables to store each user’s widget configuration is nontrivial, but as Widgetbox demonstrates this technique provides widget developers with the ultimate flexibility to modify and extend widget behaviors to all current customers using their widgets. A big downside, however, is that the technique won’t work for social networks like MySpace that disable Javascript on profile pages.

Widget embed techniques are very much a mixed bag. No single technique supports all needs. Cooqy’s widgets are currently distributed with the simple EMBED tag, that provides compatibility across most target web pages, including MySpace profiles. The extra click to activate the widget in Internet Explorer is my way of nudging people to use Firefox instead…

The New Year has been a busy one for me, thanks to several new customers asking me to provide custom OpenLaszlo-powered Flash widget development. It has been exciting working with other new ventures in their early stages. I find it noteworthy that all my new customers are utilizing widgets for e-commerce purposes. E-commerce 2.0 via widgets seems to be gaining momentum!

I’ve been meaning to write this post since December about flaws in MyBlogLog’s widget…I suppose it is good that I didn’t, because I may have upset their recent $10MM acquisition by Yahoo!

Just about any web application developed in HTML/AJAX is inherently insecure. HTML has been bastardized since the dot-com boom to be an application development technology, which it never was intended to be. HTML is fine for presenting and navigating static text, as originally designed. But when you ask a standards-based thin-client technology to perform the task of running as an application technology, you are asking for trouble with regards to performance and security. This makes AJAX, riding on the back of HTML, an insecure foundation upon which to try to build Rich Internet Applications (RIA’s).

The crux of the problem comes down to scripting. Any browser-based web application can be fooled by scripting. Scripting allows hackers (or as I call myself when doing this, an experimenter) to create automated programs that perform the actions that a human performs within a browser, like editing text and clicking buttons.

eBay is always a favorite target for scripted bots. Every automated eBay snipe program is a scripted bot, b/c eBay has granted only one company that I know about (Unwired Buyer) access to their bidding API. eBay has taken immense efforts at surely a great expense to try to defeat scripted bots (notice how eBay’s URLs are now randomly generated when doing searches…but then please be sure to use Cooqy for all your eBay shopping!).

Fundamentally, eBay and other companies running HTML web applications and HTML widgets like MyBlogLog will never succeed in preventing scripted bot attacks. The standards-based browser and availability of browser source code like the Gecko engine give hackers (or experimenters) the power to emulate humans very effectively. Steps are continually being taken to defeat scripted bots (like those annoyingly hard-to-read letter and number images you are forced to re-enter to login to many websites)…but the problem will never entirely go away…that is the bane of trying to build a skyscraper on top of a fundamentally weak foundation originally intended to support a house.

MyBlogLog’s implementation is particularly amateurish with regards to security and the ability to spoof the reader roll widget. This TechCrunch article doesn’t begin to scratch the surface of the vulnerability. The article talks about the ease of spamming a single reader roll widget…but it is just as easy to spam all reader rolls on every blog containing the widget! That makes the MyBlogLog reader roll a fantastic advertising vehicle to drive traffic! Here’s how easy it is for hackers (or experimenters) to advertise on everybody’s MyBlogLog reader roll widget:

The first step is to create a MyBlogLog account and upload an avatar with the image to appear on every MyBlogLog widget. On the account’s home page, view the page source. MyBlogLog creates a “SID” (a unique identifier) for every user. The SID can be quickly spotted by looking at the avatar’s filename (hosted on Amazon’s S3 service). It will look like “2006113016423040″. It is simply a date and time that the MyBlogLog account was created.

The way the widget works, is that when a user signs into MyBlogLog, the SID is stored in a browser cookie. The widget simply reads the cookie and displays the avatar. This is done via a simple PHP REST-style transaction the widget performs when it loads (mybloglog.com/tr/urltrk.php). The PHP transaction parameters identifies the widget’s owner (another SID) and the viewer’s SID. So simply invoking a PHP REST transaction with the SID and the target widget’s SID is all that is needed to make an image appear at the top of the widget.

MyBlogLog makes it incredibly easy to mine everyone’s SID…all someone has to do is scrape the HTML contents of their member directory and parse out everyone’s SID. I can’t emphasize how stupid it is for MyBlogLog to have an entire directory of members and communities in a static HTML structure…this is inviting all types of attacks. Actually, I’ll go so far to say it is F@#king Stupid. I can’t believe Yahoo! coughed up $10MM for amateurs with only 35,000 member accounts, but oh well. Buyer beware.

Creating the scripted bot is trivially easy (well, for a programmer at least)…just write a program to iterate through the online member directory, read each member’s HTML page to extract the SID, then invoke the PHP REST transaction with your account’s SID…presto, you have a very effective marketing tool to get noticed on several thousand blogs. It won’t be long until teenagers have fun placing porno pics on everyone’s blogs. This works very well on blogs with slow traffic, where the image is likely to stay at the top of the widget for weeks on end. The majority of blogs don’t have much traffic, after all.

Unfortunately, MyBlogLog is not an isolated example. Web 2.0 companies rushing to build widgets and web applications with HTML and AJAX technology without considering security are all ripe for attacks. Even when security is taken into consideration, there is always the possibility of scripted bot attacks.

This is one reason why Cooqy’s widgets and RIA search engine are built with Flash as the runtime engine. As far as I know, there is no effective scripting mechanism that can be used to create script bots for Flash widgets and web applications. The recent announcement of Adobe to open-source portions of the Flash player may unfortunately open up the door to this in the future, however. But for now at least, Flash provides a fundamentally more secure and hack-proof (or experimentation-proof) foundation for building widgets and web apps.

OpenLaszlo-powered Flash applications are, I believe, the fastest and safest way to bring new widgets and web applications to market.

Cooqy is developed with OpenLaszlo, a wonderful open-source tool for developing Rich Internet Applications (RIA’s). OpenLaszlo v3.3.1 has proven to be a very stable and productive tool. I consider it to be the finest development tool I have used in my 20+ years of software development.

OpenLaszlo has truly made software development fun for me again. I was really getting burned out by the tedious JSP/.NET approaches to static website development. AJAX tools are just an incremental improvement, suitable for enterprises with an existing investment in legacy technologies. For the first time, with OpenLaszlo I could develop applications that worked well on multiple platforms and browsers with little trouble. So much of web development is just tedious…OpenLaszlo effectively hides all the complexities of web-based development, allowing developers to focus almost exclusively on building the value-add functionality. This is a tremendous productivity boost!

OpenLaszlo 4 (aka “Legals”) was announced with great fanfare earlier this year, with the promise of offering a DHTML runtime. OpenLaszlo from the beginning was intended to emit multiple runtimes, besides just Flash. The selection of DHTML (and later Java Micro Edition) should have been building upon the already solid Flash runtime foundation. But alas, the OpenLaszlo development team has made decisions that I feel are leading to potential disaster.

The OL4 development team decided to totally rewrite the runtime compiler from the ground-up. This means that the Flash runtime generator was gutted and replaced. So instead of taking a very stable foundation and carefully snapping in DHTML support, the OL4 team decided to throw out the baby with the bath water and start from scratch.

All-or-nothing decisions in software development are almost never made…the risk is just too high to accept, especially with a compiler-based product like OpenLaszlo with lots of existing projects already in the field. The trouble with compiler-based products is that although you may be able to write enough test cases to cover the syntactic differences between the new vs. old versions of the compiler, you will *never* be able to weed out the semantic differences (the behaviors of code interacting together at runtime).

Throughout the year, I have been downloading the OL4 preview releases, in addition to the first beta release made just before Christmas. Every time, none of my existing code has worked with the Flash runtime, due to the rewritten Flash runtime compiler. I end up having to delete my existing code and stitching it back together line-by-line to find what isn’t compatible with the OL4 release. It has been improving with each release, but still none of my code is entirely working in the Flash mode. I fear that all OL3 legacy code will experience similar trouble, as confirmed by this thread tonight. DHTML runtime generation is even worse. I finally got fed up and posted this thread on the OpenLaszlo forum, which received the attention of OpenLaszlo’s Founder & CTO David Temkin.

I expected the DHTML runtime to be problematic for some time, but the loss of the stable Flash runtime is an expected red flag. They might as well call it a new product, because I feel that the likelihood of legacy OL3 code ever running on OL4 is slim to none.

DHTML is an interesting beast itself. A huge issue is that when runtime errors occur, you get the normal browser popup box displaying the error. Problem is, the error relates to a compiler-generated source file. So when it gives the line number with the error, you have no hope of finding the cause of the problem, unless you are lucky and can identify the little snippet of Javascript code displayed in the popup. I tried the Firebug extension for Firefox as recommended, but never could find a way to troubleshoot Javascript runtime errors with the DHTML output. Maybe someone who knows how can inform me.

I know that OL4 will continue to improve…but at what cost? How do you measure the cost of new developers who download OL4 expecting Flash/DHTML panacea, only to find that legacy components don’t function? How do you measure the impact to existing developers who expected to have a rock-solid Flash foundation that has benefited from years of development? I predict that OL3 will flourish and that OL4 will be stagnant for a long time to come…until robustness in the Flash runtime is proven again.

With OL4, I feel I have been watching a train wreck in slow motion all year long. Or maybe it’s more like watching someone you love do something stupid with their life.

Looks like I will have to develop a traditional HTML website for Cooqy in the weeks ahead, instead of my plan to convert the existing Flash website to DHTML…darn it.

This article posted over at R/WW caught my attention. Actually, this is something I’ve been pondering since earlier this year when I added certain social features in Cooqy: Is their really anything such as “Social Shopping”?

If you define “Social Shopping” in the context of other social websites like MySpace, then there would need to be elements of meeting new people for the purpose of shopping together. Based on this definition, I would disagree that there is such an activity as shopping socially. I mean really, have you ever grabbed a stranger off the street and asked them to go shopping with you to the mall?

Even the discovery phase of shopping is unlikely to be a social experience, in the sense of getting useful information about what to buy from strangers. The social circle from which you are likely to receive tips about things you might like to buy is probably limited to your existing circle of family and friends. External input likely only comes from marketing sources (ads on the Internet , TV, print).

The analysis phase of shopping is the one point where you are most likely to seek input from strangers, in the form of product reviews and seller reviews. But does this fall under the moniker of “Social Shopping”. I don’t believe so.

As I mentioned, I have experimented with different forms of social shopping tools within Cooqy, like tagging. Turns out that none of these features were ever used by anyone. Thinking that my ideas and/or designs were flawed, the features were redesigned several times. Still nobody used them. The final incarnation, the Message Forum feature (located in the bottom layer of tabs), was meant to allow eBay shoppers to get help and exchange messages with others. Nada. Instead, I now use the mechanism as a system admin tool, to communicate information about major changes to Cooqy’s users.

I conclude that the term “Social Shopping” is an oxymoron…a meaningless combination of words that doesn’t represent reality. Moreover, the business opportunity for incorporating social features into the shopping experience is probably limited to leveraging product and seller reviews. The companies profiled in the R/WW post probably have a tough row to hoe ahead.

I’ve only been blogging a couple of weeks now, but I am already a huge fan of MyBlogLog. You could say that I started blogging only after observing the MyBlogLog widget on TechCrunch. Blogging in isolation is rather pointless. MyBlogLog’s “reader widget” makes you feel you are not blogging alone, by providing tangible proof that someone cares enough to visit your blog postings. It’s also fun from the point of view of leaving my mark on other people’s blogs…my own “Kilroy Was Here” or “Sign of Zorro” mark. Both bloggers and readers can benefit.

MyBlogLog has the two key ingredients for success nowadays…social components and widgets. According to this post, they are experiencing accelerated growth across all metrics. The widget growth in particular is what caught my eye…widgets are a key component to viral adoption on the Internet. It’s funny that MyBlogLog is reporting a doubling of widget growth month-over-month, because that is similar to Cooqy’s growth for the last three months as well. Coincidence? Or is there a mathematical formula in action that describes widget propagation?

One metric that wasn’t reported is their total number of registered users. Since they have an online database of user accounts in the form of their HTML directory, I quickly wrote a program to count all the users. As of today, I counted 29,450 user accounts.

Sometimes when a company creates their product/service and releases it to the world, the utility of their creation cannot be fully appreciated. I believe this is the case with MyBlogLog, in the sense that their name and focus seems to be exclusively on bloggers. I feel that MyBlogLog is more like a socialization engine for any and all web pages. Sort of like a MySpace without walls. [Speaking of MySpace, I have added a MyBlogLog widget to Cooqy’s MySpace profile here: http://www.myspace.com/cooqy]

As good as MyBlogLog is, there are some issues that I find with their service. First, their name doesn’t really describe the power of their creation (they are looking for a new domain name, thank goodness). Second, as this post suggests, spamming is an interesting challenge. Third, their widget and website design is functional, but not what you would call eye candy [BTW: is it just me, or does the widget frequently chop off lower case descenders? I have reported this issue to their tech support.]. Finally, their overall technology design is open to all sorts of attacks…I’ll post more about this later, as it relates to widgets in general.

I must admit that I am contemplating creating my own version of MyBlogLog, perhaps for eBay and/or for the masses. I feel that in its current form, MyBlogLog is not capitalizing on what I perceive to be the overall opportunity. With that being said, imitation is the highest form of flattery. Hats off to MyBlogLog for giving us something new and useful!

I just read a report that eBay has closed their China website, finally throwing in the towel and admitting defeat in what will surely become the world’s largest Internet market. Is this my 2007 Prediction #3 starting to come true?

Anyway you slice it, this is very bad news for eBay and Meg. You knew with the recent shakeups within the highest levels of eBay that something bad was cooking internally. You can’t do much worse than failing to monetize a huge growth opportunity. eBay was not even charging Chinese sellers any listing fees!

American Internet companies should pay close attention to eBay’s failure. I believe eBay made a huge mistake by not partnering with a strong local Chinese company first before entering the market. Instead, they probably thought their strong “brand” would see them through to success in another foreign market for them.

eBay is a company struggling to find new growth opportunities. You can’t do much worse than failing with your cash cow business division in a new high-growth market opportunity. I am highly skeptical that Skype will ever amount to much in the way of revenue for eBay. Their move to start charging customers to call phones again probably won’t pan out as they hope. Certainly Vonage is already showing that VOIP is no slam dunk with regards to making money.

Usually a large company will go down the paths of acquisition and new market penetration to find sources of revenue growth. eBay has reached dead ends on both counts. They have also pissed off a lot of eBay Store owners by raising fees again earlier this year.

Add to this malaise the ever-present eBay scammers looking to cheat innocent shoppers at every opportunity. Check out this eBay Powerseller who ruined a lot of people’s Christmas this year.

What’s next? Even though eBay is a strong company with a strong brand in many large markets, Wall Street rewards growth. Public companies that don’t continue to grow get crucified, as eBay’s stock has this year. I believe eBay will start looking to merge with another struggling company, perhaps Yahoo!, as both try to renew their growth opportunities together.

Being a rampant piano-player and former synthesizer junkie back in the 80’s, I love the power of sound. Sound effects are frequently embedded within applications, like the familiar Windows startup theme, or the jingle of a new e-mail arrival. Used properly, sound effects can enhance the efficiency of using a computer, similar to how sounds help a fighter pilot effectively manage a large amount of information. Used improperly, sound effects can confuse, distract, and annoy to no end.

Flash provides easy mechanisms for embedding sound into applications. For those web developers accustomed to developing in HTML, the ability to create sound can be a tempting toy to explore. I can imagine that there is a generation of web developers who have never developed thick client applications for Microsoft Windows, Apple’s OS’s, or IBM’s OS/2 (how’s that for a blast from the past?) who would become enthralled at the prospect of using cool sound effects in their web app.

Resist that urge, young grasshopper.

Flash has gained a terrible, yet well-deserved, reputation for annoyance. The worst offenses are:

1. Having a Flash animation play before an HTML website loads, along with the requisite “Skip” button. Here’s a hint for developers: if you create something that you think needs to be skipped, don’t create it in the first place!
2. Flash music that accompanies a website…darn you, I’m trying to hear my favorite artist playing on Pandora!
3. UI design with a lot of eye candy but doesn’t follow standards, causing hide-and-seek searches for functionality.

Cooqy widgets only use a single sound effect: a mouse click. The website home page (read my earlier post on why Cooqy’s homepage is currently in Flash) does splurge and play a jingly sound when launching Cooqy or the Widget Wizard, but that’s it. I’ve used two sound effects in total.

Why just a mouse click sound?

Well, the mouse click sound serves a very functional use, in that it provides feedback that the mouse click event was successful. To make Cooqy usable in a widget form factor, some of the controls have been made smaller than would otherwise be done. That makes it sometimes hard to hit a button on the first try, so the mouse click sound provides feedback when user actions are registered.

More importantly, as a widget it is important that Cooqy doesn’t interfere with other sounds that may be more important to the user…background music playing through Pandora, for example.

I have experimented with a few additional sounds in the past, such as a “zip” sound when the search options or category tree are animated to open and close. The result has never been satisfactory, no matter how cool the sound effects may be. The cool factor works the first couple of times, but quickly diminishes. More sounds always seem to cheapen the experience and wear out the ears.

I think this is because after so many years of using the Internet, silent surfing has become the norm (minus some background music or podcast). We expect web pages to be silent, therefore anything running within the browser is expected to be silent. When we stumble onto a page that generates noise, it’s like an electric shock!

Another reason, is that sound on the Internet to this point is primarily associated with the dreaded Flash ads. Surfers have formed a Pavlovian association between sounds on the Internet with undesirable Flash advertising.

I’ll call this Yeager’s Posit #1 on Web Apps: Internet users expect to surf in silence. Music players, video players, and related tools are expected to generate sound and are oftentimes running in the background while surfing. RIAs, widgets, and other web apps should use a bare minimum of sound, primarily to confirm user inputs are registered.