Any webdesigners in the house?

[Jari]

Don't worry, I'm not looking for free help.

I was just wondering - since we have at least couple of creative topics now - if there are any webdesigners here, and if they'd like to show off.

I dabble with webdesign occasionally - have done it for living, as well. My current project, which might or might not ever get finished, is this.

Right now it's totally unoptimized, more or less broken proof-of-concept. With markup that would cause a seizure to puritans. It does validate, though, surprisingly enough. I was certain that it wouldn't... Not to mention that it's so emo that it would cut itself, if it could. It's also a very good example of style over substance design, something I often end up doing when I don't have a client restricting what I can or should do.

One day it might turn into a Wordpress-theme with couple of neat tricks up its sleeve (you haven't seen all of it, yet). Or not. It all depends.

[Grimmy]

The broken glass is a great idea, but it should be more transparent. Overall the concept and execution are good. I personally love lorum ipsum dummy text in anything. I used flash and weaver to make sites and never had such great results.

[Jari]

Awww, thanks for the comments.

The glass originally was more transparent - and darker. It however turned out that I had yet again forgotten that some Photoshop layer blend modes don't really translate to transparent .pngs (as they use data from the underlying layers to calculate the effect, and you can't do that in a browser), so I had to ditch that idea and without the gradient overlay set to... well 'overlay'-mode, it was too transparent for my taste - I guess I wanted something to show for so expensive file; that overlay eats ~400KB each time it gets loaded. So, a big no-no in regular use, but I don't plan to have that many visitors, besides I has no bandwidth cap on my host. This is meant to be blatantly artsy fartsy site, and users can upgrade their connection, if it's not fast enough for them, for all I care. That doesn't mean that I wouldn't optimize it - quite the contrary - I just won't be shedding any tears if it turns out to be considerably heavier than your average website.

For that matter, the background was more of grey/silverish/blueish, so it has already once changed color scheme during the desing. The original background image proved to be quite unsuitable for tiling, although quite pretty.

I'm akshually going for a slightly dirty glass, and having a some kind of imaginary light source shining on it, the metal background should be bit lighter in the same place the glass is lighter (and less transparent).

Anyway, I did a small experiment.

Site a.

Site b.

Look pretty much the same, right? They were meant to look identical, but after a small mishap in Fireworks, they are teeny weeny bit different looking - it's not intentional.

Site b is actually 10% lighter in filesize than Site a, yet it loads 20% slower. Care to guess why?

It's because Site b makes 27 requests to the webserver, saturating the maximum allowed simultaneous connections, while Site a only makes 4 connections. In other words, Site b builds the broken glass overlay of several smaller images (which to my great surprised actually compressed better than one large - I expected it to be other way around, due to overhead and stuff), while Site a uses single image, and each div just show a small part of it. It's Intertubes magic!

Anyways, considering that you all seem so terribly interested, I probably better stop typing and go back to tweaking. Next up; some fancy JS.

[Jari]

Shameless double-post!

Le Progress.

• I'm doing technical stuff now, thus it's missing some of the things the mockups had, and is using borrowed navigation arrows, for example.
• I suppose it's a Wordpress theme in a sense now; it's running on top of WP and displaying the posts - that's pretty much all it's capable of right now.
• Most of the heavy lifting is done by Viewport - or what's left of it; that thing resembles Viewport less and less after each tweak.
• It will have traditional navigation as well when it's finished, in addition to the Coda-slider stuff.
• Yes, it's unreasonably heavy. Content sliders are not really meant for moving such amount of pixels. It's okay in Safari, Opera and Firefox though, on my system. Then again, on average system it might be slowish. It runs rather horribly on IE, but then again; IE is rather horrible.
• Flash would probably be way more suited for my goals, but then I'd a) have to learn Flash b) make it interface with Wordpress. No thanks.

Next up is probably bit more JS-trickery for the traditional navigation interface.

[Timu Sumisu]

i can do flash! a little less so in terms of actionscript, but if ye need nething animated lemme kno!

[Jari]

Thank you.

For now I'll just tinker on my own, it's not a very serious project, and if it ever will truly materialize, it'll probably be mainly for myself. But I'll keep your offer in mind.

[Jari]

Le update.

• Switched from Viewport's content slider implementation to this. Mainly because with this one you can implement a support for incoming linking; it displays the slide URL in the addressbar, and if you use that URL... you'll end up viewing that slide. It's not flawless yet - the slider gets confused if you do that, and thinks that you are on the leftmost slide, so pressing the next and previous-buttons will have an interesting effect.
• Trident is ass-buggingly slow. But surprise of surprises; you can get quite decent JS-performance out of IE8 when you force it into IE7 compatibility mode. There's just one issue; how to do that? If you use the meta-tag, you'll have to place it before the doctype-declaration, or it won't work. That very much breaks validation. Solution: have Apache sent the string as reply to browser's HTTP request. Won't break validation, and IE8 obeys it.
• IE8's support for transparent png alpha blending is STILL broken. It has been since IE6. Sure, it has almost worked since IE7 - only the gamma has been fucked up... except... when you try to make a transparent png with alpha channel fade in or out. Then it breaks horribly. The fix? Very same method that was used to fix IE6's broken alpha support. This introduces another problem, though; IE8 won't obey opacity set in CSS anymore. No matter what I tried, I couldn't get it working. Solution: manipulate opacity from JS.
• Do note the fancy ass font used in the post titles. No, it's not an image. Nor Flash. It's actually done via JS, on the client end, with cufón.
• Also, note the obnoxiously large and very l33tly glowing-fading navigation arrows. This is what I needed the IE8 png alpha fix for.
• And see the awesome accordion-effect in the traditional navigation links. BTW, only the ones under 'Recent posts' do anything sensible - rest of them do kinda work, but the pages you end up seeing are still from original Viewport - won't look very nice, that is
• Not to mention the Lightbox. It's Floatbox, but with a twist. Move your mouse cursor close to the top edge of the image, and see mah awesome EXIF-display overlay. You better like it, I spent several days getting it to work - there certainly were several issues:
• Largest one being that NextGen gallery loses the EXIF when you resize the images. It uses plain vanilla resize from GD, so no wonder. I tried to tweak the resize function to use PEL, and while I managed to make it work outside of NextGen, in NextGen I only managed to read the EXIF, never inject it back into the resized image.
• So, then I found a hack someone had made, it reads the EXIF into a database. Only problem was that it used PHP's built-in EXIF-functions, and they are not good enough for me; I want the makernotes as well.
• Exifier to help; it's a PHP library for reading EXIF, much like PEL, but can't write it. Which is of no concern, since it's only going to the database now. Hacking NextGen to use Exifier was actually pretty darn easy. It did take some time to build manufacturer-specific features into it, though... also some more sanity checks were needed. And least one more has to be implemented; Exifier does not like photos taken with Olympus-cameras. At all. At worst they'll make Exifier hang, at the best you can recover only the camera make-field.
• After that I had to tweak NextGen's template for showing images; it already did read the caption (which actually holds the EXIF), but my EXIF was there in a comma separated format, and many photos do not contain all of the fields. Something had to be done about that. So, I made the template turn that string into an array, and built a nice, HTML-formated string from that array - with some conditional checks; for example you won't (at least shouldn't) see fields like flash bias if there was no flash used, also exposure bias displays only if there was actually some. After doing all that, the template puts that into a 'rev' of the anchor-tag. Floatbox reads it from that.
• Then I had to tweak Floatbox into doing what I wanted. I wanted an overlay display, bit similar to the one used in Lightroom. And I pretty much had to built the darn thing myself. But there it is, and it works.

Oh boy. List so didn't work for that mass of text. Oh well, can't be arsed to fix that now, you'll just have manage.

I think that covers most of the shit I've managed to do. I'm fairly pleased with myself, so far. Understand that I'm not really a programmer, I suck at PHP and I find JS-code revolting. Thus, small achievements in those areas please me and give me satisfaction.

Pay no attention to the first photo of the first page - yes, it obviously should be rotated, but I couldn't be arsed to, since I was just interested in the EXIF; and that was the first one I found that had all the fields written by the camera still intact.

I wonder what I'll start to tweak next; certainly the content styling (fonts, headers, post info like date, categories and shit, and comments) needs work. I think they are straight from Viewport, except for the fancy-ass post titles.

Also; it's very much in development mode right now; for example there's an assload of JS-scripts being loaded. When it's ready I'll of course combine them into one monolith, minify it, pack and obfuscate it and then gzip it. That alone takes several seconds away from the page loading time, as browsers have this nasty habit of loading only one JS-file at a time. Thus sites with a dozen of them will take an obvious performance hit.

----------------
Now playing: Chris De Burgh - [M1+ Top 1000 #114] Lady In Red   [foobar2000 v0.9.6.3 beta 2]
via FoxyTunes

[Jari]

I do some fix!

• Namely, I managed to fix the horrid tearing bug Firefox 3.5 exhibited while using either the slider, or just scrolling the content. It seems to be a FF3.5 specific bug; if you have elements with position set to fixed, they'll do weird shit while the other content is scrolling, unless their overflow is set to auto. That magically fixes it.
• I found another, even more curious bug, though. The navigation buttons. They render just fine in any decent browser. I also managed to get them to render just fine on the IE8 installed on this system - the problem was that the png alpha fix and the idea of clipping only a part of larger image visible (to cut down the connections to the server) didn't really get along. The weird thing is that this is the only IE8 they seem to render okay; I've tried three other systems, and none of them display the buttons as they are supposed to. It boggles the mind how that is even possible.

[drfeelgud88]

I like the way those sites look. Look great. Site A loads a lot faster than B.
*cough* You just triple-posted *cough* lol. 

[Jari]

It's not like I'm stopping you from replying to my posts. Seriously though, I plan to use this as a project blog of sorts, so most likely I'll end up making several consecutive posts.

Anyway, I think I managed to fix the navigation button issues with IE8. IE7 renders them rather horribly, dunno if anything can be done about that - it seems that the fix that helped IE8 to get the png alpha working while opacity is being manipulated does not work with IE7. At least it does show the buttons, which is something... I might just skip fixing IE7 altogether, IE8 is enough of a pain in the ass. Needless to say, IE6 would be nigh impossible - I'm totally not going to bother with it. The user share is very low already, and the rest... well, they can upgrade for all I care.

As a bonus I chopped a whopping 350KB from the filesize by going from PNG32 to PNG8 - there's slight degradation in the visuals, but it's not too bad. The main reason for the slow loading right now are the multiple JS files, but I'm not going to touch them until I finish the thing, because it's rather impossible to edit packed and compressed JS. I think it might be possible to make the final design somewhere between 500 and 600KB (not counting the photos), which would be quite ok with me.

[drfeelgud88]

Well I don't use IE, it's too laggy. I use FireFox hehe.