Tag Archives: web development

Oh, the Things PHP Can Do!

Since I’m largely self-taught in all things webdesign, PHP can be both frustrating and magical, a box full of wondrous tools I know neither the origin nor the use of. If you’re a newbie developer like me (or even if you’re somewhat familiar with PHP), you’d be surprised how much PHP can accomplish for your website these days:

Collecting Feedback

This article at CodeTricks.com explains how to make a really simple feedback form, which emails you comments and questions that people have submitted. (This tutorial covers both the HTML form part and the PHP part, so I find it VERY informative!)

Displaying Thumbnail Photos in a Gallery

Nettuts’ article covers one way to easily display photo thumbnails with a few lines of PHP code–much better than having to host your photos on another site, or worse, making an HTML table for your images and resizing all your images yourself. (Been there, done that :P) Scroll down to #12 on Nettuts’ article to find out more!

Making Easy Site Templates

This PHP article at About.com shows you how to use a PHP header and footer to create a site template, which you can change easily by editing the content of just those two files. (I use this trick on almost all my sites–it makes my webdesigning life SO much easier!)

Automatically Sending Mail to a Mailing List

Nettuts also covers how to use PHP to send mail to a specific list of people–who knew there was such an easy way to automate it? (Just scroll down to #8 on their article to see more on how to code this.)

Redirecting Your Visitors to Your New Page

Need to redirect your users to your new page without requiring them to click another link? Over at About.com, they show you how to use just a line or two of PHP code on a mostly-empty page to get it done! (I had no idea it was this easy! WOW…)

Creating Your Own Content Management System

This post at CSS-Tricks.com shows you how to set up a MySQL database, make a specific table for posts within that database, make a simple submission form so you can add posts, and display posts using PHP on a webpage. Basically, it shows you how to beat blogging websites at their own game! (Can be a little technical in parts, but it has links to other articles for extra explanation)


Can you believe PHP can handle all this–and more? I sure didn’t, until I did research for this blog post and realized just how much PHP can help us webmasters with our tasks. Try implementing one or more of these techniques for your site, and see how much time it can save you!

Robin Makes a Mobile Blog Layout, part 3: Testing Your Layout

Designing a mobile layout and knowing how to code it properly is great, but how does a webdesigner/developer test how a layout will perform on a mobile browser? After all, it’s not quite as easy as testing desktop layouts through your browser before uploading it.

I worried over this as I compiled this series, but thankfully, there are folks out there who have solved part of this problem, developing wonderful online tools that can test your site’s layout and help you identify problems in mobile browsing. The following sites are the best of the best, in my opinion, offering simple and sleek functionality as well as a wealth of information. Simply visit these sites and type your URL in to test how your current layout performs in mobile settings!

W3C MobileOK

This tool is a MUST for mobile web developers–it helps you validate, improve, and ultimately optimize your code for mobile usage. As you can see from the above pictures, Crooked Glasses currently fails miserably at being a mobile-friendly site…I got a lot of work to do. *sigh*

Responsive Design Tool

This simple online tool loads quickly and shows a range of different page widths at a glance, so that you can easily compare and contrast. (Caveat: you can’t click through pages unless you download the free tool from Github, but the download link is provided.)


Screenfly displays your website on many different platforms, mimicking everything from tablets to televisions. Click the various icons to see even more specific screen sizes (like Kindle vs. iPad, or iPhone vs. Android phones); you can even click through your miniaturized site to view different pages!

The Responsinator

The Responsinator gives you a scrollable list of all sorts of mobile devices, even comparing portrait vs. landscape orientation on the same device to show you how your site changes when the device is held a different way. The scrollbars on each individual display allow you to scroll around on your site to see what parts of your site may be obscured to the mobile user.

Further Reading

If the above tools have whetted your whistle in terms of mobile site testing, check out the following articles for even more apps and online tools!

SixRevisions: 10 Excellent Tools for Testing Your Site on Mobile Devices
WebDesignerDepot: 8 Popular Apps to Test the Mobile Version of Your Site

Robin Makes a Mobile Blog Layout, part 2: Mobile-Friendly Code

Making a responsive layout for mobile users is not just about the design of the site–the code also has to be constructed well. We webdesigners simply can’t afford to be lax about our code, because mobile browsers are less forgiving than desktop browsers. What looks great on your laptop may look terrible on a tablet or smartphone screen!

Here are some important things to remember about coding a responsive mobile layout:

Design and Code for the Smallest Device First

This seems kind of backwards, but don’t design and code your site’s desktop look first. Instead, make sure that the layout you’re making loads and operates well on a very small screen, like a smartphone. If it looks great and performs well on a mobile browser, it will function excellently as a desktop layout, too.

Include the Meta Viewport Tag

<meta name=”viewport” content=”width=device-width; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;”/>

This little tag, included in the head of your page, keeps mobile browsers from super-shrinking your site to unreadable dimensions and making your users have to zoom in to read your text. (Note: this tag should only be used on responsive layouts or dedicated mobile sites, as HTMLBOY points out.) For more information on how to format this tag, check out the Webdesign Tutsplus page.

Keep the Code Simple, Sweetheart

When you’re designing a mobile layout, as I discussed last week, you want to make sure you’re not crowding your design with lots of images, which require a lot of data transfer over small devices’ connections. But you also don’t want to crowd it with clunky desktop-only formatting, or anything else that will slow the page load time down, especially on a mobile device. Keep the code as simple as possible–even if it looks TOO simple to your eye. A simple but effective site will perform much better than a complicated site that’s trying to do too much.

Also, don’t rely on a:hover at all in a responsive layout. Remember, the user’s “cursor” on a mobile browser is their finger, which doesn’t hover without clicking (unless some folks have magical fingertips quite unlike mine, LOL). Thus, drop-down menus and image changes that happen when the user’s cursor hovers over something is not a good mobile design choice.

Set a Maximum Width for Your Responsive Layout

“Now wait a minute,” you might ask. “Why are you worried about a MAXIMUM width when we’re talking about making a layout small and graceful?” Well, if you’re making a responsive layout, that means that the same layout will be served to all browsers, and will expand and contract with the browser’s window size. The layout that looks great at a width of 400 pixels will probably look REALLY odd at 1300 pixels wide–everything will be stretched out and hard to read.

#maindiv {max-width: 900px;}

The above tag, put into the CSS for your containing DIV, will keep your layout from stretching far into the distance on a widescreen desktop. Your users will cheer!

Don’t Hide Content from Mobile Users

Lastly, don’t assume that mobile users only want to see a few articles on your site. If I visit a site while on mobile, I expect to see ALL the content I would normally see while using my laptop. (This is a big pet peeve of mine to see mobile sites with maybe 20% of the desktop layout’s content.)

So, make sure all your content is accessible via mobile, either with a carefully-designed top-level navigation, or by grouping content into navigational pages so that users can scroll through links for just the content section they want to see. It may sound clunky, but it will work much better than simply hiding content!

Further Reading

NetTuts: Flexible Mobile-First Layouts with CSS
NetMagazine: Build a Basic Responsive Site with CSS
HTML5Rocks: Responsive Design
Designing CSS Layouts with Flexbox is as Easy as Pie

WordPress “Easy Mobile Layout” Plugins: YIKES

These days, more and more people are viewing blog content through mobile means–our phones and tablets have largely replaced our laptops when it comes to simply taking in content. We bloggers must keep pace with these demands when possible; after all, visiting a site and having to re-zoom in to see the text every time you open a new page can be an off-putting hassle. (Take it from me, I’ve run into this annoyance factor even on my own blog!)

But what if you don’t have the time to develop either an app or a mobile-friendly version of your site? The solution seems to be simple: use a mobile layout plugin! It’ll build your mobile design automatically!

Since I am running a self-hosted WordPress installation on my blog, I looked up WordPress plugins which create mobile-friendly layouts. The following is what I discovered while investigating 3 of the most Internet-viewed “popular” plugins…and it’s shocking, to say the least.


Free or Paid: Both options available, but the paid “Pro” option appears to have better tech support overall.

Brief Reviews: Most people get what they’re looking for–a quick, usable mobile layout with a little customization. However, the free version seems to have some issues, especially with themes giving a “too many redirects” error or not serving menus properly to mobile devices. Upgrading to the Pro version apparently fixes this for some users. Check out more reviews on the WPTouch reviews page.

More Information: WPTouch by BraveNewCode

WordPress Mobile Pack

Free or Paid: Free

Brief Reviews: Lots of bad reviews about this plugin not working properly, messing up blog databases, and and being almost impossible to install. Looks like you’d better steer clear of this one…check out more reviews here.

More Information: WordPress Mobile Pack

Mobile Website Builder for WordPress

Free or Paid: Paid

Brief Reviews: This one looked very, very promising–the best of the three I reviewed, in fact!–until I read about all the ads that the plugin puts all over your site, which are very difficult (if not impossible) to remove. Couple that with the fact that this plugin apparently hosts the mobile version of your site on a DudaMobile web address, and this doesn’t seem as strong a contender as I first thought. Check out more reviews here.

More Information: Mobile Website Builder for WordPress by Dudamobile

Conclusion: You’re Really Better Off Doing It Yourself

If you can believe it, this post started out as a way to let people know about great plugins to simplify the process of making our blogs mobile-friendly. Sadly, after considering all the reviews, I can’t in good faith suggest any of these–it’s not worth risking all your hard work just to save time on developing your own mobile-friendly layout. (Of course, this is just my opinion, but after reading about the database problems some of these plugins created, it’s kind of given me the willies about it all!)

I’ve written a few articles here before about developing mobile-friendly designs–these will be helpful no matter whether you want to develop a mobile app, make a separate mobile site, or build a responsive layout that adjusts to all sorts of browsers.

Crashed Database Table? Never Fear, PHPMyAdmin is Here!

No matter whether you’re a veteran at using databases or a novice to the world of MySQL, there is one thing you NEVER want to encounter: a vanished database. (Especially when you’ve put a lot of work into loading that database full of content!) But if you’re facing this right now, never fear! The following article, compiled from my personal experience (and some frantic Googling) will help you attempt to restore that which seems lost.

The Situation: WP_Posts for Crooked Glasses Was GONE

Early on the morning of July 22nd, I was busily editing some WordPress pages after I had uploaded one of my weekly posts. The pages, however, would not save correctly–it seemed they “forgot” all the edits I made, no matter how many times I pressed the “Update” button.

About an hour later (I was working over dialup, so things were VERY slow), I tried again to update the page, only to be told “This page does not exist.” I tried navigating to the other pages I was working on–same message. Then I tried to view my blog…and was absolutely flabbergasted at what I saw.


A big fat 650-pixel-wide space of NOTHING, where all my posts should be. I logged into my WordPress site, and both the Posts and Pages counts read 0.

You can probably imagine what happened next. Over 2 years of work (work I had only limited backups of), GONE? Just like THAT?! Furious weeping, gnashing of teeth (and, admittedly, some throwing of small items across the room) ensued. I scanned through all of WordPress’ help files hosted in my dashboard, but to no avail. I had no idea what had happened, and had no idea how to fix it.

…Well, I had no idea how to fix it, until I thought of something a little outside the box.

PHPMyAdmin: The Unexpected Savior

I remembered, in between gasping for panicked breaths, that my blog was hosted on my domain, and that the databases and tables for my blog should be housed within the PHPMyAdmin bit of my host’s control panel. After all, that’s how I’d worked with databases back in the days of fanlistings and such.

Working as quickly as dialup would allow, I opened PHPMyAdmin, clicked my WordPress blog’s database name, and pulled up the “wp_posts” table from within the huge list of tables it gave me.

Immediately, I was greeted with the message that answered my question and gave me another: “This table is marked as crashed and should be repaired.”

Okay, great, it’s crashed but it can be repaired, I thought. So how do you go about DOING that?

I Googled for help (thank God for Google!), and came across a number of articles, such as this one from SiteGround, telling me to “look for a drop-down menu below the list of tables, check the one that needs repairing, and choose ‘Repair Table.'”

Because of my dialup connection, when I tried to look at the wp_posts table, it did not load the table list, nor did it load any options at the bottom of the screen.

I thought perhaps that the option to “Repair Table” lay at the bottom of the sidebar, but all I saw at the very bottom of the sidebar menu was “Create Table.”

In desperation, I clicked the “Home” button on the sidebar…

…then clicked the “Databases” button (the very top left button in the big window).

From there, I selected my WordPress blog’s database name (all of these have been obscured for security reasons).

Selecting the database FINALLY brought up a list of the contained tables in the larger window. And there, at the bottom of the page, lay the long-sought drop-down box. HALLELUJAH! I quickly clicked the check-mark box next to “wp_posts,” then used the drop-down menu to select “Repair Table.”

And, a few minutes later–presto! The table was fixed!

One Small Caveat

The “Repair Table” solution usually works for most crashed database tables…but notice I said usually. Sometimes, a table crashes and you can’t get it repaired no matter what. :C I recommend doing backups of your work as often as possible, just in case.

How Do You Pronounce “HTML?” (And Other Funny Pronunciations)

As webdesigners and developers, much of our work is nonverbal–we simply type it, upload it, and that’s that. But I find that when I’m drafting code, especially very difficult or time-consuming code, I end up saying what I’m typing as I go along (usually under my breath in a really irritated tone, LOL).

As I was debugging a particularly annoying piece of code for my upcoming video games fansite the other day, it occurred to me that I was doing this. Not only that, but I’d come up with some pretty strange pronunciations along the way…pronunciations which my brain considered “correct,” but which sounded pretty silly coming out of my mouth!

Check out the list below, and compare them to your own pronunciations–do any of yours appear here?

My (Strange) Mental Webdesign Pronunciations

  • HTML: Hut-mul
  • px: Picks
  • src: Surc (like “surf” with a “c” at the end)
  • CSS: Suss
  • $variable: CHA-CHING! variable (I kid you not, I caught myself doing this xD)
  • em: um
  • href: Huh-reff (all one syllable)
  • &nbsp: Nus-bup (yes, I know it doesn’t match the spelling, but it works)
  • valign: Vee-align
  • GIF: Jif (because gif with a “guh” sound at the beginning sounds wrong for some reason)
  • ?>: Huh? bracket
  • //: Suh-slash

And the piece de resistance…

  • if (!isset($var)): if MEEP! izzet CHA-CHING! var
    (with “var” pronounced like the first syllable of “varmint”–hey, I’m from the South, all right? xD)

Anybody Else Do This?

Have you ever noticed yourself doing this, or have you come up with your own pronunciations of various webdesign code? Let me know in the comments!

Why Did You Begin Making Websites?

I’d like to pose a question for my webdesigner/developer readers out there: What made you first begin creating websites?

I ask this because we all have a story of what first drew us to webdesign and development. For instance, I got interested in webdesign way back in 2001, when my family first got Internet access and I saw how people were building sites to share ideas and information. (Little did we all know then that the Internet would become SO vitally important to our lives!)

After some thought about this, I came up with three basic reasons why we all likely began designing and building websites–do any of these fit your story?

#1: Sharing Ideas and Information

Whether we built sites to share our love of a TV show to others, to blog about our daily lives, or to disseminate DIY tutorials, I would wager that many of us webdesigners and developers originally wanted to create sites that shared information and ideas. Making a small site as a hobby or as a little service to fellow Internet users may indeed be how a lot of us got started–we cut our coding teeth on those first HTML pages, grew in aesthetic knowledge as we tried (and erred) a lot with our first designs. We were doing all this for the love of the content, trying to create the best “frame” for our words and pictures.

#2: Showing Off Our Creativity

Then again, some of us likely began designing and developing websites just to see what we could do with an online space of our own. We experimented with new code and scripts, tried new color combinations, placed the navigation and content in different places, used all sorts of art as inspiration for the arrangement of elements on screen…all for the mental challenge and creativity of it, as a way to stretch our design wings. With every scrap of layout, every bit of script, we asked ourselves: “What can this thing DO? What are the possibilities?”–and then we came up with answers from our experiences, our trials and errors.

#3: Making Money

But I don’t mean to leave out or devalue those who first began building sites as a money-making tool. Blogging especially has been touted so often as an “easy way” to make online money, a job you can do on your own time without leaving home, that indeed many people have been drawn to webdesign and development through that. And this is not even mentioning other forms of e-commerce like online stores. Once those of us who began webdesign this way started toying around with the creation of the site–setting up our online storefronts, if you will–our curiosity was roused. “How DOES somebody make a layout like this? How DOES this online shopping cart work? …And could I make one myself?”

Which of these three reasons fits you best? Or are you a combination of two, or all three? Let me know in the comments!

The One Webdesign Practice Most of Us Forget

Don’t you hate it when you’re trying to see a picture, watch a video, or listen to a song, only to see a warning that reads “You need [this random browser plugin] to view this content”? It’s an unpleasant shock to any user, even (and maybe especially) for us webdesigners and developers who know the inner workings of such programming.

What compounds the frustration, however, is when a website that needs a special plugin does not tell you anything about how to get the plugin–it just tells you that you need it and leaves you to fend for yourself. At that point, most users simply exit the site and find another one that isn’t so picky about how they view content. And who can blame them? Most Internet users (and that includes us, too) don’t want to have to work that hard for information or entertainment!

It’s easy to point the finger at other websites for inconveniencing their users like this…but we who create websites often forget to provide that exact same service for our own users. We often forget to make our sites as easy and convenient as possible for our users to view.

The Solution: Plugin Links

Whenever we include media content on our websites, such as a photo gallery that requires a script to run, a video, or an audio track, we should always take the following steps:

  1. Check your media content in as many common browsers as possible, to make sure it will appear and run correctly with the right plugins installed. Today, most people use Mozilla Firefox, Internet Explorer, and Google Chrome, but also include Opera and Safari.
  2. Be aware which browser plugins process which content. For instance, Adobe Flash Player is most often used to run Youtube videos, and Quicktime still runs most audio tracks; most photo galleries use jQuery or something Javascript-related.
  3. Include plugin links for these common browsers–for example, if you’re running a Flash video, make sure you have Adobe Flash Player plugin links for Firefox, IE, Chrome, Opera, and Safari located somewhere just below the video in plain view.

This may seem like a lot of work, but it’s important that we do this backend work so that our users don’t have to. It’s all part of providing a more convenient, informative website.

Mobile-Friendly Designs, part 2: Separate Mobile Site or Responsive Design?

Last week, we discussed the pros and cons of building a mobile app for your site. But what if you’re not interested in building an app? Are there still viable options for making your regular site mobile-friendly?

In fact, there are two options we webdesigners have for this issue. We can make a whole separate site for mobile devices only, or make our desktop site “responsive” to the types of devices that are accessing it. As we’ll soon see, there are pros and cons to both approaches.

Mobile-Friendly Design #1: A Separate Mobile Site


  • Is designed specifically for mobile browsers, so no extra layout junk is needed
  • Usually pares down content to just what mobile users will want and need
  • Keeps you from having to make a layout that is everything to every browser–often cheaper


  • Have to make sure pertinent content is cross-posted between your regular site and your mobile site
  • No reliable way to know what content mobile users will want to access and what they won’t
  • It’s one more site to maintain

Making a separate mobile site can be a less time- and money-intensive way, at least at the outset, to build mobile functionality into your site. You build one separate layout that looks good for any mobile user, then put it onto a separate site that only has the content your mobile users want to see. If people end up wanting to see something that only appears on the full site, they can then click a handy “Go to full site” link, as Jakob Nielsen suggests on nngroup.com. All of that, and no more zooming in to read text or zooming out to find navigation! Sounds great, right?

However, building a separate site brings with it its own set of issues. As handy as it is in the beginning to cross-link and cross-post between two sites, it can easily become an updating/maintenance nightmare, since you have to remember to keep updating two sites instead of one. Plus, you won’t really know until after the fact whether you’re providing all the content to mobile users that they want–you’ll probably get a few emails saying “Wait a minute, where can I find this page on the mobile site?” Nielsen suggests making a lot of inter-linkage between the two sites, but some mobile users (i.e., me) can be very turned off by having to click more times to get to content than is really necessary.

Mobile-Friendly Design #2: Responsive Design


  • Layout design looks consistent and functions similarly on all devices, so there’s no “re-learning” that users have to do to use your site
  • All content is readily accessible through any device
  • Your web address stays consistent across all devices (no “m.yourdomain.com” or anything)


  • Often difficult to automatically detect what type of device a user is accessing your site through, so some mobile users might get shown your desktop layout, or vice-versa
  • Some responsive code may not be handled well by certain mobile devices–could render an awful product on some devices and not on others
  • Navigation may get misplaced way off-screen and render the site unusable on mobile or on desktop

Making a site that responds to whatever device is accessing it is what “responsive design” is all about, as Bruce Lawson at SmashingMagazine notes. Whether somebody’s looking at your site using a laptop, a smartphone, a tablet, or a giant TV screen functioning as a monitor (hey, it happens), a responsive design will ideally look great to everyone and be equally usable. Plus, no worries about interlinking content–it’s all contained on the same site, so when you update your content once, it’s done for all browsers and all devices. Lastly, you don’t have to worry about your web address looking different and possibly confusing users about what site they are visiting.

However, responsive design does require a little bit more work on the backend–it requires that you make a layout that can shrink and grow with the screen size, and a navigation design that functions well whether the screen is itty-bitty or huge. This is a design challenge and a half, let me tell you. It’s like us ladies asking for a man that is tough AND sensitive AND burly AND refined…it’s a tall order to fill. (LOL!) Plus, responsive code may not respond correctly to every browser or device which accesses it, which could lead to a lot of zooming in and out again to read text (something you definitely want to avoid).

My Verdict? It Depends

Unlike either of these referenced articles’ authors, I do not believe that either approach is the definitive answer to designing for the mobile user. I think that your choice really depends on what kind of site you have.

Responsive Design: For Content-Driven Sites

If you have a site with a ton of content, like a high-volume blog or a fansite, I think a responsive design is best. Like I said earlier, you never really know what kind of content your mobile user will want to access, and if you’ve got a lot of content to choose from and it’s your primary site focus, you really need to make sure your user can quickly get to their desired page.

Thus, a site design with as few link hoops to jump through as possible works better–a responsive design that simply serves up the content, no cross-links or cross-posts necessary. Plus, it’s less to update and maintain later, even if there’s more work up-front.

The one concern I have with this is that the responsive design may not “respond” accurately for all devices right at first. But as long as you stay updated on what kinds of browsers and devices need to be catered to, it seems to me that the responsive design still works better for big content-driven sites. (A few of the resources I’ve linked to below will help you toward making a responsive design function better.)

Separate Mobile Site: For Service-Driven Sites

If you have a site that exists mainly to provide a service, like e-commerce or social networking, I believe a separate mobile site is best. When you have a service-driven site, it’s probably already pretty stripped down in terms of content, so there won’t be a lot of excess updating/maintenance issues between your full site and your mobile site.

Thus, a separate mobile site would make it simpler for mobile users to use your service without having to worry about loading the full site’s layout or any extraneous content. (It would almost be like an app in that regard.)

A Final Word

The bottom line? Identify what kind of site you have (content-driven or service-driven), and then design accordingly. I’ve tried to give a good guideline of which to choose in this post, but it’s really up to your discretion as a designer/developer which type of mobile design you use.

But, whichever type you choose, make it the best you can. Don’t rush a half-hearted, ill-thought-out mobile design just to have one–remember that mobile browsing is fast becoming the only way some of us access the Web at all. You want your site to have the best mobile first impression it can!

Resources for Further Reading and Development

Responsive Design

Make Your Site Mobile-Ready Without Creating a Mobile Site
Why We Shouldn’t Make Separate Mobile Websites

Separate Mobile Site

How to Make a Mobile Website: 6 Easy Tips
Mobile Site vs. Full Site

Comparing the Two

32 Examples of Usable Mobile Website Layouts
Separate Mobile Site vs. Responsive Website: Presidential Smackdown

General Mobile Design Advice and Help

How to Create a Mobile Version of Your Website
Mobile Guidelines
Onbile.com (make mobile version of your site easily)

Mobile-Friendly Designs, part 1: Do You Need an App?

With much of our personal websurfing now being done through mobile devices (hey, it’s something to do while waiting in line!), many websites have created apps to make navigating to their sites that much easier. In a way, apps have become like bookmarks or favorites for our mobile devices.

But, as webdesigners ourselves, do we need to take the time and trouble to make an app for our own sites just yet? Well, as I discovered while thinking and researching for this article, it depends.

Biggest Reasons to Build an App for Your Site

  • Your site has a HUGE readership and lots of web traffic per day
  • More complete control over how content displays on all mobile devices
  • Offers a simpler way for users to access your site

If you have a blog that already gets a lot of attention, or a website that many people use, an app may be just the ticket to help boost your popularity and usage to the next level. Also, if you’ve studied your website statistics and have seen that a large percentage of your visitors are using mobile browsers to visit your site, making an app could be a great idea. Lastly, if you don’t want to build a separate mobile version of your site, an app can be a simpler, sleeker “mobile portal” of sorts for your content. (Case in point: I use the Beautylish app from Beautylish.com every day to read their articles without loading all the layout graphics and extraneous stuff from their desktop site.)

As a personal example, I’ve considered building an app for this blog to help with my mobile readership, since I update every day and get a fair following on Twitter–people might appreciate a simpler link to my blog. I’ve also noticed how I have to zoom in when I read my own blog on my iPhone, and have thought how great it would be to have a simpler layout and better social media functionality all wrapped up in an app.

Biggest Reasons NOT to Build an App for Your Site

  • It’s something else for readers/viewers to download and store on their devices, rather than just visiting a mobile-friendly site
  • Have to keep updating the app to stay current with mobile platforms
  • Can bring unforeseen complications, like app crashes, bugs, etc., which interfere with usage

If you’ve just got a small personal site, or a site you mainly build and maintain for hobby purposes, creating an app for your site is likely not going to be very helpful for you. An app is one more thing to keep updating, and could introduce more programming issues than you really want to handle, especially for those of us who don’t get into much web programming beyond HTML and CSS. (Even the apps that are “made for you” can have bugs, and they’ll still need updating, too.) And if your app doesn’t offer much more functionality than just visiting your site through a mobile browser, viewers might not opt for downloading it anyway. (Case in point: I downloaded the Google app, but found it to be so slow that I switched back to using Google in a mobile browser.)

Making an app for my main domain, withinmyworld.org, for instance, would be quite frankly a waste of time and effort at this point, since my domain is mainly a personal site and portal to all my other sites. It would be little more than a gimmick at best, since I know I probably wouldn’t update the app all that much (not much to update!).

Bottom Line: Site Size, Topic, and Popularity Matter, But…

If you want to put the time and effort into building an app yourself, or creating one using an online service, make sure you’ve done your homework beforehand. Having an app can be a great asset, or it can be little more than a superfluous gimmick. To me, frequently-updated blogs or sites with very helpful, often-accessed content would benefit most from having an app, and personal sites or hobby sites are better off not worrying about it.

BUT! If you really want an app and think it could rocket your little site into popularity, that is your choice to make. Who knows–if you’ve got a lot of people visiting your site via mobile devices, the app could just make their visits easier, and word-of-mouth advertising would spread it further!

App Creation Tips and Services

If you’re interested in creating an app but don’t necessarily have all the programming skills to do it yourself, here are some sites to check out:

How to Make a Blog or Site into a Mobile App without Programming Knowledge, @ Lifehacker

App-Making Sites

AppMakr (iPhone; Android beta)
AppsGeyser.com (Android)
Conduit (iPhone, Android, HTML5; Windows Phone coming soon)
Genwi.com (Helps you build one app in the “cloud,” and then they make it workable for iPad, Android, iPhone, etc.)
Phonegap (more hands-on app making with HTML/CSS/Javascript; supports iPhone, Android, Windows Phone, BlackBerry, and some others I don’t even know)