Today is a good day to code

Adding Machine Learning to Nc3 Bb4 Chess

Posted: September 29th, 2011 | Author: | Filed under: artificial intelligence, chess, JavaScript, nc3bb4, Programming | Tags: , , , , | No Comments »

While the garbochess engine is plenty strong used in the Nc3 Bb4 Chromebook chess game, I thought it would be interesting to look at adjusting the weighting mechanism by sucessful and unsuccessful outcomes.

The first thing I had to look at was how garbochess weights potential moves.  This took me into the super interesting world of bitboards.  A quick aside,  I have been working on mapreduce for the past few weeks, so looking at early methods of dealing with big data ( chess has an estimated ~ 10120 ) legal moves, in order to successfully evaluate all of the possible moves for a given position, plus all of the possible counters, weight them and choose the best possible move given criteria certainly qualifies as big data.

Interestingly, the approach wasn’t the hadoop approach, the hardware to use such brute force methods wasn’t available, instead early chess programmers tried to filter out undesirable moves, or obvious bad moves, moves that had no clear advantage, etc… What they ended up with was a pretty manageable set of moves for a circa 2011 computer.

The way garbochess considers moves, it looks at mobility for a given piece, control of the center, if a capture is possible, what the point differential for a trade would be, etc… and assigns a score for each possible legal move, it then runs through it repeatedly re-scoring the set relative to the available moves, removing the lowest scored moves, etc… eventually coming up with the best possible move.  What I wanted it to consider, was given that and the specific weights, mobility vs actual point value for a given piece, to use a markov chain for reinforcement learning to describe the entire process of a game and then rate each move with a weight enhancement upon endgame moves as being more important.  Every time the machine takes an action that leads to a success, the heavier the bias on the scoring for a given action.  Failure doesn’t automatically nullify the learning, but it definitely has an effect.

Where I got was a rudimentary implementation of this, as a bunch of housekeeping chores popped up, for example, as this is JavaScript, and all I really have is HTML5 storage, how do I store all of the moves while keeping the system responsive, no O(nn) or O(n2) lookups, what I wanted was to keep it O(n). Obviously that called for a HashMap of a sort, but the serialization / deserialization plus the key system were a challenge.  I didn’t want for it to cause too much overhead for the map / scoring system, as the bit twiddling is already pretty efficient, so I did the best that I could using the FEN + PGN.  The FEN is the state for the markov chain, since one could have a given PGN in many situations, and the weighting system could never be applied against the gravity of the situation.

I need to do more work on weighting changes based on how in trouble the machine is, whether they have an advantage or not, etc… But for a start with machine learning in chess, I think it works.


Why My Faith in HTML5 Has Been Reinstated ( Or How I Learned *again* to Love JavaScript )

Posted: July 13th, 2010 | Author: | Filed under: CSS, JavaScript, Programming | Tags: , , | 1 Comment »

Over the long weekend, I was lamenting over how many times I had to write the same routines in different languages… Objective-C, Java, PHP, etc… I realized that I have, and would have wasted tons of time writing native code, and how, really most of the functionality of the application can be handled with various features of HTML 5.  Originally I had been against this, but now that the iPhone has finally caught up and has a reasonable processor, I think that the HTML5 experience can be nearly as good as native.

The funny thing is that much of what is driving my decision is the desire to have my applications have data and interfaces that are available everywhere, mobile, web, desktop, etc… aka, the original promise of the web.  Using local caching, the JavaScript key/value store, and the database will help to allow me to provide a compelling disconnected use experience.  The code that I write will be useful across all of the platforms that I use.  The one caveat that I am making is that I need to focus on one browser, or approach, and for that WebKit based browsers seem to be the logical choice.

Now I realize that not all of my application concepts will be possible with HTML5 and JavaScript, however this recent thought experiment I realized that most of the features that I would have normally insisted needed to be done natively can be done with HTML5.  The biggest issue that I have run across is the 5 MB limit on database sizes in Mobile Safari.  I know it was there in iOS 3.x, I don’t think they have lifted this in the current OS.  The other issue is the forced UTF-16 encoding of characters.  While I understand this technically, it makes it difficult to store data larger than 2.5 MB on a device in the SQLite storage available to JavaScript.  The approach taken in desktop Safari, where you can ask the user to increase the available size if your database creation fails is a much better approach.

Another interesting pattern that I see emerging is that of utilizing HTML5 as the UI tier, and establishing the business logic and control structure behind a HTTP server that would expose additional native functionality to the HTML5 app.  The benefit here is that your local server implementation could match the remote server implementation, such that your client APIs could remain consistent.  This seems to me to be the best architecture for minimizing the work involved with porting solutions across platforms.  I absolutely love Cocoa and Objective-C, I enjoy the concepts behind the Android APIs, while despising Java’s syntax, and I think that .net is pretty cool as well, however when it comes to getting applications deployed to the maximum number of users in the leanest manner possible, I think it makes sense to leverage the web heavily up front, and then backfill the native implementations as necessary.


The Future of The Internet May Not be HTML5

Posted: May 7th, 2010 | Author: | Filed under: CSS, JavaScript, Programming | Tags: , , , | 1 Comment »

A few days ago, Joe Hewitt wrote a Twitter tirade about how web development has been stifled by the glacial nature of innovation at the w3c which caused a lot of reactions across the web, even some from Google.  Joe Hewitt also quit developing for the iPhone because of the App Store’s policies.  I have been thinking for a while about this, and it is what makes me want to write a web browser.

I agree with Joe Hewitt about Cocoa, the framework is awesome, for someone who has been fighting browsers for control of the UI for years, it is like a breath of fresh air.  However, this is true for any native rendering solution.  It is part of what makes it hard for me to go back to developing web applications.  I like JavaScript, but HTML and CSS not so much.  Talking it over with friends, and thinking about it further, I think that HTML5 may be exactly the wrong direction for us to be taking the web in.  Before you click away, this is not some “Apple should allow flash” argument.  I am thinking about this on a deeper level, about the types of applications that we are making today on the web, and some of the issues we are bumping our heads against.

The web has been good at delivering applications with zero-install, as well as presenting formatted documents.  The latter is what HTML was designed for.  XHTML was created because HTML was overstepping its bounds.  Currently I believe, even though native developers tend to look down on web developers, that developing a web application is one of the single most difficult challenges for modern development.  There are multiple languages that one needs to master, each with a different metaphor, syntax, and implementation.  There is overlap between the languages.  There are latency issues, networking issues, lack of resources on the client, these are all incredibly difficult things to deal with in general even with native implementations, the problems with the web exacerbate these issues.

At the heart of the problem is that with native frameworks and systems, you expect for everything to be different as you move across platforms, business stakeholders have an appreciation that moving from a Windows app to a Mac app will be hard, and they will staff up and provide the appropriate resources to do that.  In truth, coding a cross-browser application is no easier, however the issue with web development is that it appears to be easier.  HTML looks like a ubiquitous rendering language, it appears as though it would work exactly the same across the board, but it doesn’t and it likely never will.  JavaScript appears to be the same language across the browsers, but nothing could be further from the truth, it performs, and behaves differently in each.  CSS seems like it would be identical since all browsers comprehend the same syntax, but the same style can appear vastly different across the browsers, and in some not appear at all.

That is the current situation, and we are pressing further into the problem instead of dealing with it.  My opinion is that HTML should be present in browsers as a legacy rendering system.  What I would like to see is a raw vector based rendering engine, similar to the canvas tag, as the browser view that will give me, as the remote agent, the size of the window and the capabilities of the browser, such as audio, OpenGL, Sound, DirectX, etc…  It should also tell me what the origin of the screen is, UL, UR, LL, LR so that I can give the correct rendering directives.  It should send me a list of the languages that are supported, or are enabled by the user, binary, javascript, ruby, python, etc…  Then the browser should progressively download the code and execute it as it receives complete instructions.  The binary stuff could be jitted using LLVM + an appropriate front end, and cached.  The memory addresses could be sandboxed and virtualized.  The user could set heap sizes for the amount of memory that the applications were allowed to use.  Google’s native client is a step in this direction, but it doesn’t go far enough.  Scripting language code could be executed pretty much as it is.  This would allow the frameworks to control everything about the experience, as opposed to the browsers.  Innovation could happen overnight, and browsers would be more responsible for enforcing security policies than rendering.

The benefits of this approach, full on applications could be developed as one stack and would appear on the client as the developer wished.  The performance would be insane, the execution environment would be simplified such that we could develop an adequate sandbox.  Authentication would be up to the developer and would be native, many of the security issues would go away.  One could code their application as code + data to render as pages easily.

What are the issues with this approach, no one has managed to build an adequate sandbox, however as we have seen JavaScript + HTML isn’t really a great sandbox either, there are tons of exploits out there.  The delay in downloading the initial code, although with progressive execution, this should be mitigated.  The biggest issue is lack of crawlability.  This is where XHTML 2.0 comes in.  If your content is available as resources through a service, instead of crawling your app, your content could be crawled.  This would dramatically improve the value of search engines.  If you give an appropriate resource id, the engine could point the user to a URI that would render the content in your application instead of raw, or the crawler could be an application that shows your data in a slightly different format.

I think that native jitted code + data mixed together are likely our future, especially watching how the App Store is taking off with consumers.  Even they seem to be choosing native applications delivered over the internet over web apps.  I think that this is a primitive method of what I am describing, but the benefits to the end user and for the user experience are clear.


Mides 1.7 New Features and Changes

Posted: January 25th, 2010 | Author: | Filed under: Apple, iPhone, JavaScript, mides, PHP, Programming | Tags: , , , , , | 2 Comments »

I wrote Mides originally to help me to write web applications when I am on the go.  A huge part of web application development is JavaScript.  The iPhone / iPod is an awesome device for heavy client JavaScript apps.  So as a result, I added JSLint in Mides 1.7 to make debugging JavaScript easier.

The main problem with the developer setting in Mobile Safari is that it is inaccessible to other applications.  Since one of the main purposes of Mides is to enable development with either no, or an unreliable internet connection, it wouldn’t be possible for Mides’ internal HTTP server to run and serve the mobile safari application with content.  This is the entire reason I wrote an HTTP server for Mides, so that JavaScript XHRs would work correctly for testing.

What I have done to help out with JavaScript debugging is to modify Douglas Crockford’s JSLint library slightly to make it work on the iPhone.  It helps out with outright errors, but also with many excellent tips for writing safe and readable JavaScript applications.  You can see the errors and optimizations by tapping on the burst and exclamation point icon when it appears over your JavaScript or HTML.  This feature is optional and can be disabled in the iPhone settings.

Another issue I wanted to address with a new feature is that I always forget the argument, or the exact PHP method call that I want to use, especially around MySQL.  I already had the documentation in there, but since it is a full-text search, it tends to take a while.  So I added a new feature that allows you to look up just the method signature, that is the method name and the arguments to the method.  I didn’t want to put a button in there for this, it just didn’t seem right.  I tried for a while to come up with something usable, and I think I have figured out something that works.  You just need to twist the phone to the right ( or left ) to do the code-completion on the method.  If the text before the cursor matches one or more PHP method signatures, then it will add that value in context, in line into your code with the argument types.  If it matches more than one, it will display a modal dialog that will allow you to choose from the top 5 PHP methods that match what you have typed.

One fix that a customer asked for on getsatisfaction.com/mides was that I make tabs parse properly.  I also added that in Mides 1.7, now your tabs will be properly displayed.  To create a tab, just space 5 chars into the document.

I am adding features both at the request of customers on the burgeoning community on getsatisfaction, as well as through my own usage of the product.  I probably won’t implement all of them, but please keep the suggestions coming.  They help tremendously.  Some of them are really tough to implement, but if they make it more usable I’m all for it.

One of the main issues around Mides is moving files onto and off of the phone, Apple hasn’t made it easy, and FTP is not the best solution, it is a nightmare to support, and difficult for users to set up.  I thought about having a small application that you could install on your Mac and PC that would make it much easier to transfer files with, but this didn’t seem like the best solution either.  I am actively thinking through better ways, but nothing so far has really stuck.

At any rate, I am constantly trying to make Mides more useful, I know it has been rough, but I’m glad to see that some of you are starting to get real use out of Mides.  I hope to keep making it better and eventually to rival and in some ways improve upon the desktop coding experience.


CSS 3 Keyframe Animations: A Step Too Far

Posted: April 16th, 2009 | Author: | Filed under: CSS, JavaScript, Programming | Tags: , , , , | No Comments »

I understand the desire to push the development of web based applications to the next level, and allow them to truly compete with their desktop counterparts.  I like the functionality with the new perspective properties, keyframe animations, transformations and the like.  For years we enjoyed these features as part of Flash, which could never really figure out what it wanted to be.  Was it a programming environment or some sort of design environment?  We continually had poor tools that we made the best of to do some incredible things, but I think its time to take a step back and look at what we are actually doing, and where web application development should be.

For example, have a look at this syntax for defining a keyframe animation:

@-webkit-keyframes 'wobble' {

0 {

left: 100px;

}

40% {

left: 150px;

}

60% {

left: 75px;

}

100% {

left: 100px;

}

}

This is strange in that we are now defining properties in CSS.  This is ultimately a named structure which defines the behavior of a function, that doesn’t exist to, and is not accessible from JavaScript, the supposed language for logic and control.  The problem here is that we have variables and objects that are outside of the scope of the primary programming language.  This creates a second language with overlap, and set of objects that controls and defines data for UI behavior.  So far, the only functional code in CSS is via the pseudo-classes such as :hover which can then trigger the animation or transition outside of JavaScript, but it wouldn’t stretch the imagination to see a future where CSS is doing more.

With HTML 5 we are packing more functional logic into the “structured data” tier of our web applications, which undermines MVC and creates unique problems to developing web applications that traditional desktop application developers do not face.  The complexity introduced by making developers use 3 different functional languages for UI, each with their own data objects, variables, and execution or functional code should not be underestimated, not to mention the complexity of the language they need to use for their application server and its interaction with JavaScript / CSS / HTML  languages.

As more desktop applications are moved to the “cloud” the engineering effort required to build applications approaching the complexity of Eclipse for example would be daunting, and could perhaps be more expensive than developing it natively for each platform.  This is due to platforms becoming less diverse as time goes on through things like Mono for ( C# ), Ruby and Java on Linux, these same things with native UI bridges on Windows and Mac OS X as well.

I don’t really want to see that happen, but for the web as an application development platform to mature, I think these languages need to be consolidated.  Typically in a normal windowing environment, such as Windows, Linux, or Mac OS X, there are libraries that are typically written in C / C++ that drive the UI and access to the hardware.  Previously, a developer would write code to that specific library on a specific platform for performance reasons, and be required to maintain multiple sets of controller / model code.  The performance reasons for doing this today are fading, so abstractions like the Cocoa – Ruby bridge are becoming more prevalent.  This allows a developer to implement most of their business logic once with a minimum of code dealing with specific platforms in the language of their choice.  Most of this code is usually portable to other platforms, including web.

The increasing complexity in web development, and decreasing complexity and homogeneity of desktop platforms / hardware, is setting up what I believe will be a renaissance of desktop style development, or mono-language application development.  I think, however that the new class of desktop / mobile native applications are different than the traditional applications in that their model may be in the cloud with just a data cache on the actual client.

I believe that this approach, having a cloud model with a less complex native client rendering content, represents the best of both worlds.  A robust service based model that makes tables of data accessible to the client, whatever its configuration is optimal for keeping your options open on the UI implementation.

You get the power of the local CPU, a reduction in complexity by utilizing the same language on the back end as the front end ( possibly ), and the flexibility of having the data model in the cloud by writing native clients in Ruby | Java | C++ | Cocoa.  There is a side benefit of being in closer compliance with the MVC pattern that should help reduce complexity and promote code reuse and readability.

Most web developers are doing this today, but they are doing it either by not using HTML / CSS and focusing all of their efforts on JavaScript, and treating HTML as the basic building blocks of a widget approach, building up the “windowing system” themselves, and then using another chunk of JavaScript as the “controller.” Or they are doing it by pre-generating the HTML / CSS / JavaScript on the server, and abstracting it away into their native language ( GWT as an example ).  Both approaches are fine, and they work, but they do not address the increasing complexity of the resulting applications.

I think that the most effective method for solving the problem is, as always, to meet in the middle.  XUL was an early attempt at this, but it still ended up requiring developers to use multiple languages.  What I am hoping to find time to work on is a browser that does all of the existing standards compliant stuff, but in addition to that gives developers a method to use the native windowing system through a scripting language, sort of like using JavaScript to do desktop application logic, but that is downloaded from the server and cached on the client in the HTML 5 manifest method.  The resulting application would use only that language for all UI and logic. The language would be required to bridge over the 3D engine ( OpenGL ), a widget interface that looks like native windows ( could still be web based behind the scenes ), and the sound APIs.  More importantly it would have to handle binary data as native objects and streams.

I think that currently the languages that are good candidates are Ruby, Python, and JavaScript.  Ultimately it would be best if the web application had access to the camera and other hardware with the user’s permission, but I don’t know if that is really required or desired,  Flash currently does a good job of managing permissions around this stuff, but I think more sandboxing is needed for something of the scale I am thinking of.  Microsoft tried it and failed with Active X, which was a good idea, but gave too much access to the local machine.  I’m working on it, but I’m just one guy with a day job, so it takes me a long time.  Eventually I’d like to make it an open source project, but I’m a long way off from it.

To sum it up, I think that for the web languages to keep going the way they are is courting disaster; making CSS more beefy and complicated isn’t a good solution.  Already JavaScript, through the canvas tag, is impinging upon CSS’s supposed territory, but most of this display stuff should have been there exclusively from the beginning.

There is too much overlap between CSS / JavaScript and HTML.  We will be stuck with fail whales everywhere because there are too many points of failure, and too many areas to specialize in.  Even if IE fully embraces web standards the general development pattern will be too complicated to support the pace of development, and the complex feature sets available in desktop applications.  If you look at the cost of hiring a CSS specialist, a JavaScript specialist, and a server side specialist, web startups will be more expensive than desktop or mobile native app startups.  Hiring a “mono client” specialist that can do all of the things that previously required 3 people, it will reduce to cost of application development in the way that AJAX did originally, and keep the the more ambitious web startups viable.  Today for example I saw a startup offering to do video editing through the browser, wow!  The future is super bright for web development, but I think some refactoring is necessary to fuel the next surge of productivity.


Which JavaScript Framework is the Fastest

Posted: April 8th, 2009 | Author: | Filed under: JavaScript, Programming | Tags: , , , , , | No Comments »

I have been wondering for a while which JavaScript framework is the fastest. I was thinking about writing some sort of test to try to determine which one had the best speed, but I have found one that seems to work. Mootools SlickSpeed Test is a good start.

It seems to focus on DOM manipulation / access / iteration speed, rather than testing the functionality built into the frameworks. I suppose that it would be tough since each framework offers different things. When I ran the test, Prototype 1.6.0.2 was the slowest, YUI 2.5.2 was the next slowest, MooTools 1.2 was next up from the bottom, JQuery 1.2.6 was the second fastest, and Dojo 1.1.1 was the fastest by a wide margin in Safari 4 beta, albeit with some errors.

In Google chrome 2.n beta, the results were as follows:

  1. JQuery 1.2.6
  2. MooTools 1.2
  3. Dojo 1.1.1
  4. YUI 2.5.2
  5. Prototype 1.6.0.2

In Firefox 3.0.6

  1. MooTools 1.2
  2. JQuery 1.2.6
  3. Prototype 1.6.0.2
  4. Dojo 1.1.1
  5. YUI 2.5.2

In IE 8 ( Wow IE 8 is slow )

  1. Dojo 1.1.1 ( many errors disqualified )
  2. JQuery 1.2.6
  3. YUI 2.5.2 ( a few errors )
  4. MooTools 1.2
  5. Prototype 1.6.0.2

iPhone Safari ( DNF / Could not run / Simulator)

  1. JQuery 1.2.6
  2. MooTools 1.2
  3. Dojo 1.1.1
  4. Prototype 1.6.0.2
  5. YUI 2.5.2

Android Browser

  1. JQuery 1.2.6
  2. MooTools 1.2
  3. Dojo 1.1.1
  4. Prototype 1.6.0.2
  5. YUI 2.5.2 ( Big Suprise )

What is interesting about these tests is that in general it seems that you should use JQuery if your development pattern involves heavy selector use. I still prefer Prototype because of the programming features that I get with it, even if the selector part is slow. IE 8 breaks a lot of the frameworks. Prototype and JQuery hold up the best it seems. I haven’t really looked at MooTools however.

On mobile devices, you should think long and hard about using any framework that involves added overhead since the devices are really slow. It seems that Dojo supports the built in Safari functions for dom navigation or something. It was wicked fast in Safari 4, but had a few errors. Overall JQuery is probably the best. I guess I’ll have to take a look at it, though reluctantly. I still need to write a test to check iterator performance though.


Safari 4 – Worker Threads… JavaScript Domination

Posted: February 24th, 2009 | Author: | Filed under: Apple, Companies, Google, JavaScript, Microsoft, Programming | Tags: , , , , , , | 1 Comment »

I do hope you will pardon the hyperbole a bit, but If someone had told me a few months ago that we would have JavaScript threading, which I have been begging for for years, built into the HTML standard.  I would have thought they were crazy.  Now we have a situation where Safari 4, Firefox 3.1, Chrome ( Gears ), and IE 8 ( all in beta ) support it.

Lets look into my crystal ball for a minute.  We have a situation where browser based apps are becoming more and more capable all the time.  Where arguably the most efficient method for developing against mobile devices is to use web technologies, and where we have an insanely awesome JavaScript engine available for general use in any programming system in Chrome.  Looking down the line, I can see that JavaScript will be the primary development language once we start seeing implementations for HTML 5 Web Sockets.  It may be there, I just haven’t checked yet…

If you have Safari 4, or the webkit nightlies, you’ve got to check out this link:

JavaScript Ray Tracer

The speed of JavaScript as an interpreted language is up there with any of the others, in fact, Firefox 3.1, Chrome, and Safari 4 are wicked fast.  Soon, we may not need desktop apps at all, and Microsoft’s bungled ActiveX dream may just come to pass.  What an exciting time to be a developer!


I Finally Found a Real-World Use For AJAX

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

I Finally Found a Real-World Use For AJAX

Picture of Irv Owens Web DeveloperI'm working on this project now that makes heavy use of standard javascript, Flash, ColdFusion, and HTML. The project is using the TCallFrame javascript function to control the flash movie. Because of the nature of the project, the timing between the movie refresh calls makes using a refreshing iFrame not possible for the text information that I need to display. Likewise, the text needs to be displayed using complicated styles and colors, controlled by ColdFusion components that Flash can't handle easily.

So I was faced with a dilemma. I couldn't refresh an iFrame without throwing the timing of the TCallFrame request, combined with some javascript cookie writing, I didn't write the original application, and Flash remoting calls. Basically, nothing should happen until the cookie is written, which it doesn't, most of the time.

It eventually dawned on me, not only that the application needed to be strengthened with some type of cookie listener at the very least, and a small-scale rewrite at the most, but that I only really needed the application to think that there was no iFrame refresh, but an AJAX call using an invisible iFrame could work.

So I began working on it and it evolved into a two-part system. On one hand, the div that contained the text to be returned from the ColdFusion components needed to be continuously refreshed, which I found out after struggling with another timing issue. Eventually I realized that the variable that needed to be set in my parent window was empty at the time of the screen refresh because the iFrame hadn't finished loading yet.

So what I had to have happen was for the iFrame to make a javascript function call to the parent once the variable was written. Once I had that accomplished it was easy to have the checkboxes that called the TCallFrame javascript call the function to refresh the iFrame. It worked wonderfully, but unfortunately it still caused a timing issue with the main movie. It delayed the writing of the cookie by a hair. Still it was cool to see, that I had an actual use for AJAX.

I have actually found other uses for it, but none as clear cut as that. Flash just wasn't flexible enough. I'm not reversing myself, I still think that Flash should be most developers' first choice when it comes to remoting, but in a pinch AJAX is allright!


Why Flash is Still Oh, So Wrong for So Many

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

Why Flash is Still Oh, So Wrong for So Many

Picture of Irv Owens Web DeveloperI have recently come under some minor pressure from various factions about why, while knowing Flash fairly well, I am always reluctant to design and build a flash site featuring the technology. My history with Flash is pretty much the same as most other developers. My first versions of this very site three or four years ago were made entirely in Flash, as were many of my customers sites. Flash seemed like the way to go. It rendered the same in every browser, fonts weren't an issue, and it allowed an incredible amount of freedom to create.

So why then were my sites so problematic. The first issue was one of bandwidth. I had music and lots of motion on these sites. They were extremely interactive and eye catching. The problems came up when users had to come to my site using dial-up. When they hit the site and saw the loading bar, the first thing they did was to click back and go on to another site. My webtrends illuminated this for me. My next step was to go more minimal, which is my favorite thing to do, but then I wondered why I was using Flash at all, because now the motion was mostly gone, and so was the majority of the interactivity. I was using flash simply for the z-index, and I was finding that I could do this with CSS. So, not to be deterred, I did another redesign that kept the motion and interactivity, but minimized the huge bitmap graphics that were giving me the long download times. Instead, I used vector graphics. These were much smaller, but now I had a new problem. If my clients didn't have at least a Pentium 4 running at greater than 2 GHz, my site ran slowly, so slowly that it was almost unusable.

The next issue was that in all the time I had my site, I could never find it using search engines. I discovered that search engines couldn't index my site because they couldn't see through the Flash. To the spider, my site looked like a huge gif in a HTML file with some meta-tags. In other words, it looked like nothing. I tried alt tags, no script tags, etc… but nothing helped. Finally, I decided to design an alternate site for dial-up users using good ol' XHTML and CSS. I found that as soon as I uploaded the file, the search engines had me, and no one ever visited my Flash site anymore.

Suffice it to say that I took my Flash site down. Later, I would redisign my site again so that it would adhere to web standards and could render even faster for all users. That site is this one, and it is the first that I am happy with. I am enjoying some minor success with getting listed on search engines and blog aggregators, and life is good.

I don't hate Flash any more than I hate Allen wrenches or crowbars. It is a tool, and typically you try to use the right tool for the job. It seems to me that many web developers, however are trying to use a sledgehammer to staple two pages together. It just doesn't work. In some cases Flash is OK. In corporate settings, Flash is an excellent tool for presentations, product demonstrations, promotional materials delivered through the company intranet, or from the presenter's local hard drive, as long as it doesn't have to be delivered over the web.

There are a few cases where it is perfectly reasonable for designer / developers to build flash-only web sites for people. Art sites, such as photography showcases can benefit from Flash and its fantastic bitmap compression. Flash photography sites can often download faster than their HTML / CSS counterparts due to smaller image sizes. Some product demonstrations can benefit from Flash and its interactivity. Many cellular phone providers have used Flash to great effect in this regard. Simple branding banners contained within standard HTML / CSS pages with limited motion and interactivity can be excellent, as long as the text of the page is available for the user to read while the Flash is loading.

Still, designers and developers need to ask themselves, what exactly am I trying to do, and who is my target customer? I have had a very hard time making a solid business case for Flash on most of my ecommerce and business sites. Flash, like ColdFusion and Chess, takes only a minute to learn, and can take a lifetime to master. There is a lot to Flash, and a good designer knows how and when to use it to make a site look more professional, or to enhance content that may otherwise appear to be bland. However, beginners seem to tend to develop only in Flash because it addresses many of the apparent problems with XHTML / CSS. Those of browser incompatability, having to learn JavaScript, etc. Someone with limited knowledge of ActionScript and no knowledge of HTML is able to open Flash MX 2004 and create a website. Many designers use Flash exclusively, for this reason.

It seems that XHTML / CSS / JavaScript is having a renaissance. With the proliferation of blog sites, and better browser support of web standards many Flash sites are starting to look tired, and compared with the relative quick response of the HTML sites, many users are deciding to click away from the loading screens in favor of a site with similar content, or products, that is designed in standards compliant XHTML. Not because they love web standards, but because to the user the XHTML site works better and they don't have to wait. I have actually heard designers say that they don't care if dial-up users can't access the site, it has to be beautiful. This thinking is bankrupt, probably 80% of the country is still using dial-up. BroadBand is still frequently ridiculously expensive, and until this changes Flash will be limited to design and car sites mostly, while the bulk of the web is built using XHTML.

I'd actually like to see that change. I'd like to see 3 Mbps synchronous connections standard in every home across the country, and Flash sites loading instantly, but the reality is that it won't happen within the next 5 to 10 years. At least not until garbage cable company decides to charge reasonable rates, and build better fiber backbones, and adequate DNS resources.

In the meantime, I'm quite happy with CSS / XHTML. It does everything I used to do with Flash, but it does it faster and is more accessible. Hopefully more designers will build standards compliant sites, and will realize they can be every bit as beautiful as Flash sites. Check out csszengarden.com to see other great CSS designs.


Microsoft IE Developer Toolbar

Posted: December 31st, 1969 | Author: | Filed under: JavaScript, Programming, Uncategorized | Tags: , , | No Comments »

Microsoft IE Developer Toolbar

Picture of Irv Owens Web DeveloperI didn't even know about this and it has been out for about a month. Microsoft has heard the cries from web developers used to using Firefox's developer toolbar extension. While it is often pretty easy to validate your pages using Firefox, see how your block level elements are behaving, and look at the DOM of your page using the Firefox extension, it has been almost impossible with the awful lack of tools for Internet Explorer. They have finally addressed this.

The new IE Developer Toolbar has almost everything that its Firefox adversary has, except for the strong javascript debugger. This is very upsetting especially considering the lame debugging that is built into IE today, but with the relative dearth of tools for internet explorer, anything is welcome.

I have found the toolbar to be extremely useful. The DOM inspector is wonderful in that it highlights the selected item if visible to indicate for which item you are viewing properties. If you have to build applications or websites using Internet Explorer at work, I hope you are designing for Firefox at home, no… I guess you always have to design for Internet Explorer, then you will love the new toolbar. I'd suggest that you download it and install it right away.

IE Developer Toolbar