Google Chrome is great, but …

  • 2 February

I have switched to Google Chrome as an experiment, around a month and a half ago. Now, I can say that this in fact is the best browser out there, but ...

There’s always a but, eh?

There are so many things I love about Chrome, staring on the Tab system– the fact that it squeezes as much tabs as possible, even if that means showing the favicon alone. Finally, FINALLY, Flash isn’t taking the whole browser down like it used to do with Firefox and Safari.

Chrome for Mac is still in Beta, so there are things that might change, but somehow I don’t think the general UI will be altered, which brings me to the but.

Moving the window. Most apps allow you to drag the window by clicking on any white space- there’s always a fair amount of it. When it comes to Chrome this is not the case. There’s very limited space you can drag the window by. Let’s compare:

Safari

safari2

Chrome

google-chrome11

Solution

  • Introduce Status Bar
  • Add more spacing between top of the browser window and top of the Tabs container, which also allows to have the title of the page we’re currently browsing

Getting over the Something’s wrong with the styles

  • 12 July

You can't even start to imagine how many times my office minions (co-workers) repeat that something I did doesn't work, just for them do discover that the version they see is the cached one.

Even when working on a online project it would be nice to have some sort of control over what the viewers see – preferably the newly changed version.

What I tend to use lately is generating a random marker in the URL while the project is still in development:

<link rel="stylesheet" type="text/css" href="/screen.css?<?= rand(0, 9999) ?>" />

Which constitutes in the file not being cached in general.

Now, that’s an acceptable solution before the project get deployed. After deployment it would be appropriate to generate a unique release of the template, in my case the catalogue structure would look like the below:

- templates
  - release_01_05_08
    - css
    - img
    - js
    - flash
    - misc
  - release_10_07_08
    - css
    - img
    - js
    - flash
    - misc

Of course the way you divide deployments in unique instances can use a simpler method – versioning for example:

<link rel="stylesheet" type="text/css" href="templates/v1/css/screen.css" />

That should solve common caching problems on all major browsers.

The perfect sign-up form

  • 22 June

So here we are, browsing a new website you came across. Everything seems to be lovely so why not joining the community, sharing, giving... And all of that vowels-like stuff. Unfortunately joining sometimes can a big pain in the neck, why? Sign-up forms.

You would ask yourself How stupid one can be not to go through a signup form with ease?. Personally I don’t think it’s about users being not too bright, but more on developers/designers not thinking stuff through and the fact that most of us don’t have the whole god damn day booked just for filling-in a never ending form.

There are a few rules of creating super-friendly sign-up forms:

  • Keep ‘em short. The idea is really simple: If you think your form is simple enough… cut it by half. Also if a field is to be Optional just skip it… Don’t bother.
  • Inline validation. Preferably every form should use inline validation/checking (unobtrusive of course).
  • If you decide on using regular validation (reloading the page) I beg you, for Pete’s sake, remember the fields value – It’s not like I’m filling-in the form just for the heck of it.
  • Provide meaningful feedback – clearly state which fields are not valid by highlighting them. Avoid the ruby-on-rails-way error reporting – printing what went wrong at the very top and letting the user figure out which fields actually does the text apply to.
  • Provide label anchors at least for checkboxes. If you already say tick the box to … next to the checkbox, we might as well make the text toggle the box itself.
  • Don’t exaggerate with field descriptions as no one likes to be patronized. Titles should be self explanatory.
  • Avoid using any Captcha systems at all times (especially reCaptcha). Make sure the site is safe without forcing the user to spend more time on your form – even with the cost of you spending more time removing stuff from the moderation queue.

Actually I could go on with the list but I found a perfect example of what to avoid when building a signup form.

Here are some of the best sign-up forms I have came across:

280slides.com

I like this one a lot, especially the idea with adding just one field when you want to register instead of signing-up!

Newspond.com

My absolute fav of the ten. Compiles everything good – simplicity, graceful feedback and beautiful design.

Disqus.com

Yet another simple and friendly form.

Vimeo.com

The most laid back sign-up form, ever.

Safari 3 + WYSIWYG = Love

  • 19 June

Sexy...

Just a super-quick note here. Turns out that Safari 3 actually supports WYSIWYG mode - at last! Good news for everyone who works a lot in Google Docs (like me).

I pretty much assume it works on OS X and Wincrap version.

Categories