Sometimes I realize something that’s so obvious that I actually slap my forehead and say, “duh.” I had one of those moments this morning:
I use IMAP for all my e-mail accounts because I love the access-anywhere freedom it provides. But there’s definitely an associated lag with just about everything because you have to talk to the server to do it. Particularly when trying to reach Inbox Zero, this can be a major pain, because the half-second that I have to wait for a message to move from my Inbox to, say, my Action-1 (requires action, high priority) folder can really add up over a few hundred messages.
Well this morning I had this great (and blindingly obvious) idea to process e-mail “Offline.” Almost all e-mail clients have the option to download your messages, make changes/write emails offline, and then send and “do” all those changes once you get back online. Well, you don’t have to actually be offline to enjoy this feature. Not only is manipulating IMAP mail instantaneous, but you also have the added benefit that no new mail comes in to distract you from the task or sorting old mail. Genius!
I feel like I must be the last person on earth to discover this fantastic tool, but just in case I’m not, I wanted to share it with the world. Best case scenario, someone else gets to hit their forehead and say, “duh.” If nothing else, everyone who figured this out 5 years ago can have a good laugh at my expense.
Ajaxian just recently posted a great summary of Clay Shirky’s In Praise of Evolvable Systems. In it he talks about how all the poor design decisions that went into making the World Wide Web were overcome by its ability to evolve and survive in less-than-ideal scenarios. Shirky’s theory is that because the Web’s infrastucture is so versitle, and because it’s so easy to implement enough to have something, it was able to develop into what it is today.
At the end of the article, Shirky establishes three rules for evolvable (and thus potentially successful) systems:
I’ve been thinking a lot about decentralized/distributed microblogging, and when I read this article it really hit home. Shirky’s advice rings true for a lot of things, but it particularly resonated with my feelings about decentralizing microblogging. But before I continue I need to give an example:
Microblogging may be, at its core, a system for distributing 140(ish) character messages to various “followers.” But there have been a lot of services around microblogging that are definitely part of the same idea, but not quite. DailyMile is a great example of this. You’re still essentially sending out short messages to your friends/followers, but those messages have some additional meaning/metadata (such as workout type, time, etc). BrightKite is another example—you’re still sending out short status messages, but they’ve got a location attached.
The beauty of an open source, decentralized microblogging system is that you could build a system that does the core of microblogging well, and build it in such a way that those of us who also want to send out workout updates can extend the system to include workout metadata, and those of us who want to send out location updates and extend the system to include location metadata. That is, if the system is built to evolve, it can benefit from Orgel’s Rule. Anyone who comes up with a clever idea can implement it while tapping intro the existing infrastructure.
This has always been an important element for me, but Shirky’s article really solidified in my mind how important it is. If a system isn’t easy to implement in some way, it will fail. And if a system can’t evolve, it will fail.
Right now I have a few pages of notes/thoughts about decentralizing microblogging. Hopefully I’ll find some time to make them a bit more coherent and post ‘em. If you’ve got any specific ideas, feel free to get in touch with me or comment below.
A couple of days ago Saul Rosenbaum asked for a little help with a PHP utility he was writing. I took a crack at it, and we ended up with a nice little class that generates CSS sprites from pairs of images. Saul wrote a great little README for it, but the general gist is that it takes a00.gif and a00_over.gif and creates a new a00.gif that has both images vertically stacked within it (it can do this with large batches of images).
We submitted the files to IndyHall Labs if anyone is interested in using them. If I have time I’ll be adding some new functionality (Saul added a wishlist in the README file, and I’d definitely love to tackle some of those issues).
You can download the files from GitHub: https://github.com/IndyHallLabs/css-sprite-generator/
Microsoft Passport was a good idea. OpenID is a better idea. Gravatar is a good idea. Pavatar is a better idea. I think whenever a system can be open and decentralized, it should be (see my upcoming post on decentralized Twitter). For those of you who like the idea and want to use it, here’s a quick and dirty PHP method to get the Pavatar image for a given URL (supports all three Pavatar techniques)…
Continue reading “Simple PHP Pavatar Method” »
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” »
Over the weekend I made a few quick updates to the Philly New Media Hub. Now you can get aggregated content in a number of formats:
I’m also toying with the idea of a daily/weekly newsletter option. Let me know if you’re interested. Also let me know if there’s some other way you’d like to access the content.
Please fill out this form to discuss a new web design/development project.
OK, so our 100 Push-Ups group challenge started on Monday. Now we have 6 people going for it. Thanks to Roz, we got set up on dailymile.com and I threw together a group for us (there’s also a global hundred pushups group). If you want to join us, join the group on dailymile.com. If you don’t have an account, get in touch and I’ll send you an invite.
Pzizz I can live without just fine, but would someone please release an SSH app already!?
Recent Comments