Archive for the ‘Coding’ Category

Google threw a hackathon last week for their app engine product at their Chicago offices. Myself, Steve, Dan Parker and Jon Hoyt attended.

I wasn’t sure what to expect but knew we would have fun (pictures here). The event was very lax. Every couple hours Google would talk a bit about App Engine but other than that it was really just a hackathon. They encouraged us to build an application while we were there and walked around patiently answering questions.

We had a great time, despite not knowing a lot of python. Thus far, I’m not a huge fan of python but Google App Engine is pretty sweet. When the limits are removed and they start to support more languages, this thing is going to rock! That said, I’ll keep hacking with python, just so I can use it.

Oh, and obviously one of the high points was the schwag. I love schwag! I left with a full stomach, my thirsts quenched, an American Apparel App Engine T-shirt, a few funny stickers and magnets for the fridge. Speaking of full stomach, the food was awesome. Several different kinds of sandwiches, desserts, salads and drinks.

I’m fooling around with a chat application and the first time Steve tried it out, he sent through the following as a message.

<script>alert('hi');</script>

Obviously, I got an alert and laughed because I forgot to escape html in the chat body. Then, of course, before I could fix it, he sent through this:

<script>document.getElementsByTagName('body')[0].style.display = 'none';</script>

Quite promptly, my whole screen went blank. Escaping the output in the templating engine I was using was simple, but what about when inserting a new chat using JavaScript? In Prototype, the following works.

$('foo').update("<script>alert('hi');</script>".escapeHTML());

I was using jQuery, though, so I searched around a bit for something that does the same. I’m usually quite deft with Google but I couldn’t find anything. The following is what I ended up with.

$('#foo').append(document.createTextNode("<script>alert('hi');</script>");

Since I couldn’t find it anywhere, I thought I would put it here. Hopefully, it won’t take the next bloke a few hours to figure it out.

Supporting multiple browsers is too hard. I give up. From now on, I will only support the latest browser. No, not the latest version of each browser, but rather just the most recently released browser. For now, I will support Firefox 3 as it was just recently released. Safari 4 is in the works, so when that comes out I’ll update my apps to that. Also, I’ll be sure to add sniffers and detectors to redirect you to an unsupported browsers page. The next browser I support after that will probably be Internet Explorer 8. Actually, Webkit has nightly builds. I’ll just only support the latest nightly build of Webkit.

Hopefully, by now, you realize that last paragraph should be wrapped in a <sarcasm> tag. It seems like browser support, or rather lack there of, has been a hot topic amongst developers lately. I don’t have much to say but let me present with good and bad examples of handling browser support.

Good Example

Recently, 37Signals announced that they will be discontinuing support of Internet Explorer 6 in their products. The first thing they say in the post is when support is discontinued.

On August 15th, 2008 we will begin phasing out support for Internet Explorer 6 across all 37signals products.

Then they explain the implications of this decision.

If you are using IE 7, Firefox 2 or 3, or Safari, you don’t have to do anything — everything will continue as is for you.

Lastly, they explain why they made the decision.

Supporting IE 6 means slower progress, less progress, and, in some places, no progress. We want to make sure the experience is the best it can be for the vast majority of our customers, and continuing to support IE 6 holds us back.

I don’t know how intentional the order of that information was but it is pretty smart. The first thing people care about is when and what. They get that out of the way to assuage the fears that any may have that a product they pay for can no longer be used. Once they get those immediate needs covered, they discuss the why. People don’t care about the why until they know how it affects them.

IE 6 is an extremely outdated browser. It has performance issues and a newer version has been out since 2006. There is absolutely no reason to support IE6 for web applications anymore. 37Signals made a good decision and properly communicated it to their customers.

Bad Example

With much hype and excitement Apple recently launched MobileMe. Being a fanboy, I fired up my browser and signed up. Once into the app, I quickly became frustrated because nothing I clicked seemed to do anything. I know how the web works but I couldn’t get anything to do anything. Then it hit me. I wasn’t in Safari, I was in a version of Webkit (the engine that powers Safari). I closed Webkit and opened up Safari to find that everything worked. All the problems I had went away. Also, open up the app in IE7 and you get this message.

I can understand not supporting IE6 but IE7? Granted they say you can still use it but that it just doesn’t work as well.

Internet Explorer 7 has known compatibility issues with modern web standards which affect Web 2.0 applications such as MobileMe.

To me that is a total cop out. Maybe IE7 won’t perform as well but it is not so difficult to support that a message needs to be shown and users should be forced to click continue to actually use the app.

On top of the IE7 stuff, there are several little things that bother me about MobileMe. In an effort to make it feel more desktoppy, some normal web expectations were thrown to the wayside such as tab indexes and text selection.

</rant>

Go ahead and drop support for IE6 in your web app. You deserve a break from it, but IE7? IE7 is not that difficult to support. There are several ways to skin a cat (or so I’ve heard) and usually one of them will work in all the major browsers.

I’ve been working on a really cool new feature for our website management system, Conductor. Initially, I drafted up the database tables I was going to need. I poured over them, making sure that I wasn’t forgetting anything. The whiteboard with the database tables is pictured below. Once I was satisfied with how I was going to store the data, I dove into the code and started implementing the whiteboard drawing I had created.

Bad Start

About three or four hours in, I realized that things weren’t going the way I wanted and that it was going to take a lot longer than expected to implement. The solution that I had come up with felt complex and was going to require a big rewrite to our theme system. Anytime something feels complex, I go back to the whiteboard because it usually means I haven’t fully thought it through. A bit frustrated, I went back to the whiteboard. This time instead of starting with how I would store the data, I focused on how I wanted to present the data (the interface that the end user would see). Again, you can see my scratching below.

Good Start

As I framed in the interface on the board, the problem started to seem simple and I came up with a new way of doing it that would require no alteration to our theme system or any other existing part of Conductor. Also, this new way makes more sense.

Conclusion

So what am I trying to get at? I think this has taught me the difference between good software and bad software. Bad software starts with the developer thinking how they are going to store the data and technically make it work. Good software starts with the end user. It firsts figures out what will be the easiest way for the user to learn and use the feature and then figures out technically how to do it. I don’t think this is a revelation or that I’ve never built anything in this manner. I am sure, though, that I wasn’t as aware of this before when building applications.

Don’t start technical and force implementation. Start with the interface and let things come naturally.

Leave your feed reader for a bit, so you can check out my new design. The design and logo are the work of by my buddy, Oak, who I cannot give link cred because he is unable to design for himself. Maybe someday Oak. The development was all by me, obviously. It was an interesting slice and I recorded most of it so I’ll probably put out a new version of my “How to nail a sexy layout” series, screencasts included.

I was going to wait to launch this until I had finished my own blogging system (which I really haven’t started yet) but couldn’t wait. Chances are there are some bugs and I haven’t finished styling/updating everything yet, but there is enough to check out.

I have some cool ideas for this site and for railstips in the near future. That is all for now, just thought I would give people a heads up.