We are fast reaching the end of the 25KB era. 3G network speeds mean we no longer need to keep our pages (and all of their assets, cached or otherwise) under 25KB for reasonable performance.

That said, iPhone and Android users expect a rich web experience, 3G isn’t all that fast and like Firefox and IE of old, Mobile Safari and Mobile Chrome come with bizarre incompatibilities.

Take rotation for example.

Resize events happened on the desktop, but they happened in relatively controlled, incremental steps and you always knew what was happening. Resize events would fire on the window object and you could relatively easily determine the height and width, especially with libraries.

Not so in mobile. Mobile Safari fires a resize event, but may not present the new height and width to you. It all depends on which version of iOS you’re running. Android, however, does. Frankly, I’m not sure how Mobile Firefox and Opera 5 behave on those devices, not having one to test on.

Both browsers do update the window.orientation property, but for some reason, Mobile Safari doesn’t present 270 degrees (portrait, but with the button at the top), overloading 0 for that purpose.

Confusingly, the same version of Mobile Safari doesn’t behave the same across dissimilar devices. You can have a slightly different experience between an iPod Touch, an iPhone 3GS, an iPhone 4, an iPhone 4S, the iPad 1 and the iPad 2. (These being the Apple devices that commonly require support).

For example, on certain versions of iOS, media selectors can be applied differently.

Both platforms fire both onresize and onorientationchange events, but not always in the same order.

Worse still, the versions of Android can behave differently as well. Today, there is still a significant user base on 1.5, 1.6, 2.0, 2.2, 2.3, 3.0 and 4.0 is now entering the market.

In short, assume very little when working in the mobile space and try to test in a wide array of devices, because each browser can be very subtly different.

One of my colleagues pointed out the rather high ranking of Ajax Bestiary in his Net News Wire Dinosaur Report today.  While 2nd place isn’t the worst possible ranking, It demonstrates that I haven’t posted anything in quite a while.

I’ve had the best of intentions to resume blogging, but time concerns and the high level of secrecy around my current projects have both pushed me away from regular blog updates.  I’ll be making a bigger effort in the future, but I’ve also recruited a second author for the blog.  David Mahon is a talented front-end web developer who has agreed to produce regular content for AB.

You can expect Dave’s first post sometime in the next few days.

in Javascript the Good Parts, Douglas Crockford presents a simple method to curry functions.  It’s a great tool that allows you to build functions with arguments predefined in them dynamically.  In his implementation Array.splice & an indirect method declaration is used.  In my version, I use prototype’s enhanced Array object & a direct call to the Function object to the same effect.

Function.curry = function() {
var args = $A(arguments), that = this;
return function() {
return that.apply( null, args.concat(arguments));
};
};

I’ve been using this method for a few months now in both its prototype & jquery forms and find it invaluable, especially when faced with a need to manipulate a large number of similar objects.

Today I’m going to start a three part tutorial in implementing a custom datagrid with prototype & scriptaculous. In part 1 we’ll explore the html & css underlying the widget. Parts 2 & 3 will look at interactivity and legacy browser support (IE 6).

Disclaimer: this project is designed to work on IE 7 and later. It will not render properly on IE 6. We will look into that more with part 3.

So it starts with a table. Tables are much maligned nowadays. The focus is on semantic markup and creative uses of <div> and <span>. In the energy behind css layouts over the past few years, the new markup elements available to the venerable table have been slightly overlooked. Sure the reign of table based layouts is over, but tables are now able to display data more semantically and style it more simply than ever before.

Here’s a traditional HTML table to start from.

<table>
<tr><td> Item Number</td><td>Description</td><td>Qty</td><td>Unit Price</td><td>Total Price</td></tr>
<tr><td>0023</td><td> Apples</td><td>3</td><td>.56</td><td>1.68</td></tr>
<tr><td>0057</td><td> Pears</td><td>13</td><td>.74</td><td>9.62</td></tr>
<tr><td>0137</td><td> Bananas</td><td>8</td><td>.31</td><td>2.48</td></tr>
<tr><td>0587</td><td> Kumquats</td><td>17</td><td>.26</td><td>4.42</td></tr>
<tr><td>0054</td><td> Oranges</td><td>3</td><td>.45</td><td>1.35</td></tr>
<tr><td></td><td>Total</td><td>44</td><td></td><td>19.55</td></tr>
</table>

It’s a decent start, but we can do better. First lets separate the body from the head with <thead> & <tbody> tags. We’ll also replace the header cells with <th> tags to denote their importance. We’re also going to add a set of row numbers. We’ll use <th> for these as well to signify that they aren’t really part of the data (note the empty <th/> we added to the header to make everything stay consistent).

<table>
<thead>
<tr><th /><th> Item Number</th><th>Description</th><th>Qty</th><th>Unit Price</th><th>Total Price</th></tr>
</thead><tbody>
<tr><th>1</th><td>0023</td><td> Apples</td><td>3</td><td>.56</td><td>1.68</td></tr>
<tr><th>2</th><td>0057</td><td> Pears</td><td>13</td><td>.74</td><td>9.62</td></tr>
<tr><th>3</th><td>0137</td><td> Bananas</td><td>8</td><td>.31</td><td>2.48</td></tr>
<tr><th>4</th><td>0587</td><td> Kumquats</td><td>17</td><td>.26</td><td>4.42</td></tr>
<tr><th>5</th><td>0054</td><td> Oranges</td><td>3</td><td>.45</td><td>1.35</td></tr>
<tr><td></td><td>Total</td><td>44</td><td></td><td>19.55</td></tr>
</tbody></table>

The <thead> specifies the header content. When printed, a browser should print it on every page the table spans. More importantly for us, it is a unique dom node we can grab for styling instructions. <tbody> works in a similar way, It allows us to break the internals of a table into a set of segments. This will come in handy later. <th> is a different beast entirely. I like to think of it as the ying to <td>’s yang. <th> & <td> are to <table> what <dt> & <dd> are to <dl>: a semantic way to denote name / value pairs.

Now that our table has a header and a body, It’s time to give it a footer. We’ll do this by using the <tfoot> tag.

At first glance, there is visually no difference between the 2nd and 3rd examples. Both of them look identical. The source, tells a different story. In the 3rd example, the footer row is actually ahead of the <tbody> in the source. This is the beauty of <tfoot> It lets us place the footer early in the table and cleanly separate it from the tbody that follows. It also guarantees that the <tfoot> appears last no matter what we append to the table via script.

All of this looks good, except it would be great if the columns were better styled.  The two columns with financial data especially should be aligned left to ensure that the decimal points align.  In a perfect world, we’d be able to do this with column groups, but that’s something for part 2.

DOMAssitant 2.7 is a solid improvement to the DOMAssistant framework with a clear focus on CSS.

New functions:

• cssSelect
• AJAX
• setStyle
• setErrorHandling
• first

Other Improvements

• Dramatic Improvements to the CSS Selector performance: I personally consider CSS selectors the most important feature of a framework so the dramatic improvements really help sell me the benefits of the 2.7 release.
• Unicode Support.  This can be a really big one for a variety of reasons.  Personally, I think it should be built into all frameworks from day one (It is built into javascript after all).

You can find out more about the new release here:

http://www.robertnyman.com/2008/04/09/domassistant-27-released-better-faster-slimmer-new-features/

It’s been a crazy several months, new town, new job etc…

I’m finally in a position to start posting again, so you can expect semi regular updates from here on.

Hi everyone,

I haven’t been posting lately and I apologize for that.  I’m in the process of orchestrating a move and all the headaches that entails as well as finalizing all of my projects at my current job.  I simply don’t have time for AB right now.
Regular updates will resume in March.

Today I bring you the first in what I hope will be an entire series interviewing startup developers on the technical speedbumps they faced in bringing a web based software product from conception to production.  Today’s interview is with Ian Lotinksy, one of the two founders of SandwichBoard a web based CMS targeted at restaurants.

If you are interested in participating in an interview and getting some free publicity for your product, or know someone who might be, please use this form to let me know.

The interview is after the jump

In September you and Patrick Joyce decided to build SandwichBoard.  Were you already Ruby on Rails developers?

We were not doing that for work, at work we were dealing primarily with ASP.NET version 2.0.  We started with ASP.NET 1.1 and upgraded some sites to 2.0.   We were also doing some development in J2EE and were doing client side languages and so on.

Had either of you played with Ruby on Rails before or was this an extra step you took to learn this?

It was an extra step for me.  Patrick had been dealing with Ruby on Rails for I believe an entire year prior to our departure.  He had built an invitation *web app* called easily invited which was supposed to be an improvement on eVite.  I don’t believe it is hosted right now but I think he has plans to re-host it.  He was initially hosting it on Amazon’s EC2 but he wasn’t getting the traffic he needed to justify the cost of hosting of about $75 a month I believe it was costing him to keep the website running.  He decided he wanted to switch it to something else, but I don’t think he’s had time to do that recently.

So, he had experience, I didn’t. I had been following it from an onlookers standpoint.  I was reading about it. Reading blog posts about it, absorbing some of it.  But it really wasn’t until May that I just went out and bought the Agile Web Development with Ruby on Rails Development, the Pickaxe book, Chad Fowler’s Rails Recipes Book & started building a toy application.

So were you already used to Agile Development?  Because you did Agile / Extreme Programing on top of Ruby. Was that new to you as well?

As a formal practice yes.  At Lockheed Martin we’d used the waterfall method to develop our applications.  With our last big project at Lockheed, Patrick and I were on the same team.  We weren’t able to convince management to let us do it in an agile way.  But we ended up doing it in an agile way in that we took the requirements that were known and take a stab at implementing them.  We’d then present it to either the customer that was paying for the project or the user that would be using the project and then do the changes.  So we would do these small iterations.  I wouldn’t call them Agile iterations because they were a little bit longer than a week or two, But it was a break from traditional waterfall method.  It was a bit of a relief for us, at least in our environment.

You chose to develop on a Mac, is that something you’d done before? 

Patrick had been using a Mac.  He had purchased both a Mac Mini & a Powerbook and had been using them for a little over a year as well.  He really liked the integration of Unix and because a lot of the material that was already out there on Rails assumed you were using a Mac and because of the power that Patrick saw in Mac OS.  He basically made the decision that we were going to use this.  So he gave me the Mac Mini to use during the project. I’ve been using it as my primary machine.  So, I had to learn that with a little help from Patrick.  Whenever I got stuck I had to rely on just Googling stuff.  There are several white papers that IBM has on UNIX so I read those to get familiar with all the different commands.

You had to do a lot of learning, especially relative to your partner.  How did that work for you guys?

The good news is that Patrick had lots of experience.  When I was at Lockheed I developed a habit of being able to learn stuff quickly.  Usually what that looked like was not trying to understand everything about the particular technology but to get at  the main point of each technology?  What are the main features? What’s the power behind it?  What’s the strength that it has?  I focused on the core competencies of each language and framework.  Once I learned that if I needed to look up something that was more obscure or hard to understand I could do the research to find it.  I figured out I could do just as well focusing on the core of the technology.  That sort of mentality lent itself to learning Ruby on Rails as well.

What’s nice about Ruby on Rails as well is that it’s a very opinionated framework. Typically, there’s a best way of doing things and that really helped me.  It wasn’t that there was 2 or 3 ways of doing things.  Rails is opinionated and it chooses this one way of doing things.  If you want to take a different route you could, but it’s difficult and most of the decisions that they’ve made is stuff that I would agree with naturally.

Also having books and blogs that I was visiting helped.  Railscast is a blog by Ryan Bates of 2 to 5 minute videos you can watch.  He just does little tasks in Rails and teaches you different aspects of it.  Watching those consistently and using a lot of plugins and open-source helped as well.  The Rails Community has a lot of developers who are a little bit more mature than your average ASP.Net developer, so you know the code your looking at, while not perfect, is likely better than your regular ASP.Net web application.  We had the ability to look at some really nice Rails code that gave us the ability to learn that way.

About how early in the process did you bring in your beta testers.

We brought them in in late August / early September.  We had been doing development for over a month and had the basics of our web app done.  That’s when we started talking with them and getting them started.  One of them was running off our stuff in October.  We’ve just been staying in touch with them periodically and watching their sites pretty closely just to see how they’re using it and how things are performing.  Just to make sure that it is running the way they expect it to run and that they’re using all the features that are there.

We’re about to push our latest and last revisions to the code-base before going to public beta.  Once we get that pushed out, we can really push hard at the marketing end to really get people signed up and using it and giving us a lot more feedback.

How much feedback did you actually have with your beta testers?

It’s largely been over telephone, a little bit over email. What it’s looked like is just calling them up or sending emails saying “How’s SandwichBoard functioning for you?  Is there anything you’re running into that’s a problem?  Are there any features that should be added?”

So far we haven’t gotten many comments about things that haven’t worked or worked well.  The best comment we’ve gotten wasn’t from one of the beta testers but was instead from one of the beta testers girlfriend who was upset that her boyfriend was up til 3 AM working on his restaurant’s site because he was having too much fun.

Looking back, are you happy with some of the decisions you’ve made?  Are there things you would have done differently?

No, I think one of the strengths of what we’re doing and our team is really Patrick’s ability to evaluate the scope of our project as well as direct the architecture of what we’re building.  In “Mythical Man Month”, Fred Brooks talks about having an architect on the team.  The architect may not be the only one with ideas, but he’s the one responsible for the overall architecture for the system. He’s the one who chooses what goes in and what goes out and how things are implemented.  We discussed early on before we started coding just how we were going to work and I suggested he take that role because of his technical aptitude, his prior experience with Rails and Mac OSX and his ability to learn things quickly.  I thought “he needs to be the architect of this” and so far that’s worked well.

Any final remarks?

Making the commitment to leave secure jobs to go do this, although assumes some risk, has been quite enjoyable.  We’ve learned a lot doing this so that even if this fails miserably, we will have taken away a lot from the experience.  From the frameworks we’ve used, the open-source code that we’ve seen and the architecture that we’ve been able to piece together has made us stronger developers.  Even if this only means a four or five months hiatus from being part of a larger organization it will have paid off in making us better developers.

About Ian Lotinksy

Ian Lotinsky (ianlotinsky.com) is a cofounder of SandwichBoard, located just outside Washington, D.C. If he’s not helping restaurants with their online branding, he’s probably spending time with his family, his friends, or his Lord.

Alright, so I’ve been developing a minor frustration with Safari 3 on my Mac.  When I cut and paste between a url in firefox and a Tiny MCE window in Safari, a styled span is applied to the paste.  I’m not sure where it’s coming from. Ex.  http://nurey.com/corners.html

John Resig has just posted an excellent resource for getting your feet wet with jQuery and even introducing some advanced features you may not yet be familiar with.

The presentation & source files are available here:

http://ejohn.org/blog/building-interactive-prototypes-with-jquery/