With that I have compiled a list of Imulus’ New Years Resolutions. And while I’m sure each individual of our team has their own take I think this about summarizes our goals.

1. Refine and expand our internal review process
   Here at Imulus we’ve got a group of very talented people. However, sometimes we don’t utilize this to our fullest. In 09′ we’ll strive to include everyone in our internal usability and design processes. Making sure that our approach to a client solution is the absolute best it can be.
2. Have an impact on our community
   Denver and Boulder are great cities with lots to offer. Great scenery, a hip tech movement, and engaging cultural opportunities. We think it’s important to offer something back to these places. In 2009 we’d love to be more involved in the education sector. This means everything from guest lecturing to hosting students at our office for the day. We’d also like to provide our support to worthwhile local causes. Green initiatives, cool industry meetups, and cultural events.
3. Define our identity. Who is Imulus?
   We’re a group of passionate, creative, driven people. And while internally on a day to day basis we have an identity — we haven’t worked hard enough at expressing it outward. In 2009 look for us to:
   • Be more vocal about our thoughts on the industry.
   • Push the boundaries of what a small time agency can do to change the way people work.
   • Expand ourselves as people not just a company. Each employee at Imulus makes us who we are as a company. We want the world to know each one of us better and see why Imulus is who it is.
4. Stay a family, not a company.
   We love what we do and we love who we do it with. Imulus is a family. No matter how stressful the project, how stringent the deadline, or how tough the personal problem is, we are there for each other. This is why we’re not a normal company and this is something we don’t want to change.

We’d love to hear your New Years resolutions or your thoughts on ours. Please feel free to hit us up via the comments, follow us on twitter, or join us in person. Happy New Year to you!

Enter Sweetcron, a free Wordpress like PHP and MySQL content system specifically built to handle lifestreaming. I heard about Sweetcron from my buddy Ryan and decided to give it a try for my new site. To my excitement it was exactly what I was looking for. Below I’ll cover the installation, interface, and end result of my Sweetcron experience.

Installation

Sweetcron is the easiest content system I’ve set up in quite some time. You download the compressed files and upload them to your server, create a MySQL database, and edit a few lines of a configuration file with the info. Once this is done the script has a built in installer that runs to finish the installation. By the time you’ve gone through this process you’ll have a username and password through which you can login to your Sweetcron administration section.

Interface and Use

Once you’ve logged into the back-end of Sweetcron you’ll see a few pretty basic options. Write: for posting quick notes, items: a list of your imported (published or unpublished) feed items, feeds: a list of the feeds you’re importing, and options: which contains basic account settings. Setting up your feeds to be imported into your lifestream is a piece of cake. Grab RSS from your favorite social networks and add them into your feed list¹.

Adding a Feed

Feed List

Imported Items

Sweetcron will automatically format and grab the necessary items related to the feeds. From there you can select from a few different themes of how you want your information to be displayed. If you’re ambitious you can set up your own theme by using the Sweetcron documentation.

Pulling Results via Cron

As the name suggests Sweetcron is reliant on pulling information from your RSS feeds at a regular interval in order to update your database. To do this Sweetcron works in one of two ways. First, you can use a pseudo method that will have Sweetcron update itself if the last update is older than 30 minutes. This method waits for someone to hit the site and then has that visit trigger the fetch. This may work for people without cron hosting access but I found the normal cron method to work better. To set this up I logged into my hosting administration and had the following cron job run every fifteen minutes:

/usr/bin/curl -s http://your-url.com/cron/link Note that sweetcron uses curl and this program may be located at different locations on different hosting providers, for instance:

curl -s http://your-url.com/cron/link

End Result

The end is a great looking lifestream that stores all of your information into a MySQL database that you host. The benefits are awesome. First, you own look and feel of the information output. Second, you don’t have to rely on a 3rd party service. And last, the whole setup is opensource, free, and easy to set up.

1. If you have issues with a particular feed’s RSS being supported I’d suggest routing it through Feedburner first and then importing it into Sweetcron. I had to do this with Brightkite.

Unfortunately for quite some time getting MySQL to run on Mac OS X 10.5 was somewhat of a pain in the ass. In comparison to some database setups typing in a few terminal commands is no big deal, however, compared with installing MySQL on 10.4 Tiger the 10.5 install was a huge step back. Tiger had a simple PKG installer that once run offered a simple start/stop MySQL preference pain within OS X’s system preferences. However, with the release of Leopard this prefpane was no longer functional. Luckily the issue has been fixed!

The bug has been addressed and there is now a prefpane that can be downloaded and used with version 5 of MySQL. Further it also seems that new versions of MySQL have this fix implemented by default. Great work MySQL community, it’s always nice to see frustrating issues fixed! Especially those that will help new users get a chance to try the product without jumping through hoops.

From time to time when brainstorming and talking out ideas we’ll simply pull out a whiteboard marker and start drawing right on the desk. Rather than getting distracted moving into the conference room and drawing on the whiteboard (which usually involves erasing it first) we’ll just get our ideas out right away. Plus then you get the added benefit of being right next to the computer and you don’t have to retrace your ideas onto a notebook.

Sure, this could be done using a sketchbook or a portable whiteboard, but we find it a nice add-on to the standard “desk setup” of today’s office.

Fine and dandy. But there seems to be a real world problem.

There are three big reasons I see not to break out CSS into multiple files.

First, when you break out CSS into multiple files you are forced, no matter what to write a lot of duplicate code. For instance, if I want to have a certain container have a typeface, background, and color in a single main.css file I can do the following piece of code:

#element {
     position: relative;
     float: left;
     width: 20em;
     color: #f0f;
     background: url(/images/background.gif) repeat-x 0 0;
     font: 120% Arial, Helvetica, Verdana, Sans-serif;
}

However, if I break this out into: typography.css, layout.css, and colors.css files I have to do the following:

/* typography.css */

#element {
     font: 120% Arial, Helvetica, Verdana, Sans-serif;
}

/* layout.css */

#element {
     position: relative;
     float: left;
     width: 20em;
}

/* color.css */

#element {
     color: #f0f;
     background: url(/images/background.gif) repeat-x 0 0;
}

Okay, pretty easy to see that the amount of code being used favors having one central CSS file. Now, let’s talk about style management and the second argument I have for not using multiple CSS files.

A single CSS file for a website can grow to be quite a large file. Most I’ve written fall in the range of 1200 to 2000 lines. The problem with this is that making small changes can be a bit of a hassle. However, I would argue that the single best way around a complicated CSS file is to clearly comment code, use shorthand css, and make sure there is good style structure. I.E. Don’t go styling something in two different parts of the file and don’t write five lines of CSS when one will do.

But, in no way is the answer to break the CSS into multiple files. Why? Because the worst possible thing you can have to do is deal with the above problem three different times. Granted, if you only have to make a small color change than you only have to edit one file. But, if you use only one file to begin with then you only have to edit one file anyway.

Last, there’s a reason a site like digg loads in one 2500 line CSS file. The answer is that the less page requests the better. Doing multiple page requests to get different styles that are separated is inefficient. If a site gets a lot of traffic or a large traffic spike the less page requests the better. Granted, this may not be common but when it happens there’s nothing more important than trying to keep the site up.

Want more assurance?

Neither Dan Chederholm simplebits.com, Veerle Pieters veerle.duoh.com, or Jeff Zeldman zeldman.com use broken out CSS for type and color.

It has to say something when the big wigs in the bizz don’t follow the advice of A List Apart eh?

Exceptions?

As always, there are a few exceptions to this. For instance, if the website is like MTV.com and has a constantly changing color scheme then it could be useful to break out individual styles into a separate CSS file. One that overwrites the default styles of the base design and can be updated without disrupting the primary styling of the site. Also, microsites that have completely different layouts from their parent sites almost always deserve a new CSS file.

Conclusion

Basically there’s no need to break out your styles into a multitude of files. While the idea of abstraction might sound good the benefits just don’t add up. All you really end up with is a waste of time and resources.

I think that truly listening and paying attention to people’s ideas is something we all could do better.

Let me illustrate this a bit further. If browsers were cars — IE6 would be an El Camino truck that’s been sitting outside in the rain for 20 years. Underpowered, ugly, basically useless in every scenario, and ready to explode and kill you at any moment.

Development of a website that supports IE6 adds about 15 to 20% of additional time to a project. And further, IE6 doesn’t support the everyday commonplace technologies of all other modern browsers. Meaning websites simply don’t function or look as good as they do in today’s browsers.

So here’s the question.

If today’s modern browsers (Firefox, Safari, Chrome, Opera, IE7) are easy to get, run faster and safer than IE6, and are free. Why are some company IT departments still forcing users to browse on IE6? In general it seems to boil down to three big reasons.

1. The company has internal software that was built specifically to run on Internet Explorer.
2. The company manages a ton of machines and the workload/headache of upgrading them all to a newer version is too much.
3. The company and users feel comfortable on IE6 because they “know it”.

Here’s the problem. When we as an industry don’t embrace new enhancements in development it’s the client’s viewers and the client’s brand that suffers. We’re still building phenomenal web sites. But the straight truth of the matter is they’re not as good as they should be. The web has soooo much potential but it’s not being utilized. Why? Because we’re still supporting a legacy browser* that was released in 2001.

As I’ve said before. In order for things to get better sometimes you just have to make the jump. Other companies are already doing this. Apple, 37Signals, and Comedy Central just to name a few. Notice anything about those first two? They dramatically care about their user’s experience. So much so that they’re willing to sacrifice incompatibility for some users to benefit the rest of them**. Cheers to that, I hope we see it more.

^{* As long as companies ask us to support IE6 we will. We’re not afraid to share our thoughts on the browser landscape but we also recognize the need to compromise.
** I understand that some users don’t have control over what browser they use. For these poor souls I cry (really, I’m tearing up as write this).}

The thing is that a lot of my video podcasts (diggnation, TED Talks, Wine Library TV) are great to listen to with just audio. And in fact I find the extra battery life saved can be a welcome benefit. Well, about two weeks ago I figured out how to listen to audio from video’s on the iPhone with the phone locked. Here’s how:

1. Start your video from the iPhone iPod app
2. Lock the phone. At this point your video and audio will stop
3. Double tap your home button to bring up iPod controls in locked mode
4. Select play and the audio from your video will start playing while the phone is locked

I’m not sure if this tip is published but it’s been super useful for me. Hope it helps you all out too.

Update: Just realized these steps also work if you want to listen to audio only with the phone unlocked. Simply do the above and then unlock your phone, wala!

Here at Imulus we think if you believe strongly in something you should voice your thoughts. Voting is one of the best ways to put your ideas into action. We encourage everyone to register, educate themselves on the issues, and then participate come this November 4th.

If you’re not in one of the states listed above you can find a full list of voting deadlines at Rock the Vote’s website.

Updated 10/16/08
For all the Colorado visitors to our blog. Here is a link to the Colorado Blue Book which describes the various voting amendments and the views both pro and con for them.

However, as I’ve said before, to Apple’s credit they do listen when there’s an uproar. And point in case is the decision by Apple to drop the iPhone developer NDA. Now, here at Imulus we haven’t done first hand iPhone application development. But as technology advocates, developers of online software, and supporters of Apple products, we like seeing Apple make the right decision. There is no question that removing the NDA will make applications instantly better. In a nutshell it will allow developers to: exchange code samples, publish tutorials and techniques, as well as publicly talk about bugs and problems. Now instead of forcing developers to reinvent the wheel with basic iPhone functionality they can work on implementing standards for complex functions.

Apple also made the decision to restrict iPhone app reviews to actual purchasers of the app. Up to this point tons of people have been critiquing applications without ever using them. Leading to reviews that sounded like: “the app looks okay but it’s too expensive so I’m giving it a low score.” This is ridiculous. And Apple has made the right decision in allowing only users of the app to actually critique it. Another win for developers and users.

So cheers Apple, thanks for your support in making the platform better, even if it did take longer than it should have. The outcome will be worth it. Now, if only you’d give away the iPod touch 2.0 software for free to previous owners.