There’s some noise about Internet Explorer 6 right now, originating from the fact that the browser turned 7 (!) on August 27th, 2008. That’s some lifespan, and something to mock if you’re running a site called IE Death March. The list of stuff that came out after IE6 is hilarious, older than the first iPod indeed, do you remember when that one came out?

IE6 is evil, developing for it is evil, and it sucks.

Most designers agree: IE6 is evil, developing for it is evil, and it sucks. I’d reckon most IE6 users would agree too, problem is, they’re stuck with it for some reason. It could be the fact that they don’t know how to upgrade, but more likely it is an OS issue.

And that’s why I think decision to pull support for IE6 is silly. Sure, you could follow Adii’s suit and charge extra if your client wants IE6 support, but to me it sounds like you should up your prices a bit in the first place.

Let me put it this way. If you’re not support IE6, then you’re telling Windows 2000 users to piss off, along with a considerable chunk of the surfers. IE6 isn’t a 5% share browser, like Safari, it’s got 25% of the market! That’s right, 1/4 of the people surfing the web are using Internet Explorer 6, a web browser more than 7 years old.

Safari’s got 5%, and Opera even less. I’m not hearing anyone bitching about not supporting these browsers. Sure, they might be easier to develop for, but does that really matter? Isn’t that just developers being lazy?

Stats from here, almost similar numbers here. I’m sure there are other ways to measure them, and some target audiences will render completely different ones.

IE6 isn’t a 5% share browser, like Safari, it’s got 25% of the market!

Do I think IE6 should be retired? Of course, it is a bad browser, for both user and developer. However, I make websites, and both me and my clients prefer if people can use them.

When Internet Explorer 6 is truly dead, I’ll stop supporting it. Until then, I’ll clench my teeth and make sure that the sites I do work for the 25% stuck with IE6. That’s my problem, not theirs. They have it hard enough at it is, being stuck with such a crappy browser in the first place.

More reading: Wisdump, Elliot Jay Stocks, Webmaster-Source

So what do you think? Should designers stop supporting IE6, and forget about the 25% statistics? Share your view in the comments.

With the emerging of tags, and I’m not talking about Technorati tags here but tags as a part of your own blog, categories can become redundant. A lot of blogs out there has got a bunch of categories, and with the addition of tags, they suddenly have duplicates of everything. Or perhaps they have a lot of categories, because the categories have been used as tags, basically, which perhaps was a great idea back then, but today is totally unnecessary.

Finding a balance between categories and tags might not be as easy, nor as obvious, as one would like to think.

The Ideal Category/Tag Setup

In my opinion, categories and tags are two completely different things. Mind you, I’m tackling this issue as both a designer and a publisher. The ideal setup for your particular fancy or site might be something completely different, there’s the whole matter of what you need and want as well, of course.

I define categories and tags like this:

• Categories are main sections of the site. If you’ve got an entertainment blog, “music” might be one category, and “movies” another, but no more niched than that.
• Tags are descriptions of post content. This means that if you’ve got a post in that “music” category, it might be tagged “metal” because that’s the genre, and “Alice Cooper” because that’s the artist.

The benefits of this way to look at categories and tags, is that categories can be treated as true sections of your site. Most blogging platforms support category specific styling, so that music category can have a cool guitar at top, or use a special color, or whatever. The point is that you can style a specific category in a fitting way, making it more obvious that it is one of the (few) main sections of your blog.

It might take some time to apply a more sound use of categories on your blog, but defining your sections is a good thing.

Tags, on the other hand, are like a loose search query. The point isn’t to style everything tagged “Alice Cooper” in a specific way, since it might be posts from completely diverse areas (i.e. different categories), but rather to list everything relevant.

Applying This

The Blog Herald had a gadzillion tags before its redesign. Since it uses WordPress, I used the included script to convert categories to tags, and then sorted the content in more relevant categories, like news and features, and so on. It might take some time to apply a more sound use of categories on your blog, but defining your sections is a good thing.

If you’re using a blog platform as a CMS (something I’ve touched before), using categories as main sections of your site makes even more sense. After all, you’ve got your menu right there, in the categories, and you’ll be using the blog platform as it is meant to be used, the only difference is that you’ll style the various categories a bit more elaborately than you might have for a traditional blog.

What are your thoughts on how to use categories and tags on a blog? Share your thoughts in the comments!

Michael Arrington’s web 2.0 startup news blog TechCrunch isn’t just a huge success, making Arrington the poster boy of the tech blogosphere, it is also a very prominent leader in the blogosphere. When TechCrunch changes something, other bloggers look at it, and sometimes copies it. It was like that with the 125×125 pixel button ads, the de facto industry standard in the blogosphere right now, which I daresay got big because of Arrington’s design change in 2006 (from this version, I might add, to the previous one, screenshotted in this post).

And now they sport a new design, which in turn have sparked a lot of commentaries in the blogosphere, as well as 300+ opinions voiced in their Yep, We Redesigned post. Everyone’s got an opinion, it seems, as always when it comes to something as personal as design.

In other words, I won’t shut up either.

Screenshot of the new TechCrunch design

The Good

• I like the whitespace, the easy colors, and the choice of fonts.
• Front page using excerpts tightens the design a lot, toning down the need to scroll, and brings a better overview. I don’t care if the main reason is to get more pageviews, this adds to readability in TechCrunch’s case.
• Top story on front page works, although I would’ve wanted some more schwung to it perhaps.
• I like the middle column in the front page, only present for as long as needed. It works surprisingly well and almost gives the stories left of it a sort of a sub-top-story feel to it. Almost…
• Previous/next post links on single posts are always good.

The Bad

• The far right ad column is cluttered. Also, ads aren’t ideally aligned/placed, however, this isn’t something that is easily resolved, and ads are always the great EVIL of a design, so I won’t say more about it.
• The site looks pale on high resolutions with maximized browser windows. Granted, that’s hard to do anything about if you want a clean and sober look.
• The footer is simple, which is good, but I would like something more there. Especially on short posts with few comments, where the right ad column is a lot longer.
• The subscribe element on the top of the right column is confusing. I expected some sort of tabbed box, instead I got links. I also miss the RSS icon (available in the footer), since it is something I think should be pushed.
• A network menu is good, but it is not obvious that it is a network menu, it could just as well be a TechCrunch menu.

The What Now?

• Why do you have previous/next post links on top of single posts? Sure, they might come in handy with short posts, but I find them unnecessary.
• A blog like TechCrunch could really use a little more elaborate archives page. This one is just lazy.
• No dates on the front page. While this is something I normally think is OK, the news orientation of TechCrunch makes me think it should be there.

Final Thoughts

Among the criticism of the new design is the fact that it isn’t “TechCrunch green” enough. The previous one certainly was. Personally, I think it does alright on that area, with a simple green bar in the absolute top of the browser window, green links and green hovering on headlines, and so on. It works, sure, it could’ve been picked up a bit more had they wanted to, but I don’t think there is any actual need for it, really.

Also, while clean, sober, and whitespaced, the design is a bit boring. I should like it, and I do, but it is a bit too corporate for my taste. That is a fine line to thread, and I think the real issue there is the use of images. Just doing logos, and always having them on the same spot, certainly doesn’t help with de-corporatifying the design. Then again, it is a business focused blog, so it isn’t necessarily a bad thing. After all, trying to be something you’re not isn’t something for the faint of heart, so why go out and about trying to look like a magazine, when you’re a news blog about startups?

My verdict: A step up, clean, sober, suitable, I like it overall. Good.

What do you think of the new TechCrunch design?

Some of you might be furrowing your brows at this one. What does he mean, add dates to listings? They are right there, in my post meta section, so what's this nonsense? And since posts are chronological, they are already listed together with other posts with the same date, or the closest one at least.

That is true, in some themes each post got a date, and that's fine. However, perhaps you'd like to group your posts by date in your listings, adding a divider to show that a new day has started. Like we do over at The Blog Herald, for instance. There, in listings, you'll see a little divider telling you that the posts below are of this and that date, and when you've read them all, you'll find another little divider with the next date, and so on. One date can have one or several posts under it, the important thing is that the actual date is only displayed once.

This is actually really easy to make happen, with the_date WordPress tag. Here is how.

How the_date Tag Works

Some WordPress versions ago, the_date tag changed. Suddenly, you couldn't use it to display the date of each posts, because it would only output the results once per page and date. So if you had two posts on one date, only the first one would see any output from the_date tag. Theme designers solve this by using the_time instead, if they want to make sure that there is a date on every post in listings.

So the_date can only output every individual date once per page. Let's use that!

Wait! Why Would I Want to Do That?

My main reason for using the_date like this is to avoid cluttering the page with the same date over and over again. I'm also reminding the reader of how often we update, and how many stories we actually publish every day. It is a way to help readers see your update schedule. Think about it, a small little timestamp in your post meta section will either be completely overlooked, or just not read since the reader already know that it is there. That is a good thing of course, you'll want to check the date on posts sometimes, but I think it is a bit of an overkill in listings on some sites and blogs.

avoid cluttering the page with the same date over and over again

By using the_date like this, I make sure that the reader just sees the date once for each day and page, and since that means that it appears irregularly, it will have a greater impact. Again, that reminds the readers of the frequency of updates in a way a small timestamp never will.

However, you shouldn't remove all your date formatting just because of this. Having dates printed on single posts is still a good thing, and if you're not updating as often as, say, The Blog Herald, it might even look bad when there are several days between updates, which then will be very visible since the date pops out in listings. Use with care, and use when appropriate.

Group Posts by Date in Listings

So we have the front page of The Blog Herald, right? I want to output the date once, using a small little divider, get the posts for that date below it, and then output another divider. Like so:

Illustration for the_date use in The Blog Herald listsings

You want that on your blog? It is easy, just put the_date in the appropriate spot, and it will spit out the date, just once. In the case of The Blog Herald, it is within the loop:

Something similar is used in every WordPress theme, since it is the loop that makes the magic happen. You should have no problem finding it in your theme's files, just remember that different pages might use different files, so you might need to edit both home.php and index.php, as well as category.php, search.php, and so on. It all depends on your theme.

Let's take a look at the_date part of that, shall we?

That's a bit more than just the basic the_date call, right? It is quite simple, this is how it works:

the_date('date formatting', 'stuff before the date', 'stuff after the date')

Edit the bold parts, or just use the_date without any special options, it is your call. As you can see, for The Blog Herald, I'm outputting a p tag with the class the_date, and a span, before actually printing the date, and then I just close these tags after it. Since I don't want to litter the page with this code when there is not date outputted, I'm using the tag to output it, hence it won't be there if there is no date to output for that particular post.

Granted, I'm not a dedicated Reddit user, but that being said, this is the first time I'm getting the "reddit is currently offline" page. It is nothing like the fail whale of Twitter fame, more of an ironic, appropriately geeky, kind of message you get. Like so:

Is this a good way to tell people you're currently offline? What do you think a good offline page should contain? Tell us in the comments.

I've been thinking quite a lot about screen resolutions and, just as importantly, screen sizes the last year or so. Being a fan of small laptops and portability, I get constantly reminded that just because I pack a decent resolution of 1024x600 pixels (or whatever), that doesn't mean that sites looking good on a traditional screen will work on my 8.9" one, despite them both showing as much horizontally. The way I see it, there are X aspects of smaller devices you need to at least consider when doing designs, if you want to be future proof:

• Smaller laptops/netbooks with decent resolution, like the Asus Eee PC or any screen under 12" basically.
• Smaller devices with a screen size at 5-7", sporting a resolution at 640-800 pixels horizontally.
• Mobile phones or similar with sub-640 pixels horizontal resolution, possibly with a vertical focused screen size ratio (like the iPhone).

That last one is easiest, they more or less require special treatment. Sure, you can use Opera on a mobile phone, or Safari on the iPhone, and surf the regular full-grown web well enough, but if you want it to look good and really work for the screen, it'll need special adaptations. That is usually a completely different version of you standard site.

The Netbook Issue

The original Eee PC by Asus

Laptops and similar larger, but still small, devices are harder. The popular Asus Eee PCs started out with a 7" screen with 800 pixels width, that's too small for most sites today, usually optimized for a 1024 pixel horizontal limit. Some sideways scrolling is OK, I suppose, but fluid designs or smart choices could probably at least minimize the occurrence of that. However, your traditional site could work, if you laid it out in a reasonable fashion.

It gets worse when we're talking 5" or 6". The resolution won't be 800 pixels width, it'll be something like 640 or less. That more or less makes any site designed for 1024 pixels width a nuisance to read. Everything will look like crap, basically, and we won't want that as a designer. Visitors on small screens like that should be getting special treatment, probably with a completely different version of the site altogether.

Add Vertical Issues

a little bit of vertical scrolling isn't really an issue

Web designers often concern themselves with a site's width. It is indeed important to fit everything, from content and images, to ads and links and whatnot, in the Perfect Column Setup. Compared to that, a little bit of vertical scrolling isn't really an issue when having access to decent screen real estate. I'd venture so far to say that the blogosphere helped push this forward, it is OK to scroll down again, although advertisers still yap about being above the fold all the time. That may be as it be, but what might be a little scrolling on a normal sized screen, say 768 pixels height (1024x768 being the most common screen resolution), or perhaps even more, but it's not as fun if we're talking 480 pixels height in screen real estate.

It is not that there'll be a lot of scrolling per se, it is more an issue of the small amount of actual content being displayed. Take a site like this, and a post like this. Lots of text, which is fine and pretty easy on the scrolling factor after all. But add big strong graphics, add a powerful header image, add ads breaking up the post, and you'll get a mess. Then take that to a really small screen, and you won't be stuck surfing the web as much as you would otherwise.

This is a tough nut, however, because while we can optimize for less width to play with, the vertical scrolling is necessary on most websites today. There are solutions, some better than others, but the one thing they have in common is that they will probably not fit the big screen, just the smaller one. In other words, while vertical scrolling isn't as big an issue as horizontal one, you might be better of optimizing for it.

Back to the Roots: Mobile Websites

This concept would work on a mobile phone (showing The Onion anno 1997)

Mobile phones are getting more and more web friendly, with the iPhone leading the charge. What they have in common is that they are vertical aligned, meaning that there is more height than width to play with in your design. The fact that a mobile phone, or similar device, shouldn't be too bulky is actually a good thing here. It means that it'll be easier for us to do fluid designs, having text wrap from left to right, no fixed layouts or anything.

Like it was, once upon a time. Only prettier.

One thing is for sure though, these sites need special treatment. There are plugins for publishing platforms, and several services that repackage your content, and optimize it for mobile phones, and that'll help us along the way. However, we do need to consider how we lay out these sites as well, and how we can design them to connect to their older siblings (being the traditional website, should you not be a fan of metaphor). After all, if you do have a special website for mobile devices, it should feel like a natural adaptation to the smaller screen, right?

Are you designing for the smaller screen, and what do you do to make it easier for visitors to your site using smaller devices?

Picking the right color for your design can be a hassle, that's why there's so many color schemer tools out there, of course. Recently, a slightly different one was launched by Suffolk Software, called Cymbolism. What it does is that it asks you which color you associate with a word, "love" for instance, and use that data to suggest colors based on keywords, rather than just displaying sets. I found that interesting, so I decided to interview the developer, Mubashar Iqbal, about this service.

The Interview

So what is Cymbolism, your new web app?
Cymbolism is a crowd sourcing application that that attempts to quantify the association between colors and words. Users are shown a word, and are asked to select which color they associate with that word. The user votes are tallied to quantity which colors are most associated with that word.

How would you say a designer should use Cymbolism?
When working on a new design, the creative brief usually includes a few key words that help drive the design direction.

You can lookup these words on Cymbolism, via the search functionality, and see what color people associate with those words which can provide you starting point for your designs color scheme.

Even if you decided to go against the current trends, Cymbolism will tell you what the trend is.

What sparked the Cymbolism project?
I'm really bad a picking color schemes for my web projects, so I've been reading a lot of articles and books on color theory, and they mention the psychology of color a lot. I started searching around the web to see if there was something more up-to-date for those associations, when I couldn't find anything the idea for Cymbolism was born.

What are your thoughts on how colors are used in web design today?
I think the bigger sites still play it a little too safe. Most of those sites have much the same light background with a little splash of color. Even companies that have strong color associations (UPS for example) don't make strong enough use of these colors.

What do you think govern our color choices in design? Is it all trends?
External trends do play a large role in color choices. When we see one effective use of color it usually spawns a lot of copy cats.

Same is true off-line. We still pay too much attention to what the next big color will be at the annual fashion shows, driving a lot of color choice in the print world.

Online we are able to adapt quickly and easily so people should not be afraid to try new things.

I'd like to thank Mubashar Iqbal for the interview, and urge you all to take a look at Cymbolism. Maybe it can help you in your upcoming project!

WordPress is first and foremost a blogging platform, but that doesn't mean that it can't be used for other things as well. In fact, the development of WordPress have been such that I wouldn't be surprised to see a non-blog focused fork soon, because the necessary functionality for most web sites on the admin side of things are already there. I know, because I've installed and used WordPress as a content management system (CMS) for several clients the last year or so, and have had no complains yet.

"You're crazy! Get Joomla/Drupal/Textpattern/something else instead!"

I would consider doing that, actually, if it wasn't a fact that I know WordPress, can bend it to my will, and know that any necessary functionality I'd like to add is a mere plugin away. The fact that I'm using WordPress as a CMS for clients doesn't mean that I don't think that the other options out there, including TextPattern which intrigues me, are poor choices. I just know WordPress, and I know it is easy to use (as opposed to, say, Joomla) for not so familiar clients. Add a solid support for "static" content, being the WordPress Pages, and more newsy update flows controlled by the Posts, and you've got your needs pretty much covered for most websites online today.

Things to Consider when Choosing WordPress as a CMS

There are especially 3 things you need to consider before committing to WordPress as a CMS, and starting to plan it, as far as I can tell.

1. Is the functionality needed covered by the WordPress core functions, and/or with the addition of (not too many) plugins? This is usually managing information pages (using Pages), and publishing news/press releases (using Posts). If I need to add a lot of custom stuff, including the custom fields, then perhaps it gets too complicated for the client.
2. Is there a good translation of WordPress available, so that your client can get the backend in their own language? Why should my Swedish customers not have their CMS in Swedish? There is no reason, of course, and it is easy enough to install a language pack.
3. Will my client be able to upgrade WordPress themselves, or do I need to make plans for this as well? This is true for most platforms out there, but nevertheless you'll need to have an upgrade strategy.

The real issues present themselves when you've chosen WordPress as the CMS for your client project. That's when you'll have to think a bit outside the box, or not really, but at least peek over the blog focus edge at least.

Designing for Web Sites Powered by WordPress

In general, using WordPress as the CMS just means that you'll design a theme as you would for a WordPress powered blog. Most of the things you need to keep in mind is what should be powering what on the site. For example, a company presentation should of course be a Page in WordPress, that way the company can edit it easily as well. With the 2.5 and 2.6 versions, the WYSIWYG editor is actually quite good as well, so there is no harm in this at all. Basically, you'll use Pages for static content, just as you would on a blog, with the difference that Pages are your core content on the site, rather than posts, which is the core of any blog. This means that you'll have to consider the Page hierarchy and presentation, possibly providing Page templates to control the layout a bit.

The front page of the website is another thing. These days, you can set a Page as the front page by visiting the WordPress settings (as opposed to the hacks of yonder). This is probably necessary for most traditional websites, so you'll want to do a Page template for this particular front page Page as well, and make sure that the minimal (if any) editing that can be made from the WordPress backend should be used with caution. Breaking a front page isn't a good thing, you know, and chances are there's more than just text and a few images to manage, so keep the advanced stuff out of the editable part, putting them in the Page template instead.

Finally, there's the updates, usually being company news or press releases or something similar. This content can easily be managed by using the Posts in WordPress, assigning a category for news, press releases, or whatever. This way you can have a page on the site (incidentally a Page in WordPress as well) that displays the content, and then link people to the category, possibly controlling it a bit by tweaking the category template. You could even bypass the page listing the content mentioned above, and just link the categories from the menu.

The Fiction page's sub menu

Speaking of the menu, chances are you can forget about using the WordPress functions to display Pages or categories, since that would and could mean that your client can break the design by accidentally creating un-necessary Pages or categories. I usually just put these links in the theme, and if they want to add a main category they'll just have to contact me to do an edit. I do, however, try to make sure that adding sub-pages (i.e. Pages belonging to other Pages) will result in decent linkage on the mother Page, much like I've done on my fiction page over at tdhedengren.com.

Another thing you need to think about is what user priviligies your client will need to have. Sure, someone at "their side" needs to have admin priviligies, but that is probably not the general one needed. You need to consider this as well, as it is probably you that will be setting it up, and you don't want the client to break the settings accidentally.

Checklist for Creating Web Sites with WordPress as the CMS

These are the things I tend to think about before choosing and designing a website where WordPress will be used as the CMS. There's probably other things as well, things I just haven't take into account since my clients haven't had that kind of need yet. Feel free to add yours in the comments, sharing is caring after all.

• Is there even a need for a CMS for the client?
• Is WordPress the correct CMS? Will it fit the needs? Is the translations available for the WordPress backend good enough? How will it be upgraded?
• Will I need to extend WordPress using plugins? Are any hacks to the core necessary, because if they are, how will I make sure that these won't break when the core is upgraded?
• What types of content will there be, and what should be deemed static (i.e. use Pages), and what is flowing updates (i.e. Posts)? How will I present this, and what is the main type of content?
• How will the permalink structure be? Should it really say "category", why not "view" or "updates" or something else?
• Will the menu be static (i.e. coded into the theme) or controlled by WordPress (i.e. listing using WordPress tags for Pages and categories)? How could this go wrong in the future?
• What hierarchy will the Pages have? This is important for the URL, since it should be coherent with the menu hierarchy after all.
• How will I present sub-pages (i.e. Pages having a mother Page)? Should there be any at all?
• Do I need Page templates for various sections? How will these work with sub-pages?
• What categories will I use? Should the client be allowed to create new categories?
• How will I present Posts content?
• Do I need category templates for the various categories?

What is your experience with WordPress as a CMS, and have you anything to add to the list? Share in the comments.

When monetizing a blog most people tend to put up a bunch of 125x125 pixel ads, something of an unofficial standard. I believe this is Michael Arrington's doing, the relaunched version of TechCrunch (which we're seeing an updated iteration of today) introduced this in a wider scale, at least to me, and bloggers happily jumped on the bandwagon.

The concept is sound, 125x125 pixel ads aren't obtrusive, they're small, lightweight, but still gets the message out there.

Problem is, when putting 8 or even 10 of these in a two column layout you'll get a cluttered block that looks worse than a set of larger ads would.

The New Format?

But maybe there's a new format in town to gain ground. The GigaOm network runs 300x100 pixel ads in their sidebars, which looks clean compared to the 125x125 pixel ones found on TechCrunch.

While I think 300x100 pixels is a pretty decent size, design-wise, I believe it is better to look at what default sizes are being offered and sold by ad networks. The closest one is the not so common 250x120 pixels, the half square ad (being 250x250 pixel, or sometimes 250x240 pixels, hence the "half" part). This is an ad that works well in sidebars as well, without being to obtrusive.

Incidentally, both these ad formats (300x100 pixels and 250x120 pixels) offer the advertiser a total of 30,000 pixels to work with.

The Future of Blog Ads

With blogs being more like traditional websites, we'll see more traditional ad formats. That's the good thing with the 125x125 pixel ads, there are several mainstream ad networks (such as Google Adsense) that will offer this size, whereas 300x100 pixels is something of an in-house creation from Giga Omni Media. I do think that 300x100 pixels is a better aspect than 250x120 pixels, but when running the latter I've been able to get media agencies to push out ads on my site, rather than having to have the one odd ad spot breaking my design.

Big shot blogs are already running traditional ad sizes, just look at the Gawker (Lifehacker, Gizmodo and more) and Weblogs Inc. (Engadget, TUAW and more) blogs out there. This is because they reach a mainstream audience (as opposed to the TechCrunch ones, for instance), and that mainstream advertisers used to the traditional ad formats.

Both the TechCrunch and the GigaOm network are running traditional ad spots as well, with the leaderboard ad (728x90 pixels, "the new banner" size) being the most common ground here. They are also running squares, like the 300x250 pixel ad found in GigaOm's sidebar, and the 160x600 pixel skyscraper ad on TechCrunch.

What's Your Poison?

Think about this when you design the ad spots for your next blog.

• Is your crowd mainstream? If yes, look to traditional ad format.
• Is your crowd very much web 2.0 new media-ish? Then you won't go wrong with either, and might even get away with a custom size if your readership is enough to get the advertisers to do custom ads just for you.
• Is your crowd the same as the blogosphere itself? Then stick to your 125x125 pixel ads for now, but be at the ready!

What ad sizes do you prefer, and why?

Having your site hacked is not a fun thing, I can tell you that. You might think that no one would want to hack your site, why should they? You're wrong! Bots and scripts attack randomly, and chances are they've been sniffing your site already. And you know what, one of the reason for this is the amount of publishing platforms, such as WordPress or Drupal, available out there. That makes it easy for hackers to analyze the code, and find vulnerabilities. Likewise, it makes it easy for would be online publishers to get things going quick and easy.

There are a lot of things you can do to at least make it harder for these nasty things. Here are some tips.

#1: You're Not Done Just Because the Site is Up

make sure that you won't miss a security release

Congratulations, you installed your content management system of choice! Good for you, now get cracking on that content, will you?

Wait! Before you get carried away and forget all about the code behind the system that powers your amazing site, you need to make sure you've got a solid upgrade policy. And by that I mean you need to sign up for newsletters, RSS feeds from development blogs, bookmark sites, and so on, to make sure that you won't miss a security release.

Take WordPress for example. A lot of blogs are insecure because the operators aren't upgrading to the latest version. This goes for all online code, be it forums or pretty simple scripts. If there's a security issue, you need to fix it. Usually that means staying up to date with the latest software, so do that!

#2: The Plugins, Extensions, Addons...

It's not just the actual content management system that needs to be updated whenever there's a new version released, the same goes for plugins, extensions, addons, or whatever they're calling the extra features for your particular poison. Think about it, you've got this plugin that does things with your database, probably somewhat regulated, but still a vulnerability enough to make things difficult for you should it be exploited.

As a rule, keep your plugins up to date, and don't use more than you have to. Actually, it might be a good idea to delete the ones not in use.

#3: The Username and Password Thing

The importance of a good password should be pretty obvious to us all. Don't use a word, use both letters and numbers, use some caps, add special characters, make it at least 8 characters long... Easy tips. Today, most web apps have analyzers that look at your password and tell you if it is a strong or weak one. You should probably take that to heart.

everyone knows that every install will create this master account

However, there's another thing here. Your username is right there in the open, after some installs. When you installed your content management system, you probably got an admin account created. That account's username might be admin, root, master, god, or something like that. Login, create a new account with full privileges, and delete the created admin account! Why? Because everyone knows that every install will create this master account, called admin, root, god etc. - and that means that anyone who wants to hack your site already know the username to an account with full access, now they just have to hack the password.

Don't make it easier to hack than it already is. And make sure that the privileges of accounts match what they need to do. For instance, the user who writes all the blog posts is pretty public, so don't give it full admin access, just what you need to write, publish, and edit posts. Sure, you'll have to login with another account whenever you want to change settings, but it is worth it.

#4: Add Security Stuff

You need to find out if your content management system of choice have any particular brilliant security features that could make life harder for hackers. Like the secret key in wp-config.php for WordPress, for instance.

This will be different from system to system, so read up!

#5: Move the System Core from Public View

consider moving the core files outside the public folders

I'm surprised that not more online platforms doesn't do this by default. Your content management system's core files is the ones that power the whole shebang. Without them, the site just won't work, and that also means that if someone hack them, you're in trouble.

First of all, consider moving the core files outside the public folders on the server. You won't be able to move the admin interface of course, you'll need to access that online, publicly, but the other core files might not need to be in the public folder. This makes it a little harder to mess with them, which is a good thing.

However, not all systems allow this. One solution is to put the core files in a different folder than it usually is, which won't make it invisible online or anything, but people just surfing known URL:s won't find it without some hassle. Not too much hassle though, this is something that is pretty easy to figure out, so don't rely on it too much.

I hope these tips will help you make your site a little more secure. Do you have some tips of your own, or perhaps experience gained by being hacked? Then by all means share them in the comments.

This is an unofficial follow-up to my previous post, titled CSS: Fun With Floating in the Grid. We'll be using some of the same mentality to make floating elements in your design, like pullquotes and boxes containing interesting facts, something I tend to call infoboxes.

Why Would I Want to Do That?

The idea with floating elements containing information or content is simple: It eases up the design. Let's say you've got a mammoth bulk of text, a truly smashing article, but it's really a heavy piece with lots and lots of text. There might not be any obvious images or illustrations to ease it up either, what to do, what to do?

So essentially, the idea is to make the design more appealing.

Simple! Use pullquotes, something magazines are really good at. They're taking quotes from the text, and floats it to the left or right, to break the flow and add some much needed space.

Informational boxes, often containing interesting facts relevant to the content, is another way to do the same thing.

So essentially, the idea is to make the design more appealing. That's why you'd wanna do that!

Pullquotes

You've probably noticed that we use pullquotes here on Devlounge. You can make your own, and add to your site, without much hassle. I suggest that you base it on the blockquote tag, which seems fitting. However, should you be running a blog, then it might clash with your present blockquote styling.

We'll solve that by adding a class called pullquote. Here's the code:

So should you want to have a pullquote to the right, you'll use this code:

Simple, yeah? Naturally, if you want your pullquotes to be styled differently from your blockquotes, you'll have to edit that.

Infoboxes is Just More of the Same

As you might understand by now, infoboxes are just more of the same. We'll use a div with a particular class, to float a box to the left or right.

This is a very simple box, just a grey one with the same font etc. you're already using. Naturally, you'll want to complete this one with some styling that works well with your design. However, this is how you use it:

I recommend using a different font for the content of the infoboxes, as well as using a stronger color for h3 than the actual type (managed with the p of course).

Trimming Down the Code

A quick note to wrap this up! If you really are using the ideas from the previous CSS post, then you can trim down the code for these elements a bit. Since that post wants you to have global classes for floating elements to the left and right, then you can skip the float:left; and float: right; parts, of course.