Relics of the browser wars : All browsers are Mozilla

A web developers life is like this:

• The beginning : I'll do the coolest site on the Internet, I feel so lucky.
• Also in the beginning : What? Is not working in Internet Explorer? OK, let's fork the code for it.
• After a couple of days : WTF?! Am I seeing things? Is not working in IE6, IE7, IE8, IE9 but the problem is different?! Stack Overflow.. Stack Overflow..
• The end : Find some work on the server-side or move on.

People freak out when they suppose to do web development and we wonder why. After a couple of days of work on the best site ever everyone realizes that the site is not working well in all the browsers (i.e. IE.) We need to know what browser we are dealing with so we can do something (e.g serve a minimal version of the site.)

How this madness started?

And behold, then came a new web browser known as “Mozilla”, being short for “Mosaic Killer,” but Mosaic was not amused, so the public name was changed to Netscape, and Netscape called itself Mozilla/1.0 (Win3.1), and there was more rejoicing. And Netscape supported frames, and frames became popular among the people, but Mosaic did not support frames, and so came “user agent sniffing” and to “Mozilla” webmasters sent frames, but to other browsers they sent not frames.

In that moment, when none of today's browsers even existed, the "user agent sniffing" was born. Whow, is so old.

Internet Explorer

And Internet Explorer supported frames, and yet was not Mozilla, and so was not given frames. And Microsoft grew impatient, and did not wish to wait for webmasters to learn of IE and begin to send it frames, and so Internet Explorer declared that it was “Mozilla compatible” and began to impersonate Netscape, and called itself Mozilla/1.22 (compatible; MSIE 2.0; Windows 95), and Internet Explorer received frames, and all of Microsoft was happy, but webmasters were confused.

IE wanted to be Mozilla. Funny that it didn't matched many other features of Mozilla or next generation's Gecko/Firefox.

KHTML

And the followers of Linux were much sorrowed, because they had built Konqueror, whose engine was KHTML, which they thought was as good as Gecko, but it was not Gecko, and so was not given the good pages, and so Konquerer began to pretend to be “like Gecko” to get the good pages, and called itself Mozilla/5.0 (compatible; Konqueror/3.2; FreeBSD) (KHTML, like Gecko) and there was much confusion.

KHTML wanted to be Gecko, so was some kind of Mozilla.

Webkit

And Apple built Safari, and used KHTML, but added many features, and forked the project, and called it WebKit, but wanted pages written for KHTML, and so Safari called itself Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/85.7 (KHTML, like Gecko) Safari/85.5, and it got worse.

Safari wanted to be KHTML, so was some kind of Gecko which means was so kind of Mozilla

Chrome

And then Google built Chrome, and Chrome used Webkit, and it was like Safari, and wanted pages built for Safari, and so pretended to be Safari. And thus Chrome used WebKit, and pretended to be Safari, and WebKit pretended to be KHTML, and KHTML pretended to be Gecko, and all browsers pretended to be Mozilla, and Chrome called itself Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/525.13 (KHTML, like Gecko) Chrome/0.2.149.27 Safari/525.13, and the user agent string was a complete mess, and near useless, and everyone pretended to be everyone else, and confusion abounded.

You know the drill..
Here is the full article, History of the browser user-agent string

Post Mortem

Today the madness continues but is not useful anymore.
A fine web developer knows this days that he should not sniff for the browser but instead check if features are available.

5 books every app developer should read

I can tell what kind of developer you are if you tell me what are your favorite development books. What can you tell about me? Here are my favorites:

1. Getting real by 37signals
   

   If I could recommend a single book, Getting Real would be my choice.
   This was the book that helped me understand that software development can be done so much better.
   It is a revelation.

2. Universal principles of design by William Lidwell
   

   If you want to understand why some designs are great and why some suck you need to read this book. Not only once, but again and again.
   This book should be kept on your desk.
   It is the times table for designers.

3. Design patterns by Erich Gamma & Co
   

   This book is one of the Object oriented programming cornerstones. It is invaluable if you need to design relations between objects in code. Unless you have one or two object types in your apps, you need to read this book.

4. Envisioning information by Edward R. Tufte
   

   After you read this book you have the feeling that whatever you chosen to display information in your app, you could have done better, that you can use something more simple and elegant.
   It can be shocking how many alternatives are out there.

5. Mac OS X Human Interface Guidelines by Apple
   

   If you ever need to create an app for the Mac, read the HIG.
   If you ever need to create an app for iPhone or iPad read the iOS HIG.
   Yep, Apple tells you how to create great apps for their great hardware.

How a simple rule can make your code bulletproof

No matter what programming language you use, if it has objects, you likely make the same mistake as I used to do. And is not even your fault because that was the way you learned to code, because the teachers, books or tutorials don't like to talk about murdane things even if they are vital.

Null pointers

What am I talking about? I'm talking about the number one cause of bugs : null pointers. Suppose we have a function that draws a circle. The function needs a Circle object parameter to know how to draw the circle.

public drawCircle(Circle circle){
 int radius=circle.getRadius();
   
 //draw circle here 
}

Sooner rather then later, somebody will call the function with null:

drawCircle(null);

Since circle is null, the circle.getRadius() call will throw null pointer exception. That will stop the execution thread, no code after that line will be executed. A simple mistake like this in only one method in only one source file can crash an app with thousand of methods and source files. One mistake is enough.

A simple rule

There is a simple and effective way for the above problem, ALWAYS check any object you get from outside for null:

public drawCircle(Circle circle){
 int radius= null!=circle ? circle.getRadius() : 0;
   
 //draw circle here 
}

I wish some day teachers, books and tutorials will talk about simple things like this over and over again. I wish they will teach code that doesn't crash.

I Have no Fame and I Must Launch

© Steve Rhodes

People used to believe that building a great app is enough for success. This ”just launch and hope for the best” approach is not working anymore. The cruel reality is that nobody cares about your app, it's just one of many others like it.

The App Store has more then 500000 apps. And the flood continues with many new apps launched every day. Countless apps, great or bad, linger in total anonymity. It is virtually impossible for new developers and their apps to be noticed.

The question is then : what can we do to make our apps stand out?

1. Make a great app

Do whatever you can to make your app great.
It must be

• fast
• useful
• beautiful
• fun

If is just another crappy app than it deserve to die deep down in the darkest corners of the App Store.

2. Make the app/launch newsworthy

With a little luck, this might be the most accessible way. It can become newsworthy in multiple ways:

• Associate the app/launch with a celebrity, a famous product, something newsworthy
• Sync the app launch with an important event
• Create a viral video, photo, infographic, or anything else that can spread like fire.

3. Have a great community

This is in my opinion the most fair and honest way but also the slowest :

• Create a community around your blog or site
• Give valuable contributions to other communities, help those communities rise and evolve. You will rise and evolve with them.
• Contribute with valuables to popular communities like guest posts on popular blogs, artwork on creative sites, code or bug fixes or documentation on open source projects you use.
• Share freebies, byproducts, even open source parts of your code.

4. Spend lots of money

If you have the money, the quickest way to fame (besides doing incredible stoopid things) is to buy stuff :

• Buy ads, banners, radio, TV commercials
• Marketing campaigns on Google and/or Facebook, Twitter, etc.
• Interviews, coverage, etc in popular magazines and sites or blogs.

5. Launch the app on multiple platforms

Most prefer to create multiple native apps instead of a single app that runs on multiple platforms.

In practice this means they will first create the iOS app then either the Mac app or Android app. And only then, if the app is successful enough, is ported on other platforms.

A few prefer to go the way of a single application, the ”One app to rule them all” way. This means HTML5. This means the same app (the same code) runs on all smartphones, tablets, laptops and desktops.

Launching the app on multiple platforms can be extremely helpful even if your main target is iOS. Even if you give the entire app for free or make lite versions on the other platforms, more people will know about your app and will use the iOS app.

An anonymous app does not matter so make sure make the world knows about it.

6. Wait for the right day

There are developers that finish their apps but don't launch them. They wait for a better day. Instead of launching they try to find a way to change the situation.

Launching an app with success is very hard today, almost impossible. Crafting the app is only part of the story. Don't let your app die before is even born.

App development : Quo vadis?

January 9, 2007.
Nobody had the vaguest idea how important that day will be. The way the world thinks about software and the way the world does software will be changed forever.

iPhone

From day one iPhone became a magnet for many programmers, but until mid-2008, when the App Store was launched, the only way to create apps for it was the web apps : special sites optimized to run in Mobile Safari.

This, and the fact that Flash was not running on the iPhone, had a decisive impact on the spread and the adoption of HTML5.

AppStore

Almost instantly after the App Store went live, most of the developers switched their apps from web to native: being in the App Store was equivalent with fame and fortune for many lucky developers.

However at that point the evolution of HTML5 was unstoppable. It continued to be adopted on all platforms and all browser makers.

It’s 2012. These are the hey-days. It feels like the whole world is making apps. Whatever you can think of, there is an app for that.

Status Quo

Today the trend is to create native apps. But this trend might change once the HTML5 support and performance reaches a certain trash hold.

I am suppose to start a app today, to invest time and money in it, what should I do? Should I go the iOS way or the HTML5 way?

The main difference is this:

• iOS offers superior performance. No need to design and test on an infinity of device types.
  
• HTML5 offers access to all the internet enabled gadgets in the world.
  We can use the skills we already have: HTML, CSS, JavaScript. No need to buy Macs for development, can do HTML5 development on any OS.

Tough choice.
I can see people arguing on this forever. I tend to bet on HTML5 because is cheaper but I can see problems with it already. Nothing is ever perfect.(The app must be present in the AppStore, no doubt about it, but web apps have PhoneGap for that.)

App not application

©Morton Lin(Creative Commons)

When Steve Jobs unveiled the iPhone on January 9, 2007 nobody had the vaguest idea of how important that day will be. Whatever we chose, native or web, I know we’ll create an app not an application. It will be something simple and easy to use, fast, light and beautiful.

An app people will have fun with, an app that matters.

Everything You Need to Know About Writing Successfully

©Van Sutherland(Creative Commons)

I'm just starting to write this blog, I'm looking for various ways to improve my "technique". Clean and concise writing is a nice skill to have, no matter what you do.

I found this little story about how Stephen King met an editor named John Gould and how that changed his life.

[Gould] started in on the feature piece with a large black pen and taught me all I ever needed to know about my craft. I wish I still had the piece – it deserves to be framed, editorial corrections and all – but I can remember pretty well how it looked when he had finished with it. Here’s an example:

(note: this is before the edit marks indicated on King’s original copy)

Last night, in the well-loved gymnasium of Lisbon High School, partisans and Jay Hills fans alike were stunned by an athletic performance unequaled in school history: Bob Ransom, known as “Bullet” Bob for both his size and accuracy, scored thirty-seven points. He did it with grace and speed … and he did it with an odd courtesy as well, committing only two personal fouls in his knight-like quest for a record which has eluded Lisbon thinclads since 1953….

(after edit marks)

Last night, in the Lisbon High School gymnasium, partisans and Jay Hills fans alike were stunned by an athletic performance unequaled in school history: Bob Ransom scored thirty-seven points. He did it with grace and speed … and he did it with an odd courtesy as well, committing only two personal fouls in his quest for a record which has eluded Lisbon’s basketball team since 1953…. When Gould finished marking up my copy in the manner I have indicated above, he looked up and must have seen something on my face. I think he must have thought it was horror, but it was not: it was revelation.

“I only took out the bad parts, you know,” he said. “Most of it’s pretty good.”

“I know,” I said, meaning both things: yes, most of it was good, and yes, he had only taken out the bad parts. “I won’t do it again.”

“If that’s true,” he said, “you’ll never have to work again. You can do this for a living.” Then he threw back his head and laughed.

And he was right; I am doing this for a living, and as long as I can keep on, I don’t expect ever to have to work again.

How I found this? Google lead me to a 2006 article on Copyblogger

10 Commandments of App Development

© Sue Hasker (Creative Commons)

1. App must be fast : should start quickly and should not lag.
2. App must be polished : it should look very professional, beautiful, or both.
3. App must be intuitive : most if not all should learn to use the app in two minutes.
4. App must be simple not complex : remove unnecessary features, merge the rest, use progressive disclosure.
5. App must offer free or lite version if is not free: people should know what the get for the money.
6. App must not crash : should handle with grace all kinds of expected and unexpected events.
7. App must not waste device resources : respect the fact that memory, network speed and battery juice are finite.
8. App must not trick : people, especially kids should not be tricked to purchase things.
9. App must not use user information without approval: private things like location, contacts, history, purchases.
10. App must be launched when the time is right : the app must under no circumstances be launched in total anonymity, enough people should know and care about it.

So what is a app that matters in my opinion? It is an app that respects all the above ten commandments. That's all.

It is not required to be downloaded by thousands, it is not required to gross in millions or be the latest meme on the net.

But it must be great and people should know about it.

Why we loose a bit of humanity

Yesterday I found another brilliant TED talk: Chip Kidd: Designing books is no laughing matter. OK, it is.

Yesterday I didn't knew who Chip Kidd is. Today I'm grateful that I heard him, that he shared his love and passion for his trade, for the design of printed book covers.

Wikipedia says:

Chip Kidd (born September 12, 1964) is an American author, editor, and graphic designer, best known for his book covers.

I would at least say he is a brilliant and passionate book cover designer. Look at him, look at the way he talks about his covers and tell me you don't feel the urge to touch those books, to smell them, to feel them.

When you listen to him you suddenly feel that you wake up from a dream, like a new dimension of reality is regained.

He is more a priest than a geek, his word is more an incantation than a statement. Maybe that's way I keep hearing his words over and over again:

Much is to be gained by eBooks: ease, convenience, portability. But something is definitely lost: tradition, a sensual experience, the comfort of thingy-ness -- a little bit of humanity.

Navigation in Apps for Kids

Smashing Magazine has published an article called " A Dad’s Plea To Developers Of iPad Apps For Children." It was a real eye opener for me. Having two kids that love the iPad all I can do is confirm what 'Dad' is suggesting: a standard, recognizable navigation in apps, at least in those for kids.

Indeed some of the apps have that terrible tab based navigation at the bottom, and those tabs are frequently touched by mistake.

Not only the article but some of the comments are great too, here is what one of the best is suggesting:

• Support multi-touch and then ignore the touches that don’t matter. The most frustrating thing for my 2-yo is putting one hand (or palm) on part of the screen and trying to touch something else that doesn’t work.
• Undo. Unintended actions should be easily reversible.
• Timers. Allow parents to specify how much time can be spent in the app. Our kids get 20-min a day of iPad time.
• Ads in kids apps are EVIL! Especially banner ones. Charge extra if you have to. If the app is good I’ll happily pay.
• Same with in-app purchasing. I totally agree with the author. Any app targeted at small kids with in-app purchasing better have it buried somewhere hard to reach and even then double and triple password protected so only parents can authorize them.
• Variance: an app gets old really fast unless each time the child touches something, it does something slightly different.
• Please, no splash screens or startup menus. Small kids do not have the patience to sit through a 15-second promo video for the software publisher. Having to start something via a startup menu means a parent has to be involved each and every time the app is launched.
• Support app backgrounding. Can’t tell you how many times my kids accidentally hit the ‘home’ button and exit the app, then come running over. It’s really not that hard to support backgrounding so the app maintains state and when brought back to the foreground just picks up where it left off.
• Volume control: please have mercy on the rest of us. Let us set a maximum volume for music and sound-FX.
• Finally: if you put device rotation or shake input in an app targeted at small children, be prepared to get a bill for the smashed iPad screen :-)