Devlounge

Design, Develop, and Grow

Search Results for: plugins

Are You Designing for the Smaller Screen?

By

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 1024×600 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
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 (1024×768 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)
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?

Things To Consider When Using WordPress as a CMS

By

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
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.

Make Your Blog More Evergreen with Movable Type

By

A recent post on ProBlogger discussed the pros and cons of dates on blog posts. The gist of it is recent dates can make posts appear fresh, but a post with an older date might appear stale, even if the information is still relevant.

One option discussed in the article was removing dates from older posts. This seemed like an interesting idea to me, so I set out to see how it could be done with Movable Type. It’s fairly easy, although it does require either a plugin or some PHP code.

Let’s start with the plugin version. We’ll need to install DateTags. This is an older plugin that’s not entirely compatible with MT4. In particular, there’s a problem with the <MTNextNEntries> tag. We don’t need that tag for this, so for our purposes it will work fine.

After you install the plugin, open your Entry Metadata template module and add this code to the top:

[html]










[/html]

Simple, right? Let’s go through it, though, and see what’s going on.

[html]

[/html]

MT uses the Entry Metadata template module in a lot of different templates, but I only want to control the appearance of dates on individual entry archives. You can skip this check if you want the change to be site-wide.

[html]

[/html]

This is the real meat of it. We use the <mt:deltadays> tag from DateTags to find the difference between the entry date and the current date. We then store that value in the daysdiff variable.

[html]





[/html]

Now we check daysdiff to see the age of our entry. I’m checking if it’s about 6 months (180 days) old, but you can use whatever length you want. We then set another variable, displaydate, based on that age.

A bit further down in our template, we use displaydate to determine, well, whether we display the date:

[html]

By

<$MTEntryAuthorLink show_hcard="1"$>


on “><$MTEntryDate format="%x %X"$>



“><$MTEntryDate format="%x %X"$>


[/html]

If you’re using the “About This Page” widget, you’ll want to do the same thing there. Remember, variables declared in one part of a template (or in an included template module) are available to any code that follows, so we don’t have to recalculate the date difference in the widget, just check displaydate.

Using this method, you should get into the habit of regularly republishing your entire blog. That way, older posts will get updated as they “mature.”

PHP Alternative

If for some reason you can’t or don’t want to use the DateTags plugin you can still accomplish this by publishing your entry archives as PHP files. Just use this bit of PHP code to calculate your date difference:

[php]
‘)) / 86400, 0 );
?>
[/php]

Then use PHP instead of MT to test whether or not to display the date. The nice thing about this option is you don’t have to worry about republishing regularly to make this work — PHP will handle that automatically.

And there are other uses for this technique as well, like changing CSS files based on the age of the entry. You could set up a series of styles that cause your entries to “age” over time.

How do you highlight (or hide) the age of your posts? Let us know in the comments.

Quick and Dirty Security Fixes Every Online Publisher Should Use

By

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.

Friday Focus 05/30/08: Quick Descriptions

By

What’s the lesson for this week? Describe the purpose of your website in one fell swoop and you’ll go a long way. Of course, it helps to have a great design as well.

Designs of the Week

Antiphrasis

Definition: the use of a word in the opposite sense of its proper meaning.

Two things I really like here. First, the colors. Seafoam green to light yellow is the last color combination one would come up with, but it works well. Second, the black and white illustration as top header background. See, top header backgrounds (let’s trademark that, shall we?) are a trend these days, but, again, would you have thought of using such starkness on a soothing gradient? I enjoyed this discovery not because it’s worlds away from the designs we see today, but because the choices used were so unexpected.

dkoo.net

hello,
i’m a new york-based web designer with
a penchant for music and strong opinions.
have a look around, and give me a shout.

The use of SIFR can go a long way. Throw in proper contrast, some texture, and the right amount of whitespace and you’re all set. The inside pages show that the link colors are so startling a deviation from the dominant, monochromatic brown hues that I can’t decide whether I like it or not. But being different is a good thing. Startling the viewer is also a good thing.

The DECK

The ad network
of creative, web and
design culture

So minimal and yet so bold at the same time. It’s clear who designed this website—Coudal Partners. It’s amazing what you can do when you’re armed only with thin, gray lines. As this is an ad network, participating advertisers are featured first and foremost, an immediate demonstration of how The Deck works. This is how ads should be.

Social Media Weekly

Design – Create a Spectacular Grass Text Effect in Photoshop
Spectacular, indeed, is the right word. The grassy typographic effect is not too easy but not too hard, and you’ll walk away feeling very pleased with yourself after completing this tutorial.

Design – Yahoo! Design Stencil Kit
For all your interface design and wireframing needs. File support for OmniGraffle, Adobe Illustrator (PDF, SVG), Adobe Photoshop (PNG), Visio (XML).

Design – 25 resources for ornaments, fleurons, and “frilly bits”
Cameron Moll provides a very handy list of links where you can download pretty ornaments, which he is quite fond of in his designs. Resources are both free and for a fee.

Programming – CSS Cacheer
Shaun Inman releases CSS Cacheer, an improvement to CSS-SSSP. With it, CSS has evolved to a whole new level, with support for variables, constants, nested selectors, bases, and plugins. Requires PHP.

Programming – CSS Decorative Gallery
Web Designer Wall shows how you can add pretty decorations and frames to a group of images using a <span> overlay and CSS wizardry. Great for all your photo galleries and portfolios.

Programming – Featured video: quick and easy forms
Video demo showing how you can easily create forms using Google Spreadsheets. It’s definitely a great idea if you want an easy way to gather data, as in surveys and contact forms. Although not completely customizable, the best part is the information submitted is saved in an organized manner inside Google Docs.

About Devlounge

Want to read more about Devlounge, or maybe you want to contact us, or even advertise? Oh, and don't forget to subscribe to updates!

The Best of Devlounge