Musings of a Web Producer

So a couple major changes have happened over the last month or so, that I am excited to talk about. First is that I have move to Oakville, my girl friend is taking Computer Animation at Sheridan, and being that I have some freedom to move around being a web developer, I decided to come with her.

In addition a lot of opportunities have been opened up to 52 Stairs Studio Inc. We received a contract with a fiber company (A2B Fiber) to build them a really cool online application. In addition we have brought on a new adviser into 52 Stairs Studio; with this has come a great opportunity in the wine industry of all things. In addition one of the previous automotive companies we were working with presented us a great opportunity to work on another new and exciting project under a great company called Dealer Dimensions.

I will try to post more updates as things unfold.

I recently have noticed an influx in app builders. Google was the first to venture into this, and now all kinds of services are popping up that are trying to do the same thing, build an app in a couple steps! The mobile space is a new space, but it fundamentally has the same characteristics of other mediums such as the internet, or a news paper. In almost all instances these new mediums make it easier to create and share information. When the internet started there was very little, then there was a lot, and then there was services that popped up to let you make your own website, can you name any? If you can, are they still around?

The general idea is that everybody wants something such as an app or a website so if you can build something that can easily do it, it will be a gold mine; it doesn’t work, for a couple reasons.

1. The Complexity Paradox (in regards to UX)
The simpler an interface is for doing complex things, the more complex the back end. The more complex the back end becomes the harder it is to make the interface complex. If both end up being complex, the product will explode. Why is this relevant? The more features something requires, the more it is going to affect the interface, because you cannot possibly make a back end that is predictive enough to handle every contingency. Yes it is true, some people want “simple” things, however the quantity of simple things is always increasing or changing. Facebook and their various widgets is a good example of this.

So user A wants feature B. In order to change feature B something must be added to the interface, how do you maintain simplicity?

2. People don’t want to pay for partial tools
Imagine going to a hardware store and buying hammer, upon getting it you discover it only works for 50% of nails, any other nails and it will shatter. Pretty big problem. If you’re going to invest the time in building something, you usually want to use tools that allow you to do a lot. Web interfaces for building applications is like a hammer that can only do 50%. If you’re trying to buy a tool because you don’t want to work, there is a fundamental problem with that, you will probably end up just hiring someone to do it for you.

3. People always want the latest stuff
Most web developers I am sure have heard and shook their head because of their client’s misunderstanding, “I want my website to be the greatest, it needs to use HTML5!” They have no idea what HTML5 is, all they know is they want it. The nature of technology is advancements will always (no exceptions) out pace any form of WYSWIG editor that utilizes separate technology, because of this editors will always be in a catch up model unless they have a supreme amount of capital and workers behind them. What was CSS and Divs 10 years ago? Adobe is a good example of how an editor can keep pace, when they wanted to do stuff on the internet that at the time wasn’t possible (and is just catching up now) they built their own plugin. Unfortunately, app/web builders rely on other people.

4. Self Competition
Building technology that produces the same technology easier is a form of devaluation and self competition. If you can make $75 an hour developing technology, but you build a product that lets other people do it for $25 an hour, you have destroyed your own price point. Now it might be fine if through your factory you get way more sales, but because of the aforementioned concepts the only people you are going to get are usually the cheaper kind, so it won’t be $25 an hour, it will be 0.5c an hour, and once other factories come out it will be 0.1c an hour, meanwhile the rich people who want the latest and greatest don’t mind the $75. Information Technology production does not work the same way as manufacturing. People require a unique product, and if they don’t they will go on something like wordpress or facebook who don’t make their money through information technology production.

There may be a time in the future when development can become an automated or simple process, that time is not now. No matter how intuitive and simple you make something, people will always want something else, or something new when it comes to IT.

Building and selling information is not the same as building a deck. IT development is more akin to farming, the product spoils.

We recently converted our widgets over to using iframes. To date they had been direct SWF object embed code. However with the iPad surely going to hold onto a significant market share, we didn’t want to limit who could see our maps. I don’t think I have honestly even used an iframe in the last 3-5 years, I associate them with old school web days where people had the sidebar control content in a middle area (ick). You can see it in action below:

I thought I would go over why we decided to switch to iframe code, and both the pros and cons that we discovered.

Pro – Sandboxed
Widgets in iframes are completely sand boxed, you don’t have to worry about clashing with javascript or CSS styles. Particularily if you’re writing divs to the page via JS, you don’t have to worry about them getting styled incorrectly and messing with your widget. Javascript doesn’t have true namespaces, you can put everything under one class (function) but if by any chance your ‘namespace’ has the same name as some other javascript on your page you run the risk of clashing. This could be an issue when working with a lot of widgets. Further with the rise of jquery, if we decided to use jquery for anything, we don’t have to worry about version clashing.

Con – styling
It is nearly impossible to let someone modify your widget with styles on their own page.

Pro – Blogger support
The direct embed didn’t work with blogger, iframes do however.

Pro – Content Modification
Modifying your widget is simple, doesn’t require any fancy document.write code. You can design your widget in HTML.

Con – url detection/security
We cannot easily grab the URL for widget analytics like we could before, now we may have to manually pass in the url to the iframe using a document.write with all the widgets. However in this instance same origin policy is of little concern to us.

Pro – Content Redirection
With this version of our widget, our javascript enabled widget actually exists on a completely different page.

I am actually developing another JavaScript widget right now that won’t use iframes, this is on purpose because we want users to be able to modify the widget’s styles – I may post my experiences on that later as well. So that is pretty much it, hopefully this helps someone.

The following statement represent ideals, I include some religious statements, but the same principle applies regardless:

• My idea will be successful because I am a good person.
• My idea will be successful because God is on my side
• My idea will be successful because God is against my competitors
• My idea will be successful because it is good for humanity
• I have never failed at anything before, therefore my idea will succeed
• I am a bad person, so my idea won’t be successful

These are very egotistical statements, they are based on the reality of the world revolving around you, but the real reality is that the world doesn’t revolve around a single person, and when the person fails they will usually recite some other ideal such as, “everything happens for a reason” or in the case of a religious person, “God obviously has different plans for me.” The most basic truth, if you find yourself gravitating towards the ideal is this, idiocy trumps all ideals. Your idea can fail because it is simply put a BAD idea. It has been shown that most entrepreneurs fail 4 times before their first success.

Now sometimes following ideals can lead to success, but one way to limit failure is to try and reduce idealism as much as possible. Idealism can often be identified by your personal preference. John Grisham writes at a grade 9 level, if I was an english idealist and had to choose which book I wanted to sell, I might choose something with far more adjectives, but that would be the wrong choice.

You can’t make the world function the way you want it to.

Nearly 10 years ago, someone put a document in front of me it had a big confidential label across it. It was the product of millions of dollars into web site consumption. I knew someone who worked at the company, so I got my hands on it. It went over colors, sizes, and in bold letters said, DO NOT USE FLASH. I disregarded it, and continued to flash. Not even two years later it had a staggering penetration rate.

Today I find myself in an interesting situation I am developing a website using GWT (Google Web Toolkit), it is absent of any flash. This is to ensure compatibility with the iPad. This website is more of an RIA then anything, so that is why I picked GWT for this particular job.

However, I have a feeling Apple is going to back down on flash like they backed down on their power mac chips, and here is why. Android devices are quickly starting to outsell apple devices, and what does froyo have? Flash. Also I believe something else will start to happen, instead of people moving away from flash websites, they are just going to start making alternate sites for ipad, why you ask? In many cases it would be cheaper in development costs. This separate iPad specific internet I believe, while I may be wrong, will be unsustainable. 2 Million iPads in the grand scheme of things is nothing, and when android tablets start being rolled out (and they will) the iPad is going to get dwarfed like it did in the PC market.

The sites that people are starting to build now and calling compliant are essentially the same as sites made 10 years ago, except now we have png support, and the client side code structuring uses CSS as opposed to tables. The real question is why did people start using flash in the first place? The answer is pretty simple – Animation. This is the very reason why flash won’t go away, because even with Canvas (if it is supported), event with better JavaScript engines (they are getting there) animation in html5/Ajax/js SUCKS. No ifs, no buts, it just sucks. You have to remember, flash didn’t get big because it supported video, it got big because it supported animation.

So you’re a web studio and you have flash developers, you have flash websites, and you’re freaking out about Steve Jobs power trip. What should you do? I think it depends on the project.

A movie website – you will be able to make a more engaging experience with flash, but you want it to be able to work on iPad. Make two websites a flash, and an iPad compliant site. Have a big budget? Make a flash website and make the alternate website link to a native iPad app.

A web game – You’re going to have to use flash, not enough browsers support canvas yet, and even if they did JS is really slow. iPad is just out of luck, unless you make a native app.

A portal – You shouldn’t be using flash, if you want to use flash, it should be complementary and not critical.

web Video – Flash is your best bet still for broadest compatibility, but offer an iPad friendly version of the video as well.

RIA – This one hits close to home because it is what I love to build. This requires you to consider a lot of factors including what and where the application is going to be used most. If the application is intense and would not work well on a touch screen, make it flash. If it is a simple app, make it HTML/Ajax. It also depends on what kind of performance you need or are looking at. Flash can actually perform much better in certain situations. I would say if you can use HTML/Ajax, use it, it will be easier then going back later since an RIA is usually not trivial to build in the first place. If budget allows, even better then the above option is to make native applications.

So while I think Apple is going to eventually support flash or be crushed by Android in the same way they were crushed by Microsoft, I think the choice to use Flash is contextual more then anything.