Pattern: inline labels

September 27, 2016

In reaction to Baymard’s post ‘avoiding inline labels in mobile forms‘ there is a recent pattern I have been seeing, at least have seen so far on 2 desktop sites:


Clicking an empty form moves the inline label to above textfield, and resizes label

The patterns ignores Baymard recommendations, but still works for me. Still have to test if & how they did it on mobile. The only issue I can imagine is if the textfield is on top of the viewport. Otherwise shouldn’t seem a problem CSS wise.


Update: Nowadays this is standard Material design  (see


Mobile lightbox or overlay

May 13, 2014

Overlays are an aggressive disruptive method of getting users attention. If abused or not implemented properly, visitors may leave the site. Especially on mobile, due to the limited screen size, there are better solutions. As usual it depends on the context and content. Highly recommend that you evaluate the need for a (mobile) overlay on a per-project/per-application basis.

Some applications that could be using overlay (but could be handled with an alternative):

  • Web survey
  • Can I help you chat function
  • Modal dialog message   (if content is limited, say just one line of text and 2 buttons, then these are maybe the only exception for using mobile lightbox)
  • Image slideshow or video preview
  • Content preview  (by clicking a ‘?’ or info-button)
  • Other

Alternative solutions:

  • Fixed-position button that scrolls along while the user moves down the page
  • Fixed-position button appearing at some point e.g. appears only after if the user has scrolled 1 pagelength down
  • Prominent content on the page  (e.g. near the navigation header)
  • Navigate to new page, expand an accordion, slider/carrousel, swap content.  (for lightbox overlays that appear after a user clicks something)
  • Modal dialog. Probably using the alert JS function (TBC if it’s feasible to add links and other rich content)
  • Other solutions

Some principles (if overlay is the only option):

  • The overlay should always be visible in the mobile viewport. It should never be the case that a user scrolls and only sees the overlay background.
  • The close button should always be visible. (must-have).  This is often in the form of an X in the top-right and/or “Close” button, but can be a floating X or auto-hiding X as done in some Jquery plug-ins.
  • Overlay background should be visible so that user knows it’s an overlay that is part of the site.
  • Sometimes it needs to be clearly part of the site (e.g. branded or mentioning company/website name the title)
  • The overlay should be resized and the content scaled down (see some Jquery plug-ins for overlays/lightboxes)
  • It needs to be carefully tested on different devices/browsers. Zooming in and out of the conten should be possible, without hampering the possibility of closing the overlay.
  • Content should be limited on mobile. Scrolling can be problematic.
  • Generally it is not recommended to show an overlay after x seconds, especially if the user doesn’t expect it and didn’t click anything.


General behaviour

  • For regular overlays
    • Clicking outside the overlay will close it
    • Clicking on the X will close it (as is)
    • Pressing Escape key will close it (as is)
  • For modal overlays
    • Clicking on the Close label, image and/or button will close it

Examples and best practice 


A reasonable example is the cookie lightbox of on mobile:

–       Manage expectations. It seems to appear 1-2 seconds after the homepage is loaded, so the user still knows he’s on the right website and can still act on the cookie request. (dispite that lightbox may not be the best solution for cookie permission)

–       Closing. There is a clear, branded “< back” button placed on the top of the overlay, making it quick and easy to close or ignore the message.

–       Flexible. It takes up the full real-estate of the screen and if there’s a lot of content this is not a problem, it can be quite tall.




Because of the limited mobile screen size and the uasbility requirements listed here, content needs to be limited and overlays are often not ideal on mobile. Overlays that are limited in content and user-triggered may be an exception. In any case overlays must behave properly, as outlined in the principles above. I recommend to make a list of on what pages overlays are needed and approve the need for a (mobile) overlay on a per-project/per-application basis. If you have little control over this, offer guidelines (in the CMS or another form) to help the client realise the negative consequences of mobile overlays and offer suitable alternatives. Consider limiting the use of mobile overlays for the sake of conversion and the client’s own sake. Provide a overlay solution that can handle any type of (large) content and test it well.

Layout options

March 23, 2014


When designing you generally have these layout options. Using any of these patterns often will have pros/cons and consequences on the flow and rest of the page design. Possible factors/pro-con considerations influencing your decision are:

  • real-estate  (and fold)
  • visibility/prominence
  • suitability
  • loss of orientation
  • convention versus intuition


Vertical layouts

Vertical tabs









CON: Everything is shown expanded resulting in information overload and clutter.
PRO: No sub-navigation is needed


Accordions   –  popular with mobile  (risks)

Anchor links –

Carousel / caroussels

‘More details’ link (half-way accordion)

Zig zag imagery

Horizontal layouts

Horizontal tabs

Row of links

Row of buttons




Other layouts

Rollover tooltip / toast message


Navigate to a different page

‘next’ button

Progressive menu (or expandable tree)  –  popular with mobile

Filters   (or row of toggles)

Swap content  (flip div)

A combination   –   e.g.

, expand an accordion, slider/carrousel, …  (for lightbox overlays that appear after a user clicks something)


Some things to note


  • Tabs can also look like buttons or large links
  • Re-use page templates  (see Consistency post)
































Other layout options



Further reading:


Pattern: fixed toolbar

August 2, 2010

Use when

You need to give your users constant access to useful functions that need to be quickly accessible without scrolling. Think of it like the toolbar in Word or any other application for that matter.

Fixed toolbars contain functions which are:
– commonly used (share, add to wishlist)
– useful (search)
– or even promotional links (´Donate/join now´ or ‘give your feedback’)
– or branding fixed elements
Toolbar functions that need to be accessed at any time, with direct or indirect relation to the context on the page. The functions are accessible from a fixed position on the screen that holds its fixed position if the page is scrolled.

Anything could go on the toolbar. Icons (if conventional and understood by users), pulldown menus, links, textfields. It depends what the tools are.
In CSS fixed elements are achieved by using position:fixed
– The toolbar could be present on almost all pages on your site, or only on pages where it makes sense with certain cha.
– Beware: They take up space, especially on low resolutions such as mobiles. More scrolling is needed to uncover the part of the page that it obscures.
– Keep it small. If it´s a horizontal toolbar, reduce the height. If it´s vertical, keep it narrow.
– Provide a ´close´ option if you think users will find it more annoying that useful. Consider how and when to show the toolbar again.
– Add tooltips or contextual help (on mouse-over show a hint)  to facilitate learning, or help balloons to encourage use (see UXmatters example).


Pricegrabber’s “ribbon” – read about it and ribbon – bottom toolbar (browse the Reviews tab) – bottom toolbar

UXmatters – Top toolbar appears only when scrolled a certain amount down the page untill  the site header is no longer in site. Powered by Apture.

eConsultancy (blog) – Side toolbar with commercial-promotional function. Left toolbar is home-built, the corner toolbar is the ´Give feedback´ button by Kampyle

The use a fixed side-bar :

uipatterns use a ‘you might like’ pop-over in the bottom-right corner. This could be useful for cross-sell, but it shouldn’t obscure other elements or it will have the adverse effect of annoying users.    TED video docks on top when you scrol down TIP

More examples

From : “There are plenty of situations in which a fixed element (such as persistent navigation) could serve the owner’s business objectives and make the website more usable. Fixed elements are memorable and enhance the user experience. They have countless creative uses, and we will continue to see designers take advantage of them.”

For more examples, search google for ‘fixed position web design trends’

Related articles


Nominated the best new UI element @ “Sticky” headers/sidebar content – critical elements stay fixed as you scroll down the page (the way the gMail header stays fixed as you scroll through an email, lots of “share” functionality on blogs/magazines stays with you as you scroll down the page). See also main nav. The text formatting options in Quora and Basecamp Next stay with you as you write longer posts, like this one!

Dropdown usability issues and solutions

August 2, 2010

Keywords:  SELECT,drop-down list, drop down, pull-down menus, combobox (is not a dropdown, but many misuse the term)

Problem #1 – Long dropdown lists fall outside the browser viewing area

When the user clicks to open the dropdown the value that he wants to select falls off the screen, outside the browser viewport. If the user tries to scroll, chances are that the dropdown will close again. In worst case the user won’t be able to select his value with the mouse at all.

In Firefox (3.6.8), product detail quantity dropdown seem to position the dropdown list above or below where the dropdown control, depending on position of the viewport.
If this is browser dependant behaviour, are there researches or sites that force this behaviour?

Other solutions:
– Dynamically shorten height of dropdown list (drawback is that you must scroll more to find something at the end of the list)
– Dropdowns are suitable for common lists such as country, but for long lists HTML links are preferred.
– Autosuggest (e.g., Google Suggest) allows user to type and select from a dynamic list, but has its own issues…
– Add a ‘show more…’ link to bottom of dropdown

Problem #2 – Dropdowns pull attention

In one eye-tracking study

, the dropdown menu grabbed the user’s eyeball attention, no matter where it was positioned. Probable cause is that the dropdown is situated among empty textfields in a form, but looks as if it is prefilled which makes the user curious.

Problem #3 – Dropdowns are often skipped

In one usability test

, a dropdown was the first element in a form. Likely this is because it looks like a textfield that is already filled, so hasty users will skip it.


– Use a label with good copy. I prefer ‘(select your country)’ over ‘ — select your country —‘

– For this label, use a grayshade that is distinctly lighter than the black text colour used for filling in textfields.

– Add a form label in front of the dropdown, just like you do for textfields. Example:  ‘Country:     (select your country)’

– Keep the width of the dropdown equal to the width of textfields above and below it.

– Don’t make the dropdown (or radiobutton or checkbox) the first element in a form.

Are dropdowns problematic?

In favour of dropdowns:

– US users are more used to dropdowns, because they are used to selecting their State. International sites often ask for country.

Opposed to dropdowns:

– …

More issues

General usabililty issues of  dropdown menus

Avoid long dropdown lists.Elderly have difficulty or annoyance of using dropdowns, especially if they are long. In some cases users don’t know that you can scroll inside the menu.

(source needed)

Dropdowns affect user performance and error rate. Using the mousewheel you can change the selection inside the dropdown if the mouse cursor is over the dropdown menu. The dropdown is prone to accidentally change the value. In one form usability test the most common user error was the user had selected the wrong expiry year for his creditcard.


– Dropdowns z-index obscure other elements such as custom tooltips, lightboxes, Flash applets

More issues:

Alternatives to dropdown

Radiobuttons –

Articles/research:;Match;Matches&z=4 – discussion about various issues and usability test results of  dropdowns


autocomplete (e.g. Gmail To field), autosuggest (e.g. many latest browser and Google Auto-suggest)  and

Scrolling shopping baskets

December 7, 2009

Some quick thoughts..Scrolling SB has comes with risks. If the shopping basket is too long, the totals and ‘checkout’ call-to-action button could appear below the fold. This is especially the case if many products have been added and at lower resolutions or non-maximized screens. Users would have to scroll to the bottom of the page to get the ‘checkout’ button in view.

I recommend:
– non-scrolling SB.
– if it must scroll, then make sure it anchors to the bottom of the page, so the checkout button is always in view (the top the basket then won’t be though..)
– make it scroll along slowly 
– either keep the product descriptions short (or empty) or consider removing the totals. test the worst-case scenario if it is a likely one.

Anybody seen any examples?

Tooltips and title (and a bit about alt tags)

January 9, 2009



Also known as

title attribute, titles, link title

See also

Variants of tooltip: click-tip  (user must click to view tooltip), super-tooltip (richt-text styled tooltip)

Similar to tooltip: ALT-tag   (see below for differences of ALT tags)



Above: NiceTitle is a JS/CSS implementation by somebody

Applies to

– Links <a> and navigation links
– Form elements and controls
– Buttons and controls
– Images and logo’s  (could contain tagline)


– The goal of the link title is to help users predict what will happen if they follow a link.
– It’s a navigation aid to decrease disorientation of links. For example, tooltips on the home page allow the user to quickly preview the underlying content behind a link, without having to drill down into the page.
– Tooltips can save user time, avoid waiting for pages to load, especially those of badly named links.

– People often ignore embedded links. They don’t want to be interrupted by having to wait for another page to load. Tooltips can increase motivation to visit a link (if written well and not overused).
– In Web Apps, use tooltips as a descriptive text to tell user what the object under the mouse does. If you don’t need them, that’s great -you have a self-describing design- but many users expect tooltips anyway. [3]. “Minesweeping” is the irritating activity of moving the pointer across icons to uncover ToolTips or rollovers in order to figure out what the icons represent. Such designs require the user to actively decipher the interface, probing and testing the meaning of each interface element, rather than the interface elements being self-apparent.
– For form controls?? (e.g. the +/- buttons in a shopping cart)
– For images use the alt attribute, not the title attribute.


– Beware, tooltips can obscure the view of any elements under it.
– Mac browsers show web tooltips in [balloon tooltip] style instead of rectangular PC style [Nielsen, 1998].

– Tooltips appear after 0,5 seconds and dissappear after ~5 seconds


– Title attributes are by default NOT read by screen-readers (as oppossed to what Nielsen says), but if the user has turned it on can be read out loud by auditory browsers.
– There are some notes that state that the title attribute can be harmful to accessibility.


There are no known SEO beneficial effects to using TITLE attributes. If any benefits are mentioned, they are often myths. Further research is needed.


Appropriate information to include in a link title can be:    [source:1]
– name of the site the link will lead to (if different from the current site)
– name of the subsite the link will lead to (if staying within the current site but moving to a different part of the site)
– added details about the kind of information to be found on the destination page and how it relates to the anchor text and to the context of the current page
– warnings about possible problems at the other end of the link (for example, “user registration required” when linking to The New York Times) 

– Don’t add link titles to all links: if it is obvious from the link anchor and its surrounding context where the link will lead, then a link title will reduce usability by being one more thing users have to look at.
– The user should not have to read the whole tooltip text. The first few words should give the user a good idea of what the link is about.
– Tooltips have to be brief. Some browsers (FF) can show only a limited amount of tooltip text and often disappear after 5 seconds. Limit to 60-70 characters.
– Tooltips on links should be used to enhance website usability through information scent.
– Use tooltips only when they provide the supplementary information about the link that they’re intended for – don’t use it to say ‘Click Here’ and don’t repeat the link text redundantly (although Amazon and Landsend do do this for their image-based commerce buttons).
– Don’t use title attributes for anything not supplementary, definately don’t use it for site critical information.
– make the link anchor and its surrounding text understandable without seeing the link title. Users should not have to point to a link to understand what it means: the link title should be reserved for supplementary information.
– There is no proof that titles affect SEO.

Process of identifying alt/title tags

Next time we define tooltips, maybe we should first carefully identify if each link/button we want to give a TITLE tag/attribute is not in fact a button image. For example, I’ve found that the buttons in an Order Process I was working on were not images, but (copy-able) text. To check this, right-click an image or try to select the text characters in the link (would this work for all cases?). However, what to do in such cases where there is a clickable, copyable link on top of a clickable image button? I suppose that the former should receive a TITLE tag that has the exact text as the ALT tag of the button below it..

Differences with ALT-tag

Whereas the TITLE tag can be used for practically all HTML elements (<a>, <span>, etc), the ALT tag or attribute is used for images (<img>) only.

All the above guidelines apply to the ALT tag also, with the following exceptions:

  • All images should have an ALT tag. All clickable images should have an ALT tag which describes the text on that button, usually just a repeat of the exact text of the button itself.
  • Possible SEO benefits of using ALT tag versus none for using an TITLE tag.
  • Accessibility benefits of ALT tag has been proven over and again, whilst those for the TITLE tag are over overrated.
  • Possible design (look) differences.

Links and further reading

[1] Jakob Nielsen’s “Using Link Titles to Help Users Predict Where They Are Going” @
[2] Presentation about Title attribute at Web Essentials 05 @
[3] Designing interfaces (book)
[4] Microsoft (Windows) tooltip guidelines @

 For Developers

NiceTitle by
Similar examples to Nicetitle here
A gallery of 50+ Tooltip scripts also useful for designers