Archive for the ‘safari’ Category

Review: Adria Airways and NLB

Monday, June 16th, 2008

Recently two more big and very frequented Slovenian sites relaunched and I think they too deserve a mention.

Adria Airways

The first page I want to put to the test is the new page of the first and the biggest Slovenian airline. It was recently launched by my ex colleagues at Parsek as the second version to be made there. The first edition was designed and prepared in another agency and Parsek only did the backend while the new version is all Parsek. To be fair the biggest and the most important part — the reservation module — is still made by the french company Amadeus.

The new design tries to incorporate a leaner navigation with less elements even though it became wider, almost reaching the 1000px mark. The front page is much more sales oriented, displaying a lot of useful information. I can’t get past the color scheme that is really too dull. There are quite a few validation errors, the ones in HTML mostly due to non–escaped ampersands, while those in CSS are just sloppy coding without checking the validator.

I was surprised to see that some stuff doesn’t work well with Firefox 3 and Safari 3 even though the first one isn’t released yet (will be tomorrow) and the second one doesn’t have a lot of users in Slovenia. I’d still stick to what Yahoo! has to say in their Graded Browser support table for browser support.

I was positively surprised at how well some inside pages are designed down to the last dot and icon and negatively how bad the pages that “only” present CMS content look. I don’t know whose fault this is and I don’t even care, it doesn’t matter for the end user. I’m sure the guys at Parsek will check these pages out and try to make changes that will make them better. When I first saw the design while I was still at Parsek I wasn’t sure if the title on the right would work but now that I’m surfing the page I actually think it does. There is one problem there though – if you visit this page (screenshot) you’ll see that you can see its title “About us” four times in a very small area. It’s nice to know where you are but isn’t this a little bit too much?

NLB

The next big redesign is the biggest Slovenian bank which redesigned their site after quite a while. I don’t really know what to say about the redesign – the last one was horrendous so this one is easy on the eye. It too got wider and restructured so people can find relevant information easier. The home page lists all the products for residents and businesses so you can access them directly.

If the design got overhauled the backend didn’t — if it did it got it fashion tips from the 90s. Validation returns a lot of errors and — prepare for a shock — the encoding is iso-8859-2. The number of non semantic elements is significant and inline scripts are there too (<SCRIPT language=JavaScript>).

The most interesting thing about the new page is the fact that it now uses “friendly URLs”. And how utterly broken they are. You could also say this page is a textbook case for how wrong things can go when you don’t think about them. So you’ll have two pages, one at /nalozbe-v-vrednostne-papirje and the other at /nalozbe-v-vrednostne-papirje1. I have no idea how that tells you anything about how the content behind these links is different. It would tell you more if the first was prefixed with /residential and the second one with /businesses.

Another funny thing I noticed is how banners are designed to look as if they weren’t images but rather just HTML parts of the page. The reason I noticed is that I was on the Mac while checking the page and since font rendering is different it looks really weird. I think I might have seen the same difference on Vista with ClearType on.

Zemanta Pixie

Background on html

Monday, March 24th, 2008

There’s a paragraph in the CSS specification regarding the background property that states the following:

For HTML documents, however, we recommend that authors specify the background for the BODY element rather than the HTML element. User agents should observe the following precedence rules to fill in the background: if the value of the ‘background’ property for the HTML element is different from ‘transparent’ then use it, else use the value of the ‘background’ property for the BODY element. If the resulting value is ‘transparent’, the rendering is undefined.

This might lead to a surprise when trying to add a background on top of what you have on the body element – when you add a background property to the HTML element everything will shift. You can observe this in most browsers on the links below.

Before:

html {}
body {background:#fcc;}

After:

html {background:#ccf;}
body {background:#fcc;}

It seems you really have to add a semantically meaningless element…

Use Array.join instead of concatenating strings?!?

Thursday, September 6th, 2007

I read this article at Usable Type and said to myself – true, true, true, true, WTF?

So I did a quick test:

  1. Concatenating 3 long strings: without ~135ms (45ms) [25ms] {33ms}, with ~220ms (120ms) [40ms] {65ms}
  2. Concatenating 12 shorter strings: without ~215ms (190ms) [85ms] {90ms}, with ~470ms (180ms) [105ms] {165ms}

The tests were done on my laptop on Windows Vista in Firefox (IE7) [Safari3] {Opera 9.2}, the function was repeated 10000 times. It seems that you’re better off without using array.join(), though it might be an option for huge joins in IE.

I wonder what sparked the idea – I’ve seen the use of arrays for string operations in Flash – string.split(old).join(new) for replacing until a proper method was available. I’ve never thought about abusing JavaScript that way…

On a side note – have you noticed that Firefox was significantly slower than others?

Update: I created a test page so you can test your browsers and post a comment

Firefox and Opera statistics are underrated

Wednesday, September 5th, 2007

While testing browser behavior regarding inline JavaScript evaluation and the back and forward buttons I found a very interesting thing. When a script is included in the HTML to execute on parsing (not on load but inline) Internet Explorer (7 on Vista tested) and Safari 3 for Windows will re-execute the script when a user returns via the back button. In my mind this is the correct behavior, since you actually visited the page twice.

The thing is that Firefox (2.0.0.6 on Vista tested) and Opera (9.20 on Vista tested) don’t agree with me. Well maybe they do and don’t live by their beliefs. What they do is nothing. You come back and no scripts are executed. Not even one request is sent to the server in Firefox.

This “feature” is sometimes a great thing – all the AJAXy stuff and all the JavaScript enhancements are already there and don’t need to be rendered again in turn saving power and time. At other times it’s a pain in the a** since some stuff does return to its default state and some doesn’t. This problem is most often observed with dynamic/advance forms that lose their default values/states. Since even onload is not fired this can get annoying…

Besides all the interface problems you might encounter due to this “rogue” behavior, there are also a few issues regarding statistics. It’s harder to inspect the path of a user, the time a user spent on a page, the number of page views in a visit and other related metrics. The other significant issue is that browser usage statistics might be skewed. To answer this last issue we’d have to know how these statistics are measured.

Let’s take a user that is used to clicking the back button while navigating a site with a 2 level deep navigational tree. She comes to the page, goes in one branch and then to a second, very distant branch. Internet Explorer would register 7 page views (1 on the root, 2 to get down, 2 back up and 2 more down), while Firefox would only register 5 page views (1 on the root, 2 to get down, ignore the 2 back buttons, 2 more down) – a 1.4:1 ratio.

If the statistics are based on sessions or unique users we have 50% IE and 50% FF. If we base them on hits we have 58% IE and 42% FF – a 16 percentage point difference or as we said before a 40% difference. This is not something you could just ignore…

Exercise for the reader – why do “unsupported” browsers always have a small browser share in hit based browser metrics?

Impressed by Apple

Sunday, June 24th, 2007

Safari for Windows is already in 3.0.1. No, they didn’t fix this flaw, they fixed the other one. Nonetheless, I’m impressed…

After another look at my blog I figured they changed another thing – Google AdSense ads now show up.

Update #1: I’m writing this in Safari for Vista 3.0.2 – for the third time. I cannot shake the feeling that there’s something wrong with submitting the textarea in WordPress. In any case – strongs are now bold and even AdSense appears sometimes. All these issues make me wonder if things appear the same on Safari/Mac and Safari/Win which was a big point in releasing a Windows version…

Update #2: I’m posting the first update in Firefox – exactly as written in Safari. I posted it twice without it appearing on the page. The third time I copied it and found out that it only copies the code until

Safari on Vista

Tuesday, June 12th, 2007

Apple released Safari 3 beta for Windows.

It doesn’t work that well:

Bold fonts in Safari 3 beta

Hopefully a “yet” should be appended to the end of the last sentence.

Update: PPK writes about this bug and it is suggested that it’s a graphics card issue. My laptop has Mobile Intel(R) 945GM Express Chipset Family graphics card. If you’re experiencing the same issue add your graphics card in a comment…