First of all, what is networking? There are many definitions … some make sense and some don’t, but for me, networking is simply the art of reaching out to people.

I’m sure you can agree that making this very first contact is not always easy. There’s a lot of things that can go wrong … you can sound aggressive, for example, or desperate, or simply not clear.

Also, anyone who says that you should simply “be yourself” needs to get a grasp on reality(!) … sorry for saying this :)

Now, to blogging.

There are many important tasks for a blogger to take care of every day. Apart from the obvious task of publishing content, one also has to do some SEO, link building, guest posting, advertising (at some times), and … wait for it … networking.

The fact is that no website on the internet has become popular on its own. Every popular website is popular because at some point some other popular website mentioned it to their readers, and the whole thing started. (How many times can you say “popular” in one sentence?)

In fact, if you have a nice network of contacts you will do just about fine in the blogging world. That’s how important it is.

During the past couple of months I’ve been working on a Networking Guide for Bloggers together with Hongkiat. There are 7 chapters inside the guide. Each part/chapter has been published as a guest post at Hongkiat.com. Feel free to check it out:

By the way, the e-book version of the guide is coming soon. I’ll keep you posted.

P.S. The e-book will be available as a free download. No strings attached.

Related Posts:


How About a Networking Guide for Bloggers? | newInternetOrder.com

WordPress 3.4 is ready for beta testers!

As always, this is software still in development and we don’t recommend that you run it on a production site — set up a test site just to play with the new version. If you break it (find a bug), please report it, and if you’re a developer, try to help us fix it.

If all goes well, we hope to release WordPress 3.4 in May. The more help we get with testing and fixing bugs, the sooner we will be able to release the final version. If you want to be a beta tester, you should check out the Codex article on how to report bugs.

Here’s some of what’s new:

  • Theme Customizer with Previewer
  • Flexible Custom Header Sizes
  • Selecting Custom Header and Background Images from Media Library
  • Better experience searching for and choosing a theme

And some of the under-the-hood changes:

  • New XML-RPC API for external and mobile applications
  • New API for registering theme support for custom headers and backgrounds
  • Performance improvements to WP_Query by splitting the query (Please test!)
  • Internationalization improvements (improved performance and locale support)
  • Performance and API improvements when working with lists of installed themes
  • Support for installing child themes from the WordPress Themes Directory

Remember, if you find something you think is a bug, report it! You can bring it up in the alpha/beta forum, you can email it to the wp-testers list, or if you’ve confirmed that other people are experiencing the same bug, you can report it on the WordPress Core Trac. (We recommend starting in the forum or on the mailing list.)

Theme and plugin authors, if you haven’t been following the 3.4 development cycle, please start now so that you can update your themes and plugins to be compatible with the newest version of WordPress.

Download WordPress 3.4 Beta 1

So far in this series we’ve talked about many different ways of getting backlinks to your site … the backbone of SEO. Depending on your personal preferences and your backend you can end up using some of them more than the others, and that’s okay.

The task for you is to always select the ones that give the best results with the least amount of work (a classic 80/20 case). And in order for you to be able to do this you have to be aware of as many link building techniques as possible. That’s why I’m publishing this series.

Just to recap, as we are slowly approaching the end of the series, so far we’ve discussed:

Today we’re taking on one of the most obvious sources of links possible – blog comments and forum posts.

This practice doesn’t have the best publicity nowadays. Many people believe that building links on blogs and forums doesn’t work anymore, but I don’t really see any point why it should be the case.

First of all, Google knows how blogs work, and that whenever someone writes a comment they get a link pointing back to their site. Just because Google has this knowledge doesn’t mean that comments don’t work for SEO. You see, what Google also knows is that all comments are moderated, so if anything goes through it most likely means that it’s worth of being published, and therefore maybe the link is worth noticing as well … just a thought.

Okay, enough with the talk, let’s switch to the how-to part.

How to use comments and forums to get backlinks

The most important rule is not to submit spam. Spam is really REALLY easy to detect, and every blogger with a month’s of experience can point out a spam comment a mile away. Not even mentioning forum moderators – they are really sensitive about this.

When it comes to blogs there are a couple of guidelines to follow when you want to write a truly valuable comment. In a nutshell: be natural, join the discussion, don’t promote your stuff, don’t thank anybody for anything.

Forums are a different story. Basically, you never know if your post is going to be considered as spam or not. Especially when you include a link to one of your sites. Forums are more difficult to handle than blogs in terms of getting backlinks.

When you’re commenting on blogs you need to make your comment relevant to the post, but your link doesn’t have to be relevant. For instance, you can comment on a post about guitar playing and link to a site on dog training.

When you’re posting on forums, however, and the post is about guitar playing then there are not many contexts in which you can shift the discussion and link to some dog training content. Actually, it’s impossible.

That’s why forums are most often used a little differently. What you do is don’t actually link to your content from inside your posts, but instead you create a signature box – this is where you put a link to your site. Whenever you post a response to someone else’s thread, your links will be automatically displayed in your signature.

Link building tutorial for blog comments

Simply start by going to a blog and writing a comment, but don’t submit it yet.

First, do a quick research on what type of anchor texts get approved on that given blog. Some blogs are very strict regarding what you can and can’t use as your name in the comment.

There are blogs that will let you use a fully anchored name (a keyword name, e.g.: “learn guitar chords”). Others will only allow you to use your actual name. And there’s the final group that uses plugins like CommentLuv, or KeywordLuv, in which case you can get both your actual name and an anchored link name.

The only thing you have to do is take a look at other comments published on the blog, and take notice of the general trend of the names used. Then craft your name accordingly.

Link building tutorial for forums

Online forums run on different platforms and have different rules of taking part in the discussions. Before you post anything you have to go through the basic rules to make sure what’s allowed and what is not.

The most common setup for forums is to enable users to have a signature once they publish 5-10 posts, so don’t be surprised if you don’t see any possibility of setting a signature right after registration.

When you get access to the feature you can pretty much do whatever you like. However, try to play it safe – don’t include more than two links in your signature. Of course, make them fully anchored – use your main keyword phrase for the anchor text.

The value of getting links on blogs and forums

There are two main benefits here:

1. Obvious SEO “juice”

Google and other search engines see your links, so they become a part of your backlinking profile.

Even though comment links are not that valuable on their own (they are mostly no-followed), they can boost your rankings once you’re really active building a large number of them every week.

2. Traffic

Yes, both blog comment links and forum links can bring you serious traffic.

Whether you believe it or not people actually click through on comments they find interesting just to check what’s going on on someone’s site.

Actually, I’m getting quite a noticeable amount of traffic every month from sites where I’ve never guest posted. This traffic comes solely through the comments I submitted.

The story is similar with forums. This time, though, you’ll be receiving traffic from returning visitors. That’s because forums are usually closed communities with just a small number of new users joining on a regular basis.

How to find blogs and forums in your niche

I’m sure you already know a couple of those, but anyway.

For blogs, Technorati seems to provide the best results. You can browse by category or search with a keyword. The results are mostly popularity ranked, so the most valuable places to have a link at will be displayed at the top.

For forums, try using Google. The best way is searching for a phrase like this:

“your-keyword-phrase forum”

Every niche and topic has at least a couple of popular forums. As a matter of fact, there are many more ways you can benefit from being a member of a forum. Link building is just one of them.

There you have it. The task for you today is to find 5-10 blogs and 1-2 forums in your niche or topic, and start commenting. Try to make it a habit. Whenever you read something interesting write a short comment to express your opinion about the piece.

Are you an active commenter or forum member? How often do you read blogs or participate in forum discussions?

Related Posts:


Where to Get Backlinks to Your Site – Part 7 – Blog Comments and Forums | newInternetOrder.com

The South by Southwest Interactive Festival (SXSW) holds a special place in the history and heart of WordPress. Though the conference has changed in the years since I first met Matt in the hallway in 2003 — before WordPress even had a name — it’s still arguably one of the most influential events in our industry, and we’ll be there again this year. Will we see you there?

Booth

There will be a WordPress booth at the SXSW trade show March 12-15. Our booth was packed to overflowing last year as we helped people with their blogs and gave away WordPress swag, so this year we’ll have more space to meet as many of you as possible. Stop by if you need a helping hand with your site, or just to say hi. We’ll also have buttons, stickers, and t-shirts again this year.

Party

This year’s WordPress party will be hosted by the WordPress Foundation on Monday, March 12 from 6-9pm. Space is limited, so make sure you RSVP (no SXSW badge is required). The party this year will be at the Buzzmedia Pure Volume House, and the story of how we hooked up with them is pretty cool.

Once upon a time, David Wang had a business called Buzzmedia in Malaysia, with the twitter username @buzzmedia. When David changed gears and started ClickWP, a WordPress support business, he stopped going by the Buzzmedia name. In the U.S., a company also called Buzzmedia wished it had that Twitter username, and asked if they could have it since David wasn’t going to use it anymore.

David, feeling the WordPress community love, said he would give them the name, and suggested they do something in return for the WordPress Foundation. So, everyone talked to everyone else and it worked out that Buzzmedia was willing to donate a fantastic venue for this year’s party as well as covering the bar.

In the end, the Foundation got a great SXSW party, Buzzmedia got their twitter username, and David got the warm glow of having used his power for the good of the WordPress community, and they all lived happily ever after.

Seriously, though, the PureVolume House is always a great SXSW venue, so thank you David and Buzzmedia for your generosity! We’ll have drinks and snacks and a few hundred WordPress-loving partygoers, so you know it will be a good time. Kind of like a WordCamp afterparty without all the work of a WordCamp. :)

The venue can hold 500 people, and based on last year, we’ll hit that pretty quickly. The one requirement is that you use WordPress. On the RSVP form, you will be asked to enter the URL of your WordPress-powered site (if you have more than one, just pick your main site). If you fill in this field with something other than what’s requested (such as “N/A” or putting in a fake url) your RSVP may be deleted, so please make sure to enter your real site.
RSVP Now!

Fun fact of the day: about 37% of WordPress downloads are for non-English, localized versions.

So as a plugin or theme author, you should be thinking of localization and internationalization (L10N and I18N) as pretty much a fact of life by this point.

Fun total guess of the day: based on my experience in browsing through the thing, roughly, ohh… all plugins and themes in the directory are doing-it-wrong in some manner.

Yes friends, even my code is guilty of this to some degree.

It’s understandable. When you’re writing the thing, generally you’re working on the functionality, not form. So you put strings in and figure “hey, no biggie, I can come back and add in the I18N stuff later.” Sometimes you even come back and do that later.

And you know what? You probably still get it wrong. I did. I still often do.

The reason you are getting it wrong is because doing I18N right is non-obvious. There’s tricks there, and rules that apply outside of the normal PHP ways of doing things.

So here’s the unbreakable laws of I18N, as pertaining to WordPress plugins and themes.

Note: This is not a tutorial, as such. You are expected to already be translating your code in some way, and to have a basic grasp on it. What I’m going to show you is stuff you are probably already doing, but which is wrong. With any luck, you will have much slapping-of-the-head during this read, since I’m hoping to give you that same insight I had, when I finally “got it”.

Also note: These are laws, folks. Not suggestions. Thou shalt not break them. They are not up for debate. What I’m going to present to you here today is provably correct. Sorry, I like a good argument as much as the next guy, but arguing against these just makes you wrong.

Basic I18N functions

First, lets quickly cover the two top translation functions. There’s more later, and the laws apply to them too, but these are the ones everybody should know and make the easiest examples.

The base translation function is __(). That’s the double-underscore function. It takes a string and translates it, according to the localization settings, then returns the string.

Then there’s the shortcut function of _e(). It does the same, but it echoes the result instead.

There’s several functions based around these, such as esc_attr_e() for example. These functions all behave identically to their counterparts put together. The esc_attr_e() function first runs the string through __(), then it does esc_attr() on it, then it echo’s it. These are named in a specific way so as to work with existing translation tools. All the following laws apply to them in the exact same way.

So, right down to it then.

Law the First: Thou shalt not use PHP variables of any kind inside a translation function’s strings.

This code is obviously wrong, or it should be:

$string = __($string, 'plugin-domain');

The reason you never do this is because translation relies on looking up strings in a table and then translating them. However, that list of strings to be translated is built by an automated process. Some code scans your PHP code, without executing it, and pulls out all the __()’s it finds, then builds the list of strings to be translated. That scanning code cannot possibly know what is inside $string.

However, sometimes it’s more subtle than that. For example, this is also wrong:

$string = __("You have $number tacos", 'plugin-domain');

The translated string here will be something like ‘You have 12 tacos’, but the scanning code can’t know what $number is in advance, nor is it feasible to expect your translators to translate all cases of what $number could be anyway.

Basically, double quoted strings in translation functions are always suspect, and probably wrong. But that rule can’t be hard and fast, because using string operations like ‘You have ‘.$number.’ tacos’ is equally wrong, for the exact same reason.

Here’s a couple of wrongs that people like to argue with:

$string = __('You have 12 tacos', $plugin_domain);
$string = __('You have 12 tacos', PLUGIN_DOMAIN);

These are both cases of the same thing. Basically, you decided that repetition is bad, so you define the plugin domain somewhere central, then reference it everywhere.

Mark Jaquith went into some detail on why this is wrong on his blog, so I will refer you to that, but I’ll also espouse a general principle here.

I said this above, and I’m going to repeat it: “that list of strings to be translated is built by an automated process“. When I’m making some code to read your code and parse it, I’m not running your code. I’m parsing it. And while the general simplistic case of building a list of strings does not require me to know your plugin’s text domain, a more complicated case might. There are legitimate reasons that we want your domain to be plain text and not some kind of variable.

For starters, what if we did something like make a system where you could translate your strings right on the wordpress.org website? Or build a system where you could enlist volunteer translators to translate your strings for you? Or made a system where people could easily download localized versions of your plugin, with the relevant translations already included?

These are but a few ideas, but for all of them, that text domain must be a plain string. Not a variable. Not a define.

Bottom line: Inside all translation functions, no PHP variables are allowed in the strings, for any reason, ever. Plain single-quoted strings only.

Law the Second: Thou shalt always translate phrases and not words.

One way people often try to get around not using variables is like the following:

$string = __('You have ', 'plugin') . $number . __(' tacos', 'plugin-domain');

No! Bad coder! Bad!

English is a language of words. Other languages are not as flexible. In some other languages, the subject comes first. Your method doesn’t work here, unless the localizer makes “tacos” into “you have” and vice-versa.

This is the correct way:

$string = sprintf( __('You have %d tacos', 'plugin-domain'), $number );

The localizer doing your translation can then write the equivalent in his language, leaving the %d in the right place. Note that in this case, the %d is not a PHP variable, it’s a placeholder for the number.

In fact, this is a good place to introduce a new function to deal with pluralization. Nobody has “1 tacos”. So we can write this:

$string = sprintf( _n('You have %d taco.', 'You have %d tacos.', $number, 'plugin-domain'), $number );

The _n function is a translation function that picks the first string if the $number (third parameter to _n) is one, or the second one if it’s more than one. We still have to use the sprintf to replace the placeholder with the actual number, but now the pluralization can be translated separately, and as part of the whole phrase. Note that the last argument to _n is still the plugin text domain to be used.

Note that some languages have more than just a singular and a plural form. You may need special handling sometimes, but this will get you there most of the time. Polish in particular has pluralization rules that have different words for 1, for numbers ending in 2, 3, and 4, and for numbers ending in 5-1 (except 1 itself). That’s okay, _n can handle these special cases with special pluralization handling in the translator files, and you generally don’t need to worry about it as long as you specify the plural form in a sane way, using the whole phrase.

You might also note that _n() is the one and only translation function that can have a PHP variable in it. This is because that third variable is always going to be a number, not a string. Therefore no automated process that builds strings from scanning code will care about what it is. You do need to take care than the $number in _n is always a number though. It will not be using that $number to insert into the string, it will be selecting which string to use based on its value.

Now, using placeholders can be complex, since sometimes things will have to be reversed. Take this example:

$string = sprintf( __('You have %d tacos and %d burritos', 'plugin-domain'), $taco_count, $burrito_count );

What if a language has some strange condition where they would never put tacos before burritos? It just wouldn’t be done. The translator would have to rewrite this to have the burrito count first. But he can’t, the placeholders are such that the $taco_count is expected to be first in the sprintf. The solution:

$string = sprintf( __('You have %1$d tacos and %2$d burritos', 'plugin-domain'), $taco_count, $burrito_count );

The %1$d and such is an alternate form that PHP allows called “argument swapping“. In this case, the translator could write it correctly, but put the burritos before the tacos by simply putting %2$d before %1$d in the string.

Note that when you use argument swapping, that single-quoted string thing becomes very important. If you have “%1$s” in double quotes, then PHP will see that $s and try to put your $s variable in there. In at least one case, this has caused an accidental Cross-Site-Scripting security issue.

So repeat after me: “I will always only use single-quoted strings in I18N functions.” There. Now you’re safe again. This probably should be a law, but since it’s safe to use double-quoted strings as long as you don’t use PHP variables (thus breaking the first law), I’ll just leave you to think about it instead. :)

Law the Third: Thou shalt disambiguate when needed.

When I say “comment” to you, am I talking about a comment on my site, or am I asking you to make a comment? How about “test”? Or even “buffalo”?

English has words and phrases that can have different meanings depending on context. In other languages, these same concepts can be different words or phrases entirely. To help translators out, use the _x() function for them.

The _x() function is similar to the __() function, but it has a comment section where the context can be specified.

$string = _x( 'Buffalo', 'an animal', 'plugin-domain' );
$string = _x( 'Buffalo', 'a city in New York', 'plugin-domain' );
$string = _x( 'Buffalo', 'a verb meaning to confuse somebody', 'plugin-domain' );

Though these strings are identical, the translators will get separated strings, along with the explanation of what they are, and they can translate them accordingly.

And just like __() has _e() for immediate echoing, _x() has _ex() for the same thing. Use as needed.

Finally, this last one isn’t a law so much as something that annoys me. You’re free to argue about it if you like. :)

Annoyance the First: Thou shalt not put unnecessary HTML markup into the translated string.

$string = sprintf( __('<h3>You have %d tacos</h3>', 'plugin-domain'), $number );

Why would you give the power to the translator to insert markup changes to your code? Markup should be eliminated from your translated strings wherever possible. Put it outside your strings instead.

$string = '<h3>'.sprintf( __('You have %d tacos', 'plugin-domain'), $number ).'</h3>';

Note that sometimes though, it’s perfectly acceptable. If you’re adding emphasis to a specific word, then that emphasis might be different in other languages. This is pretty rare though, and sometimes you can pull it out entirely. If I wanted a bold number of tacos, I’d use this:

$string = sprintf( __('You have %s tacos', 'plugin-domain'), '<strong>'.$number.'</strong>' );

Or more preferably, the _n version of same that I discussed above.

Conclusion

Like I said at the beginning, we’ve all done these. I’ve broken all these laws of I18N in the past (I know some of my plugins still do), only to figure out that I was doing-it-wrong. Hopefully, you’ve spotted something here you’ve done (or are currently doing) and have realized from reading this exactly why your code is broken. The state of I18N in plugins and themes is pretty low, and that’s something I’d really like to get fixed in the long run. With any luck, this article will help. :)

Disclaimer: Yes, I wrote this while hungry.

In trying to figure out what to talk about at WordCamp Atlanta, I remembered a question put to me in WordCamp Birmingham. The question was how can a theme developer easily make a plugin-dependency in their theme?

I wrote some code to do this sort of thing, just as an example/test/demonstration, but then after looking over the schedule, I found that Thomas Griffin had beat me to it. After looking over his slides and having him walk me through his code, I realized that his solution was much more fully featured than mine, so I’m glad I didn’t present anything on this topic. (I ended up just doing an answer session where I tried to answer any question put to me, and frankly that was much more fun than having slides, so I’m probably just going to do that from now on.)

You can find his cool library here, BTW: http://tgmpluginactivation.com/

However, his solution is highly complex. The class he came up with is well done and fully-featured. He has capabilities for making notifications in the header space on the admin section, lightbox popups, bulk installs, forced activation, custom skinning, etc. It’s a big thing. While that’s great for a lot of people in terms of having code you can just drop-in and use, I thought that it doesn’t do much to teach how one can DIY it.

See, the code I wrote was tiny. It basically just provides some minor functionality to show a theme author how to detect installed plugins, how to detect when they’re active, how to build install and activate links, etc. It doesn’t do any pretty stuff. No custom skinning. No lightbox popups. All these things are possible, but if somebody hands you a hunk of library code to do them, then you know how to use that library, not how it works. I dislike using libraries for this reason.

So here’s the small class I wrote to do the same sort of thing, but in a very bare-bones style.

/* 

Simple class to let themes add dependencies on plugins in ways they might find useful

Example usage:

	$test = new Theme_Plugin_Dependency( 'simple-facebook-connect', 'http://ottopress.com/wordpress-plugins/simple-facebook-connect/' );
	if ( $test->check_active() ) 
		echo 'SFC is installed and activated!';
	else if ( $test->check() ) 
		echo 'SFC is installed, but not activated. <a href="'.$test->activate_link().'">Click here to activate the plugin.</a>';
	else if ( $install_link = $test->install_link() )
		echo 'SFC is not installed. <a href="'.$install_link.'">Click here to install the plugin.</a>';
	else 
		echo 'SFC is not installed and could not be found in the Plugin Directory. Please install this plugin manually.';

*/
if (!class_exists('Theme_Plugin_Dependency')) {
	class Theme_Plugin_Dependency {
		// input information from the theme
		var $slug;
		var $uri;

		// installed plugins and uris of them
		private $plugins; // holds the list of plugins and their info
		private $uris; // holds just the URIs for quick and easy searching

		// both slug and PluginURI are required for checking things
		function __construct( $slug, $uri ) {
			$this->slug = $slug;
			$this->uri = $uri;
			if ( empty( $this->plugins ) ) 
				$this->plugins = get_plugins();
			if ( empty( $this->uris ) ) 
				$this->uris = wp_list_pluck($this->plugins, 'PluginURI');
		}

		// return true if installed, false if not
		function check() {
			return in_array($this->uri, $this->uris);
		}

		// return true if installed and activated, false if not
		function check_active() {
			$plugin_file = $this->get_plugin_file();
			if ($plugin_file) return is_plugin_active($plugin_file);
			return false;
		}

		// gives a link to activate the plugin
		function activate_link() {
			$plugin_file = $this->get_plugin_file();
			if ($plugin_file) return wp_nonce_url(self_admin_url('plugins.php?action=activate&plugin='.$plugin_file), 'activate-plugin_'.$plugin_file);
			return false;
		}

		// return a nonced installation link for the plugin. checks wordpress.org to make sure it's there first.
		function install_link() {
			include_once ABSPATH . 'wp-admin/includes/plugin-install.php';

			$info = plugins_api('plugin_information', array('slug' => $this->slug ));

			if ( is_wp_error( $info ) ) 
				return false; // plugin not available from wordpress.org

			return wp_nonce_url(self_admin_url('update.php?action=install-plugin&plugin=' . $this->slug), 'install-plugin_' . $this->slug);
		}

		// return array key of plugin if installed, false if not, private because this isn't needed for themes, generally
		private function get_plugin_file() {
			return array_search($this->uri, $this->uris);
		}
	}
}

Obviously, for theme authors wanting to do something, they’re going to want to make much prettier means of displaying things and installing things. Thus, this code is meant as an example, to show the basics of how to detect such things.

So, use it directly if you like (it works), but more importantly, if you want to put plugin dependancies in your theme, then I suggest reading it and figuring out how it works instead. Then you can see how plugins can be detected and how to build simple install and activation links.

(BTW, note that I used the slug and the PluginURI for a reason. Plugins should be using a unique URL for the plugin in their code, and that URL is very likely to be the most unique thing about the plugin, and therefore the best way to check for a plugin already being there or not. Slugs can be duplicated by accident or design, but URLs are generally going to be unique and specific to a particular plugin.)

This site is for an innovative, forward-looking Dutch architecture company.

It is powered by WordPress, based on the AutofocusPro theme, with extensive customisation, including to the layout of the site’s categories, the site’s header, and with additional sidebars implemented.

The site’s home page behaviour has also been modified to give roll-over effects which indicate the post’s categories, and the behaviour of a slideshow function for individual pages has been customised by Urban Legend web.

A customised plugin, qTranslate, has been used to offer Dutch and English versions of the site. 

To put it in a sentence, information overload is a true plague nowadays.

And I really mean it. I truly think that the amount of information available on the internet these days is a bad thing. There’s a page on any topic imaginable. In fact, I would even risk saying that if you can’t find something on the internet then it most likely doesn’t exist.

OK, but why is it a bad thing? Because it’s simply paralyzing. Whenever you’re searching for something on the internet the problem isn’t that you can’t find it, the problem is that there’s too much information available, so you can’t stop searching … you know that there’s always something else waiting on the next page.

Having the confidence and knowing when to stop searching for something and using the information you already have can be a skill difficult to develop.

Luckily, there are some simple steps you can take to start your information diet. Check out my guest post at Lifehack.org to find out what I’m on about:

How to Fight Information Overload

Feel free to share your own ways of fighting information overload and not letting it take over your life.

Related Posts:


How to Defeat Information Overload | newInternetOrder.com