That is plain horrible–no one needs a font multiple times–and it is making me seriously rethink this. I know, I know–it’s a blog, and I very much doubt I have readers who would still be on dialup. But it is taunting me and my years shaving kilobytes off page loading time D:

Tell me, is it worth it?

A few years ago–especially my last year in college and a year or two after I graduated–I enjoyed developing for the sake of developing. I didn’t care who would see it and use it, or what it would bring me: I only cared that I enjoyed making these things, and that they were useful to me in some way. That gave birth to the small hobby scripts in my archive, to the multitude of sites I used to own.

Now, I feel this pressing need that what I make/develop needs to either be profitable at some point, or game changing. It needs to matter to a lot of people. It needs to be significant to people.

And then I never get enough steam to carry me through more than a couple weeks to get it out. Since I am creating for the sake of some imagined external return (in various forms), even if I do love the idea (i.e., one of these ideas have been in my “plans” since more than five years back) it’s never been enough to keep me going on to completion.

(Some say this is why a “co-founder” is important, because you get to have the support you need to keep you going and fueled, but that’s for a different time.)

A friend suggested, well, why not redo those things you did, but this time in HTML5 and CSS3 and use AJAX and all that? But that’s exactly the thing: I don’t feel like redoing them anymore, aside from the occasional spurt of ambition. I have the expertise, but I don’t feel like redoing them for nothing, “just for the hell of it”. However, once I give my little project a goal, I get embroiled in doing it “the right way”, and I end up in that sad little hole that is called over-engineering. Which I dislike, and end up abandoning.

It is a disheartening realization. I have this need to be purposeful (likely a symptom of growing older?) in what I do, but I soon lack the joy in creating as I used to do. There is no drive to make something without a “purpose”, but there is no love in making something tailored for one.

But, a light at the end of the tunnel! As I’ve mentioned before, most of my hacking had been brought about by my learning something new. I don’t think it has to be anything really significant sometimes–I’ve had fun hacking together a few dirty WordPress plugins for my own use, for example. Baby steps, but steps all the same.

It’s never too late. :)

In 2010, I didn’t give myself any of that. In 2010, I planned to get myself an iMac, but that didn’t happen. I spent my money on other, “bigger” things, and subsequently I did not have any budget left over to give myself the iMac. (I’m hoping to give myself the iMac this year, but with my finances at the moment, I doubt that’s going to happen.)

In 2010, I also lost my ol’ monitor. I don’t think it’s entirely lost, but it flickers every so often that I’ve just plain stopped using it. Maybe someone else can figure out how to fix it, but that someone isn’t me. Part of me says just give it to the recyclers who come by around once a month, and part of me says maybe someone will want to buy a slightly wonky monitor cheap and, if not fix it, salvage it. For now, it’s going in the storage room, because I don’t know what to do with it.

In 2010, I did buy a color printer, so I can do my own printing and also do a bit of bookbinding with my own printed paper, own designs, own whatever. I have not fully utilized it in 2010, that’s for sure, but I’m happy anyway with my li’l purchase. It’s already saved me a couple of times.

I also started to be more vocal about user interfaces and user experiences in 2010. I’ve always been very interested in how the web affects users, how it can influence people, but I think it was this year that I started gaining more confidence in my experience and knowledge. It was this year that I was really able to pinpoint what I wanted to do–not just websites, but what kinds of websites, what kinds of projects, what kind of experiences I wanted to create.

I think all those realizations are due in part to the support from my teammates and superiors, but also because in 2010, I started treating the web as a hobby again, like I used to do. I started taking this blog seriously, I reopened my portfolio. It wasn’t that I had more time, because I actually had less, but I made time for it, and that extra dose of creativity is reinvigorating me in other aspects of my life, opening my mind to more ideas and more experiences.

2010 was an interesting geeky year. No new geeky toys, but a lot more geeky experiences.

This week is recap week! Stay tuned for piecemeal recaps of how 2010 went for me.

Take this gem:

This week gave us 45 resolved bugs (mark and fu were rocking the review queue), which are described in this week’s code tour by sporky_rat.

So, I realize that not everyone will read that and think coding and resolving 45 bugs in a week is “fun” and “glamorous”. However, it reminds me of the days when I was working on Enthusiast and my other scripts, of working on my couple dozen websites. It was fulfilling and fun to set out to do something and have it done quickly.

Now, where to find the motivation to look at PHP, HTML, CSS and JavaScript after a day’s work on the same thing? Or even to go back to web design? That’s what I’d like to know.

I enjoy coding. I enjoyed it many years ago when I made my first website from scratch, and I continue to enjoy it today. I especially enjoy making things that I can use but make it so that other people can use it, too. I like finding out that something I made is useful for others. That’s the whole reasoning behind all of the linkware scripts that I have done.

And then, Enthusiast happened. For whoever of you who have no interest in the fanlisting online community, you probably have no idea what it is. Enthusiast is a fanlistings and fanlistings collective management script, and a pretty damn good one (at the very least, back when I was active in the community). I have no idea where fanlisting scripts stand nowadays, but I’d like to think Enth is holding its own even if it’s old and “clunky”. I started writing the earliest versions for myself, prettied it enough to make it downloadable, and in no time at all it was huge (figuratively and literally).

It’s still my baby. I loff it the same way I loffed it before. But after months (a year? more?) of hemming and hawing, I’ve decided that I needed to step back from it, maybe temporarily, maybe permanently. Enth has affected my life a huge deal, in many different ways.

The good things:

1. The no-brainer: easier fanlistings management! I love fanlistings, they’re cozy and cuddly. But they can be crazy in droves! But Enth has really pulled through for me on this.
2. I learned a lot about PHP coding from making Enthusiast. A lot, from things I researched myself, and things people taught and showed me.
3. I’ve met a lot of people via Enth; from users to fellow coders. A number of them I’ve grown quite close to, even if we’ve all slowly moved away from fanlistings.
4. I can’t begin to imagine how much time I’ve spent on Enthusiast, but the time spent with it has been, on the whole, very enjoyable.

Enth’s popularity does have its downsides, such as:

1. Enth’s slowly morphed into something almost unmanageable. I’ve felt a bit of pressure with doing this and doing that simply because, well, it’s what users want. While generally these are things that I do want somewhere down the line, it’s just slowly gotten to the point when my hobby project has become a bit of a burden and yet there’s this pressure to work on this, to fix this, to add this feature.
2. The pressure related to this has affected my participation in the fanlistings community. I’ve felt guilty working on my fanlistings when Enth (Enth4 specifically) is still not done. I haven’t applied for any fanlisting in ages because of the same.
3. People’s expectations seem to keep rising and rising. I have no idea what people expect now, but that’s because I’ve purposely avoided knowing what they are, now. I want to make Enth better so much, and I have a lot of ideas on how to do that; but can you imagine how many will complain about what happened to this feature, or why is this doing this now, or I’m not moving because it’s a pain to upgrade. These are certainly all part and parcel of getting a script up for others to download, but little ol’ me feels overwhelmed.

I feel it’s sad that the reason why I worked on Enthusiast (that is, fanlisting) became something I avoided or felt guilty about doing because of Enthusiast.

I’ve gone through months and months of agonizing about this. The fact that I do have other things on my plate doesn’t help with the indecision and the pressure that I was getting, too. When I finally made the decision to put Enth on hold, I finally felt that I could breathe easier.

And thus, there you have it. Enthusiast is officially on hold. All development is stalled, I haven’t looked at any Enth code in months. It doesn’t mean to say I will never go back to it, but it won’t be for a good while. :) Maybe when I can get back into the fanlistings world, eh?

If you have any questions, concerns, or any general comments about Enth (or anything else dev-related I have done), please feel free to comment and ask. (Don’t ask me for troubleshooting support though ;) that doesn’t change, haha!)

One of the best ways to speed up website performance is by reducing the number of HTTP requests the website makes — it’s the first rule in YDN’s Best Practices for Speeding up your Web Site and YSlow, which is arranged according to what technique would have the most impact on your page’s performance. This rule can be quite tedious to do when optimizing a current website/layout, so the best case, really, is to start a project with this in mind.

The article explains it well, so I’ll just quote them (italics mine):

80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, stylesheets, scripts, Flash, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages.

The use of CSS sprites has been around for quite a while now, and is the best way to reduce the number of HTTP requests to your server. A CSS sprite is basically multiple images combined into one single, larger image, which is then positioned into your HTML elements via CSS.

Can you imagine the conversation between the browser and the server for either case?

Browser: Give me the background for the Index menu item.
Server: Here you go, it will take around 1 second.
Browser: While I’m getting that, can you also get me the background for the Blog menu item?
Server: Here it is, another second for that.
Browser: And let’s not forget the background for the About menu item, too.
Server: Of course, here you go, you’ll get it in a second.
…

As opposed to when you use a CSS sprite for your menu items:

Browser: Give me the background image for the navigation menu items.
Server: Here you go, it will take a bit less than 2 seconds.

Short and sweet.

Note, however, that if your visitors are predominantly dialup users, this might not be a good rule for you to follow — mostly because you really can’t stuff any more data into that pipe than that pipe can handle. It will take longer for them to download the image, which will affect their perception of the website, as opposed to an image that gets downloaded faster and shows up on their browser faster. Remember those old-school rules about slicing header images? That’s basically rooted in that scenario: dialup can only download so much, so give them a couple parts of the header to download and see immediately. What’s best for your website depends on your target visitors.

There are a couple of CSS sprite tutorials and generators around:

• CSS Sprites Generator – a simple generator, giving the sprites in PNG and GIF and giving background positions for each image
• Website Performance’s CSS Sprite Generator – contains a lot more extra configuration options for sprite generation if you want finer control, allows you to choose what image format to generate
• A List Apart’s CSS Sprites: Image Slicing’s Kiss of Death article
• CSS Sprites: What They Are, Why They’re Cool, and How To Use Them
• Image Sprite Navigation With CSS

…to name a few. If you’re just getting started with spriting, I’d suggest you create your sprite manually in your preferred image editing application before trying one of the generators and work on something simple like navigation or lists with icons for the first few times. This should give you a better grasp of what happens with a sprite.

Something to keep in mind: sprites will add complexity to maintaining your design. Adding another image to an existing sprite, updating your CSS code to reflect that (and possibly impacting current CSS rules on other images using that same sprite) is slightly more time-consuming than just uploading a new image and a new CSS rule to use that single image. And of course, the more images on a single sprite, the more difficult it is to keep that image and the accompanying CSS rules maintainable. One of the ways to combat this is to organize sprites according to use. As opposed to one über-sprite containing everything and the dust on the coffee table, a sprite for navigation and a sprite for list items separately is easier to maintain and organize.

Good luck with minimizing your HTTP requests!

With high-speed Internet, a lot of times we tend to forget about the size of the files we put up on the Internet on our websites, much less worry about how long someone takes to load our website. It’s easy to forget, but when you’re on a crappy dialup or using your mobile phone as a model (er, like me while transitioning houses!), or you’re, say, a trouble-checker for one of the fanlisting networks out there, the wait for websites to load can take its toll, and feel painful on the pocket.

Two reasons why optimizing websites — even if you’re not Yahoo! — are:

1. You keep visitors longer, because the wait time is less, and people like things faster than you can chug them out. It’s all about instant gratification these days.
2. You save on bandwidth! Something smaller by even 10kb can mean megs or gigs of bandwidth savings in the long run. If you pay for hosting and you have a fairly popular website, this is a big deal.

A lot of this work is done on the frontend side of things. After all, once the server has cobbled together the page, the bulk of serving the page code and objects rely on the user’s connection. The HTML code is just one part of what’s served out to people, but images, stylesheets and other media are downloaded all after the source is available. And these are the things that users see and perceive. The image below shows around a third of Firebug’s Network tab on one of my websites:

Building and serving out the page takes up only 715ms. But the rest of the objects on the page are then loaded, and I end up with a 4.08-second load time. That isn’t so bad, but all the rest of the objects on that page form the bulk of the load time that users have to endure. If we save a few milliseconds from each object, overall we can get a snappier load time for the whole page.

In The Psychology of Web Performance, Andrew King highlight a few interesting results of bloated load times, in case you’re still not convinced:

• Google found that moving from a 10-result page loading in 0.4 seconds to a 30-result page loading in 0.9 seconds decreased traffic and ad revenues by 20% (Linden 2006).

• Tests at Amazon revealed similar results: every 100 ms increase in load time of Amazon.com decreased sales by 1% (Kohavi and Longbotham 2007).

Over the next Frontend Fridays, I’ll talk a little more about some ways to optimize frontend performance. I’ll mostly be going through the rules Yahoo! has published, but I will probably cherry-pick and talk about the ones I like most, the ones I like doing. Stay tuned :)

The event is basically a networking session with Philippine developers, with a bit of overview on what YDN is: a free resource for web developers that contains not just information, documentation, and tutorials on the various APIs Yahoo! has, but also a couple of tools and articles to help developers (like YUI <3).

There were lots of shop talk, which was definitely fun and a lot more of the same would be fabulous. :D I’ve never really attended networking sessions before, as I’m generally a bit of an introvert when it comes to approaching people and introducing myself, but the night went quite well and I had a great time. I hope everyone else who was part of it felt the same. :)

As I had a pretty busy week last week due to the event preparations and travel, I hadn’t been able to work on last week’s Frontend Friday! Sorry about that, but I promise I’ll have something this week, and will also prep for next week’s FF (I will be Internet-less next week (save for when I’m at the office) due to moving out!).

I just wanted to know how you decide how much AJAX is too much AJAX? You don’t seem to use much (if any) on this website.

It’s a good question, but the answer isn’t too straightforward: it will always depend on a large number of factors. For me, an indication of a developer/team getting too AJAX-happy would be when the site becomes unusable when JavaScript is turned off or isn’t working. For example,

1. a website that loads all (or most) of its content via AJAX, therefore rendering the page content-less without JavaScript; or
2. a website whose navigation is inaccessible without JavaScript.

JavaScript should enhance websites and applications, no doubt about that. Most, if not all, of the well-loved web apps of today are due to the snazzy-ness of AJAX. But we can’t always rely on JavaScript being present: even if users have it turned on, spotty connections and unexpected data returns can result in JavaScript being pretty much nonexistent. Progressive enhancement and/or graceful degradation should be important when working with JavaScript–whether or not you’re doing asynchronous calls or not.

However, like I said, the answer isn’t straightforward. Some applications really do rely on the existence of JavaScript, and for good reasons. Graceful degradation can be prohibitively difficult when you’re dealing with some specialized web applications, like mail: Yahoo! Mail and GMail come to mind. User interactions with both of these are so fine-tuned and uses a lot of convoluted interlocking parts, and degrading gracefully would be a pain. That’s why both apps have a no-JavaScript version as well (Mail Classic and Basic HTML view, respectively).

As for the second part of the question–no, Indiscripts doesn’t use any AJAX :) Mostly because I don’t see a need for it, or the “need” to use AJAX is lower than the time I have budgeted for designing and coding up my tech blog ;)

This year’s survey corrects many of last year’s mistakes, with more detailed and numerous questions for freelance contractors and owners of (or partners in) small web businesses. There are also better international categories, and many other improvements recommended by those who took the survey last year.

I took it. Have you taken it already?