The Bootstrap Revolution

Twitter's Bootstrap CSS framework has been wildly successful.  I am using it on some (behind-the-firewall, unfortunately) consulting projects and am very happy with it.

Like anything else successful in tech, it has its detractors, but I'm truly surprised by the lack of substantial criticism. The biggest complaint, which I've made myself and have cautioned clients about, is that if you're not careful your site will end up looking too much like all the other Bootstrap sites that are out there.  This problem occurs if you don't take the time to customize Bootstrap -- something that is relatively easy to do with a little tinkering with LESS.

In Why Bootstrap might be very important Dave Winer argues that this apparent drawback is actually a good thing and draws a comparison between Bootstrap and the original Macintosh Toolbox.  In short, he's reminding us that UI standardization is beneficial.  Read the whole (short) thing and skim the Hacker News discussion it spawned and draw your own conclusions.

Another valid complaint is that sites that use Bootstrap don't completely separate content from presentation in part because key Bootstrap CSS classnames describe layout, not content.  In practice this is only a minor issue and is probably unavoidable with a CSS framework, but it might upset a Semantic Web pilkunnussija.

Bootstrap (and LESS) have changed my perspective on front-end development.  I'd like to apply some of the lessons learned to the iUI Framework, but that's a subject for another time.

Mobile Best Practices in the iPhone Era?

A friend e-mailed me this evening asking about what the current best practices are for mobile web access.  My immediate, flip response is "Make it look good on mobile WebKit and if the others can't read it, that's their problem."

I've been so focused on iPhone (and compatible sites) over the last year, that I have almost no idea what people are doing to support other devices.  Maybe the best practice is (essentially) to make it look good on the iPhone.   Most of the other devices are using Mobile Safari and are pretty close to the iPhone in capabilities.  Those that aren't are moving quickly to catch up.  WebKit is pretty much standards-based and when you look at actual mobile web usage statistics all the other phones don't add up to much.

She asked about a specific client that has an existing site that currently uses Flash navigation and has a limited budget.  The client wants improved mobile support.  Without knowing any details on the implementation of the site, the clients needs or budget, I'd guess there are four possibilities:

1. Remove the Flash navigation and replace with HTML and CSS navigation that is as modern as possible given the structure and complexity of the existing site and the customers budget.  Use the iPhone viewport tag and other techniques to make the site iPhone-compatible.
2. Create an alternative mobile site using XHTML that can be viewed by iPhones and other mobile devices, even older ones with limited web browsers.  Redirect mobile users to the mobile site (giving them an option to return to the main site, of course)
3. Redirect users to an iPhone-optimized site using iUI or another of the iPhone-centric mobile libraries.
4. Create an XHTML and an iPhone-centric site (In other words #2 and #3)  (Optionally remove the Flash navigation on the desktop site, as well.)

I would recommend #1 or #3 depending upon the budget.  But I'm an iPhone bigot (or at least Mobile WebKit bigot.)  Ultimately, it's a matter of return on investment.  For a relatively small site, why make the huge investment of supporting all the older phones with small screens and lousy browsers that no one uses anyway?

Whichever strategy is chosen, testing needs to be performed starting with the most popular devices and extending as far down the "long tail" as the testing budget and ROI calculations can justify.

Am I too much of an Apple fan boy?  Does anyone else have some pragmatic alternative best practices?

iUI on Google App Engine Using Gaelyk

Since Google Code project hosting doesn't provide web hosting other than wiki pages, iUI has been using SVN to host the sample applications, like the music sample.  The problem is that neither of these solutions allows PHP or any other server-side solution to run properly (e.g. Search or Stats in the music sample)

I wanted a free hosting solution for the project and also am a big fan of the Groovy programming language (my Java background showing)  So, I thought I'd try using Gaelyk on Google App Engine.  I first pushed a test version several months ago, but I've just pushed a new version to iui-js.appspot.com and also checked in my work-in-progress to revision control.

I've also created a wiki page called iUI on Google App Engine.  The wiki page has (hastily-written) draft instructions on "How I Did It" -- as well as a to do list.  Please let me know if you have any suggestions on the to  do list.

iUI Design Philosophy

The forthcoming release of iUI (version 0.40) is going to be the first release of iUI that add significant architectural changes.  iUI today is not that different from the original release of iUI over 2 years ago.  The major reason for lack of change has been simple: lack of human resources on the iUI team.

There have been many great contributions from the community, from simple bug fixes to beautifully crafted patches that add multiple features and almost double the size of the codebase.  I have also read and heard many opinions on the value of iUI, both positive and negative.  I'd like to write a formal statement defining the design philosophy of iUI so that users, developers, and even critics can better understand what iUI is and what it wants to be when it grows up.  This philosophy comes from three sources:

1. Joe Hewitt's original vision and source code
2. The experience and feedback of the community as it has developed applications with iUI
3. My understanding of the above sources and desire to move the project forward while staying true to its roots and to the loyal community.

Here are some of the key points in outline form:

1. iUI is a micro-framework (small, no underlying framework)
2. iUI is standards-based, but Safari focused (no IE)
3. iUI is lightweight.
4. iUI is a great starting point for any iPhone-optimized mobile site
5. iUI is a great starting point for those who want to learn modern mobile Web Dev.
6. iUI provides a functional core that is extensible through plugins
7. iUI is independent of server side technology.

I'd like to add a little more detail on these points (and was holding off on blogging this until I did) but I'm going to publish it now as it may answer some questions I've received recently.  Comments are very welcome.  This should eventually end up on the iUI project site.

Goal: I Wanna Be a JavaScript Ninja

I've wanted to create a blog that focuses specifically on software development, with a focus on JavaScript development for some time now.  Since Apple's introduction of the iPhone and initial announcement that all iPhone applications would be Web Applications, I've been interested in improving my knowledge of JavaScript and have made solid progress, but still have much to  learn.  Someday I hope to be a JavaScript Ninja (I bought the early access edition of the book, last week.)


I became involved in the iUI project over two years ago, and offered my skills as in the areas of revision control,  release management, and documentation.  I had hoped to learn more about JavaScript by assisting other experts on the project where I could.  Joe Hewitt, who created iUI had moved on to Facebook and was working insane hours on the initial Facebook iPhone Web Application.  A handful of other developers made contributions to the project but it didn't turn out to be the apprenticeship opportunity that I had hoped.  I used iUI on several consulting projects and over time learned much more about JavaScript and came to understand the iUI code base quite well.  Recently, I've decided that I have the expertise and can make the time to begin moving iUI forward and have made a few releases, fixed a few bugs, and added some minor features.  I'm hoping to get more developers involved with iUI and I'm also hoping to interact with and learn from the wider JavaScript community.


I've also had an interest in teaching JavaScript programming.  JavaScript is the de facto language of the Internet and is (at least indirectly) a part of everyone's daily online life.  In some ways it is well suited for beginners, in others it isn't.  I would like to write some posts for beginners or new developers as well.


I've debated whether I should use Apache Roller, Wordpress, or Blogger to do it.  Apache Roller is a great piece of software, I have a server side Java background, and there is a great team of helpful developers working on the project.  But ultimately, I didn't want to commit to maintaining a blog on an instance of Tomcat or on a hosted Java Servlet environment.  I may revisit this in the future, as I'd love to be able to be able to get under the hood of the blogging software I am using.


Blogger is overall the quickest and cheapest way to get started and now is the time as I have several subjects I want to discuss.