Six entries in "Software"
Stats tracking using Mint and Google Analytics
Wednesday April 23, 2008 - 28 months ago
Posted by James Ellis / Filed under Code, Software, Web
Most every web project we push out the door uses both Mint and Google Analytics (GA) for site stats/tracking/analytics.
Analytics software has come a long way since the days of server log file analysis programs such as Webalizer. Modern jobs like Mint and GA take a different approach, using client-side Javascript to grab more in-depth user data. The client-side approach better differentiates between humans and robots, and captures the return visits of users browsing pages from their browser’s cache. And though it was once a concern, nowadays only weirdos are browsing without Javascript support. They don’t count.
Mint
http://www.haveamint.com
Unless you’re juggling metrics at an ad agency, Mint will generally get the job done, delivering a well organized and easy to digest overview of site activity. A single page/interface reveals your latest visits, referrers, pages, searches and more.
The user experience is very different from GA. Mint doesn’t dig particularly deep, but it’s fast and fun. The interface is chock full of Javascript/AJAX flippity-do’s.
Mint is a self-hosted app and requires a server running both PHP and MySQL — basic gear. Mint collects data via Javascript, then drops it into a MySQL database using a bit of PHP. Mint runs quick, provides real-time stats, and is easy to install.
Cost: $30 per site license (per domain). Cheap.
The Visits module:

The User Agents module displaying Screen Resolutions. Notice how many users are still at 1024×768, even on a site generally trafficked by design/tech folks.

The User Agents module displaying Browsers. Sadly, 10% are still using IE6.

The User Agents module displaying Flash Player installs. 94% on 9, amazing. Thanks Youtube…

Favorite feature: Mint provides an RSS feed of your site’s newest unique referrers. Plug this into Google Reader (or whatever you like) and you can keep up every new website, blog, link-list, etc. that directs traffic to your site. Beyond the obvious utility, this tool can also reveal web theft in progress.
Mint Demo:
http://www.haveamint.com/about/demo
Mint Feature Highlights:
http://www.haveamint.com/about/feature_highlights
Google Analytics
http://www.google.com/analytics
Upon acquiring Urchin’s tracking software in 2005, Google re-released the software as Google Analytics, free of charge. Given Urchin’s popularity and the new non-price, GA was everywhere seemingly overnight.
GA does fifty-eleven things; it certainly out-features Mint. You’ll find charts, graphs, tables and maps everywhere, for every possible metric. It’s great for analyzing very specific trends. You could spend hours digging through it all.
You can manage any number (or at least a whole bunch) of domains within a single GA/Google account. Not everyone manages a pile of domains, but for those that do, this is a big deal.
If you’re prepping a stats report for a client, check out the export-to-PDF or XML feature. GA produces very attractive PDFs which you can then take into Illustrator and chop up as needed. This includes charts, and it’s all vector.
Unlike Mint, GA allows for the tracking of Flash events, and of file downloads (PDFs, mp3s, etc.) See here and here.
GA even offers a Content Overlay view, allowing you to browse your site with GA sprinkling stats all over the page. You can see which links are getting the most clicks. Check it:
(If you’re into this sort of data visualization, check out Crazy Egg. That’s their whole deal.)
Another interesting feature is the Map Overlay. By analyzing user IP addresses, GA is able to map which countries visitors are coming from.
Why run both?
The biggest difference between Mint and GA is that GA is always a day behind. GA only updates account data once every 24 hours. (Real-time analytics would introduce massive data-processing overhead for Google.) Mint, however, always displays up to the minute data.
Analyzing trends is great, but there are many instances where you want real-time stats. If you can’t ride the refresh button the day you get linked up on Digg, NYTimes, etc., you’ll have missed the fun.
Questions? Comments? Contact James via email - .
Free Code: Simple-Auth by Athletics
Saturday March 29, 2008 - 29 months ago
Posted by James Ellis / Filed under Code, Software
Today, a free snippet of PHP code. Simple-Auth by Athletics makes password-protecting web documents easy, and looks pro at the same time. After being asked about it a few times, we figured we’d share.
We regularly use this code to password-protect client work — design comps, wireframes, prototypes, dev sites, etc. Clients love password-protecting things, and for good reason: you never know what’s going to end up on some blog, message board, Digg, whatever. This is certainly a concern with some high profile clients, but even if no one in the world (other than you and your client) cares about what you’re up to, everyone enjoys a little professionalism and peace of mind.
For most, password-protecting a document or directory involves entering your web host’s control panel, clicking into the password-protect tool, navigating to the directory in question, and creating a new username:password combo. The control panel software will then generate an invisible .htaccess file and drop it into the directory. This whole process is somewhat cumbersome, isn’t very portable, and most people have no idea how .htaccess files work.
Simple-Auth makes it relatively easy to password protect any PHP file. It’s a snap to drop in once you get a sense of how it works. It’s easily configured and modified. You don’t need to mess with a hosting control panel. No hidden .htaccess files. And it’s more attractive than the standard http authentication dialogue box.
Demo
In the demo below we password-protected a very simple HTML document. Instead of using the .html file extension, we use .php. We do this because we need to add one line of PHP code at the start of the file in order to activate the Simple-Auth PHP brain. Now when visitors attempt to access this document, they will be required to provide an authenticating passcode before viewing.
View the demo here. The passcode is “passcode”.
Simple, right?
Download
Download the code along with a sample document. (ZIP, 5k)
Customizing
The simple-auth-by-athletics.php file is organized relatively well. Take a look around and you’ll see where you can set the passcode, modify commonly used bits of HTML, and dig into the HTML/CSS. A basic familiarity with code-noodlery required.
Enjoy.
Comments? Contact James via email - .
Testing & debugging Flash apps in the browser
Friday March 28, 2008 - 29 months ago
Posted by James Ellis / Filed under Code, Software, Web
I’ve always found debugging Flash applications to be somewhat challenging. The Flash IDE offers a decent debugger complete with download simulation, bandwidth profiling, etc., but this is only available when you build and preview a SWF directly in the Flash IDE. If you want to do any debugging outside this environment, you’re going to need to look beyond the tools Adobe provides.
Given that web users generally consume Flash apps within the browser via the Flash Player plugin, it only makes sense to test in this environment.
Many Flash apps are totally dependent on dynamically generated XML (i.e. Flash apps tied to content management systems). In such scenarios – which the majority of our Flash projects fall into – you really need the ability test & debug in the browser. By running Flash in the browser, we get to test on top of our full local development stack (Apache, MySQL and PHP on OS X).
Also, many Flash apps require some sort of javascript integration. This might just be having Flash content rendered using swfobject, or using SWF Address for deep-linking, or doing some more complicated communication between Flash and HTML page elements. Obviously, you’ll need a browser around to test this sort of gear.
There are a couple of tools we use to get under the hood while running Flash in a browser.
FlashTracer
This free Firefox extension created by Alessandro Crugnola allows you to view all output generated by Flash’s trace() function in a sidebar window.
An example screenshot:
FlashTracer does require the use of the Flash Debug Player, which you can download here:
http://www.adobe.com/support/flashplayer/downloads.html
FlashTracer works by displaying the Debug Player’s log. This log consists of trace() command output from any running Flash app. This means that FlashTracer will display output from Flash running in any browser, not just Firefox.
Strangely, on OS X the Debug Player seems to be overwritten by other applications from time to time. Perhaps application installers overwrite the Debug Player with the regular player — I’m not sure. For this reason, it’s a good idea to keep the Debug Player installer handy.
Also, keep in mind that the Debug Player does introduce some performance issues, especially when you’re tracing off fifty-eleven things per frame.
Charles Web Debugging Proxy
Charles does all sorts of things, but for me, it’s most useful as a bandwidth throttling tool. Charles acts as a man-in-the-middle and simulates various bandwidth situations by introducing network latency even when accessing content on local machines.
If you’ve ever developed a Flash application, you know that Flash behaves differently when (pre)loading content from a local machine vs. a real internet connection. It’s important to test how Flash behaves in real-world scenarios, including slower connections. Charles makes it easy to do so.
Of course, Charles does fifty-eleven other things as well. A more complete (and complicated-sounding) description from the Charles website:
Charles is an HTTP proxy / HTTP monitor / Reverse Proxy that enables a developer to view all of the HTTP traffic between their machine and the Internet. This includes requests, responses and the HTTP headers (which contain the cookies and caching information).
Charles simulates modem speeds by effectively throttling your bandwidth and introducing latency, so that you can experience an entire website as a modem user might (bandwidth simulator).
Charles is especially useful for Adobe Flash developers as you can view the contents of LoadVariables, LoadMovie and XML loads.
Charles is shareware. You can test it out for free. $50 for a single user license.
Other options
There are alternative approaches. Most hardcore AS folks will tell you to stay away from trace() altogether and use something like the LuminicBox.Log API (english translation). However, for quite a few developers, trace() gets the job done, especially since it’s possible to view its output within the browser.
Comments? Contact James via email - .
Thoughts on bandwidth and Amazon S3
Tuesday February 19, 2008 - 30 months ago
Posted by James Ellis / Filed under Code, Software, Web
This past September we relaunched the Dangerbird Records website. Since then the site has experienced a massive increase in traffic, with the new videos section being particularly popular. In addition to regular web traffic, we’re noticing a significant number of users embedding Dangerbird videos on MySpace/blogs/etc. As a result, site bandwidth has been growing exponentially — a good problem, but a problem nonetheless.
Here’s an example video:
That’s a 27MB video file. If ten thousand people check it out, that’s roughly 270GB of bandwidth.
Here’s another example:
At 17 minutes in length, this video is a whopping 124MB. If 10k visitors consume it, we’re way up to 1.2TB of bandwidth. With high-performance bandwidth costing about $1/GB, you can see how costs can quickly get out of control for a popular website.
Fortunately, we can move this high-demand content elsewhere. The services meeting this type of demand are generally referred to as content delivery networks.
Traditionally, CDN’s were designed for performance and marketed to the enterprise crowd. For example, Apple uses Akamai to serve up images and videos for apple.com. Akamai hosts copies of Apple’s assets on high-performance servers all around the globe. When a user requests a file, they receive the file from whatever server is closest to their geographic location. Akamai helps Apple maintain global performance at web-scale demand, but it’s not exactly cheap.
There haven’t always been a lot of options in economy content delivery. (You might try to exploit Dreamhost’s ridiculous 5TB/month @ $6/month plan, but Dreamhost isn’t exactly performance hosting.) However, in the last few years we’ve seen a lot of activity in the economy content delivery space as web sites/hosts have struggled to keep pace with increasing demand for content such as videos/images. Surprisingly, what appears to be the best offering in this market comes from Amazon — best known as the world’s largest online retailer, not web infrastructure provider.
In March 2006, Amazon launched S3, or Simple Storage Service. S3 is a web service providing websites with unlimited storage and unlimited bandwidth. You simply pay for you what you use and at minimal cost (Storage: $0.15/GB/month, Bandwidth/transfer: $0.10/GB).
S3 is both an online storage service and content delivery network economy hosting/bandwidth provider. You could use S3 to backup your entire computer, or you could use S3 to deliver fifty-eleven-gazillion copies of a single animated GIF. Both tasks fall outside the scope of capability of a normal web host. Meaning, you can generally only host so much data, and any single server will eventually choke upon receiving too many concurrent requests.
Update: Our colleague Larry Ludwig of Empowering Media & HostCube – our primary hosting/IT provider – emailed to comment that Amazon isn’t currently set up as a proper content delivery network (See Wikipedia’s definition here), as S3 content is delivered from one of two locations – either out of Amazon’s D.C. data center, or from Europe – rather than being replicated across various nodes and serving users by geographic location. It’s important to make this distinction between CDN’s and S3’s economy storage/bandwidth/hosting.
A few example use-cases for you:
- An individual might use S3 to maintain a private, off-site backup of important documents, using minimal storage, and near-zero bandwidth, costing pennies per month.
- Dangerbird Records can use S3 to deliver an infinite amount of video content at minimal cost.
- A gigantic site like SmugMug (a photo site similar to Flickr) could use S3 to store a staggering amount user image data (in fact, SmugMug does use S3, saving them roughly $1M/year, crazy!)
It’s all a very interesting application of the distributed, on-demand, grid/cloud-computing, redundant, failure-tolerant, scalable (and many other words) systems architecture that we’ve arrived at in the post-Google world. Amazon sorted out the fundamentals of S3 in developing their own infrastructure for amazon.com. Now in true software-culture form, they have opened up their otherwise proprietary infrastructure to the world at minimal cost.
Since moving all video content to S3, we’ve seen Dangerbird’s normal bandwidth stabilize. Also, requests and transfer of video content will no longer being tying up server resources; now the server can focus on rendering page requests. And Dangerbird will save money.
Getting started with S3
If you can use FTP software, you can handle S3. It’s quite simple. First, set up an account. Then connect to S3 using some sort of client. The latest version of Transmit now provides support for S3, and there’s even a Firefox plug-in interface. Also, you might want to look into JungleDisk if you’re interested in off-site backup.
Various thoughts on Flash, past and present.
Friday January 4, 2008 - 32 months ago
Posted by James Ellis / Filed under Code, Software, Web
I’m not sure you can be a Flash designer/developer here in 2008 and not have mixed feelings about Flash websites. Understand: I have been working with Flash for ten years. I like Flash a lot. It does one million things. But I think everyone has realized that all-Flash, all-the-time, makes no sense. Specifically, I’m talking about “Flash-world” websites, or websites that load all site content into a single Flash shell.
Before web browsers were any good, before CSS worked well, before AJAX Javascript noodlery, before blogs and RSS hit, before Google ruled the earth, a lot of people thought Flash might be the answer to everything. During this time (1999-2005ish) the Flash-world approach dominated among designers and ad agencies. Unlike HTML, Flash offered designers exacting control over the visual experience. In particular, designers were lured by Flash’s ability to render fonts. Ad agencies were seduced simply by Flash’s ability to render the Photoshop “boner-boards” they sell to clients. (This is why ad agencies are still obsessed with Flash.)
However, even as early as 2000, Flash-world sites were receiving a lot of criticism, particularly regarding usability (See: Flash: 99% Bad). By giving designers total control, Flash-world sites broke nearly every rule of the web; each Flash-world site introduced new, idiosyncratic conventions for navigation, scrolling, etc. The mess of the whole slowed the emergence of many of today’s established web design conventions. Now, many realize that Flash is best used to solve specific problems, not provide complete site architecture.
Consider YouTube. The entire site is predicated on the delivery of video using Flash, yet the site itself is HTML/CSS. At this point, the silliness of rolling all of YouTube into one giant Flash-world should be obvious to all.
MTV.com is another example. In 2006 mtv.com went Flash-world. As a designer and developer, I found the site interesting and certainly an impressive technical achievement. However, the user experience was frustrating. MTV realized their error and within nine months ditched the Flash-world and returned to an HTML/CSS architecture. Flash is still used to deliver video content, but the site browsing experience is no longer hijacked by a Flash-world.
Flash Development
Beyond the issue of appropriateness, Flash applications (especially Flash-worlds) are challenging development projects. It’s not that Actionscript is complicated. (It’s pretty easy to pick up for those familiar with Java, Javascript or any OO language.) Flash development is challenging because it is ridiculously tedious. By providing designers and developers with a blank canvas and complete control, Flash development becomes an exercise in reinventing wheels. Want to go to another “page” in your Flash-world? You’re going to need to write Model, View and Controller classes. Want a form in Flash? You’ll need to instantiate a bunch of objects, add event listening, and tie the whole form to a bunch of logic for error checking, data handling, etc. Even the basic task of loading an image (a no-brainer with HTML in a browser) is a challenge in Flash — you’ll need instantiate an image loading class, set up some logic, and bother with event handling. It’s all a lot of work.
Flash-world development is essentially the reinvention of the browser, inside a plugin, running in a browser. It’s silly. Browsers already do such a good job of managing state, rendering content and working with forms. Why start over?
To be profitable in the Flash-world business, you have to develop and maintain a library of frameworks and classes to deal with all the wheels you need to reinvent. Historically, Flash development had a closed, proprietary, arms-race quality to it, with studios maintaining proprietary arsenals of frameworks and classes. The closed nature of Flash development was due to a number of factors:
- Unlike plain-text HTML and CSS, SWF files are compiled runtimes and there is no way to “View Source” or otherwise look under the hood of Flash apps. This keeps the code mysterious, prevents the development community (from beginner to pro) from examining and learning from the work of others, and generally excludes Flash from the web’s traditional culture of knowledge-sharing. Two notes: Flash decompilers do exist, but such tools have only been used by the extremely motivated, and again, one doesn’t need a decompiler to view HTML or CSS source. Second, View Source functionality is now possible in Flash, but this still remains a developer-elected option rather than a default.
- Flash started as a designer’s tool. Designers, being a bit more guarded with their intellectual property, do not have the same culture of sharing that you find in the software world.
- Actionscript did not become (in the eyes of developers) a real programming language until the introduction of Actionscript 2 with Flash 7 (2004). AS2, being styled directly from Java, was designed to appeal to Java developers. Having AS embraced by the software world injected a lot of software culture in Flash, and helped pull Flash out of its designer-centric origins.
There is now a growing open source Flash community, but you still don’t find near the scope of community as you do around big-timers like PHP or (relatively) new technologies like Ruby on Rails.
Flex
Adobe has tried to remedy Flash’s customization-over-convention problem with the introduction of Flex, a development framework for creating Flash apps, or what Adobe refers to as Rich Internet Applications (RIAs). Summary: it’s like HTML for Flash. There are certainly some very interesting things about Flex, but again, it all seems like a very complicated way of doing things that are already possible with HTML/CSS/Javascript in browsers.
Flex doesn’t seem to have much of a future, and it’s difficult to find anyone excited about it. These days the web is full of rich internet apps (i.e., Gmail, Basecamp, Flickr), but I couldn’t name a single app built using Flex. I went to Adobe’s Flex Showcase but didn’t find any particularly rich internet experiences — mostly the same confusing, idiosyncratic Flash interfaces quick to hijack the browser’s scrollbar and disable the scroll wheel (in OS X anyway).
More coming
Over the years we have certainly built our share of Flash-world sites, though we have been moving away from this type of work. Rather, we try and only use Flash when appropriate – video/audio players, widgets, games, slideshows, etc. But now, for the first time in nearly a year, we are tackling a proper Flash-world project — an experience-oriented site with a few particular demands that only a Flash-world can accommodate.
Flash-worlds have come a long way since our last contact. Developers have been working to bring Flash apps in line with standard web conventions, most notably deep-linking and browser back/forward-button support.
We are using Asual’s open-source library, SWFAddress, to provide our Flash-world with state management and deep-linking. SWFAddress plugs in nicely in front of our otherwise proprietary MVC architecture. It has been great to find a solid open-source, cross-browser solution that solves one of the most glaring Flash-world usability issues. We first discovered SWFAddress after visiting Burst Labs, a wholly appropriate Flash-world site designed by Gridplane and developed by David Knape. (Note: Knape has also released Bumpslide, an open-source library of useful AS2 classes.)
Given our thoughts on the Flash-world practice, this return to form has been an interesting challenge. In some ways frustrating, others rewarding. We are pleased to be using Flash for its intended purpose: constructing interactive applications combining both visual and technical challenges. Despite our criticism and reservations, the Flash-world architecture can still make for smart solutions given the appropriate context.
Look for more Flash-related thoughts over the next months as this current project progresses.
Adobe CS3 Install: Punishing Experience
Thursday November 15, 2007 - 34 months ago
Posted by James Ellis / Filed under Business, Software
If you’re doing commercial design work, you’re likely running Adobe software. If you don’t want to be left behind, you’re always upgrading to the latest gear. Even if you don’t care about new features, an entire industry is working against you: Apple keeps releasing machines and operating systems that ditch one thing for another (OS 9 for X, PowerPC for Intel), and the commercial design world is always graduating to whatever Adobe’s latest offering may be. It’s a never-ender.
The CS3 Experience
Last week I purchased Creative Suite 3 Production Premium. That’s a bunch of stuff. Being a model citizen is expensive: $1,841.00 with tax from Adobe.com.
During checkout I elected to download the massive 16GB package (the equivalent of ~24 CDs of data).
After completing transaction, I was ready to start downloading my 16 gigs immediately. Instead I received the following email confirmation:
You will receive an email within the next business day confirming the status of your order.
Really? One of the biggest software companies in the world can’t figure out how to automate my order? Fortunately, a human emailed me a few hours later providing me with my serial number and instructions for downloading. I navigated the complex Adobe html-flash-hybrid-web-world and started downloading.
Activation
Adobe introduced activation with CS2. Activation forces CS owners to verify the product’s serial number within 30 days. By verify, I mean Adobe collects identifying information about your computer (the physical computer, not you personally), which it sends, along with your Adobe serial number, to the Adobe activation database super-brain. With this data, the super-brain enforces the term’s of Adobe’s license agreement, which states that the product can only be installed on two machines.
Two machines – that’s it. If I want to install the software on another machine, I need to deactivate one of my other machines first.
Considering that it’s still not very difficult to acquire a cracked copy of CS3, Adobe’s strict enforcement of a strict software license is just sorta gross.
Trial software odyssey
A few months ago I had downloaded the Flash CS3 Trial to test it out. I was impressed, and it was definitely one of the reasons why I moved to CS3. The important point is that I still had the trial software installed on my machine.
While installing the full CS3 package, the installer detected that I already had Flash CS3 installed on the machine and informed me that, as a result, the installer would skip Flash. This seemed smart to me. I had already tweaked out the trial a bit, and I didn’t want to have to reconfig all my palettes and such.
The installation went smoothly, and after activating the software, I was back to work. I was pleased with Photoshop — much faster on my Intel-Mac than the non-universal CS1 I had been running.
Then I tried to open Flash…
Upon launching Flash, I was required to provide my serial number. Unfortunately, my serial number didn’t work. I discovered that my CS3 serial number is incompatible with the Flash CS3 Trial software. I googled around and confirmed that this was the case.
Next, I tried to uninstall the trial software using the uninstall tool provided with CS3. Amazingly, the uninstall tool was unable to uninstall the Flash CS3 Trial.
Getting frustrated, I started trashing anything Flash CS3 related — the application, preferences, anything I could find. Yet, over and over again the CS3 installer refused to install Flash because it kept detecting that it had been installed already.
I started Googling harder and began finding others with the same issue. Apparently, only the Flash CS3 Trial Uninstaller is capable of removing the trial software. I had to go back to the Adobe site and re-download the Flash CS3 Trial software (another 800 MB). I ran the trial’s installer to re-install the trial just so I could uninstall the trial. So ridiculous. This actually worked, and the CS3 installer finally gave me the green light to install Flash CS3 proper.
Unfortunately, I still couldn’t install Flash CS3. The installer would repeatedly stop responding while “repairing support files.” All I can figure is that something got corrupted with all the trial deletion/installation/uninstallation that was going on. Finally, I uninstalled CS3 in its entirety. Only then was I able to re-install everything, including Flash.
A massive waste of time.
Software is hard, DRM is harder
Globo-chem-level software is bound have issues — it’s spectacularly complicated. And all software is hard. From Scott Rosenberg’s Dreaming in Code:
Our civilization runs on software. Yet the art of creating it continues to be a dark mystery, even to the experts, and the greater our ambitions, the more spectacularly we seem to fail.
Yet, punishing experiences like mine are totally unnecessary, and when you’re paying big cash, unacceptable.
Most frustrating is that my trial-software-odyssey is likely due to the limitations of Adobe’s activation and serial-numbering system. If the software wasn’t rolled into a complex activation system, Adobe probably wouldn’t require different installations of the same software, or different types of serial numbers for blanket CS3 packages versus stand-alone products.
Adobe’s activation system is like other anti-piracy technologies — iTunes DRM, Microsoft’s Windows Genuine Advantage, etc. – in that it always finds a way to punish the paying consumers, while piracy always finds a way around it. I can’t recall a single anti-piracy scheme that actually made both vendor and customer happy. If software is hard, DRM is harder.
I’m happy to see DRM nonexistent at the new Amazon MP3 store, and slowly being phased out of iTunes. But, with regard to Adobe, there is minimal competition and minimal incentive for them to do anything differently. After Adobe’s 2005 acquisition of Macromedia, their only significant competitor is Apple with Final Cut and Aperture. If Adobe releases a junk installer, or chooses to enforce a strict software license through activation, few design professionals have the option of taking their business elsewhere.



