We changed our name! After 14 years of creating award-winning digital products & services, it’s time for a new identity that better reflects the human insights-driven, digital customer experiences we create.
We changed our name! After 14 years of creating award-winning digital products & services, it’s time for a new identity that better reflects the human insights-driven, digital customer experiences we create.

AIAIO: Our Blog

AIAIO: Our Blog

The pulse and reviews of Alexander Interactive

Posts Tagged ‘web development’

wEbVOLUTION Timeline

A history lesson and evolution timeline brought to you by Ai…


The World Wide Web debuted to the public, for free, 20 years ago today. Yup, only 20 years ago. Here was the first website, which has been re-released by CERN for this occasion:

First WWW web site


Our founder, Alex Schmelkin, made his first website for Hofstra University 17 years ago. Check it out:

Alex's first web site


The year Ai’s created its VERY FIRST WEBSITE. The lucky client?

Ai's very first web site


We developed our first ecommerce website for is ranked 153 on the Internet Retailer Top 500.


That’s now! This month we launched, with e-commerce and custom product configuration. Voila!

Any guesses what websites will look like and what technologies will be important in another 20 years?


HTML High-5

Everyone is jumping on the HTML5 bandwagon, and we at Ai are no exception! For a while I’ve been a little reluctant to introduce the new revision for our projects mainly due to the lack of solutions that would target cross-browser compatibility out of the box. As an ecommerce shop, browser compatibility means more users, means more revenue, means happy client.

HTML5 Boilerplate - A rock-solid default template for HTML5 awesome

For the past couple years I’ve been monitoring the development of HTML5 Boilerplate, a project created by Paul Irish and Divya Manian, aimed to seamlessly integrate HTML5 and modern CSS3 features into your site across all browsers (even back to IE6). The current 1.0 build was recently released with a bunch of goodies such as HTML and JS minification, image compression, cache management, updated CSS reset, custom build script, the option to choose modernizr or html5shiv, and so much more.

To learn more about the project visit


Web 2.0 Expo: thoughts from Sean

Guestblogging today are David Yoon and Sean Auriti, two of Ai’s developer team, who attended the conference and shared their observations.

Here are Sean’s thoughts. We’ll post Yoon’s on Monday.


“REST with Rails” was a good refresher with some good points on keeping the code DRY as well as providing different formats of content using a single url.

Great takeaway: keep it restful, every resource should have its own controller.

I learned some things on the new rails 2.1 caching methods… can change etags, expire time. Saw how simple coding can be by using rest methodology. Very easy to implement, atom feeds, api calls and csv exports.

Presenter David Heinemeier Hansson is the creator of Ruby on Rails and a partner at 37signals.


Wither Windows?

So quite recently, the Ruby on Rails open source web framework announced that they would be migrating from the Subversion code repository they had to a new one managed by Git.  Git is a version control system created by Linus Torvalds to manage the Linux kernel.  Linus had several requirements in mind when he made Git, requirements that involved specific sets of features, scaleability, stability etc.

As might be expected from the creator of the Linux kernel, none of these requirements included running well on Windows.
Git does technically run on Windows, but its kind of a hack, and Redmond’s favorite platform is definitely treated like a second class citizen (ooh… irony…).  So naturally when Rails moved to Git, there was a number of Windows users who were concerned they were being left behind.  Interestingly, the Rails maintainers responded that amongst the core developers of Ruby on Rails, Windows users were a small minority.
So then, in this other piece I was reading (I need to see at least two things before I declare an Official Trend) John Dvorak rips on Dell, claiming they’re stuck in a 90’s mentality.  In the article, he says Dell isn’t keeping up and startups in Silicon Valley these days tend to use laptops, and many many of these laptops are Macs.
Even Senator Schmelkin, a long time Windows guy, switched completely over to a Mac a couple of months ago (I tried to get him to blog it…sorry, no luck…).
Okay – I knew Apple was getting a boost from the whole  iPod thing, but I never expected to see quite this level of momentum (and yes, yes…I’m sure in the accounting and parking facility businesses Windows still has 18456% market share…).  There seems to be an accelerating trend, especially in the software and web world where not only is it more desirable to work on a Mac, but its beginning to look like people are beginning to take the position that Windows doesn’t matter.  It’s like it’s deprecated.
(Disclosure – I was a Mac guy from before it was cool, except for a span of about 5 years that I spent trying to install Linux on a laptop).
The Rails guys do tend to be a bit religious at times – “my way or the highway”.  But I do find the basis for their switch interesting.  The lack of first-class support for Windows was simply not a consideration.  Has the world finally changed?  Is the wicked witch finally dead?

SAS, Outsourcing and Business Risk

Update:  This post has nothing to do with these guys.

I have long been a fan of outsourcing (not necessarily offshoring, which is a different animal).  Take the stuff that’s not the core of your business and move it off to those who are experts in it.  I think it gets even better when that service can come through a nifty lightweight web 2.0 interface.  In other word, Software As a Service (SAS) UPDATE: Sorry – this should actually have been abbreviated “SaaS”. Acronym fixed in the rest of this post.

So, along those lines, we here at Ai use a number of web-based outsourcing services to handle our non-core activities.  We use BaseCamp as a collaborative project management tool, and Harvest for time tracking, to name a few.  These decisions are cost-effective for us, because we’re not in the collaborative project management tool business, nor the time tracking tool business.  We build websites for clients.
There’s a catch, however (you knew the catch was coming, didn’t you?).   There is a question of risk for each business function that is outsourced to a SaaS.  This risk can be difficult to quantify, so it can be a bit much for the more risk-averse business people.
SaaS-related business risk generally falls into two categories:
  • Availability:  How often does the SaaS go down, and become unavailable to its clients?  Depending on the level that business depends on the SAS, lack of availability can have a serious business cost, usually taking the form of paralyzing the business in some way.
  • Data Loss:  Much worse than availability, when mission critical data is put into an SaaS, data loss can be deadly.  Data loss can kill a business.  Dead.  A less deathly, but still damaging variant on this is vendor lock-in, where there’s no expedient way  to leave the SaaS, because all of the business’ data  is in the SaaS system, with no way to export it. 
Am I being hyper-cautious?  Are these risks just hypothetical?  Well, in the last week BaseCamp (actually all of the 37 Signals apps) went down because of a bad router.  There was no backup router in the rack, apparently, meaning that the entire suite of SaaS apps from 37 Signals had a single point of failure which, well, failed.  For all of Friday morning, no one derived any benefit from BaseCamp.
Last week Twitter (admittedly not the first thing one thinks of for business-facing SaaS, but still…) died unceremoniously during the Steve Jobs Macworld keynote.  Too many Apple fans live-blogging for Twitter to stand, apparently.

These risks slow SaaS adoption.  In order to make the leap across the chasm from early adopter types to the majority, SaaS providers must find a way to mitigate these risks.  This kind of thing  will be tolerated by a certain breed of early adaptors, but the more  conservative majority need more assurances.

Hello, SaaS providers – I’m talking to you now:
  1. Service Level Agreements for SaaS:  How about an uptime guarantee.  That is typically followed by an investment by the provider in the technical infrastructure to provide the agreed upon service level.  Like backup routers.
  2. Data backup and export:  Some assurance that a) our data is safe and b) we can get it away from you would go a long way to mitigating fears of certain business death in the event of a technical failure of an SaaS, or should we decide that we want to switch to another SaaS.

Now I’m not asking for regulation or anyone to pass a law or anything.  But it would be nice to have a certifying body out there somewhere for this kind of thing – a “Hacker Safe” for mitigating SaaS business risk.  That would provide businesses the assurance they need, and allow SaaS to fully cross over into the mainstream.


Platform: Proprietary vs Open

Some time in the last 12 hours or so this went live.

OpenSocial is a common API for writing social networking apps. Its being embraced by practically every single social networking site out there, with the notable exception of FaceBook. Basically the promise of this is that an application developer can write an application against one API and then deploy it in any of the compliant social networks.

FaceBook, as the current king, has the least incentive to adopt the open standard. In fact the OpenSocial API can be seen as a check to FaceBook. Its simple to understand really, in place of “Facebook” use the word “Microsoft Windows” and in place of “OpenSocial”, use “Java”. The FaceBook strategy is to add value to their platform by harnessing third party developers to write to their proprietary API. OpenSocial is a counter-strategy to that, by making a universal API that is supported by all social networking sites.

The potential fallout from a successful deployment of OpenSocial is the movement of value in the supply chain away from the social network, and towards the applications. When an app can be deployed on any social network, it doesn’t matter so much which network someone is on.

The natural response to this would be for various social networks to “embrace and extend” the OpenSocial API, to try and create lock-in for their own platforms. In the past Java had several legal protections in place to prevent this (not that Microsoft didn’t try anyway). JavaScript, with none of the legal protections of Java, was forked mercilously, creating a difficult programming environment for JS developers that persists to this day.

Historically, Java failed at driving a wedge between Windows and application developers. It remains to be seen whether the social networking application community will standardize on FaceBook, OpenSocial, or something else.