Meanings behind the fancy transition effects

March 2nd, 2009  |  Published in Uncategorized

It is quite popular that websites have more and more “AJAX animation effects”(which should be JavaScript animation effects actually…). Many AJAX learners are obsessed with adding fancy animated effects on there web page, and sometimes, adding it without thinking the particular effect’s meaning, will actually confuse or disturb the end users.

In the following, I will follow script.aculo.us‘s effect naming. You may see the live effects in its wiki.

There are quite a few animation effects that are common, like fade in/out, blind up/down, slide up/down. They can be seen easily over the web and their meanings are obvious: to bring things in or out. But there is still some different among them.

For fade, the transition is much smoother then the others since there is no moving part. It should be applied on things that do not need much attention, like changing top banner’s background image, just let the users focus on what they are reading.

For blinding/sliding, the sense of changing is stronger. One of their special usages is to resize things, like panels. Since resizing panels often leads to change of layout, if there is no transition, the user may not be able to catch up with the movement of the page elements.

Some less popular effects like puff, shake are more easily to be used wrong.

For puff, since the animation ends with zero alpha, some developers may use it as disappearing effect, but that’s wrong. Since Mac OSX is using puff for a visual effect on opening files/programs, many Mac user may be confused if you use it on removing elements.

For shake, some developers may think that it can draw user’s attention effectively. Really, but we should use it carefully since shaking will cause the user not able to see the elements inside the shaking area easily. So, it takes time to let the shake stop and refocus on the element’s details and it may disturb the user’s work.

Tags: ,

The right way to work with a web service

February 23rd, 2009  |  Published in Uncategorized

Mash-up is certainly a big feature of web 2.0. It make use of different open web services to create creative apps, or even artworks. But creative is creative, “hacking” open APIs with some way might not be so appropriate.

Let say here is a blogging API

The API lets people write and read blogs in the server. For security reason, the web service do not allow HTML appears in the post content. Certainly, as a user, we hate this feature since plain text is boring and a text-only blog is likely nobody would like to read. So, developers (and even bloggers) will try their best to create some workarounds.

One developer thinks that he might encode the blog content in his software before sending to the web service, so the server will not recognize the HTML stuff and store the whole content. When retrieving back, the content is decoded before showing up to the users.

What’s wrong?

Firstly, the security problem that “patched” by filtering out HTML is come back again, like we are back to the starting point. Secondly, since the API is open, that means there are other software/programs that will make use of the API, and they all do not know the decoding method used by the developer. So, the end users of that developer’s software will be likely blogging encoded posts that no one can read without using the same software. Thirdly, this may break the terms of use of the API.

There is no hope in that case?

If you want HTML, no, there is no hope. But you might still implement other methods to work with the API.

For example, Twitter is very similar to this case, mirco blogging with plain text, but there is TwitPic, which store the picture in other server and insert the link of the picture to the tweet. Users of TwitPic is certainly seeing their picture displayed beautifully. And the normal Twitter users can still see the picture by clicking on the links. The idea is similar to “graceful degrading”.

Tags:

Some research on JavaScript benchmark

February 16th, 2009  |  Published in Uncategorized

Since I am going to make a benchmark for ActionScript performance across different browser/platform, I take a look into the JavaScript benchmark to see if I can simply port one to be used in ActionScript.

The most famous ones should be Apple’s SunSpider, Google’s V8 Benchmark Suite, Mozilla’s Dromaeo. All the benchmarks are compose of several test areas, basically including some basic JavaScript operation test like Array manipulations, some more practical based test like regular expression, ray-tracing etc.

V8 Benchmark Suite consist 6 tests which has the least tests among the three. But when I take a look into the source code, the testes are very long. It even overrides Math.random() to a seeded random generator.

SunSpider’s structure seems to be more simple and the tests inside are more easy to read (although less documented compares to V8′s). I think it should be not that hard to port to AS.

I still do not have time to look into Dromaeo’s source but it has quite a lot of tests. And some of the tests includes DOM and use of library like jQuery and Prototype, which is not quite appropriate to be ported.

My target should be porting SunSpider. But there is still some things to be considered like whether to use AS’s build-in library, coverage of Graphic manipulation etc. More researchs are needed ;-) .

Tags: ,