The Web Design Book Blog

Tablets and Web Design · 19 days ago

It is clear that there will be tablets. First, Slate PCs were announced, then came the iPad circus, followed by rumours of a Google Pad and the news that Amazon had acquired a touch-screen startup, presumably to add multi-touch to the Kindle.

It is also clear that one of the main uses for these devices will be Web browsing. What does that mean for Web designers? Superficially, nothing, because these devices are all capable of running real browsers on reasonably sized screens. However, the ergonomics of touch screen interfaces might have some implications for Web designers.

One thing that was consistent about reviews of the iPad was that the people who actually had a chance to use the device all emphasized how you couldn’t really appreciate it until you tried it. I was not among their number so what follows has an element of speculation.

The mouse is a pretty clever little device. It allows you to move a cursor over a large screen with great precision, using small hand movements. With a bit of practice, you can do the same thing with a trackpad. Touchscreen interfaces are different. Their attraction lies in being able to use direct manipulation of the interface. You don’t move the cursor to click on something, you tap it with your fingertip. There is no longer any intermediary in the form of the mouse and cursor.

This immediacy brings two drawbacks with it. Fingers are relatively large, so they cannot hit a target as precisely as a mouse-controlled cursor can. This is already apparent with the iPhone and iPod touch: Apple’s interface guidelines for these devices advise you not to use buttons smaller than 40px square. It is probably not a coincidence that we are seeing far more big chunky buttons on Web sites than we used to, and this trend will surely continue if an appreciable proportion of Web browsing is done on tablets with touchscreens.

The other drawback of using a touch interface is that you have to move your finger all the way to something you want to click. With small handheld devices, like a smartphone or iPod Touch, this is not a problem: the screen is so small that most of it is within reach of your fingers when you are holding the device. With the larger screens of the tablet devices this is not the case. There must be a substantial movement of the hand to reach some parts of the screen. In particular, for right-handed people, the top and left of the screen will require the longest reach, no matter how you are holding the tablet. And those edges are just where Web designers like to put important elements like navbars, because people who read from left to right and top to bottom will see them most easily in those positions.

If you want to minimize the amount of hand movement and risk of RSI, the best place for your navbar when the site is being viewed on a tablet is the bottom right corner. Ideally, you would provide some means of moving it to the bottom left corner for left-handed people. Formerly, navbars were never placed on the right because of the risk of their being entirely lost if the window was not wide enough. Similarly, they could never be put at the bottom, in case the page content forced the navigation off the bottom of the window. Now that we can use position:fixed we can avoid this problem by pinning the navbar to the bottom right corner of the window, letting content scroll past it if necessary. (Naturally, this doesn’t work on IE6, but no tablet will run IE6, so you can use some conditional comments to put the navbar somewhere else if you still need to support that browser.)

The iPad demos show a new interface element, apparently called a ‘popover’, which is a translucent bar that slides over the main content to display some extra information or controls. It looks like a nice innovation, suitable to the size of the screen. (An iPad can be used in either orientation, and although 1024×768 is no smaller than some fairly recent monitors, 768×1024 is pretty narrow.) I tried to create something like a popover that could be used for a Web site’s navbar. The mock-up I did only works properly on Safari, because I used CSS transitions to make it slide up, and rgba colour for the translucent background. You can get some idea of what it’s like using Firefox or Opera, but I don’t know if it works on the World’s Favourite Browser. Probably not. In case it isn’t obvious, clicking on the tab in the bottom right makes the navbar appear, clicking away makes it disappear again. It’s done mostly with CSS plus a little JavaScript. If you’re interested in how it’s done, download the document. All the styles and scripts are inline. (I know what it says in the book. It’s just a mock-up.)

Even if you have to use your imagination about the operation of this navbar, you will probably be able to see the problem straight away. You don’t see it. Not even with that big arrow pointing at it. Interestingly, when the body of the page was just filled with lorem ipsum text, the navbar’s tab did stand out. Once I added the called-out box with the warning in, the box with its bigger text dominated the tab.

I hope that someone with a better grasp of gestalt principles would be able to overcome the bias towards top and left that makes it so hard to put important information in the bottom right of a Web page. It can certainly be done: think about poster design and magazine adverts, where you will often find vital information at the bottom right. Often, though, in such designs, there isn’t competing content in the rest of the page.

It’s an interesting challenge for the visual designers among you.

— Nigel Chapman

Hubris · 58 days ago

You've probably heard of 37signals, best-known for their online project management and related software. David Heinemeier Hansson, the original developer of Ruby on Rails works for them. They also have a blog, much of which is concerned with design and usability. They're pretty good.

Recently, 37signals launched a listing service for Web designers, called Sortfolio. (It's called that now, anyway, following a trademark dispute.) The design may not be unique, but I haven't seen anything like it before. It uses AJAX to provide an infinitely long page: as you scroll down, new content is added at the bottom, so there is no need to paginate the listings. Undoubtedly clever, if a bit unsettling at first.

They have also provided a page footer, with copyright information and a contact link. Supposing you want to contact them, you scroll down to the bottom of the page. By the time you have moved your mouse over the contact link, a whole load of new content has appeared and pushed the footer out of sight.

You can play this game for quite a while.

— Nigel Chapman

A Security Reminder · 93 days ago

Here’s an extract from the logwatch report from yesterday:

requests with error response codes
   404 Not Found
      //phpMyAdmin/: 2 Time(s)
      //phpmyadmin/: 2 Time(s)
      /boutique/install.txt: 2 Time(s)
      /butik/install.txt: 2 Time(s)
      /cart/install.txt: 4 Time(s)
      /catalog/install.txt: 2 Time(s)
      /install.txt: 2 Time(s)
      /shop/install.txt: 2 Time(s)
      /shop2/install.txt: 2 Time(s)
      /store/install.txt: 2 Time(s)
      /zcart/install.txt: 2 Time(s)
      /zen-cart/install.txt: 2 Time(s)
      /zen/install.txt: 2 Time(s)
      /zencart/install.txt: 2 Time(s)

I could have used today’s report to illustrate the same point, but it’s about three times as long.

Recently, I’ve been seeing this sort of thing nearly every day: attempts by hackers to access the installation files used by various popular Open Source packages. Many such packages require a similar setup process. You copy all the files from the distribution to your server and then point your browser at some URL within the directory on the server. This causes an installation script to run, which asks you questions about where your database server is, and so on. During this stage you often have to provide the user and password for your database, and set an administrative password for the application amongst other things. The script takes your answers and creates a configuration file which is stores somewhere safe where it can be read when the application you have installed is accessed in the future.

The installation instruction for a package that works this way will almost always tell you to delete the installation script or some temporary configuration files after you have done the set-up. If you don’t, it could be possible for a hacker to run the installation script again to give themselves access to your database and application, or deny it to you.

Often, it is also necessary to change the access permissions on certain files and folders after installation.

As the log entries shown above demonstrate, intruders know about these setup scripts, and are actively looking for copies that have been left over. So if you are installing any Open Source packages on your server, take the time to read the installation instructions carefully and do any tidying up that they tell you to. Some packages refuse to start unless you have taken these precautions but by no means all of them.

You will notice that besides installation files, the attackers are looking for phpMyAdmin (ineptly). Considering what it does, phpMyAdmin makes a tempting target, so if you need to use it, be especially careful about installing safely and securing it.

— Nigel Chapman

Older