by Rick Stratton, founder

I love software services that embed into a website, rather than install into a server.  It's easier to setup, easier to manage, easier to update. 

Adsense was the service that made that light go off in my head.  Copy and paste some code and ads start showing on a site.  And with Youtube, people started doing it every day.

This past weekend I was reminded, once again, about the benefits of copy & paste software: Wufoo.  I made some changes in Wufoo.com to our contact form that runs on our blog, Feed.Us, our demo site and inside our application.  I added a few fields, changed some text and then saved the form.  Voila... the form was updated on allover Feed.Us.

Of course the problem with these widget style software services is that they are javascript and thus rendered in the browser cannot be indexed by Google.  But most people don't need a contact form to be indexed.  And javascript based comment systems (like Disqus), it's an advantage - spammers can't get their links indexed into Google.

For Feed.Us, we created a serverside version of this embeddable software. It requires the extra step of adding one file on your server but still maintains the cut-and-paste style software theme and is indexable.

Here are the embeddable website services I love and use.  Can you please use the comments to add more?

Forms:  Wufoo and FormAssembly.com
RSS & email newsletters: Feedburner
Comments:  Disqus & Intense Debate
Links:  Delicious
Stats: Google Analytics & Chartbeat
Feedback/Survey forms - kampyle, uservoice
Customer help & website IM - Plugoo & Meebo 
Live camera: UStream.com
Video: Youtube & Viddler.com
Ads: Adsense
Maps: Google maps

CMS: Feed.Us (of course!)

Back in 2001, at our old company, our host went out for 3 days and knocked out service to all of our customers.  Then their DNS system went out for another 3 days.  It was by far the worst experience of my life.  Our customers depended on us and we couldn't do anything about it. We were lucky to survive through it.

I was reminded of that horrible event yesterday.  WordPress.com went down and with it went a couple hundred thousand websites, including TechCrunch (full story here.)

This wouldn't have happened if those sites used Feed.Us.  Here's why:

We built Feed.Us knowing full well that at some point our hosting company might screw up.  We have a great host - but that stuff eventually happens.  But if Feed.Us ever goes down (it hasn't happened yet but it is possible), Feed.Us won't take our customers with it. 

Feed.Us 'feeds' content to your server at your hosting provider.  Your site is built with PHP or Rails or the platform of your choosing -- not with some bloated content management system. So if we have a problem, Feed.Us won't take down your site.  Your site will continue to function as normal. You just won't be able to publish new content until Feed.Us is accessable.

But your host could go down and screw you.  And to defend against this sort of problem, some Feed.Us customers have created backup, fully functional websites. For example our demo sites  FeedUsDemoPHP.com and FeedUsonRails.com are the very same websites - but hosted at different providers in different states but with the same content (also on different platforms - PHP & Rails, respectively).

In the event of this type of crash, the publisher can just switch the DNS and be back up again (yes, DNS is slow to propagate) .

Please contact us if you would like more of an explaination.

by Rick Stratton, founder

Typically, your CMS controls every part of your site.  It's part publishing system, part file manager.  Every page is created within the CMS.  Every file, script, image, etc runs through your CMS. 

It's a "Totalitarian Regime" of CMSes. 

A Totalitarian Regime is one that "recognizes no limits to its authority and strives to regulate every aspect of public and private life wherever feasible".  That sounds about right, doesn't it?

Well, consider Feed.Us your Lech Walesa... we're here to help generate a little perestroika.

Recently I was reminded of this fact when I helped create a site for a  new Feed.Us customer. 

The site is just basic CSS/XHTML and PHP, hosted on Godaddy, and:

Feed.Us for the blog content.  Comments from Disqus. The links come out of Delicious.  Ads from Google. "Share" options from Addthis.  Email from Google Apps. Contact form from Wufoo.  Images from Flickr.

Competition = Freedom

If there's some sort of issue with this site, any one of the pieces can be easily swapped out. 

Commenting system not working right? Switch it over to IntenseDebate.  The ad system can be quickly copied and pasted out of there.  Even Feed.Us can be quickly/easily removed - replace it with straight text or find another provider.

The Godaddy hosting? We can pack that site up and have it on a new host in about 10 minutes. There is no special software that we're using on Godaddy that isn't available on every other cheap hosting provider out there.

There are no more ties that bind. No more getting stuck into a crappy software system just cause it's hard to leave.

It's Perestroika!

Update... Wufoo is actually currently down.  The contact form that's on this site (on the right) and the site I describe above are both not working.  I can quickly replace it with FormAssembly.com if they don't fix Wufoo.

by Rick Stratton

I wrote a post yesterday about the death of your homepage.  That was tongue-in-cheek; your homepage isn't going anywhere.  But it's importance has certainly declined over the last 6 years. 

This post is about the death of your site and no, your site isn't going anywhere, either.  But your content is - it no longer has to be secured within the walls of your website.

Your content needs to be free

By free, I'm not talking about $$$. I mean that readers don't have to visit your site to read your stuff. 

For some publishers, it's already happening. Celebrity blogs and porn sites have traded content with their competitors for years.  They've found that this shared content brings more visitors and more visitors means more money. 

More recently, tech news blogs have begun the act.  And no one does it more than The Business Insider.   TBI regularly republishes articles from Gawker, AllThingsD and random bloggers.

Feed.Us has several customers that produce and sell content that never appears on their own sites. Like Blockshopper.com - they produce real estate content for several larger publishers.  BS gets paid or swaps the content for traffic.

And now there are publishers, like Demand Media, that make a good living producing content for others - and don't even bother with their own site.

If you're a publisher, here are some ideas to free up your content:

1. Content swap: Regularly swap/trade/give your stories to other publications.   If you believe in your content, you should never miss a chance to get your content in front of new eyeballs.

2. More more more posts.  More posts = good, right?  So ask for permission to run articles from other publications.

3. API your content.  Create a special feed or give an API that other publishers or developers can use.   There are people out there who will make a better site with your content.  I wish my local Milwaukee Journal Sentinel would do this. 

4. Ads: Your ads should run on your content regardless of where it's viewed. 

Most ad systems won't support this.  But even if it's just a link ("sponsored by x") at the end of the day it's about getting your sponsors more visitors. 

5. Create a new site with your competitors:

Setup a partnership with your competitors and combine your content onto a separate site around a specific niche.   I'd love to see TechCrunch, AllThingsD, Mashable and Alley Insider make a big site that has all of their headlines on one page.  It would save me time and I'd probably read more.

6. Consider selling space on your site to other publishers.  Or allow your advertisers to publish to specific spots or even pages on your site.

The bottom line is that your content doesn't need a home.  It can find other places to live and still bring home rewards to your publication.

(Note: Feed.Us can be used to produce all of the above suggestions)

Your homepage used to be the first page that everyone visited on your site.  There was no other way to find your stories (aka the "permalink").   Those headlines and teasers were the only way a reader might figure out what link they wanted to click. But now...

Your homepage's importance is dying.

Google started this trend.  A search in Google "deep linked" to the specific story on your site.  Vistors never saw that homepage you spent so much time on.

Then RSS feed readers helped reduce the homepage's power.  Your best readers suddenly bypassed the homepage and visited the full story directly.

Social media has only accelerated this trend.  Readers get their links from their "friends" on Twitter and Facebook and don't have to bother with your homepage.

Look at your stats -  I just looked at one of our sites's stats.  Last month the homepage was the fifth most visited page and has a third of the traffic as the top four stories.

I suggested this trend to Nick Aster, the original designer of Gawker and TreeHugger and now the publisher of TriplePundit.com. 

"Yes, the article page is the new front page," said Nick.  "The front page of a website will always be important, especially for your regular readers. But, especially on news style websites, the majority of readers, and the vast majority of new readers, will arrive at an inside page first.  They may in fact never see your front page.  So your inside pages need to be designed as if they were the first things people see - including any key calls to action."

Luke Beatty, founder of AssociatedContent.com, agrees: "homepages are for portals almost exclusively nowadays. The homepage has been made obsolete by the link economy and search. "

What this means to publishers

It means your should pay more attention to those story pages.  This is probably the first and only page people see on your site.  Do you treat it that way?  No.

The last redesign... did you work on the story page first and then worry about the homepage? No one does this.  Publishers need to focus on the story page.  

Advertising - this is your money page.  Advertisers probably don't realize that they should want to advertise along the full story and not on the homepage.    The savvy ones realize this now and more will in the future.

What do you think? Please let us know via a comment.

by Rick Stratton, founder

This is the most boring demo you'll ever see.

I created three separate sites on three separate platforms with the same content.

I made these three sites to show how you can publish content to multiple sites on multiple platforms all from one Feed.Us account.

We've got PHP, an ASP and Rails.  I'll somehow add an ASP.NET, JSP and Python soon, too.

FeedUsDemophp.com
FeedUsDemo.com/asp
FeedUsonRails.com

You can try it out, too.  Shoot an email to this address
(it's an image, you'll have to type it). After a short delay, it should show up along the right side.

You can also contact me and I'll give you the login info to this demo account.

At some point in the last couple weeks, our RSS feed died. 

The feed I gave to Feedburner had every item from that we've written on blog - about 300 posts.   Feedburner really only likes about 15 posts in the "original feed", FYI.

Luckily, we have a way to quickly create new RSS URLs on-the-fly and can limit the number of items.  I was able to replace the feed in about 30 seconds and bring it back to life.  Now, it's working just fine.

An RSS feed with a ton of items might be useful for content transfer/archiving, but it's not great for feed reading.

I apologize to those people who still use RSS readers.  And god bless you, you're the curmudgeons of the tech world.

It's our ongoing quest to be the only "platform independent CMS" and have Feed.Us work on all technology stacks. 

In this spirit - we've recently added Ruby on Rails to our list of supported platforms. 

This means that content hosted on Feed.Us can now feed to any site or application that runs Ruby on Rails.

Also, from one Feed.Us account, you can control websites that are PHP, ASP.NET, ASP, JSP and now Ruby on Rails.  (Soon we'll add Python too.)

Here's how Feed.Us works with Rails:

1. Become a Feed.Us customer (contact @ feed.us)

2. Add content to Feed.Us (via importing, Google Docs or via the Feed.Us site)

3. Download and unzip the Feed.Us Grabber Rails files.  A "ReadMe" file contains instructions on how to use the RoR grabber and details on the Feed.Us code snippets.

4. Create your Rails code snippets on Feed.Us using our HTML code exporter.  (see photo)

5. Copy & paste the code into your file.

Contact Rick for more info or a demo (rick @ feed.us)

UPDATE:

Ok, we've got our first couple Rails sites:

FeedUsonRails.com: here's our traditional demo site but this version is a Ruby on Rails version.  Imports from and RSS feed then feeds that content to a Linode-hosted server. 

WineTweets.com: here's a twitter app built on Rails that uses Feed.Us for the content sections (the right column, the about page, the contact page, blog etc)

Here's a packers news widget that will fit nicely into a right or left column of your site.  It's 130 pixels wide and can be altered to have less or more articles.  I will eventually add the source field as well.  

Stories are pulled from: ProFootballTalk.com, PackersGab.com, MyPackersBlog.com, Yahoo, GB Press Gazette, Packers.com and JSOnline.com.  

Email Rick at feed dot us for custom code.  It can also come in a php version (or asp or asp.net, etc).  

<script type="text/javascript" src="http://render.feed.us/Feedjs.aspx?g=28b63027-2097-de11-938c-00304891151d"> </script>

Here's how it looks:

We've got a series of video help pages up on the Feedushelp blog to help get you started with Feed.us.

1. Add Content to Feed.Us

2. Add a "CachedWebContent" directory on your server

3. Download and add the FeedUsGrabber files to your server.

4. Create the Feed.Us embed code and copy/paste on your website files.

5. Remember to "publish" your content (aka refresh the cache) to your site.

6. Finally, review how Feed.Us works with CSS/XSL and your platform.

Email us or add a comment if you have questions.

I've always thought that Google's "Google Docs" would make an excellent CMS.  Simple to use and has terrific WYSIWYG editing abilities.  The only problem is that Google doesn't host my sites. 

Now with Feed.Us, your team can collaborate on your website using Google Docs as your CMS. 

Feed.Us uses MetaweblogAPI, an XML-based technology invented by Dave Winer. Metaweblog is supported in many blog systems (but not many CMSes).  It's also used by Microsoft's terrific "LiveWriter" to enable remote posting to blogs.

Feed.Us added Metaweblog and has tweaked it to work with Google Docs.  Right now it works just with Google Docs' "Document" application (aka Writely) but it will eventually work with spreadsheets, forms and presenations.

It's part of our strategy to allow you to use Feed.Us without using Feed.Us.

I'm using Google Docs right now to create this post.  At the end, I'll go under the "share" options and select "send to blog".  Then it will be immediately sent from Google to Feed.Us CMS and from Feed.Us CMS to the Feed.Us website.

Contact us about how you can make Google Docs your CMS.

By John Welborn, Feed.Us CTO/Founder

The thing that makes Feed.Us Templating so special, is that it isn't.  We didn't cook up some home grown solution to allow you to customize your layout, and content display, we used W3C standards like XML, XSLT, XHTML AND CSS.   The benefit is that if you have to learn something new, it might as well be a universal standard, not something that only applies to the particular CMS you're on.

So how do you launch a site with Feed.Us?

1.You get your domain.  Hopefully My-Favorite-Website-About-My-Favorite-Topics.com is still available.

2.You choose a host for your domain... maybe even where you registered it.

3.Go into your control panel and create a folder called CachedWebContent and give write permissions on that folder. (this process varies by provider, but it's usually done througha "file manager" type application.)

4.You design your site and convert it to XHTML, or you select a template from some site (we like FreeCssTemplates.org)

5.You create an account @ feed.us and punch in a few articles (or import from email, metaweblog or RSS).

6.We store your content in an RDMS (SQL Server, in this case) and when you request it, we return it to you as XML.

7.You use our HTML export tool to choose which content you want to export and how.  The tool allows you to select a the specific content you want (like everything in a category, or a date range, or a specific story, etc), a layout (we have lots of templates, or you can EASILY modify / make your own), and the target server platform (ASP, PHP, etc..) you'll be putting the content on.

8.You paste a couple lines of code onto your page, not unlike adding a javascript widget but this is serverside.

9.Sit back, relax, and let the visitors come rolling in!

Ok... so how do you customize the layout.  Well that's the beauty of it.  You use XSLT which is the W3C standard for transforming XML into whatever format you choose, be that HTML or XML, or something else you cook up on your own.  Here's a sample.

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:output method="html" encoding="utf-8" standalone="yes" omit-xml-declaration="yes"/>
    <xsl:template match="/">
        <xsl:apply-templates select="//ContentItem" />   
    </xsl:template>
   
    <xsl:template match="ContentItem">
        <div class="contentItem">
            <xsl:if test="Title != ''">
                <div class="contentTitle">
                    <h3><span><xsl:value-of select="Title"/></span></h3>
                </div>
            </xsl:if>
            <div class="contentItemBody"><xsl:value-of select="Body" disable-output-escaping="yes"/></div>
        </div>
    </xsl:template>
</xsl:stylesheet>

The first two lines are two explain that this is an XSL file and that it's going to output HMTL. Kind of boring.  Like the <HTML> element.

Then you get to the more interesting stuff.  This next section will appear in most all of your custom XSL sheets. 

    <xsl:template match="/">
        <xsl:apply-templates select="//ContentItem" />   
    </xsl:template>

This tells the XSLT document to match the root element of the XML source, and apply the templates to the ContentItem elements.

Just below you see the actual template where all the magic happens.

    <xsl:template match="ContentItem">
        <div class="contentItem">
            <xsl:if test="Title != ''">
                <div class="contentTitle">
                    <h3><span><xsl:value-of select="Title"/></span></h3>
                </div>
            </xsl:if>
            <div class="contentItemBody"><xsl:value-of select="Body" disable-output-escaping="yes"/></div>
        </div>
    </xsl:template>

The first line says to match a ContentItem element from the source XML (each article is a ContentItem) (view the XML source for this article)

Then there's a test to see if the Title element is defined.  If it is, then you output a DIV tag with a class of contentTitle, and inside you render an H3 tag surrounding a SPAN and finally then actual Title field from the XML.  Then we close out the DIV and the IF statement and move on to the body where we have a DIV with a class of contentItemBody surrounding the BODY from the XML.

The point, is that you can see how easy it would be to change the template.  You could change the class of the div to whatever you like, you could change the H3 to whatever you like, you can add or remove any tags of fields as you see fit.  XSL is a very powerful language, and since it's a standard, there's help available all over the place!  Just google it.

Now you say, "Yeah yeah, but how does that get onto my page?"  Easy there friend, I'm just getting to that.  Now you've customized out XSL to have the fields you want and the tags that you need to match the design.  Copy your template page and name it, to say 'about.php'.  Depending on your hosting platform you may be using PHP, ASP, ASP.NET, or JSP.  So your file would be named accordingly, and you replace the stock filler text with the couple of lines of code that you get from our HTML export tool.   Which will look something like this.

<?php $FeedUsURL = "http://stage.render.feed.us/Feed.aspx?xp=2&id=202196&xs=New-Title-Body&l=login&pNames=&pValues=&a=0&f=399&q=&pCO=&pCN=&pCV=&COB=Start+Desc&CNI="; ?>
<?php include("FeedUsGrabber.php"); ?>

 It looks a little intimidating, but you don't need to understand it.  Just paste it in there in place of that Lorem Ipsum nonsense.  The next time you load the page, the FeedUsGrabber checks to see if it has your content cached locally (That's what the CachedWebContent folder is for) and if it doesn't it makes a server side AJAX request to our server to grab it.  Part of that big long string is what tells us which content to grab, it could be a singe story, or a category, or a date range, etc. and that gets fed into the XSL we created above (also part of the big FeedUsURL).  Feed.Us returns just the html of your request and saves it into a file on your server so it's lightning fast on the next request.

So when a web browser sends a request to your server it gets back an HTML page.  Then it uses your css to style it. 

The end result, is that you make Feed.US fit your design, not the other way around.  You can quickly modify our stock XSL templates to use the tags and classes defined in your CSS / XHTML design.

What do you think?  Any questions?  Email me at John [a t] feed dot us.

The Record Newspapers recently came to Feed.Us for a content syndication solution.  They wanted website widgets to help display their news on outside websites.

They tried out Widgetbox, but didn't like Widgetbox's branding all over their news.  They also researched NewsGator, but wanted a php/asp/asp.net option for some of their publishing partners.

Feed.Us worked with the Record to create news widgets for all of the Record newspapers.  Here's the Madison County Record's widget and below is the code to add it to your site:

<script type="text/javascript" src="http://render.feed.us/Feedjs.aspx?g=50f64560-6cee-de11-9b9d-00304891151 d"> </script>

More about the project on the Madison Record website.

Feed.Us is probably the easiest-to-install content management system on the web today.  But it's also quite possibly the most powerful web syndication platform on the Web as well.  How so?

Feed.Us recently was used in two syndication projects and we want to share some details.

WLSAM.com's Weather widget:

WLSAM.com (AM 890 in Chicago) recently encountered a problem with their Weather.com weather widget - it did not fit into their redesign.  Weather.com's widget was a minimal 200 pixels wide and WLSAM.com only had 140 pixels to play with.  What to do? No weather? Change the design?  No, use Feed.Us.

Feed.Us imports from Weather.com's Chicago RSS feed.  Then relays just the current conditions to a Feed.Us javascript export.  That javascript plugs in nicely into WLSAM.com's 140 pixels and uses WLSAM.com's CSS.  It updates automatically throughout the day and has minimal page load time. WLSAM could have also utilized Feed.Us's serverside widget and speed up load time (ie no Javascript).

Blockshopper.com Pioneer Press News Widgets:

Chicago.Blockshopper.com is utilizing Feed.Us's widgets to display suburban Chicago news on Blockshopper.com. The news comes from the RSS feeds of Pioneer Press's suburban newspaper outlets, like the Wilmette Life.

Feed.Us grabs RSS feed items every 20 minutes and then relays them into a Javascript widget or serverside widget. Check it out:

**editor's note... we realize this post reads like an infomercial.  For that we apologize and promise to deliver a helpful, unbiased blog post some time soon.

A significant source of website pageviews can be contributed to the social networks, notably Facebook and Twitter.  Check out this article from Hitwise:

"Although Twitter is a news source for many, it is also a source of traffic for news websites. During February, 9.6% of Twitter’s downstream traffic went to News and Media websites, and 41% of that went to the News and Media – Print sub-category, which is dominated by the newspaper sites."

If you run a publication and you're not using Twitter and Facebook to reach new readers and increase pageviews, you need to start.

Get started:

The easiest way to get started is using Twitterfeed.com and an RSS feed.  Twitterfeed will update your Twitter account whenever there are new items in your RSS feed.  Thus... you don't have to actually use Twitter.  However, we recommend that there's some sort of manual operations... some personality seems to help grow the people who will "follow you" on Twitter.  We also recommend using SocialToo.com to "auto follow" your followers.  (If this is a little too advanced... sorry.)

Example? Our local Milwaukee Journal Sentinel has actually (surprise!) done a great job of adopting Twitter.

Facebook "fan pages"

Facebook has recently updated the "Fan" pages.  Now your publication can have a home on Facebook (previously these didn't really work right).  You can use then use Twitter to update the Facebook fan status using the "Twitter to Facebook" app on Twitter.

Reaching your readers (and new readers) where they congregate is always a great idea.

Using Feed.Us to reach social networks:

Also, beta (and future) Feed.Us customers can take advantage of our Facebook, Twitter and Flickr export tools.   The Facebook app comes in particularly handy.  Any reader of your publication can add headlines to his/her Facebook profile. 

Contact us (anytime) for help on how to setup these features.

We here at Feed.Us love our Amazon Kindles.   Obviously, other folks do too.

A couple of months ago we stumbled upon the fact that Feed.Us could be a great Kindle software tool for publishers.  With just a few tweaks, we could help thousands of newspaper, magazine and blog publishers send their content (news, articles, etc) to Amazon without having to learn about Amazon's syndication system (it's not as simple as you might think).

Currently there are only 29 newspapers and 21 magazines selling their articles on Amazon's Kindle marketplace.  We think we could help change that.  We just need to find a publisher to help us finish our Kindle publishing service.

If you're interested, all you'd need to do is give us your content via RSS feeds or email. We will take care of the heavy lifting and put it into Amazon's format and send it to them.   contact rick at feed dot us.

BTW, if you reached this page because you're trying to figure out how to use Amazon's Digital Text Platform - that's just for books and we're talking about web/newspaper/magazine content, which does not seem to be supported in Amazon's DTP.  The best person around for book-related kindle publishing info is Joshua Tallent.

Windows Live Writer is the quick and easy version of Word for feeding content to blogs and websites.  It functions similarly to Word, but lets you update your site remotely or save your work for later posting.

We recently added the ability to write posts on Feed.Us using Live Writer via MetaweblogAPI.  (You can also use MetaweblogAPI to send posts to Feed.Us from other CMSes. More info later on.)

Also, the most recent version of Office 2007's Word works like Live Writer so you can actually use Word with Feed.Us

Before you start, check out these directions or the video below.  You'll need 2 URLs:

http://feed.us/Publishing/PostMgmt.aspx
http://feed.us/Services/MetaWebLog.ashx

1. Download Live Writer and then "run" the program to install it.

2. It will try to get you to install all of the "Live" family of products.  You just need "Writer". (Be careful not to get tricked into making Microsoft your default search engine.)

3. Close the installer.

4. Then go to "START" (on your computer) and find the "Windows Live" folder, and choose the "Writer" program.

5. Under the "BLOGS" tab, select "Add Blog Account".

6. Choose the "other blog service" option. 

7. The "Web Address for your blog" should be the first URL above (http://stage.feed.us/Publishing/PostMgmt.aspx)

8. Username and password are your Feed.Us username (gjohnson, etc) and password.

9. Resulting page has a dropdown for "Blog Provider".  Choose "MetaweblogAPI".

10. Put the second URL into the "remote posting" field.  (http://dev.feed.us/Services/MetaWebLog.ashx)

11. You don't need to "detect the theme" so choose "NO".

12. Give it a nickname.

That's it!  Remember to choose a category when you post using Live Writer. 

To submit/post/etc, choose the "Publish" button in the left-upper corner.

 Watch the VIDEO BELOW for further instructions.

Lunch at Zaca Tacos (again!) last week.  I asked Feed.Us CTO John Welborn why developers should consider using Feed.Us in their applications and website.

Money quote: "The best reason is that it reduces your deployment time."

See the video below:

Here's a video to show how you can avoid Feed.Us to post articles, news etc. to your Feed.Us powered website.

Feed.Us works with Microsoft Word (or Live Writer), Email (Outlook or gmail, etc), and third party blogs (like Typepad or Blogger).

Windows/Live Writer - setup via MetaweblogAPI
Email: send an email to helpsick5865 at newsstand.feed.us (try it!)
Blogs: via RSS

See the video below for more info:

Here's a quick (less than 4 minutes) video of me setting up Feed.Us on a new site FeedUsDemo.com.

I spent most of the day creating a new site for a local community organization. 

Of course it uses Feed.Us.  The webmaster can email in new announcements and schedules. And the site grabs a flickr RSS feed so that members can email photos to Flickr and have them automatically added to the site.

But I was a little frustrated. I wanted to spend just 1-2 hours and but after 4-5 hours I was still plugging away. I was taking so much time away from making/improving Feed.Us.

But then it hit me:  This is improving feed.us.

How many other website software providers actively use their own product? I do every day.  If I'm not posting to the PackerBackerBlog.com (the top ranked packer blog in google, btw), I'm helping a beta customer make a new site or operating one of the Feed.Us network of sites (blog, help site, etc).

Creating and operating websites is what we do and it's why Feed.Us is in our blood!

John and Rick visit Zaca Tacos and show you how it's done:

We've just about wrapped up the 'new' interface on Feed.Us and we are in the process of migrating beta customers to the new interface.  After a few weeks of testing, we'll be ready to open up Feed.Us to all customers. 

Meanwhile, we're finishing up a couple syndication projects.  One of our main goals with Feed.Us is to be able to import content from a variety of sources and then export that content anywhere.  This is the idea of "publish everywhere".

Currently, FeedUs customers can import content from email, XML and RSS.  We'd also like to be able to import ical calendar files and Google's calendar XML. 

Feedus currently lets customers publish to any website via javascript widget and serverside (non javascript) widget.  They can export to an RSS feed or XML.  We're about to finish a Facebook application so that customers can add articles to any profile.  Integration with Google and Mac calendar files will come shortly as well.

Another project we're working on is exporting content to Amazon for selling news/articles on the Kindle.  Publishers will be able to import their content from a variety of sources and then send that content to Amazon for the Kindle.

Feed.Us is a great content management platform, but it also will be a powerful syndication platform as well.

*This article was published to the FeedUsBlog via an email from Gmail.

We've been working the last 4-5 months on an interface for Feed.Us.

The new interface highlights the "Sections" concept (that was built after the old interface).  But the main reason was to make Feed.Us a lot easier to use with new ajaxy functionality.

Check out the tour.  And thanks to the PackerBackerBlog for trying it out!

Feed.Us was recently featured on the Thirsty Developer, a .Net podcast.  We were interviewed by Microsoft's Larry Clarkin last month and the interview is now up. 

Larry refers to Feed.Us as "content management in the cloud".  We wish we had thought of that! 

Thanks to Larry for getting us on and for enduring the TGI Fridays veggie food. 

You can listen or download the MP3 of the podcast here. 

One of the great features with Feed.us is the ability to add/edit/write/manage/etc content across multiple publications.  I currently use one Feed.Us account to manage articles on my 37 travel-related websites (like Caribbean Travel News).

There are two features that make this especially easy.  The first is our "categories".  Categories are similar to "tags" on blog systems.  You can add a category on the fly and any one article can be added to any number of categories.  For example, a story could be added to the "news", "Illinois news", "political news", and "Illinois political news" categories. 

Each category creates a "feed" of articles that can be added to any website with just a few lines of code.  So if you've got a special section or an upcoming event, a new section of your website can be added for a new category within just a few minutes.

But these categories can also be used across separate publications/websites.  This is where syndication gets interesting.

The customer in question (let's call them X) produces real estate news for daily and weekly newspapers.  Currently X has to login to separate CMSes for each publication and post each story.  So X's writers have to be schooled in many different systems.  It's a real pain.

Feed.Us can simplify the process.  With Feed.Us, X can give each of its partners some custom Feed.Us code and one local file.  Within a few minutes, X's partner can install Feed.Us on their website. Now X can use Feed.Us to control pages on the partner website without any access to their CMS. 

An example?  The FeedUsBlog.  Posts on the FeedUsBlog also show up on Feed.Us's homepage.  Feed.Us is the application, so it's hosted on our fancy servers at the fancy data center.  But FeedUsBlog is hosted on cheap servers over at Godaddy.  The same articles appear in both places, by just selecting the right categories.

If you'd like to learn more, contact me about it: Rick at feed dot us.

We here at the Feed.Us headquarters have worked with a number of radio show producers.  I thought I would share some insights about getting radio show MP3 podcasts online.

1. Domain: Buy a separate domain name for your shows.  You don't have to make a separate site, it's really for the storage of the files.  Like WBBQPodcasts.com or something.  

2. Hosting - I'd buy a cheap hosting plan, like Godaddy.  You can get 150 Gigs and 1500 gig transfer for $7 a month. 

2. FTP - Funny how old school FTP has become, but it's still the easiest to upload large MP3 files. Create a folder for each show and save the FTP folder on your desktop.

3. Now with the new domain and FTP, you'll have your podcast URL. Example:  WBBQPodcasts.com/showname/filename.mp3

You can just give out the MP3 file names on your website.  But you can also use Feed.Us, Feedburner, widgets and iTunes to get more listeners. Details:

4. Use Feed.Us to create an RSS feed (you'll have to contact us for an account). You should create RSS feeds for each show.  

5. "Burn" your MP3s into iTunes using Feedburner.com. Feedburner is setup to automatically submit your podcasts to iTunes as long as there is a URL in the body of the RSS feed (Feed.Us can automate this for you).

6. "Stream" your shows using a Web Widget. You know how it's really nice to play a video on Youtube?  That's a flash Web Widget and there are tons of free widgets that you can use to allow your website visitors to easily access your shows. It's better than making them download the show. 

I like the ones at WidgetBox. You can find others using a Google search for "flash mp3 player".

You could actually give out the code to the Web Widget and let others display your shows on their own Websites as well.

If you have any related questions, feel free to email me. rick at feed dot us. 

I recently tried a new cell phone voicemail service called YouMail.  It's supposed to replace my AT&T voicemail and send me emails with caller ID and an mp3.  Pretty sweet, right? Well, it doesn't seem to work on my phone. And they had me turn off my AT&T voicemail and now I have no voicemail! Now I'm worse off.

This kind of crap really pisses us off.  At Feed.Us, we realize that you might not love us.  And you might want to leave.  We hope not, but we understand that it could happen.  So we're going to try to make it really easy to leave:

1. Your site. If you've setup a site with Feed.Us, the site is on YOUR servers and uses YOUR platform of choice (or your developer's).  There's no special templates, no fancy "themes".  If you view the source on this page, it looks just like a normal flat file.  Go ahead and try this if you're using Drupal or WordPress.  You can't "leave" those services very easily.

2. Your content.  It's your content.  We don't want it, actually.  So, if you close your account, we'll delete all of it off of our servers.

3. Take your content to go.  Feed.Us is about getting your content in easily (email, RSS import). But we're also about getting your content out easily, too.  

Take a look at this link:

http://feed.us/render.aspx?xp=4&id=245&cs=&xs=Default-RawXML&l=feeduscontent&a=00000000-0000-0000-0000-000000000000

That's all of the content from this site (the Feed.Us Blog).  View the source.  It's one big-ass XML file.

Like RSS? You can have your entire archives in RSS as well.  

Update regarding YouMail: seems like it was user error.  I went through the setup on YouMail again, and bingo it's working. So far, so good. 

We have enjoyed working with some new beta customers. Heck, it's easy to love our customers when we love Feed.Us.

Here's a list of some new sites powered by Feed.Us:

GolfHippie.com - Feed.Us integrated into an ecommerce site.
 
The penske file - RSS importing website.

Nicolet Home Run Club - team website

Wisconsin Condo Law - SEM website

Wisconsin Bike Law - SEM website

TwitterBotting - twitter news site

WineTweets.com - RSS import and Twitter API website.

Whitefish Massage Therapy - marketing website
 

The Feed.Us "detail" page is a little tricky to explain.

It's the way that Feed.Us can create dynamically generated "permalink" pages on your website.

It's where the "full story" will reside - the unique page for a specific article, calendar, etc.

Still confused? Look at this page (the one you're looking at). The title and teaser on the homepage links to a permanent full page that we generate dynamically.  When I write this page, I don't have to create the permalink location.

Here's how it works.

1. Create a PHP or ASP page called "detail.asp" (or detail.php). 

2. Where the Body of the article would go, you place the following code:

ASP:

<%
                If (request("c") <> "") Then
                    FeedUsURL = "http://feed.us/render.aspx?xp=2&id=" &request("c") &"&cs=&xs=Default-Title_Body&l=loginname&a=00000000-0000-0000-0000-000000000000"
                else
                    FeedUsURL = ""%>
                    No content specified.
                <%end if%>
                <!--#include file ="FeedUsGrabber.asp"-->

PHP:

3. See that "Default-Title_Body" in the URL?  That refers to an XSL on Feed.Us.  You can use any XSL and display any fields in Feed.Us and use specific CSS div tags.

4. "loginname" in the URL is your Feed.Us username.

5. You can add great web services like javascript-based comment systems and sharing services on this detail page.  Just add the javascripts below the Feed.Us code.

6. With PHP, you can do a URL rewrite (like ISAPI rewrite on ASP), and include the page's title out of Feed.us into your URL.

The Detail Page is one of the great features of Feed.Us because it makes a complex problem incredibly simple.  You could actually make two files, a default (index) and a detail page and then use feed.us to create your navigation and all the rest of the pages of a site.  

I can't really blame this on anyone but myself.  I suppose RTFM probably applies here, but the error seemed misleading as well.  In any case, I was attempting to add an AJAX.NET update panel to a page (without reading any tutorials, or manuals, or much of anything else for that manner), because I had seen a demo video or two in the past.  Supposedly, it's just drag 'n drop Ajaxification!  Woohooo!  Well, as it turns out, it is pretty easy, but not quite as easy as drag n' drop (though it is close).

1. Include the Script Manager.

   I saw this on someone's page where AJAX was working, and it wasn't on mine, so I put it on there.  As it turn out you need exactly one instance of this on your page.  In other words, if you're working in a team environment, and someone else created your Masterpage that uses AJAX (read: it already has the scriptmanager) then you won't need it on yours or you'll get an error (Only one instance of a ScriptManager can be added to the page.) and then you'll beat your head on the desk for a while until it finally occurs to you to check the master page.

   <asp:scriptmanager id="ScriptManager1" runat="server"> </asp:scriptmanager>
2. Drag on the UpdatePanel.

   Easy enough... check the toolbox for AJAX Extensions and drag it out where you want your Ajax.

3. Add a ContentTemplate to the UpdatePanel

   This is the part that threw yours truly. I tried adding all my controls directly into the Update panel. To which .NET calmly replied: asp:MultiView is not a known element. Sweet. Thanks guys. So apparently you have to add

   <asp:scriptmanager id="ScriptManager1" runat="server"> </asp:scriptmanager> <asp:UpdatePanel ID="UpdatePanel1" runat="server"> <ContentTemplate> <-- YOUR CONTROLS GO HERE!!! ---> </ContentTemplate> </asp:UpdatePanel>
4. Add your controls to the ContentTemplate

   It probably makes sense to the gang that created this stuff... but why wouldn't you include the ContentTemplate when you drag it into the Form in the first place? The only other option there is a Triggers tag... and I doubt that is going to be useful unless you have some content. Oh well... blah blah blah.

5. Take that puppy out for a walk!
   

   At this point... you should be Rokken like Dokken.

Hopefully this can save someone a little frustration.

We seem to have a tough time explaining this one.  Maybe it's because we're not speaking loud enough or frequently.  So we'll try it again:

Feed.Us is just for your Website's (or application's) Content.

What do we mean by CONTENT?  It's the stuff that's in the center of your site.  It's the stuff that gets added regularly and edited.  The stuff your readers submit for publication. It's the stuff that's added by the non-techies (how come techies don't write much, besides code?).  It's the stuff that you need to add a photo to or make a movie for.

It's your company's news.  It's your President's press release.  It's your publication's articles.  It's your firm's product line.  It's the video you made that's on youtube.  It's the calendar of your team's games in June.  It's a list of famous quotes or favorite recipe. It's a big bunch of important links. The stats of your favorite football team.  The directions to your office. That's what we mean by "content".

And Feed.Us only cares about Your Content. In fact, we care A BIG BUNCH about your content.  We want to make it REALLY EASY to add more of it, edit it on the go, syndicate it to your partner's site or sell it to a larger publisher.  Most of all, save it, store it, and FEED IT to any website, any application, any server hosted anywhere. 

What don't we care about?  Your site's template.  In fact, we don't care what your site looks like. We don't care about  What "platform" you use to put your site or where that site is hosted.  Because feed.us works with virtually all websites on any server.

Pheew.  That was a rant! 

by Rick Stratton, Feed.Us founder

I'm a webstats junkie - daily... sometimes several times a day, I sort through the stats on my sites to figure out who's been there and what they looked at and where they came from.  The measurements, the tools, the services have changed through the years, but I'm still doing the same digging  and I still love doing it. 

Webtrends is what we used for a long time.  We used their log analysis product.  It did a fine job but it hogged a ton of server space/resources.  We've moved on to a Google Analytics. 

The main reason we changed is because it's free (Google DESTROYED a large segment of the web software market by releasing GA totally free).  Also, it works via a javascript on each page, so we didn't have to keep all those logs around anymore. But Google also has made a terrific product.   (It could use some improvement but hey... it's free.)  Also, Google has done a great job integrating location and 'network properties' of website visitors.  (Probably the only real change in analytics since I started my addiction.)

So here is what I do:

1.  Set the date: Google defaults to a monthly view of stats.  I have to automatically change the date settings to the last week (ok last 24 hours!).

2.  Total Visits: this is the number of visitors, but it's not unique.  If one person comes back 100 times, then you've got 100 visitors.  There's a unique visitor number somewhere, but people care less about this stat these days.

3. Pageviews: the number of visitors x the number of pages they viewed is pageviews.  

4. Bounce Rate: bounce rate is confusing.  It's good to be low, but not always.  Bounce rate means that someone visited one page of your site and then left.  If that's your goal - your bounce rate is probably not important.  For a site like the DrudgeReport, their bounce rate is like 100%.  If you want folks to 'dig deep' then a low bounce rate is better.

5. Some stats get ignored: I don't care much about pages/visit or new visits or avg time.

6.  Visitors: Next I look at my visitors - where they came from (map) and if their 'Network Properties' are set.  Network Location is probably the most addicting for me. (Nutshell: if your visitor is on an IP address that is identified, it'll show.  Most are from a large cable company (Comcast) so you can't tell anything about them.  But many corporations are set so you know they came from Microsoft or Adobe, etc. We never had this before 2006 so it's pretty addicting.  If you don't run a business-to-business service, this probably doesn't excite you.)

7.   Source & Keyword: Next I typically go to look at where and how the visitors came to our site.  If you've got a consumer-facing site, this is probably where you need to spend most of your time.  Google's "Traffic sources" is awesome.  It puts the top sources and keywords on one page.  Unfortunately it only shows like 10 at a time.

Google Analytics tip: you can slice pretty much any stat using the "segment" option.  For example you can figure out that the person who typed  'calendar xsl tutorial' came from Google, is located in Brisbane, and works for a company called Citec.  They also left after 23 seconds (whoops!).  Click on the stat you're interested in seeing, and thenuse the "segment" dropdown.

8.  Finally "Content": aka  the pages on the site that people visited.  I like to keep tabs on what is most popular, least popular etc.  This is probably where Feed.Us works really well for analytics.  If you're using our "detail" page (that dynamically creates asp or php pages), you'll get a nice record of each page and how many folks have visited each one.  If you're running a URL re-write program on your server, it'll work nicely with that too.

That's pretty much my strategy.  In summary: total users, pageviews, keywords, source and location. 

Final Tip: Consultants should like the way that Google lets you give access to different users.  It's great for consultants to have one large account but give specific access to clients. 

We're all very very excited here, right now.  Well, we always are pretty excited.  But we're especially excited because we're getting very close to launching the first public version of Feed.Us, and it's going to be FREE!  And it's coming in JUNE.

This initial version of Feed.Us is going to be simplified and not the full-throttle Feed.Us.  Why? Well because we want to make money off this thing, eventually.  But the 'Free version' will still be MONEY (pun intended). 

So what do we offer?

1. A simple to use CMS that can be used by even your dumbest clients/co-workers.  Create stories, calendar events, product guides, how-tos, FAQs, link lists, etc.  

2. Some basic 'work flow'.  Users can have some basic limits on what they can see and do.

3. Importing from RSS and from email.  Writers can submit their articles via Blogger or their blackberry, etc.

4. The Feed.Us "scriptomatic" Web service that makes it really easy to add Feed.Us-hosted content on any site/platform/server.  

5. Pre-set Feed.Us: We'll set it up so it works right out of the box, er... screen.  With "sections" that are pre-configured for common content: news, calendars, product info, links and video.  

6. A simple RSS generator for making a crap-load of  RSS feeds 'on the fly'.  Burn them into Feedburner, use them on other applications, whatever. It'll be the best thing out there.

7.  A startup zip file that has all the stuff you need to setup a feed.us powered site in 15 minutes or less.  Just add a domain and hosting.

8.  Simple account setup, Reaaaally great help and support.  (Help is via video and text.  Support is via me.)

We're FIRED UP.  So watch our twitter or  RSS feed.

Also - why is it free?  

Along with the new layout/design of Feed.Us, we're going to change the logo.  We like the old one a lot and we like the newer one that we've been using on the new layout.

Here are all of our logos over the last couple of years, back even when it was RSSCMS.com.  Any thoughts or comments?

Recently my favorite email newsletter's design went from elegant to horrible.

It made me realize that we should comment about the dying (dead?) art of  email newsletters.

We've posted about newsletters in the past.  We're really not big fans, really never have been.  Actually, we're not fans of any kind of marketing where the target is a single digit response rate. (Update, just checked our data: our previous company's email newsletter application had a 33% open rate and a 26% average click rate. We assume that's about typical?)

The only way to do a newsletter is to think of the effort as customer support.  It's not marketing and it's definitely not sales.  It's about giving your audience another way to touch you that's convenient to them.

That's why we were so disappointed to see the WSJ's Best of the Web Today newsletter design change at the start of March.  I've always enjoyed Best of the Web 's clean, almost elegant newsletter design; It was extremely readable.

On the left is the old version. On the right the new.  Why all that space along the left side of the new newsletter?  All that space is saving room for advertising.  

Hey, we love ads!  Advertising makes the web work and grow.  But newsletters should probably be advertising free or at least minimal.  Why?  Newsletters are all about reaching your audience the way they want to be reached.  Few people want newsletters anymore. Those that do are very serious about their subscriptions. 

So treat your readers with respect and make your newsletter as readable as possible. 

We're stuck on the topic of iPhone / iPod touch website designing.  (But we're also pretty stuck on our iPod Touches and iPhones.) 

Browsing is pretty phenomenal on a wifi connection for such a small device.  As we've said before, eventually, maybe even now, lots of folks are going to be surfing your website via an iPhone.

One of the dramatic problems that the iPhone creates is with the "pinch". This means taking your thumb and for finger and kinda reverse pinch the screen to make the page magnify.   It makes it easier to read text on a non-iphone formated webpage.

It used to be that I'd recommend making a news article webpage as wide as possible in order to make it easier for folks to read.  But that's probably not the case any more with the iPhone.   It's actually better to be narrow.

Compare these below screenshots (sorry for the crappiness).  On the left is the BrewCrewBall.com website (the new design is niice, btw).  On the right is "under the fold" of one of the WSJ websites.  Neither are formatted for the iPhone.  The BrewCrew site is very "pinchable". The WSJ is completely unpinchable.

Why? The center column of the Brewers blog site is 450 pixels wide.  The WSJ site is is over 800 pixels wide.  Here's the deal: when you pinch the center of the Brewers blog website, it expands perfectly to the right size to read.  Expand that WSJ site the same way and you'll have to scroll side to side.  It's practically useless on an iphone. 

This seems like a minor point, but it's not.  

We're making a news site demo for Feed.Us.  We're also going to make an iPhone version.  I haven't made an iPhone specific site before, so I'm doing a little research.  Here are a few things to keep in mind.

1. If you're a publisher and you don't have an iPhone or an iPod Touch, you better run out and get one today.  Your site probably sucks on an iPhone.  In case you haven't heard, these things are pretty popular -- you're site needs to work on them.

2. ESPN.com SUCKS on an iPhone/Touch.  So does My.Yahoo.  You need a SEPARATE version of your site for the iphone.

3. Text needs to be huge.  Bigger text... much larger... how else do I put this?

4. The "two finger expand" aka "pinching" works, but it's not great.  You shouldn't force your readers to use it.  Accidental clicks happen too often when I try to "pinch" a page.

5. Best iphone/touch pages I've seen so far:

 ESPN's Podcenter for iPhone

 New Leader's ThinCloud Twitter app. 

6. The iphone/touch screen is 320 pixels wide and 690 pixels tall.  That's what you've got to play with.  See screenshot below.  That's what you've got to work with.  (BTW, it's ThinCloud by New Leaders).

by John Welborn, Feed.Us VP of Engineering 

Honestly, I suppose part of the decision was based on past experience with the Microsoft platform and environment.  I used to develop in ASP and wrote some VB components for performance critical components.  ASP was / is a pretty solid scripting language.  If you ever took the time to explore the, although weakly implemented, class system, you could do some pretty advanced stuff while maintaining a reasonable separation of interface and implementation.  I even experimented with Visual Interdev, which was, IMO, an early version of asp.Net. and if it didn't have so many bugs and such a lack of documentation, it might have gone somewhere.  So it seemed natural to check out .Net.
 
I started fooling around with vb.net and went through a few tutorials, and the Visual Interdev experience made it very familiar.  I'd been hearing about c# and how it was like a cross between c++, which I cut my teeth on in college, and vb which was easy to develop with.  Visual c++ was a nightmare... I new c++ but when I looked through all that MFC stuff that got thrown in when you tried to make a windows app I was LOST!  And I had plenty of learn Visual C++ in x days books, that I never really made it through... but I could make vb apps with ease, so I was really excited about the prospect of a combination of the two.  The OOP of C++ and the simple application development of VB!
 
Now that I've used it for a while I can say it is exactly what I wanted.
 
All that history aside... why .Net?
 
1) A great development environment.
 
One of the wonderful things that was SUPPOSED to happen in Visual Studio was a great debugging interface.  Which was pretty cool if you could ever get it to work, but it took everything short of an act of God to make it so.  .Net however, has its own built in web server and the debugging is fantastic.  A great debugger makes development SO much easier.  Gone are the days of putting in 500 print statements to check what the variables are at any given time, and then having to go back and remove them or comment them out.  Instead you just set a watch and keep rolling.
 
2) It's a real object oriented programming language.
 
Asp was great, Php is better... but at the end of the day, they're scripting languages.  The .Net platform is for application development.  We wanted Feed.Us to be a true application.  I really wanted to plan ahead this time, and build our application with the future in mind, and in that future the web is just one piece of the puzzle.  With .net we could build a standalone windows app, or a Windows Mobile app or whatever else might pop-up and we can leverage all of the same code.  Now arguably, you can get to a browser on most phones and pcs so we may not need another interface, but I still like having that option.
 
3) It's compiled.
 
That means it runs faster, and , if you want, you can distribute it that way so folks can't root around in your code.  That's not too inline with the open source way of doing things... but it is an important factor if you're considering selling your application.
 
But what about RoR (Ruby on Rails)?! 

Yeah, well I looked at that too... and I'll admit it's pretty cool, a nice framework.  Someone else wrote a whole bunch of code so you wouldn't have to!  Yeah!  But that also means your code has to work the way theirs does.  I've worked with and written some frameworks, so I know how they work behind the scenes... before the scaffold:TableName ever comes into the picture.

I know we wrote those frameworks to make it easy for people with limited programming knowledge to make sites, and I know what compromises were made in order to do that.  Certainly, Ruby is better than ours ever was... but in general I think frameworks are excellent for building straightforward sites that follow the rules, but if you're pushing the envelope it can be a serious waste of time.

CMS Wire's Jason Campbell sat down for a discussion about Feed.Us with Rick Stratton. 

Sorry, Rick but you were pretty wordy.  We here at Feed.Us actually feel sorry for Jason and wonder how he made it through the whole thing.  But thankfully he did and gave us a pretty good intro:

Feed.us has taken a shot at the content management market and one that strikes a distinctly different approach to solving the typical problems with light-weight publishing. Via the combination of software-as-a-service (SaaS), XML data transformation and flexible input and output APIs, Feed.us thinks they’ve carved a foothold in the market. If they’ve played the cards right, it could be one that’s going to make life easier for a whole lot of folks.

If you feel up to it, you can read the full interview over at CMSWire.com. 

You gotta love the way CMS "solution provider" describe their product. It's as if they have a program that makes their language extra convoluted.  We've been doing this work for more than 10 years and we cannot understand what some of these product descriptions mean.

You can't even make this stuff up:

"Interactive content management (ICM)-which is generally viewed as the evolution and integration of digital asset management (DAM) and web content management (WAM). Interactive content engages an audience with information that informs, involves, and entertains them."
- EMC Documentum

"Uniquely provide native management and delivery of all electronic assets"
- Vignette

"... solutions that enable organizations to effectively leverage content to drive business growth by improving the customer experience, increasing collaboration, and streamlining business processes in dynamic environments."
- Interwoven

"... a dynamic run-time delivery engine..."
- Interwoven Livesite 

Even Wordpress can't escape this trap (but at least they realize it): "WordPress is a state-of-the-art semantic personal publishing platform with a focus on aesthetics, web standards, and usability. What a mouthful. WordPress is both free and priceless at the same time."

So here's our description of feed.us, in techno babble:

"Feed.Us is a highly scalable and flexible content delivery platform, utilizing a server side Ajax request and cache mechanism combined with standardized XPath content retrieval."  

Which translates to...

We're Feed.Us.  We want to save your web content and then make it really easy to put on any website, anywhere.

There are a lot of folks who hack-the-crap (HTC) out of Movable Type and Word Press to make them do more CMS-y things. 

We can understand why folks HTC them. MT and WP are inexpensive (or even free). Both are widely-used, thus well-known and safe.  And they're certainly easy for the end-users (writers, content creators, editors, etc).

But it's just blog software.

Here's an example: you're using MT for your company's site.  It's great for a company blog, obviously.  It's also great for press releases.  What if you want to display all the events your company is going to go to? Yeah, it's not so great for an event calendar.  You've got to HTC MT in order to make it work.

Enter Feed.Us sections...

We designed Feed.Us, from the very start, to have a variety of different kinds of Web content.  News & blog posts, yes... but also product info, address books, FAQs, event calendars and even recipes.

You can build your own publishing applications to make it easy for your folks to add a variety of content. Use fields like "start date" and "location" or even "event coordinator email address" or "number of spots available".

Also, Feed.Us imports from RSS feeds and will import from calendar XML feeds.  So adding events to your site's calendar can be done via Google Calendar or even Outlook. 

Here's the first calendar we built.  It's the the 2008 National League Central Division Champs MLB 2008 schedule.  Imported from the MLB's Google Calendar to a Feed.Us Demo site.  It took about 30 minutes to get the whole page working. 

Try that with MT.

More evidence that supports our theory that 2008 is the year of the mobile web.  Research from a publisher called "Change Wave":

Record numbers of consumers are abandoning their basic cell phones for more-advanced models, according to the latest ChangeWave consumer cell phone survey... the Apple iPhone is now the top choice among respondents planning to buy a new cell phone in the next six months (up one point to 17%), but second-place RIM has the most momentum (up three points to 15%).

We belive that all publishers have to come to the realization that a larger, growing chunk of their visitors will be on iPhones and Blackberries.  Publishers have to create multiple sites and be prepared with alternative versions of their articles that work well on smaller aka "third" screens. 

Here is the full story. 

If you're confused between a Content Delivery Network (CDN) and a Content Delivery Platform (CDP), we can understand the confusion.

According to Wikipedia, a CDN:

is a system of computers networked together across the Internet that cooperate transparently to deliver content (especially large media content) to end users.

CDNs, like Akamai and Limelight, are employed by large websites to host and delivery large files to the website's audience.  Example? A publisher, like ABCnews.com, would give all its large files (photos, mp3s and videos) to Akamai while ABC hosts the site, site files/code, text, etc.  The large files just get delivered faster by the CDN.

While, a CDP (like, ahem, Feed.Us) is a hosted publishing application.  Publishers store all of the website content on Feed.Us.  News, product reviews, calendar events, images, etc.  Then publishers feed the content to their self-hosted Website using one of Feed.Us's APIs, like our very cool Server-side Ajax request mechanism.  Publishers control the site files and site structure; the content flows from Feed.Us.

We hope that settles it. If not, email us.  Or if you work for Limelight and might need some more info... 

rick at feed dot us.

I just finished a CSS/xhtml site and I thought I'd share a few thoughts about why CSS and XSL are powerful ingredients of Feed.Us.

First a couple of admissions... I am not a programmer nor do I play one on TV.  I can only design using Photoshop and have to off load my layouts to a CSS guru (theChoppr).   I can't really straight up code HTML or xHTML.  Most of my sites start as free CSS and then I tweak em till they do what I'm looking for.

Also, despite having used Feed.Us for about 6 months now, I finally forced myself to integrate CSS tags into Feed.Us so the content coming out of the Feed.Us servers adhere to my CSS.

XSL loves div tags 

Feed.Us sends all the content to your site as XML.  So we use XSL to decide what content needs to be displayed.  Then we give you a little cached piece of code that you can put on any page to display that content.

In Feed.Us you can quickly copy and convert your own XSLs (we've got default ones).  Then you can add div tags within the xsl so that the content coming out of Feed.Us adheres to your style sheet.  XSLT is very different, so think about that.  You can put your own div tags in the XSL on FeedUs's server so that when your content displays, you won't actually have to put the div tags in your xhtml. 

That's very different but very cool. 

XSL also allows javascripts

The other thing I love about XSL on Feed.Us is that I can embed javascript services in to the XSL on Feed.Us so that specific services run on pages on my sites. 

Again, you're probably like "but why?" You can actually put embed code within the XSL - add Google ads or a js-based comment system (like Disqus) to the XSL on Feed.Us.  Then when you add the FeedUs code on your own pages, those javascripts all appear.  

That might not be important to you right now.  But imagine if you're feeding content to 100s of other sites.  You could put your Google Ads on all of those sites (technically it violates the Adsense TOS). 

I'm sure I'll add more advantages to Feed.Us and XSL in the future.  Stay tuned! 

"How do I make an RSS feed?" I am continually suprised by how often we hear this question.  We heard it a lot in 2005 when RSS was becoming popular and here we are in 2008 and we're still hearing people ask this question.

Even with all these great Web 2.0 services popping up it still isn't simple to create an RSS feed.  You want to use Feedburner! Great, you still need an RSS feed.  You want to syndicate your podcast to iTunes... great you still need to make an RSS feed.  It's not automatic but it should be.

With feed.us, you can make a RSS feed on the fly, with no technical expertise,  from any type of content. Content based on date or author or category.  Or all items.  And with our implementation of XSL, you can easily edit the actual RSS code without going back to coder school. 

But there are a lot of folks out there who aren't using FeedUs.  We don't know why you wouldn't want to try it, but that's fine... we all have our flaws.

If you're not using Feed.Us and you want to make an RSS feed, here is a hack to make yourself an RSS feed without being a developer:

Create an RSS feed quickly, easily: 

(Assumptions: you're not a developer and your CMS software doesn't make it easy to create an RSS feed.  You can figure out Delicious and Feedburner.)

1. You're going to use Delicious or a similar bookmarking service. (There are others out there but we have always been partial to Del.icio.us.  I guess you could even use something like Digg or Reddit.)

2. You'll need to decide what is included into your RSS feed.  All of your 'news'? All of your 'blog posts'? Calendar events? Product pages? What will make up your rss feed? Hint: generally it's news and items that get regularly updated.  

3. "Bookmark" every item, story, article, page, etc that you want included into Delicious.  we recommend adding the "browser buttons" so you can make this a one click process.  

4. Write a description of that item. Delicious doesn't allow for a lot of space... so write a short summary.  If your site isn't using decent page titles, you'll need to write out a page title as well. 

5. Tag each item with a custom tag.  I sometimes use "ricksreading".  

6. Go to your page for that tag.  It should list all the items you've tagged.  At the bottom of the page there's a link for the RSS feed for that page.

7. Take this RSS feed over to Feedburner.   "Burn it" in feedburner.  Make sure you go back to the "Optimize" page and edit your title/description. 

8. Feedburner will give you the new URL for this RSS feed.  Congrats, you've got an RSS feed! 

Note that there are two problems with this: (1) It's a manual process.  RSS feeds should flow automatically.   (2) The feed will just use shortened items - not the full post.

Also, an alternative hack if you have a general RSS feed and you want to make an RSS feed out of certain categories... use Google Reader and publish your "shared" items out of the RSS feed. Google Reader's shared public page has an RSS feed that will work nicely in Feedburner.  

We've traveled the world (ok the eastern half of the US), hosted conference calls and spammed people on Twitter in order to convince some beta testers to try out Feed.Us.  

And although we've got some great feed back (feedusback?), we've also here many reasons why Feed.Us doesn't work.

Now, from the home office in Milwaukee, Wisconsin... here are the top reasons NOT to use Feed.Us:

#6:  Paying $150,000 for a CMS and then spending another $300,000 in consulting fees is a good investment.

#5:  What else would I do if I didn't have these servers to manage?

#4:  I enjoy learning a whole new, custom mark-up language!

#3:  A four day software installation sounds like fun!

#2:  Updating to a new version helps mark the passing of the seasons.

and #1:  We need more money so we're going to make something custom for our client!

Do we sound bitter? Yes, we do.  It's not like we're Chuck Yeager vs the sound barrier, but we still get upset when people think there isn't anything better out there. 

There is a better CMS out there.  It's actually a CDP and it's called Feed.Us.

Click on the video below to start. 

Here's the URL of the page I created with the content coming from Feed.Us.  I made the page dynamic, with perma-links to the full story.  It's just as easy, but you have to make a second ASP (or PHP) page that has a different FeedUs scriptomatic code on it.  Longer description, here.

Email us with questions: contact at feed dot us.

Hopefully you saw our earlier post about why we think the mobile web will finally take off in 2008.  In this follow-up, we offer some suggestions for making a mobile news website. 

We here at Feed.Us have most of our web experience building/managing newspaper Websites.  So our suggestions are probably for a site that has regularly flowing "news" (we throw the term news around a lot).

We think the aim of a mobile news site should be to get the most recent items to regular readers when they're away from their computers.  In that way, it's similar to RSS or even email newsletters. 

We built this mobile version of the FeedUsBlog to test/try out our suggestions.  Just two pages and very simple, it works quite well and we don't mind saying it.

Domain/URL:

We like using http://m.domain.com.  This seems to be the defacto url.  Examples abound. 

In fact, we'll go so far as to declare the "m.domain.tld" format as the official URL of mobile browsing.

Layout:

The mobile site is where you need to keep it simple.

We're a big fan of a small logo and then your headlines. There should be a brief "teaser" aka a summary as well, but not necessary. Each headline links to the story.  Some news services offer just a short summary.  We prefer the whole story - let us do the skimming.

So to repeat, just a logo and headlines.  Keep your nav short and near the top if you have to have one.  But you shouldn't need one, we think.  Just go right to the latest news.

Also, the sites that use "accesskeys" in the links are really helpful.  See CNET's mobile site for an example.

Drudge has a list of mobile-friendly news sites.  Each seems to agree, to some extent, with our layout suggestions.  

The W3C's mobile best practices is quite helpful, but a tad outdated.  It's located here. 

 
Coding it: 

You can use asp or php or jsp or asp.net.  We don't think that matters (also, FeedUs works with each, did we mention that?). 

We used the xhtml mobile 1.0 as is standard in Dreamweaver.  There is a 2.0 but we couldn't find a site that uses it.

Also, we recommend making the images' code display the width and height.  Supposedly that helps.  

Using Feed.Us (aka it's our blog so we'll pimp our product):

Feed.Us  offers a number of advantages.  The way our service displays news content, via a few lines of code, works really well on mobile xhtml pages.  And Feed.Us was really built to display news headlines with a teaser or without.  Finally the news story dynamic pages (we call it the "detail page") lets you just make 2 mobile pages: a homepage and the detail page. Feed.Us code on the detail page pulls the full body of the story automatically.   More on this here.

Already got a CMS?

Say you've already got a CMS and you want to create a mobile site but your CMS ain't so friendly?  If you've got RSS feeds, Feed.Us can be your solution.  Feed.Us can import your RSS and then you can build normal xhtml/asp or xhtml/php pages.  Use Feed.Us's simple scripts to display the content from your CMS via RSS.  (Or probably email us for a better description: contact at feed dot us). 

Redirect:

It's important to redirect your potential mobile readers to the mobile version.  If they don't know it's m.yourdomain.com, then they need to be redirected.  

Redirection depends on your website (php,asp, etc) and on your audience's phone type.  A good description of how to do it is located here.  A list of the mobile phone "user agents" is here.  Generally, the mobile browsers types are: netfront, minimo, series 60, open wave, opera mini, blackberry.  Apple iPhones use Safari which isn't easy to redirect.  Please use the comments if you have any suggestions. (It doesn't look like Drudge is using a redirect, even for Blackberries.  That's interesting.  Probably because of the Apple Safari problem.) 

In Sum:

Make a mobile version.  Use m.domain.com (cause it's the standard, now).  Make it simple.  Use Feed.Us.  Got it? 

Update: The Wall Street Journal had an article on Monday titled "Web Surfing on iPhone Erases Doubts of Mobile Devices Futures Online".  Link is here.  It's login-able so you might not be able to read it.  However, the title pretty much sums up the article.  We don't agree with their assumption that most mobile sites are "watered down".  The iPhone's screen is still too small to view a full, normal website.  And Drudge probably agrees with us, because his mobile site is intended specifically for iPhone users.

Yeah, the mobile web has been around for a long time.  And it's been active, for sure.  But we here at the Feed.Us headquarters are witnessing a sudden explosion of mobile browsing.

Finally, worlds are colliding (and George is getting upset!).

The problem with the mobile web has been slow connections and small screen, not to mention the crappy mobile phone companies. Slowly the tide has moved in favor of the mobile web and we think that 2008 will have an explosion.

(Toot toot our horn here... We created this mobile site for eprairie back in 2000.  Weird that it still exists in the same form and still looks/works fine.) 

Recent developments:
Obviously, the iPhone is the serious development for the mobile web.  We finally have a decent phone for viewing websites.  But have you tried it on a normal digital phone network? It's too slow for surfing.  But try it on a Wifi connection... and it's not bad.  If you're sitting on your couch, watching a football game.   It's still a small screen, but it's a nice connection.

Wifi Blackberries
In November, RIM started to sell the Blackberry Curve with wifi.  (Unfortunately for me, they started right about 30 days after I bought my curve... right after my trial ended.)   Like the iPhone, more folks won't mind browsing on their phone.

Twitter and texting
I think 2007 was the year when "normal people" began text messaging.  Meanwhile, new mobile applications like Twitter have started folks sending links to mobile phones via text messages.

I think publishers are just starting to realize that there's an audience on phones. Publishers are starting to send their news via text. (FYI, I previously made some suggestions for sending news to mobile phones using Twitter).

NYTimesRiver.com
There are some creative mobile news solutions popping up.  Dave Winer created this nifty mobile phone homepage of the New York Times website.  It links to the mobile versions of the New York Times. 

iDrudgeReport
Last week is when I think the new game started for mobile browsing.  Drudge released probably the first change to his service since he started in 1997, this new mobile phone website at iDrudgeReport.com.

He hasn't really changed anything in years.  No email newsletter.  No RSS feed.  No widgets.  But a mobile site.  Obviously, Drudge sees the potential here.

However, Drudge includes  this redirect. I have to assume that most of our news sites do not publish mobile versions that work well. 

Mobile Web
So based on all the previous clues, I think it's pretty obvious that you need to start thinking about the mobile web.

It's certainly easy to make a mobile version of your news site (or blog). And we think Feed.Us can help create and manage a mobile site.  It can also work with your existing system by using an RSS feed.

In part 2 (coming Tuesday), we'll make some suggestions about making a mobile version of a news site and, of course, identify how Feed.Us can help.

It has always been our goal that Feed.Us works with just about any kind of platform out there. Flash, php, asp, jsp, .net whatever. 

Well we're on our way.  Last week we completed the .PHP and .JSP versions of our "grabber" so that Feed.Us is now fully compatable on .asp, .php and .jsp websites. Asp.net is coming soon.

If you've been playing along at home, you know how Feedus works.  But if you aren't our mother, we'll try to explain it quickly:  Feed.Us is a content management platform.  You store your site(s)'s content on our servers.  Then there's one file you host locally.  That local file (a jsp, php, asp, asp.net file) pulls content from our servers and serves it into your page via 2 lines of javascript-like code.

Special thanks to Melissa, Dee and the "JSP guy" for help on this project. 

You may have heard of Twitter.  It's a group text messaging service, kinda.  Folks use it to text a group of friends or even as a "microblog" service.

There's a growing trend to use Twitter as a way to publish to mobile users.  News sites and blogs have long used RSS feeds to reach regular readers via feed readers.  Now with the growing use of the iPhone (and of course Blackberry), more folks are reading web content via their mobile phones.

Guy Kawaski's Truemors was one of the first to regularly push website articles to mobile readers via Twitter (see it in action, here). The NY Times has followed, as well as many others.   

You don't need to dig into the Twitter API in order to get this going.  It's actually quite easy to get going.  Recently, Feed.Us helped the PackerBackerBlog.com  start publishing to twitter using Twitterfeed. The PBB has about 200 visitors per day.  With the the Twitter addition, the PBB has added about 20 mobile readers per day. Publishing articles to Twitter has also increased the number of Twitter followers of the PBB.

Here's how it was done:

Twitterfeed takes an RSS feed and publishes it to Twitter using the Twitter API.  Twitterfeed is actually pretty sweet - even though the OpenID login is kind of a pain.   

But you need an RSS feed.  The PackerBackerBlog wanted to publish specific articles that worked well on a mobile phone.  Long stories aren't really ideal.  So using Feed.Us, they built a separate RSS feed that is used in Twitter (using a separate category and then a separate XSL schema.  Sounds complicated, but it's pretty simple). 

Twitterfeed allows you to adjust how often items are sent to Twitter.  Every 3 hours, Twitterfeed checks the new RSS feed for new items, and publishes the headline, the summary and the URL over to Twitter.  Mobile readers get a text message with enough of the story that they can click the link to visit the PBB site directly on their mobile phone.

Using Twitter is a nice little addition that you can try to help promote or reach your visitors where they want to be reached.  Try it out (even if you don't use Feed.Us).

 (Update: we just realized that we should probably build the Twitter API into Feed.Us. Duh!)

(Update again: Kawasaki twitted today: "Twitter generates so much traffic to my site.")

Here's some background on XSL - one of the main ingredients of Feed.Us: 

About XSL

XSL is Extensible Stylesheet Language.  It formats or transfers XML (the data) for, or into, a layout.  XSL is a template language developed by the W3C and is recognized in all the big browsers.  You can actually attach an XSL file to an XML document much like you'd apply a CSS file to an xHTML document.  Your XSL dictates what fields get displayed out of the XML and how it displays.   (BTW, XSLT is Extensible Stylesheet Language Transformations - the language of XSL.) 

Most big web companies, like Six Apart, Facebook, Automattic etc write their own markup language rather than use the widely accepted XSL.  That's why you probably had to learn something new if you created a MT, WP, Typepad blog or if you're working on a Facebook app.  But XSL is more convenient - there are tons of documents and existing files floating around the internet. The W3C tutorial is a great place to start to learn more about XSL. 

Negatives?

XSL has a received a mixed reaction from developers, from issues about competition with CSS, to performance.  After lots of research, it's seems there are pros and cons as with any technology.  We've seen the benefits outweigh the ills.  It also appears that XSL 2.0 proves to address many of the concerns with XSL 1.0.  We're looking forward to that and will implment it as soon as it's available.

The most tangible concern is that of performance, but with Feed.Us we're caching the XSL results to a local file on your server.  So it performs remarkably fast. 

XSL works great with CSS.

XSL was created to transform XML, and with a little knowledge it works wonderfully with CSS.  You can easily apply whatever div tags and classes you choose within your XSL file in order to make the data (the XML) work in conjunction with your CSS.  See the graphic on the right - it's from an XSL we're using to display this article.

XSL dovetails really well with XHTML and CSS because they are both W3C technologies, made to fit together.  The proper use XSL and XML can make your CSS work a lot easier.   You can standardize your div structure and just change the CSS.

Why we use XSL with Feed.Us

Well, first of all your content (your data) comes out of our server to your website as XML.  So it's a natural that we'd use XSL.  But the big reason is that we try to not push anything new or unconventional on our customers.  We want to re-use technologies that are accepted and well-known.  Everything you need to know about XSL can be quickly found at a bookstore or on a tutorial site. 

Plus, XSL is a natural progression for folks who started with HTML and picked up CSS.  Like CSS/xHTML and HTML, it's very readable.  You might not be able to code it straight up, but you can easily read through it and make modifications and there are so many XSLT users out there you can find answers to almost any questions you might have.

For example, a common use for XSL is to transform an XML source into multiple output formats (i.e. HTML, WML, even other XML and it's derivatives like RSS, ATOM, etc).  So by simply checking the source of your web request you can respond with a properly formatted document, and since it's all cached, it happens lightning fast.  We provide the starting templates for you and you can customize them as needed.

Platform independent.  

XSL is conveniently platform independent.  The XSL documents you use with Feed.Us can come from outside sources and can be used outside of Feed.Us.  If you choose to leave Feed.Us, you can take your XSLs with you and continue to use them with your CSS layouts on some other service.  

More importantly, you can get XSL files from other sources and apply them within Feed.Us.  We recently found a really nice "box style" monthly calendar XSL file via a search in Google.  We're using it to display a bunch of upcoming events.  It's a lot like the free CSS templates that are readily available via a Google search. 

WNS Hockey is a local high school team in Milwaukee playing in the WIAA.   The team is made up of 4 local high schools.  Because it's a diverse organization from a bunch of communities, the Website is run by the parents and is the way the coaches, parents and players stay connected.

The site had been previously created in Frontpage but in 2007, the team wanted an upgrade for look/feel and for management.  They chose the Feed.Us content management platform.

The design of the site is CSS/xHTML template  provider Free CSS Templates.  The site is hosted at Godaddy, on Godaddy's basic windows hosting.  Feed.Us powers ever piece of content from the photos and calendar to the copyright in the footer.

Content:

The site serves as both a calendar and a news service.  The practice and game schedule for both varsity and JV is the most visited part of the website.  Feed.Us's calendar application should come in handy as should Feed.Us's XSL support - WNS should be able to make daily weekly and monthly calendars with ease.

News and game photos are also included.  WNS is using Flickr for photo storage and uploading.  Any parent can email photos to the WNS flickr account.  Feed.us can access the Flickr RSS feed, download and then display photos directly from the Flickr account.  That makes the management of the Website much easier for Webmaster/parent Jim French.

"I have been able to do all the work on the site... pretty easy!"

Visit:

WNS-Hockey.com 

This is a four part series.  Part 1 was about monetizing your domains. Part 2 compared the different contextual ad networks.  Part 4 will consider ecommerce.

I am assuming, here, that you're running Google Adsense or Yahoo YPN.  In my niche, I run Adsense because the ad quality and per click prices are better.  It may be different in your niche.  Regardless, there are two ways to increase your ad network revenue... more traffic (I covered the SEO basics earlier) or more clicks. 

So... how do you drive clicks?

1. Remember to help people

By all means, provide answers.  People search and visit your site to answer their questions.  Your main goal has to be to help people.  If you do a crappy job of giving people answers, eventually people will not click on ads and Google will not rank you high.  Remember this point - I think it's essential. 

2. Format the ads to look like content.  

I tailor my ads to look like my site.  White background and make the ad links the same color as the other content links.  Also, I use the biggest unit possible and build the content around it. 

3.  No other ads

If you want to maximize your ad power, don't run ads for anything else.  No link exchanges, no banner ads.  All of that will reduce the power of your contextual ad network.  

I used to run a hotels.com search (IAN.com).  When I took it off, my clicks jumped up.

4. Maximize the ad units

Whatever the limit that Google or Yahoo places on the number of ads, maximize it.  I've got 1 link unit and 2 ad units on each page.   

5. Make the ads blend in

I run a Link unit where my navigation used to be.  The navigation is at the bottom of each page.  People skim read - they don't read everything that I write.  So they are going to click on ads if the ads are compelling.  So I make a long page, then places above and along the units.

6. Don't give people an option

Reduce your number of website pages.  Make less options for people to click on.  Combine these two ideas and your clicks will go up. 

7. Follow the big SEO plays:

When you're in doubt, check out some of the big companies that make money like this.  I follow Squidoo.com, Mahalo.com and Associated Content.  These guys are setup to arbitrage traffic from Google and turn it into clicks so they spend money on figuring out how to do what I just described.  

I am constantly tweaking and tracking.  During October, I made some pages and tracked the results.  I currently have a about a 27% click to impression ratio.  So for every 100 visitors to my sites, I get about 25-30 clicks.   I have to assume that's pretty good.  However, if you think I can do better - please comment or email me?

Over the past couple years, we've made thousands of websites.  Some did great with the search engines, many didn't do well. 

SEO was never our MO, instead we hoped content-rich websites would make the search engine love fall down like rain.  In some cases it worked. 

However, we realized we had to figure out what helps Google's software.    As Kramer said, "I'm watching the watchers, Jerry!!", we too have learned to figure out what Google likes and what Google hates.

Here are some guidelines for Google.  (Not sure about the other engines - I hope they all just copy Google.) These are not "tricks" -  just a method that helps in Google's PageRank.

1. Page title should be unique to each page and should be like a headline.

Example: BrettFavre.com/I-am-the-greatest-of-all-time.htm

2. Use <h1> tags near the top of the page, for the page headline and be unique to each page. 

Example: The page title and the <h1> headline for this page should be both "SEO basics for folks who are SEO averse"

3. URLs should be unique to each page, be the headline and use dashes (not underscores) between each word.  (Dashes are very good, btw).

Example: See #1 above. 

4. More content.  Obviously the more "keywords" in the content, the better.

5. This is a good one: when possible, the page title, url and <h1> should all be the same or very similar.

6. Use a <h2> paragraph to summarize that page's content, article, etc. It should go right under the <h1>

Example: "Here are a few, basic, often neglected SEO tips to remember."

7. Change content frequently.

8. If you sell links on your site, use the "no follow" attribute within the <a href> links.  It's this: rel="nofollow"

9.  Use Google's webmaster resources and sitemaps (Yahoo and MS have sitemaps programs, too). Link below. 

10. Keep track of Google's "ranking factors". 

UPDATE:

11. Metatags...

We didn't talk about meta tags.  They are important, though not as important as they used to be.

Just remember that the MTs should be unique on each page, both keywords and description.  They should sync with the page title and the h1/h2.

12. This just in...

Seems like Google (currently) really likes the combination of title, url and H1 to be very similar.    

Links:

Google webmaster

About google page rank

Google ranking factors

The new RSS Importing is now functional.  I'm using it on my site with Twitter, Delicious and Flickr feeds.

This is the first step in our "importing" project.  The goal is to enable Feed.Us customers to use Feed.Us without visiting Feed.Us.

We hope that our customers can assemble sites from a variety of sources.  I think the big use is to allow writers to publish via their own favorite source, and then send an RSS feed to their editors.  

(Next, we're going to do email importing, like Flickr.   Metaweblog synching will come as well. Metaweblog will be really cool because you could 'pull' content from a variety of different CMSes and Blog systems, or use a variety of different publishing applications.  Then assemble and syndicate all that stuff to wherever you want.)

There are few tweaks left (not bugs, tweaks) on this RSS stuff, but email me for info/suggestions/help. 

Update 1: The only problem I see, right now, is that Twitter seems to put the entire tweet in both the headline and the body of the RSS. Weird.

Update 2: I just saw that Tumblr got funding. Tumblr is a really neat blogging tool.  Basically it lets you 'reblog' all the stuff you create in other places, using RSS, and assemble it on one Tumblr blog website.Try it out.

 That's the new RSS import page, via our dev site. Click on the image and you'll go to the Flickr page with a better view. This is setup so that you can take RSS feeds from your other sources (Flickr photos or Twitter accounts or Google Blogger rss) and have them show up within your site(s) as individual posts.  This is great if you have a ton of content in different places and you want to combine it all in one site.

But why we're really doing it... is so that you don't have to use Feed.Us to use Feed.Us.  Your writers might like Blogger or Typepad.  Then they give you an RSS feed of their writings and you can add their content to your site or to other sites.

Yes, Tumblr does this... Tumblr is very very nice.  However,  Tumblr isn't a professional solution.  It doesn't let you manage your content on your own servers, multiple sites, etc.

Over the past few weeks, I've experimented with the contextual ad networks.  I've just gone back and forth between Google Adsense and Yahoo Publisher's Network.  In my experience, Google is way better.  However, there's a reason to use both networks - and you probably won't guess why.

Both networks work the same.  The only difference that I noticed is that Yahoo doesn't offer "link units" - while the Google ones do quite well for me. It may be because they look like a navigation.

(One note: it's against the TOS to use both ad networks on the same site.  And your limit is 3 ad units, and one link unit.)

In my segment, travel, Google does way better than Yahoo.  I'm told that it depends on the type of content.  There seem to be way more advertisers in Google.  Yahoo seems to have a smaller number of advertisers. That makes sense to me - Google is the leader and has been around longer.

The per click ad rate is also better in google (although it seems to have declined quite a bit over the last six months).

From an advertiser's perspective, I would be using Yahoo more.  They have a ton of traffic and they own more content.  But there is less competition for that traffic - advertisers have got to get better rates at Yahoo (I should test it out). Of course, Google has way more search traffic, that's the advantage with Google).

So why switch over to Yahoo YPN?  This is where it gets interesting.  

When you add Google Adsense or Yahoo YPN ads to your site, Google and Yahoo (and Microsoft) force their search engines to re-cache your site.  They use the caching to display relevant ads to your site.

They also have a tendency to display your site higher in the rankings.  This makes sense - they want to send more traffic to your site, improve your ad results, and make more traffic.

So yes, you move over to Yahoo and you reduce your per click rate.  However, you'll get a bump in traffic (about double, I've found) when your site hits the cache.

Once your site is cached, the ads will start to make sense.  That's when you know you can switch back.  I believe if you keep it over at Yahoo for a while (a month?), when you switch back to Google, Google will re-cache you.  (I am not sure about this one... it's an assumption.)

This isn't going to make our break your ability to make money via content.  But it's important to keep in mind that you should be trying out all the different systems from time to time. 

Feed.Us was made to work on any servers - especially cheap hosting. 

Feed.Us works by using a local directory setup for read, write and web access.  Here is how to setup the directory in Godaddy's Windows/asp/asp.net hosting to work with Feed.Us:

1. Login to the main Godaddy login.  (Godaddy is confusing.  There are separate logins for everything.  Just start at the homepage.)

2. Select 'My Hosting Account' under 'Hosting & Servers'.

3. Choose the hosting plan that you're going to setup with Feed.Us.  Click 'Open'.

4.  On the resulting page, go to the 'Content' tab and select "IIS management" (formerly "Directory Management").

5.  Click "Create Directory".

6.  Type "CachedWebContent" and select "read", "write" and "web"  permissions.

7. Click Continue, and then confirm your choices.

8. Takes about 10 minutes to setup on Godaddy's end. 

Check out the following video:

This is part 1 of a 3 part post regarding making money with domains.  It's for folks who own domains and the domain just sit there in your godaddy/netsol/register.com account.  

I'm also going to discuss my experience with the contextual ad networks (read: Adsense), in part 2. Part 3 will be about maximizing clicks and then ecommerce in part 4.

(Note: I suggest AssociatedContent.com or even Squidoo.com if you are looking to make money quickly with web content.  Feed.Us is a content management platform that works on your own domain and hosting.)

Background:

Back when Adwords & Adsense were new (2003?), our customers looked to us for guidance about these new services.  In order to learn,  I bought some domains and built a few web travel guides.  I purchased traffic on Adwords and then monetized the traffic using Adsense. 

I learned quickly that "news" sites don't make many 'clicks' with Adsense.  But 'how to' type sites do quite well.  So I started to make money on sites like: VisitTortola.com.

Making some cash: 

At the start I was making a couple bucks per day in profit.  At the height of the deal, with 40+ sites, I was doing about $1000 and spending $600 in Adwords (per month).  Over time, there has been a general decline in adsense revenue.

Why the decline?  I believe that Google and Google's customers are getting savvier about their keyword buying. Additional factors could be:  type-in traffic has declined overall on the web, everyone is better with SEO now, Google has not changed their algorithms in a while, seasonality. 

But mainly people have learned how to buy traffic cheaper.

Some tips if you are considering monetizing your domains:

1) Choose a revenue-driving topics.  

Your content and domain need to be in a category that drives revenue.  Politics doesn't pay.  Writing about your pets is not going to pay.  Some categories that do well?

Travel, especially expensive destinations.  Home Improvement (design, fix a roof, etc). Automotive (not car reviews, how to fix things). Finance (Mortgage related ads used to be money, probably not as much now).  Lawsuit (not much traffic but high per click prices).  Wellness (drug-related sites are huge, disease probably do great).

Bottom line: domains that like hilaryvsrudy.com are not going to make any money with Adsense (Sorry Andrew).  


2) There's no free lunch

Your efforts have to be genuine. You can't just slap some ads on a domain. You can't just  "domain park" it and retire.  It takes effort.

If you focus on making a property that is valuable to someone, you can make money.  But it has to be genuine --  not a trick.

3.) You can't give them everything.

Now for the sad part: if you do too good of a job, visitors won't click on ads.  If you provide just enough information, your customers will be more inclined to click on ads.

(I know, it's sad.

4.) Less links.  

Put as few links on your page.  Basically the only clickable options should the ads from Google or Yahoo.  Again, another sad reality.  You can't make a really functionable site.

The links should also blend into the content as much as possible.  I'll talk about this more on PArt 2.

5.) Other kinds of ads.

If you're making money via adsense, don't try to use other kinds of adnetworks.  For a long time we tried to sell hotel rooms via Hotel.com's ad network.  I think it just took clicks away from Adsense.

6.) Updated content.  Google likes refreshed content.  Keep adding and tweaking and editing.  

7.) Google News.  If you can get your site into google news and then publish often, you're money.  It's hard to get into Google news, but if you do, it's a traffic gold mine.  If you're publishing in a category that gets high price per click - you may be able to quit your day job.

Stay tuned for Part 2 because I'll talk about contextual ad networks (like Yahoo YPN, Adsense, etc).

We haven't posted to the FeedUsBlog in over a week, so here's a quick summary of what's coming up:

Feed.Us "sections" update is in "dev" mode and being tested internally.  We're using it to make calendars and recipe pages.  We've got a few more things to finish up so it will be a few weeks before it's live on the 'normal' Feed.Us system.

Meanwhile the "RSS Import" update should be wrapped up by next week.  We hope to have our beta customers trying this out.  (If you'd like to 'beta' Feed.Us, just email me).

Finally, I've been testing the different pay-per-click ad networks on my group of sites (Microsoft, Yahoo Publishers Network and Adsense).  I am going to publish some thoughts and findings this week, here on this blog.

Later!
- Rick Stratton

One of our last large projects, before Feed.Us, was to create an ad network for a medium sized daily newspaper.  Our original intention was to integrate an existing ad system for the customer.

The customer had advertisers and ads lined-up, ready to go.  Just wanted to serve these ads. 

Unfortunately there aren't many options.  Here's what we found...

Google Adsense, Yahoo Publisher Network, Quigo, etc...

These are all Advertising Networks. Emphasis on NETWORK.  Their business is selling ads.  They don't care about people who already have ads and advertisers.  (We well rate the different networks via an upcoming post).

Basically if you've got ads and advertisers (and you need to get those ad(s) on your site) your options are somewhat limited.  

OpenAds:  Great news, the open source advertising system "Open ads" (which used to be PHPadsNew) has raised a bunch of money recently and they seem to be making an effort to get organized.   Also good news - lots and lots of sites run Openads. 

Now for the bad news... Open ads, like most open source projects, is complicated, doesn't have a great amount of documentation.  You can't add Open ads like it's Adsense (copy/paste), you're gonna need someone who is a decent level developer to set this up on your site (my $.02 is a $40k or higher type person).  You're also going to have to have someone with a technical ability to run the system as well.  It's also going to take at least 2 weeks (50-80 hours) of development to get it to really work on your site. 

On the plus side, they've got most of the options you're going to want.  It'll just take some work to get it.

Doubleclick or Doubleclick provider:  Great News, again.  Doubleclick is the industry standard that all the big guys use to serve their ads.  New York Times, Wall Street Journal.  It's got anything and everything you'd want.  Your advertisers will get great analysis, etc. You can tap into their network when you've run out of your own ads.  

Bad news, of course.  You're going to need to be huge (like 20 million impressions) to be able to work with Doubleclick.  If you're a tad smaller (Say 10million impressions) you can work with a reseller (like Operative).

Doubleclick warns that it will take up to 10 business days to setup, even on their end.  We have no clue what they have to do on their end.  Also, it's not copy/paste on your end.  You'll need a developer.  And your sales folks WILL NOT be able to run this bad boy - you'll need to get someone trained specifically on how to post ads.

DC was built like 10 years ago and it's my feeling that they haven't upgraded to modern systems since then.  Hopefully Google's purchase will help them get updated to where a person with normal abilities can add their ad system to a site.  

We also hope that Google/Doubleclick builds an ad serving system "for the rest of us".  We'll  be waiting.

How does Feed.Us work with Ads?

Feed.Us can work easily alongside any kind of ad system or network.  We're also hoping that our customers will manage ads like they'd manage other web content.  Writers submit articles or reviews.  Advertisers submit their own ads.  That's the way we think Feed.Us will work with ads - so your advertisers can add/edit their own ads like it's their own content. And of course across all of your sites, if you have more than one. 

We, here at Feed.Us, have been making web publishing applications since the "glorious" 1990s.  

Back in 1998-2000, it was at Guitar.com.  We hosted the world's guitarists and gave them a place to learn, share and connect.  Sadly, it's gone.  (Some day it will rise again!)

From 2001-2006, we made customized publishing applications for the customers of 1871 Media. 1871 is now uxCast, LLC and has one of the best ecommerce systems on the planet (if we do say so our selves).

The benefits of our 10 years of experience is that we have an understanding of the kinds of "stuff" that our customers want to put on their websites.  We built dozens of different kinds of applications from polls and email newsletter mail systems to shopping carts and banner ad serving.   

What's the point?

The future is now and you don't need someone to custom make you some sort of application.  Whatever you want to do, there's a developer out there making an application for you.  

You need a little flexibility, how to use a javascript, and have access to your site and be able to use the "control p" keys (aka paste).  

Here's my list of website "plugin" applications (so far)...

> Email newsletter and RSS: Feedburner.com
> Polls, surveys and quizes: Quibblo.com
> Comments/discussion: Disqus.com
> Email newsletters: Feedblitz.com
> Donations, shopping cart: Google Checkout (or paypal)
> Ads: Adsense, Yahoo, Adpinion.com , Adbrite.com
> Search: Lijit.com, Google Co-op.
> Discussion, texting, community: Twitter.com, MyBlogLog.com
> Photogallery: Flickr.com
> Music Player: Streampad
> Video player: Brightcove.com
> Avitar: voki.com
> Site discussion: MeeboMe.com

What am I missing?  Please reply and let me know.

CSS is a little scary,  whether you're a html monkey or a designer.  (There are no tables! Ahhh!).

But, you should learn to love CSS. 

(To be technical, CSS can be used on other types of documents besides HTML.  I'm specifically talking about CSS and xHTML.)

First some background:  CSS means "cascading style sheets".  CSS is like HTML version 2. xHTML and CSS has been recommended by the WC3 since 1998, yet it's still not the norm on the Web.  Why? Probably because we fear change. 

Your xhtml webpages reference one CSS file for the style - the way everything looks:  Font, background colors, amount of space, etc .  You can modify one/hundreds/thousands of pages by changing just one item in the CSS.  Say one day you want all the text in the main body of your site should to be a dark gray. The next day you can change it to red - on every page - all via the CSS file. 

I've simplified, but if you want to learn CSS, I'd probably recommend CSS for Dummies. It's written for all levels -  not just for dummies. 

If you're a designer, you should love CSS.

So why should you love CSS?  I've always avoided coding.  I can make tables etc... but I've always left the heavy stuff to the experts.  CSS lets me do just about everything.  Because I don't have to really know CSS in order to use it, I just understand it.    

I get by using CSS templates from other people.  I purchase them online or even download free ones.  (See list below.)  When there's a big project and I need to create something from scratch, I'll design a few pages in Photoshop, and then use a "Slicer" service to "chop" my design into CSS.  (We use the Choppr.) 

You could probably do a layout in powerpoint or in Word, and they'd probably be able to turn your sketches into CSS. 

CSS on Feed.Us: 

Feed.Us was made to work with CSS/xHtml so I've been using CSS templates a ton since we started testing. Feed.Us will work with HTML sites, but we built it to work with the CSS/xHTML div tags.  

So don't be afraid.  Embrace it asap.  You'll be happy you did.

Links (Please comment if you have others.)

Learning:
> CSS tips: http://htmlhelp.com/reference/css/
> CSS Zen Garden: http://csszengarden.com

Layouts:
> Arcsin templates: http://templates.arcsin.se/
> Very bare CSS files: http://www.code-sucks.com/css%20layouts/
> Free CSS templates: http://www.freecsstemplates.org/
> Template monster

Slicing/Chopping services:
> The Choppr
> Most Sliced

Coding:
> Firebug
> CSS Fly

Back in the day, say 2000 or 2001, you could garner a pretty good audience with an email newsletter.  You could create a newsletter, ask people to join and folks would. And they'd read it.  And they'd click on ads.  Marketers wanted HUGE lists.  They even spammed people (everyone did it back in the day). 

Those days are long gone.  You cannot spam people - actually you never could, but nowadays you get in trouble for it, thankfully.  And worse - few people actually read even the newsletters that they actually used to want (it's call "bacn", btw).  The nice thing is that doing an HTML newsletter back in the day was a major pain.  Nowadays it's not as important and technology has advanced, so you don't have to spend much time.

You STILL want to do an email newsletter?

Here's how I would do it. Before I start, remember these two things:

> Permission.  Let them get you the way they want to.  That means email newsletter, but also RSS feeds, your site, Twitter.com, the way they want to be reached, not the way you want to reach them.   i.e. Don't interrupt your audience.

> Short.  Don't write a book.

Doing a html newsletter with Feed.Us: 

If you had Feed.Us (you can't yet, but soon!) you could quickly add email and RSS capabilities.  Make a category for your RSS and email posts.  This could also be your blog posts, that's what we do with the FeedUsBlog.  Then make an RSS feed with Feed.Us's simple RSS tool. 

What is RSS?  Read here.  

Do a html newsletter without Feed.Us:

If you don't have Feed.Us, don't worry.  Yes, Feed.Us is great, but there are other options. 

Have your programmer make an RSS feed out of whatever CMS you're using.  If you don't have a CMS (or a programmer!)  then you can also use one of the free/cheap blog systems to publish and create an RSS feed.  Examples: Blogger or Typepad.  These services have an RSS option (but it's not built in to the system like Feed.Us!).  

You've got an RSS feed for your newsletter: 

Once you've got an RSS feed, you've getting close.  The first option is to make sure folks can sign up on your website for your RSS feed.  You can make a simple link to the RSS url and most people can figure that out.  

However, we always use Feedburner because FB makes everything very easy.  They give you some code to copy/paste on your site that allows folks to subscribe to your RSS feed easily.  Get your RSS feed using Feedburner's services here.

Guess what? Feedburner also has email newsletter service(s) built in.  Once your RSS feed is rocking in Feedburner, you can use Feedburner to sign-up for three different email newsletter services.  They've got their own service, which is sufficient.  But they also have FeedBlitz and RMail built in.  

I've got one setup for the FeedusBlog.  Every morning, after we've added a new post to the FeedusBlog... Feedburner sends out a newsletter to all of our subscribers.  I don't actually do anything... that's the way I like it.  I've spent countless hours sending newsletters in the past, that was back when we had like 30% readership.  Now you're lucky to have 5%. 

FeedBlitz has some nicer qualities than Feedburner.  So if you want to do more with your newsletter, check them out.   

Additional tip: use Feedburner's "Headline Animator" to display your newsletter content on other people's websites.  

Have an additional tip?  Add it via the comments, here. 

Update: I forgot to add one thing... remember that folks with Blackberries (Blackberrys?) enjoy reading HTML emails on their device.  This is an audience that would actually like to read your newsletter.  However, most HTML email newsletter are heavy on the HTML and thus look terrible in a Blackberry, which is a very basic email viewer.  I think that Feedburner's emails look pretty good on a Blackberry. But the BIG email providers (Constant Contact) look horrible. Whatever email system you go with - test it on a Blackberry. 

Below is a description of how to add web video to your site, blog etc when you're using Feed.Us.  I originally wrote this piece to help out an old customer who was new to making web video.  I thought it would be helpful if I re-wrote it including the Feed.Us steps.   

First an overview of creating/hosting a web video:  

Now get it on your site using Feed.Us:

With Feed.Us, you setup categories for all the different parts of your site(s).  For most folks, they'll be adding videos into an existing part of their website.  However, you could setup a separate category for 'Video' and put the video embed codes (described above) in their own category.  If you're using our "sections" (longer description coming soon), you can actually setup video specific  fields so that it's much easier than what I'm about to describe. 

But lets assume that you're uploading it into a 'normal' news or blog type page.  That means you've got the body of your page in the "full description" field.  Compose a 'new' article.  Give it a name, add a quick summary, choose an author.  Then in the "full description" field, put in any text that you're going to run around the video.  

One of the really cool parts about Feed.Us is the roll of RSS.

Once we launch it, Feed.Us will probably be the quickest/easiest way to create an RSS feed (if you don't have a Phil Plencner around).

Feed.Us started life as RSSCMS.com.  It was a quick and dirty way to make a feed, add news and then burn the Feed into Feedburner.   It worked fine. 

But then we started using Javascripts and using RSS CMS as a website publishing tool.  It was so easy that we started to think about it seriously.  

So now Feed.Us uses XML instead of RSS and has a variety of options besides javascripts (RSS, XML feed, javascript, XML&SOAP, our PHP/ASP web service).   But you'll still be able to make an RSS feed for any category (like tags) within seconds.

The other thing we're adding is the ability to import via RSS.  We don't really want force your writers to use Feed.Us as a composition tool.  If they like Typepad, they can publish via the RSS feed out of Typepad.  

So RSS goes in and RSS goes out.  

We are about to put the finishing touches on our "sections" update. 

But meanwhile, Welborn did an upgrade on Feed.Us' CSS.   The new layout screenshot is to the right (click to enlarge).

All of Feed.Us' frontend (where you'd go to manage sites, get the scripts, etc) is all via div xhtml/CSS.

So if your customers don't like the way our layout looks, you can upload your own CSS and change the whole thing around.  

Kinda like CSS Zen Garden.   CSS/xhtml is pretty amazing.   

We spoke with a hosting company CEO last week.  He told us, "I can't compete with Godaddy."  He charges between $10-$15 per month.  Godaddy charges about $4 per month for the same options.  It's hard to compete with the likes of Godaddy and Yahoo and the other big hosting companies.

One of the reasons we started making Feed.Us is that there's tons of cheap hosting out there yet most CMS applications can't run on Godaddy or Yahoo, etc... you need custom hardware or software that won't run on normal, basic hosting.  Not to mention that the developer probably wants you to pay him $50 per month just to host the site with her.

With Feed.Us, all you need is to be able to run php or asp pages on a site. You don't even need mySQL.

One of our beta sites is doing about 25,000 uniques per month on Godaddy hosting.  It's only $4 per month via godaddy and with Feed.Us only utilizes .01% of the disk space and .02% of the 250000.00 MB bandwidth allotment.

Thanks to the folks at Disqus... any site can now have a blog.

Disqus' comment system works with a simple Javascript.  It's insanely easy to add comments to your Feed.Us-powered site. 

See the comments below.  Nice work Disqus! 

For the past couple months, we've been hard at work at one of the last "beta" upgrades on Feed.Us.  Once we get this one out there, we're going to start opening Feed.Us up.  (We'll also have to get some real servers in a real hosting facility).

We call this new upgrade: sections.

There are two meaningful advances with Feed.Us.  I've talked about the first one, many times (i.e. feed.us makes it really easy to add our software to any website hosted anywhere).

The second advance is sections.  "Sections" refers to the sections of a typical website: Products, News, About, Contact, Calendar, etc.  Each section generally refer to different kinds of content.

"News" typically is either press releases or media articles about  the organization.  News uses typical RSS fields for the content: title, maybe a summary, body, links, etc.

News is also very similar to blog content.  If you've worked with Moveable Type or Wordpress, you recognize these fields above.  

Also if you've worked seriously with MT or WP, you realize that when you bend MT or WP to fit non-"news" type content onto a site, it gets hairy.  Example: have you ever tried to do an event calendar with MT?

Currently Feed.Us handles News-type content.  But with our upcoming "sections", we're now branching out so that we can store just about any of the fields of data/content that our customers might need.

Examples: Product length, event start date, address, last name, pet's name, mother maiden name, first girlfriend, end time, address 2, cooking time, ingredients, cell phone number, etc, etc.

Our hope is that advanced users of Feed.Us can combine different fields into their own CMS applications, hosted on Feed.Us.  Their users can add/store any kind of data with ease. And then developers can easily display that data on any site hosted anywhere.

Again, if you're interested in trying out Feed.Us, contact me at rick at feed dot us.

As of Friday, August 17, Feed.Us is now being utilized as the CMS on over 40 websites.  It reaches approximately 10,000 unique users every day.

All via one server sitting in a basement.

We've built Feed.Us in such a way that it can handle any amount of traffic that your web host can handle.  

And if Feed.Us were to go down - your site would be unaffected. 

Late this summer we'll get Feed.Us off the dryer and moved over to a real hosting company.  

But for the time being, it's pretty fun to say: "Feed.Us is in the basement".

Feed.Us is currently live on over 40 websites.  We run several networks of sites that mostly make money via advertising.  We also occasionally help out our friends.  Here's a sampling:

www.InnerControlGolf.com

www.TurtleCreekOnTheParkway.com

www.VisitTortola.com

Contact Rubber Corp

Caribbean Travel News

The Caribbean Search Engine

StBartsTourist.com

Visit Anguilla 

Ben Smith, out in Boston, said:

"Why do I need to learn to be a programmer in order to install Drupal or Wordpress?"

That's a good question, Ben.

Here's a comparison of Feed.Us setup versus the major blog systems.  Remember - with Feed.Us there's nothing to download, unzip, etc.  It's completely hosted.

Install Feed.Us:

1. On your server, your hosting company's "control panel", setup a new "directory" called CachedWebContent.  Give it read, write and web access.  (We have instructions for the major hosting cos.)

2. Upload the "grabber" file.  Just one file that gets ftped to your server, hosting etc.

3. Plug in the 2 lines of code whereever you want the content to flow. 

Compare to Wordpress:

Compare to MoveableType:

Compare to Drupal:

 I'm sorry.  I would have put the full setup directions for Drupal, Wordpress and MT, but it's just too long of a process.

We've avoided adding any kind of comments system to Feed.Us.  It's not really a blog system (though it works great as one) it's more of a CMS or web publishing app then just a simple blog system.

But comment-type activity is really unavoidable in our future and we hope to make a really smart comment-like interaction manager that works within Feed.Us.  But that's a different post for a different time.

We are currently watching two new blog comment startups.  They are both javascript-based systems (at least I hope they are). They are:

> Disqus 

> Intense Debate

We hope they will be able to just "plug" right into a site that uses Feed.us.   

If you have a different suggestion - email me at rick at feed dot us.  (Or use the new Meebome chat widget along the right there!)

We created Feed.Us so that non-technical users can quickly manage/edit/add to/control the content that sits on a website, in a blog, on a web calendar, etc.

Examples:

> Customer service folks want to add/edit the FAQ section of your site. 

> Sales guy wants to update the product pages.

> PR firm wants to update the press release area of the site.

> Events Coordinator wants to publish the calenar.

Feed Them:

So you "plug in" Feed.us scripts into the approiate places on the site and upload the "Grabber" file to your server (see below for more info).  

Then give a login and password to your folks and they can add/edit using a simple web form that looks like this:

We're also working on other ways to import posts... from RSS, email, etc. 

Feed.us doesn't use a javascript to put your content on your website(s). We started out with a javascript but quickly realized that Google can't spider a javascript. 

We made our own process for it.  It's like a javascript - kinda.

There's one file on your server (or your host's server). That's called the "Grabber".  The grabber downloads content for you.

Then you copy and paste 2 lines of code into any webpage.  That code tells the grabber file what to display.  The code looks like this:

That's it.  

"Being a tech company means you aspire to be a platform, a layer in the stack that others can build on."
- Founder of Facebook.com, Mark Zuckerberg

Feed.Us started as "RSSCMS.com" (which still lives here). 

We were getting asked to make tons of RSS feeds by our political customers in late 2004, early 2005.  So we made a quick RSS feed tool that people could use to quickly create a feed, add some news items and give the feed to Feedburner.

It worked fine.  Then we started messing around with javascripts to display the feeds on websites.

That made is realize that we had a cool, lightweight CMS.  

However, RSS and javascripts have their shortcomings:

RSS has specific fields: title, url, author, date, and body.  What about event data?  Addresses?  Doesn't reall fit well in RSS (we know there's geo-RSS).

Meanwhile, javascripts have a huge downfall: Google can't read them.  They run on the "client" and google's spiders can't spider through them.

So we decided to start from scratch and make a whole new product, using XML and a variety of APIs.  

But the concept is the same: simple, lightweight, hosted content management/website publishing system.  

We generally have trouble telling people what Feed.Us is/does. 

Here's a good description: 

Elevator pitch: "Remote web page management" or "content management web service". 

Longer...  

It's a Web Publishing application that works like a Widget. No need to download or host Feed.Us locally.  Copy/paste a few simple scripts to any web page hosted any where and you can quickly/easily use Feed.Us to put text, images, audio, video etc on a website  remotely - without knowing any coding, or using ftp, etc.

It's like a blog software - similar to Wordpress or Moveable Type.  Except there's nothing to download.  Instead of forcing the design into your blogging software - you simply add some javascript-like scripts into the spot where you want the content to flow.

But there's more than that.  It can publish to multiple sites from one account.  Or store your content all in one location.  Collaborate with others on Website(s).   Make RSS feeds on the fly.  Make a feed of display or text ads that can run on any Website.  

If you'd like to try it - please let me know. rick at feed dot us.