A while back, Randy, of ümlatte, posted some thoughts on becoming a full-stack developer, something that I take pride in being. Though I think it may be impractical in many (mostly larger) situations, developing a Web application (or anything) from end-to-end can be remarkably fulfilling, not to mention extremely efficient (assuming you’re good at each part of the stack). I think that as Web development has become more of a “real” profession, we see less and less people doing it all.
Anyway, that’s another post. Randy’s a fantastic developer, and he’s hoping to become a fantastic designer as well. In his blog entry, he says:
If anybody has any suggestions about how I can go about achieving my new goal, please feel free to speak up! I have a feeling this is going to be quite a bit more difficult than web development since design is so subjective.
That got me thinking—can you learn design? I’m not sure. In fact, I have two completely conflicting views: one practical (a) and one philosophical (b):
I’d guess that my first HTML project was maybe 95% other people’s code, 5% mine. Similarly, my next project was probably 90%, the third 80%, the fourth 70% and so on. Now it’s rare that I copy other people’s code, but that pattern holds true for every new language I learn, and I’m guessing that’s true for most Web developers. So why not for design? In design we call it inspiration, but is it really that different? The first two pages of my delicious bookmarks include an overwhelming number of design galleries, trends and tutorials. Often when I start a design project, I’ll find myself browsing through some of my favorite galleries and design magazines looking for inspiration. When I was first learning Photoshop, my designs were probably 95% tutorial, 5% my design. Now it’s rare that I actually follow the tutorial instructions, but I still look at them for inspiration.
So, my practical advise would be: do the same thing you did learning HTML, learning CSS, learning Javascript, learning Ruby, learning PHP, etc, etc. Copy. Over time you may find that you need to copy less and less.
But there’s more to it than that. I don’t know what it is, but I know it exists. There’s something that makes Jonathan Ive special; something a Web designer like Joshua Davis or a graphic designer like Fabio Sasso has that not everyone has. We’ve all got a little bit of it, but while some folks have a tablespoon or maybe even a cup, others have a bucket.
That’s not to say that you shouldn’t try. It doesn’t necessarily just bubble out of you like you might imagine it did for DaVinci. Sometimes you don’t have the technical knowledge. Sometimes you just haven’t given it a chance. But I don’t think anyone can just pick up a Wacom tablet and design a site like Dave Shea or Dan Cederholm any more than they can pick up a paint brush and paint like Thomas Eakins.
So what do I actually think? I don’t know. I think there are a lot of things you can learn, from color theory, to proper use of white space, to typography, to concepts like the Golden Ratio. And I certainly know that I was a better graphic designer after taking some design classes in college than I was before. But I think a lot of that comes from doing it, and either getting it or not. Randy’s a pretty talented guy, so I wouldn’t be surprised if he gets it, but I’m not sure if he’ll learn it or just finally discover it was already there to begin with.
OK, this has bugged me for a long time. Many times I’ll come to a site which helpfully auto-focuses on the input element I’m most likely to use (either the username field of a login form, or the query field of a search form). But if the script to make this happen is slow, I’ll often find myself typing over my already half-written search query, or even worse, typing my password (in plain text) into the user name field.
I’ve come up with a few possible solutions. To start, you could just skip the auto-focus code all together and let your users manually select the input they want to type in. This can be fine, but in my opinion, what separates good UI from great UI is when the system seems to know what you want and is one step ahead of you. So how can we avoid the problem while still providing the functionality?
Commenter Joe points out that all three of these techniques fail if you use your browser’s autocomplete to pre-populate the field, but want the web page to focus on the field so you can either hit return or enter a custom username. To handle this scenario I’ve come up with a new recommendation based on focus rather than content:
<script type="text/javascript">
$(document).ready(function() {
var el = $('#query')[0];
if (true !== el.hadFocus) {
el.focus();
}
});
</script>
<input type="text" onfocus="this.hadFocus = true;" id="query" />
So now, instead of checking to see if there’s any content in the “query” field, we’re checking to see if the user has focused on it. If they haven’t, it’s safe to change the focus there. If they have, you know they’re ahead of your code, and you can just get out of the way.
You might want to expand this to check if any field has been focused on. That way if someone starts typing in your search box, you don’t accidentally send them to the username field. But in general, something like the code above should be good in most situations.
Let me know if you see any potential problems.
Continue reading “Auto-Focus Input” »
Recent Comments