A couple hours ago, I received a notification email from Goodreads and unlike usually, I decided to actually visit the site (by the way, I believe that Goodreads, i.e. a last.fm for books, is an awesome idea but poorly implemented).When I did, I was quite annoyed to find out that I wasn’t already logged in, so I had to remember which one of my many passwords I had used for it and try them one by one. This is not a Goodreads fail, but a fairly common nuisance, since most (if not all) social websites behave that way.

“What if there was some magic involved?” Bill Scott & Theresa Neil advise interaction designers to ask themselves in a book I’m currently reading (highly recommended by the way). Well, I guess, if there was some magic involved, the site would “understand” that my click was initiated from an email and would automatically log me in and let me view whatever I was trying to.

What’s the point of asking for a password if the user can prove they have access to the associated email account? Such access is usually all that’s needed for someone to break into an account, theirs or not (via the forgotten password feature). So, it doesn’t help security much, just makes it slightly more time-consuming for potential impostors, while turning legitimate users with a weak memory (like yours truly) away from the site.

I’m not sure whether it’s a good or a stupid idea, I’m not really suggesting it, just expressing a thought.
I have some concerns myself too:

1. It’s definitely harder to implement.
2. All links sent in notification emails must contain some special token, like reset password links do (I’ve never seen it implemented otherwise). The tokens in reset password links expire after a while, so probably these should too, for security reasons. And what happens after that? A regular login is required? Doesn’t this render the whole idea a bit pointless, since notification emails are frequently read 1+ days after they’re sent?
3. Usually a frequent user receives a bunch of email notifications per day. Isn’t it a bit too risky to have dozens of such powerful emails floating around in your inbox? On the other hand, it doesn’t seem more dangerous than using the “remember me” feature while logging in: Anyone that manages to get ahold of your laptop for a minute is able to use your account in most SN sites, one way or another. However, the “remember me” feature is a classic case where usability triumphed security, at least in cases where the computer isn’t shared.
4. Thinking of the “remember me” feature gives me another idea: It could be optional and active by default. Perhaps with a link to easily deactivate the feature in every such email. On the other hand, more options = more confusion.
5. Also, to avoid the issues stated in #3, this feature could be activated only if the user in question was inactive for a while. Frequent users don’t need it that much and even if they did, they don’t run away so easily, so it’s not as crucial.

What do you think? Mostly useful or mostly evil?

There has been a recent flood of CSS experiments that utilize CSS3 features to convert some meaningless markup to spectacular pictures. It all started when David Desandro used CSS3 to draw the Opera logo. This seemed to inspire lots of other folks who created similar demos:

• Pure CSS icons
• Create Social Media Icons in pure CSS
• CSS flower
• Curtis CSS typeface
• CSS3 Gradients coffee cup

I can certainly share their enthusiasm and I am also amazed by their results. Besides that, I think that pushing CSS3 to the edge like that, helps us understand the spec better, which leads us to find and file browser bugs or write comments regarding the spec itself. Filing bugs is crucial at this stage, with all browser vendors gradually adding experimental –and frequently buggy– CSS3 support to their products. Also, don’t get me wrong: I can easily see the benefits of reducing the number of images in a web application interface (far quicker/easier modifications, less HTTP requests and most of the time, less bandwidth).

However, I’m afraid we’re losing sight of the big picture. These aren’t demos that are or will ever be legitimate CSS use cases. Even after universal CSS3 browser support is achieved, they would (and should) still be considered “hacks”. Almost all the arguments pro their usage also apply to more suitable ways of including images in web applications:

• Fewer HTTP requests: Same with any kind of embedded image (data URIs, inline SVG and so on)
• Scalable: Same with SVG and symbols embedded in custom fonts
• Easier to modify: Same with SVG
• Less bandwidth (in some cases): Same with SVG (and it can be cached too, when not inline)

CSS is supposed to enhance the presentation of a document or interface, not to be (ab)used for the creation of illustrations from scratch. It’s supposed to separate presentation from structure, not generate stuff. There are other technologies that are far more suitable for this (*cough*SVG*cough*). I think we should use our energy and creativity to make CSS3 demos that people will actually use in the future when all this is fully supported, not stuff doomed to be eternally considered hackery.

“Where should we draw the line?” one might ask. For example, is a Pure CSS analog clock a CSS abuse case? Or even my own CSS iPhone keyboard? Now that’s a good question! A rule of thumb seems to be “if it inherently (=not due to browser support issues) involves a bunch of empty (or with meaningless content) HTML elements, then that’s a bad sign” but that might be overly strict. What’s your take on it?

Disclaimer: Yes, I’m fully aware that most of the time, such experiments are created just for fun by their (very talented) authors, which are perfectly aware of all the things mentioned above. However, I’ve also grown tired of reading comments by people that seem to to think that “This is the future of the web!”. Let’s hope it’s not.

If a web application has some sort of registration system (and most do), the registration page should be one of the most attractive, inviting, usable pages of it. It should make you to want to register, not repulse you. We don’t want the user to give up in the middle of filling it because they are fed up with it’s length or bad usability, or -even worse- not even attempt to do so, do we?

The most popular websites usually take this rule to heart and employ the simplest registration forms: Only the basic fields required, and most of the times, even without password/email confirmation.

I was wondering lately – what would be the simplest possible registration form? It should have the minimum number of fields required: Username and password and a field for some kind of human verification.

At this point, some readers might argue “Hey, why not an email field as well?”. In my opinion, the email is not always a required field. Let’s see why it’s being asked for in most cases: Unique identification (to prevent double accounts) and for sending out notifications for important events. However, it’s useless for the first purpose due to all these disposable email websites. As for the second purpose, since notifications can be switched off (and if not, then they are essentially considered spam), it could be regarded optional and we don’t include optional fields in registration forms, do we?

Of course, in websites that use the email instead of a username to let their users log in, you may just substitute the username field above with an email field (since in that case, the username is what could be considered optional) and we also have two fields. Smart readers might have noticed another pattern here: The only fields that are truly required for a registration form are the same ones that are required for a login form plus a human verification field.

And then it dawned on me: We can make the registration process almost as quick as logging in! We could use the same form for both actions. The submit button label could indicate the dual nature of the form, for instance “Log in or register”. If the username (or email) doesn’t exist, we could then ask the user whether they want to create a new account and present them the human verification field at that point. There is no need for a password verification field, since we could just have a checkbox for displaying what the user typed, if they feel insecure about it.

I find 3 inherent issues with this approach:

1. Security. If a login attempt fails, the user will know whether he got the username or the password wrong. However, in most websites, you can easily check whether a username exists anyway, so I don’t consider this a real concern. I just included it because I’m certain that if I didn’t, somebody would point it out to me in the comments.
2. Despite being a more usable approach by nature, it’s not by any means a convention yet. Until it becomes one, I’m afraid that some users will be confused by its extreme …simplicity! Funny, isn’t it?
3. We won’t be able to employ Ajax verification for the registration form, since it will essentially be a login form as well, and until the user submits, we won’t know what they plan to do (login or register). Having an Ajax verification script there by default will confuse existing users as hell (as in “What do they mean by ‘Username is taken’? WTF??”). So, we have to sacrifice some usability to gain some usability. The question is: Is the usability we gain more than the usability we sacrifice? What do you think?

As you can see by the problems mentioned above, it’s still a rough-on-the-edges idea (I just thought about it and I haven’t refined it yet), but I think it’s interesting. What are your thoughts?

In the past, I used MySQL for any of my DBMS needs. It wasn’t really an informed decision based on solid facts, actually I had never really given it any thought. It was what most developers used, it was what vBulletin used (one of the main projects of my company is based on vBulletin), it was what most hosts had pre-installed, in other words, it was the popular choice and I went with the crowd.

Unlike most decisions taken that way, this one turned out to be correct (so far at least). In the university where I study (yeah, I do that too occasionally ), there is a great and extremely useful class on Database Systems offered in my semester. The only drawback is that it’s done on MS SQL Server. Consequently, I had to work with it quite a lot, and my conclusion was that MySQL is far superior (mostly syntax-wise as I don’t have the deep knowledge required to judge them fairly for other things, so don’t expect a deep analysis about performance or security – as far as I’m concerned, they are equally good at those). Here are a few reasons:

1. No ENUM datatype. Yeah, of course I can define a column with a char/varchar type and add a constraint to only allow for particular strings, but this kinda defeats the purpose of memory saving that the ENUM datatype in MySQL offers.
2. No INSERT IGNORE. Instead you have to go through hell to simulate that in MS SQL Server.
3. I hate it that I can’t use “USING(columnlabel)” in a JOIN query and I have to use “ON(table1.columnlabel = table2.colmnlabel)” all the time. Yeah, I know that the first one isn’t standard, but it’s shorter, cleaner, more elegant, and …you can still use “ON(…)” if you don’t like it. Having more options is never bad, is it?
4. With MySQL you may insert multiple rows at once elegantly (“INSERT INTO tablename (…), (…), …”), without using the “INSERT INTO tablename SELECT (…) UNION ALL SELECT (…) UNION ALL …” hack. Moreover, the elegant MySQL way also happens to be the standard, a standard that SQL Server doesn’t follow.
5. Triggers can only run per statement, and not per row. This isn’t really important, since for most cases, it’s more efficient to define a per statement trigger anyway, but it doesn’t do any harm to have an extra option, does it?
6. Paging is dead-easy on MySQL: SELECT * FROM foo LIMIT 10,20 . With MS SQL Server you have to jump through hoops to do the same thing, especially if your query is not trivial.
7. In MySQL, when you want to convert an integer to a hex string, you just call HEX(). In SQL Server you have to call an undocumented function and do some string manipulation to do the exact same thing.
8. MySQL runs on every platform, whereas with MS SQL Server you’re stuck with Windows.
9. Last but not least, MySQL is free (and when it’s not free, it’s at least cheap) and opensource

As someone who dealed a bit with print design in the past, I consider CMYK colors the easiest color system for humen to understand and manipulate. It’s very similar to what we used as children, when mixing watercolors for our drawings. It makes perfect sense, more than HSL and definately more than RGB. I understand that most of us are so accustomed to using RGB that can’t realise that, but try to think for a moment: Which color system would make more sense to you if you had no idea and no experience at all with any of them?

Personally, even though I have lots more experience with RGB, given the fact that most of my work will be displayed on screen and not printed on paper, when I think of a color I want, I can instantly find out the percentages of Cyan, Magenta, Yellow and blacK needed to create it. I can’t do that with HSL or RGB, I’d have to play a little bit with the color picker’s sliders. I sometimes start by specifying a color in CMYK and then tweaking it via RGB or HSL to achieve the exact color I need (since the CMYK gamut is smaller than the RGB gamut) and I find that much faster than starting with RGB or HSL right away.

Also, when you don’t have a color picker, it’s much easier to create beautiful colors with CMYK than it is with RGB. For example the CMYK magenta (0% Cyan, 100% Magenta, 0% Yellow, 0% blacK) is a much better color than the RGB Magenta (255 Red, 0 Green, 100% Blue).

Given the above, I’ve always thought how much I wanted to be able to specify CMYK colors in my CSS. I agree that sometimes this would result in crippling myself, since as I said above the CMYK gamut is smaller, but it has other significant advantages that I think it would make it a useful option for some people. There are algorithms available for CMYK to RGB conversion, and the browser could use those to display the specified color on the screen. Then, if the user decided to print the page, The CMYK colors could be used as-is for the printer. Another advantage, as none of the current CSS color formats allow us to control that. People who don’t find the CMYK color system easier for them to understand, they could still use it for their print stylesheets.

Also, graphic designers who decided to switch to web design would find it much easier to specify color values in a format they are already comfortable with.

To sum it up, the advantages that I think this option would provide us are:

1. A color system that’s easier for most people to understand and manipulate.
2. The colors you get when combining “easy” CMYK values (0%, 50%, 100%) are more beatuful than the ones you get with “easy” RGB values (0, 128, 255). Bored people and people without a taste in color selection would create more beatuful websites this way and our eyes wouldn’t hurt.
3. We would be able to specify how our colors will get printed, something that is not currently possible at all. Extremely useful for print stylesheets.
4. It would be easier for graphic designers to switch to web design.

And the format is very easy to imagine:

background-color: cmyk(0, 100, 50, 0);

or

background-color: cmyk(0%, 100%, 50%, 0%);

or

background-color: cmyk(0, 1, 0.5, 0);

So, what do you think? Useful or useless?

Edit: As it turns out, I’m not crazy! The W3 already considers this for CSS3 with the 3rd format (from 0 to 1)! However, no browser supports it yet, not even Webkit nightlies…

Translations

• Portuguese

Recently, PPK stated that he hates Google Chrome’s automatic updates. I disagree. In fact, I think that all browser vendors should enforce automatic updates as violently as Google Chrome does. There should be no option to disable them. For anybody.

But what about the user’s freedom of choice?

This might sound a bit facist at start, but imagine a world where all browsers would get automatically updated, without the possiblity of an opt-out. If you went online, you would be bound to have the very latest version, regardless of how computer (i)literate you were (Many — if not most — home users that don’t upgrade are like that because they think it’s too difficult for their computer expertise level). Sure, if you were a developer you wouldn’t be able to test a website in older browser versions. But why would you need to do so? If everybody had the latest browser version, you would only develop for the latest version and perhaps for the next one (via nightlies and betas, that could still be separate in that ideal world).

Imagine a world where your job wouldn’t have to involve tedious IE6 (and in a few weeks, no IE7 either), Firefox 2, Opera 9.5 and Safari 3.1- testing. A world where you would spend your work hours on more creative stuff, where you wouldn’t want to bang your head on the wall because you know you did nothing wrong but the ancient browser that you are currently testing in is just incompetent and YOU have to fix it’s sh*t. A world where the size of your Javascript code (and the JS libraries’ code) would be half its size and constantly decreasing as new browser versions come out. A world where you would only have 1 CSS file in most websites you develop. A world where you wouldn’t feel so bad because IE8 doesn’t support opacity, border-radius or SVG, because you would know that in 1-2 years everyone would have IE9 and it will probably support them. A world where designing a website would be as much fun as designing your personal blog.

Doesn’t such a world sound like a dream? Would it harm anyone? Users would browse a much lighter and beautiful web, with a more feature-rich and secure browser. Developers would work half as much to produce better results and they would enjoy their work more.

What about corporate intranets and abandoned sites that won’t keep up?

Oh come on, that isn’t a good enough reason to not make that dream come true! Companies and individuals could be allowed to have an older version of the browser installed as well. They still wouldn’t be able to opt out from the automatic upgrade, but they could apply somehow to have an older version of the browser in the same system as well. Similarly to what happens now with browser betas. People would use the older version to access corporate intranet applications and obsolete sites and the latest version to surf the web. I may be overly optimistic, but I think that if a user had both versions of a browser installed, (s)he would prefer the latest wherever (s)he can. Perhaps another step towards enforcing that would be if the OS prevented an older browser version from being set as the default browser, but I guess that would be too hard to do, especially if the browser in question is not the OS default one.

Other people who agree with me

• Aaron Boodman
• Joe Walker

What’s your opinion?