AltFontPrev is a JavaScript bookmarklet that allows you to preview how any website would look if a particular font was not available or a different font chosen. Each font used to style elements on the page is listed under its selector and, when clicked, is moved from being a fall-back to being the primary font.

As well as choosing a font from the existing CSS declarations, you can type a custom font to override everything. Hopefully this will help you choose alternative fonts when perfecting your site’s typography.

Most designers wireframe their designs in one way or another, even if it just involves them making quick sketches on the back of some scratch paper. Wireframing is an important part of the design process, especially for more complex projects.

Wireframes can come in handy when you’re communicating with clients, as it allows them to visualize your ideas more easily than when you just describe them verbally.

This guide covers what you need to know about website wireframes to get started.

I loved elastic textareas since the very first moment I used one (at facebook obviously). They let you save screen real estate while at the same time they are more comfortable for the end user. It’s one of the rare occasions when you can have your UI cake and eat it too!

However, I never liked the implementation of the feature. In case you never wondered how it’s done, let me explain it in a nutshell: All elastic textarea scripts (or at least all that I know of) create a hidden (actually, absolutely positioned and placed out of the browser window) div, copy some CSS properties from the textarea to it (usually padding, font-size, line-height, font-family, width and font-weight) and whenever the contents of the textarea change they copy them to the hidden div and measure it’s dimensions. It might be good enough for facebook, where the styling of those textareas is fairly simple and consistent throughout the site, or any other particular site, but as a generic solution? I never liked the idea.

So, I tried to explore a different approach. As Andrea Giammarchi recently wrote “This is almost intrinsic, as developers, in our DNA: we spot some interesting concept? We rewrite it from scratch pretending we are doing it better!” and I’m no exception (although in this case I don’t think I did it better, I just think it has potential). The basic idea is quite naive, but it works quite well in most browsers (Internet Explorer being the black sheep as usual): Test if the textarea is scrollable, and if so, increase it’s rows attribute and try again. If it’s not scrollable initially, try decreasing it’s rows attribute until it becomes scrollable (and then ++ it).

It works flawlessly on Firefox and quite well on Safari, Chrome and Opera (it just slightly twitches when it enlarges in those). Stupid Internet Explorer though repaints too many times, causing a flicker at the bottom when the user is typing, something really disturbing, so I can’t consider the script anything above experimental at the moment. I’m just posting it in case anyone has an idea of how to fix the aforementioned issues, because apart from those it has quite a few advantages:

* Should work with any CSS styles
* No library requirements (unlike all the others I know of)
* Only 800 bytes minified (2.4KB originally)

So, here it is:

My name is Lea Verou (actually, in official papers it’s Michaelia Komvouti-Verou, but who can bare to use such a long name in everyday life?) and I’m a front-end web developer currently living in Greece. I am the co-owner of a small company named Fresset Ltd. At the same time, I study Computer Science in Athens University of Economics and Business. I am passionate about JavaScript and CSS3, so this blog is mostly devoted to them. You can email me at me＠leaverou․me (don’t copy/paste the email, it won’t work. Note to self: Must add contact form). Please note however that I am too busy to accept web design/development projects for clients at the time, so if you wanted to contact me about one, don’t bother (unless it’s something quick and interesting I guess).
View my CV
About the blog style:

This was my first second attempt of creating a WordPress theme. Given that it’s a personal project, I promised myself not to pay much attention to the Evil browser (we all know which), especially older versions of it (*cough* 6 *cough*). This theme is heavily based on experimental CSS3 properties, so it will look better in more CSS3-supporting browsers (modern versions of Firefox, Safari, Chrome or Opera). I did devote some time to make it look OK in other browsers but given that this is my personal blog, I wanted it’s design to be fun for me, and browser incompatibilities aren’t much fun, as you probably know already. :P

Most of the hard core C++ programmers I know hate user interface programming. This surprises me, because I find UI programming to be quintessentially easy, straightforward, and fun.

It's easy because you usually don't need algorithms more sophisticated than how to center one rectangle in another. It's straightforward because when you make a mistake, you immediately see it and can correct it. It's fun, because the results of your work are immediately visible. You feel like you are sculpting the program directly.

I think most programmers' fear of UI programming comes from their fear of doing UI design. They think that UI design is like graphics design: the mysterious process by which creative, latte-drinking, all-dressed-in-black people with interesting piercings produce cool looking artistic stuff. Programmers see themselves as analytic, logical thinkers: strong at reasoning, weak on artistic judgment. So they think they can't do UI design.

Actually, I’ve found UI design to be quite easy and quite rational. It’s not a mysterious matter that requires a degree from an art school and a penchant for neon-purple hair. There is a rational way to think about user interfaces with some simple, logical rules that you can apply anywhere to improve the interfaces of the programs you work on.

I'm not going to give you "Zen and the Art of UI Design". It's not art, it's not Buddhism, it's just a set of rules. A way of thinking rationally and methodically. This book is designed for programmers. I assume you don't need instructions for how to make a menu bar; rather, you need to think about what to put in your menu bar (or whether to have one at all). There is one primary axiom I'll teach you which guides all good UI design, and it's not hard to understand at all.

As coders, I’m sure we all know the value of good error handling. So I thought a quick post about how Codeigniter deals with those pesky errors would be a good post.

The way I see it, there are 2 types of errors we have to work with. The ones which are displayed out in nice friendly text to your users, and the type which are hidden and shown only to you as the coder to figure out where something has gone wrong. CI provides the means to do both, thankfully.

Creating buttons with CSS becomes a lot more comfortable. The following example demonstrates how to create nice looking, dynamic buttons that are fully scaleable using the new CSS3 properties border-radius, box-shadow and RGBa.

I’m wrapping up my first jQuery UI widget (see multiselect on GitHub) and thought it would be useful to share some notes I took on the widget factory & widget development in general. I personally found development on the factory to be quite enjoyable; a lot of functionality is available right out the box (custom events, ability to change options after initialization) and idioms you might not otherwise consider, like widget destruction. Furthermore, it imposes a clean object-literal development structure with public and private methods, making it much easier to start a project or maintain other’s projects.

Ryan will explain the key concepts you should understand to design and implement UI for your apps. He’ll cover screen-level details like language and visual techniques as well as deeper topics like modeling and best practices for coding templates and helpers.

Style guides are a great way to ensure user experience consistency when developing an application and a way to communicate user experience standards across an organization. They can be application specific, platform specific, and may encompass enterprise-wide standards. A style guide can help make the development of user interfaces more efficient and help ensure good user interface design practices.

On websites that have a lot of pages, breadcrumb navigation can greatly enhance the way users find their way around. In terms of usability, breadcrumbs reduce the number of actions a website visitor needs to take in order to get to a higher-level page, and they improve the findability of website sections and pages. They are also an effective visual aid that indicates the location of the user within the website’s hierarchy, making it a great source of contextual information for landing pages.

Working with progressive enhancement in mind for a long time, I found that the following rules all made a lot of sense and have quite an impact to the final product in terms of maintainability, size of code and general sturdiness:

1. Separate as much as possible
2. Build on things that work
3. Generate dependent markup
4. Test for everything before you apply it
5. Explore the environment
6. Load on demand
7. Modularize code

We have put together a great compilation of beautiful web application interfaces.

The web applications that were selected to be part of this showcase are based on usability, simplicity, colors and overall layout.

Despite what many people will tell you, there are no hard-and-fast rules when it comes to call-to-action buttons. Yes, it’s true that large, colorful buttons, surrounded by plenty of space are usually the most successful, but it’s important that you tailor each button to the primary task of the web page in question, whether it’s to Signup, Checkout, Register or anything else. As a designer, it’s your job to make it as easy as possible for visitors to achieve these tasks and call-to-action buttons are the most powerful tools at your disposal, so use them wisely.

Generally speaking, call-to-action buttons should be simple and clear. They must stand out and grab a user’s attention. Everything must be carefully considered, from the trigger words used to colors, sizes, shapes and positioning. These buttons must be highly visible, but not so garish that they render your site ugly or unbalanced.

With jQuery outside events you can bind to an event that will be triggered only when a specific “originating” event occurs outside the element in question. For example, you can click outside, double-click outside, mouse-over outside, focus outside (and over ten more default “outside” events). Also, if an outside event hasn’t been provided by default, you can easily define your own.

Note that this was previously known as the “jQuery clickoutside” plugin.. but, hey—it’s pretty amazing what a an awesome idea and few more lines of code can do!

The other day I was chatting with some of the designers at work about secondary navigation and the subject of breadcrumb trails came up. Breadcrumb trails are those bits of navigation summed up by Jakob Nielsen as:

a single line of text to show a page’s location in the site hierarchy. While secondary, this navigation technique is increasingly beneficial to users.

and illustrated on Wikipedia by:

Home page > Section page > Subsection page

For reasons which will hopefully become clear the whole subject of breadcrumb trails vexes me and rather than shout into Twitter I thought I’d type up some thoughts so here goes.

User Interface Design Pattern Library. UI patterns for web designers. See examples and read rationale, solutions, and implementations for each pattern.