| LED Digest 1941: Creating HTML Ezines, also RSS |
|
|
|
================================================== The LED Digest Moderated Discussion List "Effective Online Advertising, Since 1997" pair Networks: The LED's Web Host Hosting and Domain Reg. from a Trusted Leader pair.com for Hosting | pairNIC.com for Domains ================================================== List Moderator: Published by: Adam Audette LED Digest This email address is being protected from spam bots, you need Javascript enabled to view it http://www.led-digest.com .............................................. March 8, 2005 Issue #1941 .............................................. .....IN THIS DIGEST..... ====== NEW ===================== --== Creating HTML Ezines ==-- ~ Sascha Hewitt "I'm interested to hear more of the nuts and bolts of how to build an HTML e-zine." ==== CONTINUING ================= --== Total Hours vs Billable Hours ==-- ~ Graham Brown "I would expect an employee to be able to turn in 1400 to 1600 paid hours per year." ~ Don Baker "22% seems awfully low for employees dedicated to client work rather than sales..." --== RSS Feeds, Spam, and The Future of Publishing ==-- ~ Steve Pronger "Distributing links (content, actually) between websites is just one application [of RSS]." ~ Tom Aman "I am writing this for all of those LEDers who are interested in the background [of RSS]..." ==== BILLBOARD =================== --== Blocking Email Forwarding ==-- ~ Kevin Decker --== Working with Framed Sites ==-- ~ Renee Kennedy ~ Daniel Crane ======== NEW ==================================== From: Sascha Hewitt Subject: How to create HTML ezines I'm interested to hear more of the nuts and bolts of how to build an HTML e-zine. Can anyone recommend sites that show how to do this. Do you build them in an HTML editor? What email programs will send them? I think Yahoo won't. Any tips appreciated. Sascha Hewitt http://naturalhealingcenter.com ===== CONTINUING ================================= From: Graham Brown Subject: Billable hours > Last year my crew of 2+ designers / programmers hit about > 22% of their total time worked as billable hours... I don't know > if that's good or bad. I don't expect anywhere near 100%, but > wondered if we couldn't do better too. - Brian Rideout, LED 1939 22% seems a bit low to me, but my experience with time recording is in a different field (professional advice) so I am not sure how it translates across. Assuming that the work is there to be done, I would expect an employee to be able to turn in 1400 to 1600 paid hours per year. 1,000 hours would be cause for concern. 22% is a figure that points to defective time recording or other problems. IMHO to be of maximum benefit, time records need to be completed and filed daily. If completed less frequently they have little merit as a billing or efficiency measuring tool. Graham Brown ------- new post - same topic -------- From: Don Baker Subject: Billable hours I can't tell you my own billable-time percentage off the top of my (pointy) head, but 22% seems awfully low for employees dedicated to client work rather than sales or CxO management functions. In the Internet world, I would think at least 50% should be billable, unless there's simply not enough client work to do -- then you either need more/better sales people, or need to change these folks from full-time employees to on-demand consultants. (In my old days of defense-industry consulting -- where the government determined the ridiculously low profit margin -- we non-mgmt types were expected to bill 80% or more of our time to client projects, or else.) My company uses the web-based ClickTime (http://www.clicktime.com) to track all our time, whether billable or non-billable. Not only can we track by client, job & task, but we add notes to our time and can run reports that provide excellent detail for planning purposes or to answer client questions. We track all of our non-billable hours in the same detailed fashion, to understand where our time is going. Having your folks describe their non-billable hours in detail for a couple of months might prove interesting. Don Baker, SEM Director NSI Partners www.nsipartners.com ------- new post - new topic -------- From: Steve Pronger Subject: RSS and more > RSS is a cheap way of distributing links > to other sites. Nothing more. - Michael Martinez, LED 1940 Don't agree. There is much more to RSS. Distributing links (content, actually) between websites is just one application. There are many others. > I still haven't fielded any requests for an RSS feed. - Martha Retallick, LED 1938 Not surprising. We are still in early-adopter stage and most publishers have not done a good job of educating their audience of the benefits. Heck, until about 3 weeks ago I had no idea what that little RSS icon meant. Most people wouldn't. But, if you are adopting a stance of "no one asks for it, therefore I don't need it" you should consider this; it's understood the next major overhaul of Internet Explorer will have RSS support built in. All of a sudden RSS will become mainstream. When your average web surfer discovers that they can click on that little icon and have the information they want delivered directly to their desktop, without giving their email address or any personal details, and without whitelisting or sorting that information from all the garbage that fills their inbox, they'll be hooked. How could they not? > Don't mistake every tool out there for a piece of gold. > It may only be another pick or shovel. - Michael Martinez, LED 1940 Wonder if someone once said that about email :-) Steve Pronger http://www.stevepronger.com ------- new post - same topic -------- From: Tom Aman Subject: RSS It is interesting that, that for something that is supposed to be "the greatest thing since sliced bread", that it is so difficult to find information that explains how RSS actually works at the "nuts and bolts" level. Even sites like "Fagan Finder - All About RSS" (http://www.faganfinder.com/search/rss.shtml) that are supposed to tell all about it don't get down to the underlying system. So I am writing this for all of those LEDers who are interested in the background and the "nuts and bolts" of how it all works. One comment that keeps appearing is that adding an RSS feed will dramatically increase your site traffic. Once you understand how it works you will see how that is almost guaranteed (although it is somewhat questionable as to whether those hits will actually represent page views by a live person!). Also, "feed" is a real misnomer. "Feed" would seem to mean that you are automatically sending (pushing) something to all subscribers. Not so!! You are just creating a document in XML that their software checks (pulls) periodically for changes (and each check = 1 hit). First, the meaning of RSS: it is variously defined as meaning "Really Simple Syndication" or "Rich Site Summary" or "RDF Site Summary". The original idea originated with an Apple employee in 1996 and was picked up by UserLand in 1997 (see http://rss.userland.com/) and subsequently was used by Netscape to fill channels for Netcenter. Originally RSS stood for "RDF Site Summary" (RDF is an XML based W3C standard meaning "Resource Description Framework"). In July 1999, Netscape changed it to mean "Rich Site Summary" and moved away from the RDF rules. They later just dropped the whole thing. I was not able to find out where the term "Really Simple Syndication" originated - my guess would be Userland again. See http://goatee.net/2003/rss-history.html for a more complete history. Various parties have been involved with the standards behind it and, at present, there are about 7 variations. There is also an alternate, but similar, format call Atom, created because some people felt they could do better than RSS allowed. Most readers will handle all of them. The basic mechanics involved to make it all work are really very simple: 1. A site (you) creates an XML document based on one of the standards. Among other things, this document will contain a title and description for the "channel" followed by one or more items. Each item will contain at least a title (headline), summary, and a link to a URL (ususally a web page) where the actual content appears. This XML document is saved to any location you like on your Web sever. There does not appear to be any standard as to the location or name to be used for it, and some sites may have more than one document (i.e more than one "channel"). 2. You place a link on one or more of your pages, usually in the form of a button displaying "RSS", "XML" or something similar to show that you have a "feed". The anchor tag for this link should be in the form <.a type="application/rss+xml" href="feed.rss">RSS feed for this page<./a> where "feed.rss" is replaced with the link to your XML document and "RSS feed for this page" is replaced with the button or any text you like. The important element in this link is the 'type="application/rss+xml"' since this is what aggregators need to recognize the "feed". 3. When a person wants to subscribe to your "feed", they use an "RSS aggregator", more commonly called an "RSS Reader". The reader will use the link described about to find the XML document then take the information in it and display that in readable form. There are also "public aggregators" that take the feeds from a multitude of sites and present the headlines, and sometimes the descriptions, in a single list for easy reference. 4. When something on your site changes, you change the XML document and all of the aggregators will pick up the change. To do this, the aggregator must visit your site periodically (once a week, once a day, once an hour, every 10 minutes - no standards for this) and check for changes by making a standard HTTP request for the XML document. Every request becomes another hit on your site. That is how the "guaranteed" traffic increase is created - if 100 people who leave their computers on 24 hours a day subscribe to your "feed" and set their readers to check every hour, you are guaranteed 2,400 "hits" every day. If you submit your "feed" to one or more of the public aggregators, you will get even more hits. But there is nothing there to guarantee that this will translate to actual page views. (If your site is third-party hosted and has bandwidth limitations you need to give really serious thought as to whether or not you want to have all these "checking for changes" hits or not.) A good tutorial on RSS can be found at http://www.mnot.net/rss/tutorial/ I hope the above info is helpful to all. Finally, I would like to add my own observations on RSS: 1. Seems to me that RSS is a solution looking for a problem. It makes something complicated that could have been easily handled within the existing HTTP / HTML protocol. In fact, the reader I have been testing will let me import my IE favorites and at the click of one button, check them all for updates. This does not require RSS and RSS does not seem to be any big improvement over this since the quality of "feeds" varies so widely. 2. Until such time as there is W3C standard, or at least an RFC aimed in this direction, there will be a variety of flavors of RSS and it will continue to be difficult to find details about it, particularly the internal functioning required of any client program that would make use of it. 3. The lack of real standards means that the quality of feeds varies widely. Worse, some of them are reported as updated every time I check, even though the last change was almost a month ago. Again, this is due to lack of standards regarding how everything should be done. A manually generated feed document will only appear as updated when it is actually changed while a dynamically generated document appears as updated every time it is checked. This is a function of the HTTP protocol since the "last-modified" date/time is always the current date / time for dynamically generated document while a static document retains the date / time it was actually last changed. Thus a request for a document "if modified-since" the last retrieval will return a simple "not modified" response for a static document if it has not changed but will always return the complete document if it is dynamically generated. ("dynamically" = via database, asp, php, etc.) 4. I can see the possibility of RSS becoming as bad a traffic generator as SPAM since all of the aggregators must check for updates at regular intervals. Consider that many sites have multiple feeds (e.g. the BBC has 68 at last report) and add to that all of the personal feeds and it adds up to a lot of traffic. A software review I read from one individual reads: "I have found a great product that is used to create RSS feeds. I have found it extremely useful, and worth while. I have created nearly 28 feeds already!" My first question is "Why???" While I can understand the 68 BBC feeds, I find it hard to believe that one individual actually needs 28 feeds from a personal site. Must be some kind of status symbol among his peers. 5. I downloaded and installed an RSS Reader and have tested RSS for over a month now. I am removing the software from my system as I find it more trouble than it is worth. Until it matures and some reasonable standards regarding updates are developed (such as how they should occur and how they should be displayed), it is more "nuisance" than "added value". The emailed newsletter, like LED digest, is still a much more effective and efficient use of my time. Tom Aman Aman Software http://www.cyberspyder.com ==== BILLBOARD =================================== From: Kevin Decker Subject: Mail Relay / Forward Blocking Arrghh! My ISP recently started blocking mail that is 'relayed' to them. For years I've been using the mail forward function with my various web hosting accounts and having all mail sent to the ISP account. This way I'm not trying to manage 9 mail accounts for 9 websites. Apparently one of my web hosts is not using a 'forward' function but instead is using a 'relay' function. The ISP says that they're reducing spam. The web host says sorry, forward (relay) to another email address. I feel like I'm stuck between the proverbial rock and a hard place. Anyone else having similar problems? Any recommendations? Kevin Decker We Help You Relate... www.romanticantics.com ------- new post - new topic ------- From: Renee Kennedy Subject: Frames > How do search engines feel about frames? - Nancy Cardinali, LED 1940 Frames are not search engine friendly unless you employ a few workarounds. First, you would need to make sure that you have a text link navigation on every page inside the frame. This will allow the search engines to follow your links within the frame (to crawl your site). However, this creates another problem. If the pages indexed by the search engine are inside a frame, then people coming in from search engines will only see the page and not the entire frame. (There are also solutions to this, as well, but it will require more programming - I work on a site that uses frames and it is highly successful in search engines, but it is also programmed in ASP and each page will call up the entire frame around it when people come in from the engines.) Second, make sure that you have keyword rich text and links within the "no frames" tag on your index page. Those are the basics, but if at all possible, I would get out of the frames altogether. That particular site looks like it needs a complete redesign anyway, so now is the opportunity to get away from frames. Renee Kennedy e-Healthcare Solutions, Inc. www.e-healthcaresolutions.com ------- new post - same topic -------- From: Daniel Crane Subject: Frames I checked out the site, much of it is simply a redirect from another site: http://stevekukla.bizland.com/index.htm This seems to be where most of the content lies. If you go to that site you can see all of the HTML in the source code. As far as search engines handle frames, you have to be very careful. If you do not set up frames correctly the spider may not be able to read the site properly. Also, some browsers have trouble displaying frames. I have done a little work with frames, but I do not recommend it, I suggest that you ditch the frames and do a total redesign with more search engine friendly code. Good Luck! Daniel Crane http://www.sensiblediet.net ------------------------------------------------------- The LED Digest is sponsored by pair Networks: pair.com for Hosting | pairNIC.com for Domains © Copyright 1995-2005 Orange Wheel, LLC. All Rights Reserved. ----------------------------------------------------------------- "We are unknown to ourselves, we men of knowledge..." - Friedrich Nietzsche |
