Responsive design is becoming irresponsible

Posted by on Jan 18, 2013 in Design | 0 comments

Responsive design is becoming irresponsible

Responsive design is all the rage these days. No grid system is worthy if it’s not responsive, “mobile-first” is the first thing that experienced designers tell their clients and so on. Recently, Smashing Magazine published an article about “preparing websites for the unexpected” which is just another piece of “responsive propaganda”.

First of all while the article suggests it will teach us to prepare for the unexpected, the only examples include desktop and mobiles. If I recall corectly, responsive design was supposed to solve the problem of tens of different screen-sizes out there, but more an more I read articles that only shows the 2 extreme. I understand that it’s easier to illustrate a point using only 2 examples but if it where to take into consideration only the 2 extremes it would be easier to implement 2 versions of the website, mobile and desktop.

At one point the author suggests, for the sake of the reader, to break long articles into small pieces, for mobile users. Which obviously raises more problem than it solves. How the editor of a website who’s writting an article in an WYSIWYG editor determine the best way to split articles, if it’s so important not to force the user to scroll that much? How is going the article going to be splint on a portrait iPad or Galaxy Note? Does it matter that the user is in landscape or portrait mode? Can anyone imagine adding breaking points in a WordPress post?

In another recent article from Smashing Magazine, we are told about the benefits of the PICTURE tag.

art_direction

The “Art Direction” use case. Image credit: W3C.

Looks nice doesn’t it? But how would a user know that  viewing the “desktop” image on its mobile is wrong? The designer has some knowledge about the technology and can envision a “better” solution, but the user is ignorant about this issues. If it were to really be responsive we would need to account for network speed as well and deliver “not-so-perfect” pictures for people on slow mobile connections. The people I talked to prefer they wait a little more for a “retina-enabled” picture than get an average picture fast. I remember a usability talk where there presenter was baffled when his 50 year old mom was able to adjust to the new Apple mouse (at some point Steve Jobs decided to change the scrolling direction) in a matter of seconds although the usability-minded people where screaming its a bad move.

Most of the time people go with what they receive. Unless they are told otherwise they will not know the difference. There are places where people can learn to spot the differences but not everything is comparable. People can detect if a website is faster or slower than another but they will give the benefit of the doubt in some cases (like people that will accept a slower speed if they see beautiful screens) but you need to think hard about why the story about the President’s dog has a picture where the dog is 20% of the picture and not 100%.

Now, let’s assume for a second that I’m wrong and ponder this question. Who are the people that we are trying so hard for? Do you really want to please people that will flip out if their images on the smart-phones are not properly resized and cropped or that long articles are not split into flippable screen-sized chunks? The road to  hell is paved with good intentions. People are starving to death in many places of the world and yet we try to improve the lives of people that change their smartphones every year?

Read More

Feaxures, progressive enhancement done right

Posted by on Jan 15, 2013 in Web | 0 comments

About 1 year ago I came up with an idea for better handling of progressive enhancement and I finally have been convert into a project that I can share with the world.

My solution is about abstracting the way we load the resources required by an enhancement and how we initialize it. Being mainly a server-side developer I’ve written a lot of code like the one below

This type of coding creates some problems. You cannot easily change the script that makes the enhancement (if you want to use a “lighter” solution for tabs you will to make changes in lots o places) and you cannot reuse the code (for each project you have to write again all those lines).

Once I’ve found out that curl.js and require.js exists my computational machine that I call “the brain”, brought this solution to my attention. I’ve implemented it about 1 year ago but I didn’t have time to make it public (you know… write documentation, make a GitHub repository). It’s available now at Feaxures.com.

Read More

Whitespace in design and the eye

Posted by on Mar 16, 2012 in Design | 0 comments

Whitespace in design and the eye

Recently I’ve been watching a documentary on how the brain works and how we get a grasp on reality. At one point the presenter said that although we think we see clearly and we believe the image we have on our minds about what is in front of our eyes is clear that is not what the eye actually transmits to the brain. In order to create the crisp image of reality that we enjoy the eye has to move a lot, and fast. The brain gathers lots of tiny snapshots and recomposes them to create on big, sharp image.

The eye sends to the brain images that are crisp in the middle and more and more blurry towards the end. Like this:

This explains why whitespace plays such an important role in web design. Look at the following screenshot from the adevarul.ro website

and how the brain sees it

As a comparison look at bostonglobe.com

and how the brain sees it

Read More

Fluid grids are less complicated than you think

Posted by on Jan 8, 2012 in CSS | 0 comments

I’ve been trying to find a solution for creating fluid grids (and layouts for that matter). The problem with fluid grids is the box model in the browser. When you have fixed-width grids you can easily calculate the right width of a column. But with fluid grids that is not possible (yet). If you set the column width to 25% and you need 2.5% left/right margin the total width of the box will be 30% of the container.

If you try to use negative margins and increase the width of the container (like some fixed-width grids are doing) the browser breaks down. In the example above you’d need to increase the width of the container to 105% and redo the computations for the grid boxes. The grid boxes will have a 2.5% left/right margins and a width of 21.25% (105%/4 – 5%). The math becomes more complicated for 16 column grids or for nested grids. I tried it but the browsers do not behave consistently so, even if you are willing to struggle with the math, I don’t think this is a viable solution.

Stepping back from this problem I realized that the complexity of this problem is generated by the desire to have the left margin of the first column exactly aligned to the left margin of the container and the right margin of the last column exactly aligned to the right margin of the container. But if you stop and think about it, when you want to use a fluid grid/layout you’re not working with a, lets say, 960pixels wide container. So, even if the container is the BODY tag you still need some kind of left/right margin so the content doesn’t touch the margins of the browser window.

Since you must have those margins you can use those margins to help you with the problem. Let’s say, inside the BODY tag, you only have a 4 column fluid grid, each column being 25% in width. That is perfectly possible in any modern browser. Since the first and last columns in the grid must have a left and right margin, so that their content don’t reach the window’s margins, you must make sure that the content of the columns will have left/right margins. That can be achieved easily via CSS using child selectors. All you need to make sure that the columns will have only block-type elements. Which that happens most of the time; there are very few occasions when you have text or inline elements in columns)

This is a WordPress blog and the side bar contains only block type elements with class “widget” and the main area contains only block type elements (headings and divs for the articles) so it’s easy to see how a fluid layout (75% for the main content and 25% for the sidebar) can be achieved on this blog.

The only caveat with this approach is that, since the content of grids will have a left/right margins relative to the grids container you must make sure that the rest of the children of the container must employ the same margins.

But enough with the theoretical mumbo-jumbo. I’ve created a set of LESS mixins that can help you create fluid grid/layouts. Check out the project page.

Read More

My first GitHub repo

Posted by on Dec 29, 2011 in PHP | 0 comments

I finally summoned the courage to create a GitHub account for some of my projects. I’m using GitHub on my computer but on a basic level (haven’t used branches or tags yet). It took me a while configure it on my Windows machine but I got it to work.

Without further ado, here’s the WrappingFactory.

Read More