| LED Digest 2233: The WYSIWYG Debate |
|
|
|
A debate is evolving between the "hand coding" camp and the WYSIWYG
camp, yet voices are appearing in the middle. Each tool has strengths...
==================================================
======== CONTINUING ===============================The LED Digest Moderated Discussion List "Effective Online Advertising, Since 1997" Data > Information > Knowledge > Wisdom pair Networks: The LED's Web Host Hosting and Domain Registration from a Trusted Leader pair.com for Hosting | pairNIC.com for Domains ================================================== List Moderator: Published by: Adam Audette LED Digest adam, led-digest.com http://www.led-digest.com ............................................. August 25, 2006 Issue no. 2233 ............................................. .....IN THIS DIGEST..... ==== CONTINUING ================= --== HTML Editor Recommendations ==-- ~ Phil Chave "...page size, for the majority of users, isn't an issue anymore." ~ Rick Gortatowsky "...WYSIWYG editors are exceptional mechanisms for general site design." ~ John Smart "I had never heard that nested tables would upset search engines before." --== The Click Fraud Problem, Part II ==-- ~ David Yancey "...the fast-growing SEM industry has apparently awakened to the huge threat of clickfraud..." ==== BILLBOARD =================== --== .htaccess and Rewrite ==-- ~ Cheryl Berry From: Phil Chave Subject: HTML editors Hi All I think the stated worries about load times and extraneous code are a bit academic now that broadband is here with a vengeance. In the days of dial up, I would keep code to it's minimum and that meant learning HTML, and using cuteHTML or UltraEdit32 to play with it. But I too ended up building sites for clients who wanted to do their own updates etc. and use FrontPage to do it. This invariably meant that the phone would go when FrontPage took my perfectly good code and rewrote it without asking, resulting in the page looking for images, not on the server, but on the clients computer. Even when it didn't do that, there'd be more div and   tags than you could shake a stick at, and a 30kb page of text would suddenly bloat to 80kb for no reason. And this is all achieved by simply opening and closing the document, whether you make any changes or not. I guess the point is, use which editor you find easiest to learn and use, because page size, for the majority of users, and rising, isn't an issue anymore. If you stick to the rules about stating image sizes in the link, all browsers make room prior to its arrival and displays the text around it first, therefore the page isn't held up for the user even if it is rather large. Regards Phil Chave (Blagdon, UK) -------- new post - same topic -------- From: Rick Gortatowsky Subject: HTML editors > There is a time and a place for hand coding. A lot > of scripts (php, asp, etc) create tables based on the > data they get from a database. When you are writing > this sort of code, life is so much easier if you can hand code. - John Smart, LED 2231 Ah! A voice that actually makes sense! I am a developer and have been a software engineer since I was 19, I am now 44. I am versed in Intel Assembler, C#, C++, VB, ASP, PHP, PERL and more... yes even HTML. For MANY sites hand coding is simply ridiculous unless one has lots of time on their hands I suppose. Irregardless of that the WYSIWYG editors are exceptional mechanisms for general site design. I can design a base template of a site faster in a WYSIWYG editor before even the best of HTML coders can get any significant portion done in HTML by hand. For anyone (obviously many have not) who has used Visual Studio 2005 would be saying, "What a nice environment" as Microsoft has integrated Web Applications quite nicely into the overall picture that is now VS 2005. If two firms were given same projects and one firm wishes to hand code, the other uses VS 2005 I can guarantee you that the client is going to not only get their site A LOT sooner but also actually have a MAINTAINABLE application. Hand coders dont like talk about that, maintainable yet it is one of the most important facets of computing in todays world. Saying it's BEST to hand code HTML ALWAYS is like saying, "Never use a C Compiler but instead all applications should be written in assembler". Compilers resultant output object code is often inefficient and prone with baloney not applicable to an application. A hand tuned assembly language application is usually 500++% faster than the comparable results of a compiler. Usually literally night and day. However, the development curve is MUCH longer and the maintainability is simply gruesome in comparision. John Smart is smart. He is 101% correct that everything has its place, purpose and proper usage for given tasks. Certainly WYSIWYG web editors are at times a hindering factor in certain types of webs just as Assembler code is seldom the proper choice except in functions that require fastest speed and efficiency. For the "would be" development firm who has time to fuddle about to make any web by hand, bless ya... I hope your paid well. For firms like ours that have more work than we know what to do with whats important is getting the work completed, working, maintainable and effective. Part issue in many of these types of discussions is what businesses think as businesses. If your "small business" is drawing less than 1 Million in actual revenues annually you are not classified as a "success" as far as small businesses go, in fact, your barely on the map. That's not "me" talking, that's the banks and Fed. We have and continue to do quite a bit of work for banks and collections units, lots of database work. I am often amazed how many small businesses think they are really successful. The problem is that they never see what revenues a really successful small business generates which ranges 4-10 million dollars per year. It's not that said small businesses cannot make those amounts. What is different is the realization of what work to take and what not to take, where money is and where money is not. We do not run our business for the sake of "lets make some money". We run it as, "Lets make as much money as we can make" and that means selecting the right clients. Rick Gortatowsky TSS Inc. -------- new post - same topic -------- From: John Smart Subject: HTML editors > PHP does not create tables, HTML does, and > its power goes *far* beyond linking to databases. > I don't use ASP so I can't speak for that... - Mark Whitman, LED 2232 I should have phrased that: A lot of scripts (php, asp, etc) are used to create tables based on the data they get from a database. And whilst PHP ASP and others do a lot more than interact with SQL, it is a common use, and certainly in the context of the statement I would think that most php or asp created tables are done so to show database content. Nested tables should be avoided, not because of search engines, but because of load times - it looks to me that multiple nested tables take a long time to render (even on a high end PC with a high speed connection). Of course, nesting some tables is pretty hard to avoid on a complex page layout, I am talking about multiple nesting - a table in a table in a table etc. I had never heard that nested tables would upset search engines before. John Smart InternetDesign.com - A Human Touch in a Digital World -------- new post - new topic -------- From: David Yancey Subject: The Click Fraud Problem - Part II We should also correct another misconception, namely that the click-fraudsters are employing a zillion Indians or Chinese or impoverished Russians to pound their keyboards. Clickfraud is very likely 98% automated at this point. That means that if you give my baddies a chance to earn, say 10% of a PPC bid that averages just 40 cents, then I can probably clear at least 50% net per click. Figure only, say, 100,000 fraudulent, automated clicks per day, and I have an appreciable tax-free income if I happen to live in Romania or Brazil. Or Omaha, for that matter. Raise the average bid level to, say, $1.00, and I am making nearly two million bucks a year, untaxed profit. But some ask what is the motivation for some bad guys to pay the operators of click fraud networks to generate fraudulent clickthroughs? The answers are, again, detailed, and will vary somewhat depending on each industry, and, especially, on the prevailing keyword bid prices in the individual market sector. Most simply assume that the bad guys are trying to quickly consume the defrauded competitor's PPC budget, forcing them to spend more, and hence raising their costs. We are pretty sure this happened to us, since we are a brand new site and company, and can be presumed to have a minuscule PPC budget. Any competitor in our sector could quickly determine this, and also that our particular targeting approach and products are uniquely fresh and, according to our test shoppers, very appealing. So it makes sense to a dominating competitor to try and kill off our budget out of the gate. Like it or not, the PPC systems run by Google and Yahoo et al make this kind of counter-marketing easy. But actually, most clickfraud is probably much more subtle: the criminal company uses clickfraud to *drive the victim company's ads off the visible or upper end of the AdWords list on search pages*. The clever bad guys simply work the rules used by Google to determine which ads are the most "popular", to make sure the target company's ads don't show up at the most desirable times of day. It's really more about *positioning* the bad company's *own* ads, than simply trashing a competitor's ad budget: If I were a bad guy, I'd be only too happy to spend, say, an extra 15% or even more per click to *keep your and any other serious player's ads from.ever showing up in prime net time*. Plus, there is the very substantial pay-off: if I can zap your daily ad budget quickly, and drive you off the search pages, I can then *lower* my own bids, possibly even enough to pay *less* on average per clickthrough to my own site. It's called eating you and having your cake, too. In our case, and this must be true for many thousands of businesses, this seems to be the explanation. As a brand new small, but potentially major site in an intensely competitive sector, casual fashions and accessories, it seems certain that at least one major competing vendor went after us as soon as our Google Adwords ads began to place in the top 3-6 positions. We found that lowering the bid to move the ads down the right-side list significantly cut the level of fraudulent clicks. This lends credence to the presence of automation I described earlier. Our ads which measured highest in "pulling effectiveness" were the ones most targeted for fraudulent activity. Ads for more specialized, less pricey keyword phrases attracted less fraudulent activity, which makes sense for a number of reasons. As to Google's alleged ability to track fraudulent AdSense clicks, this too is a common misconception, I fear. Imagine for a moment the same sort of dynamically- rotated-IP-based clickfraud operation outlined above. Now, suppose I am a scam-prone "publisher" who has set up a few *thousand* cookie-cutter "web sites", and spread them over a few dozen or perhaps one hundred different AdSense accounts. If my cut of Google's revenue per paid click on these sites averages, say, just 10 cents, I'd be happy to split that with the clickfraudster guy, especially if our scam produced revenue from tens of thousands of virtually un-trackable clicks per day. If you doubt that there are hundreds or even thousands of these so-called "AdSense arbitrageurs" out there, don't take my word for it: read what one of the top ten SEM experts on the planet has to say: http://www.dmnews.com/cms/dm-opinion/columns/37863.preview Does this make *all* publishers who use AdSense bad guys? Of course not. But the great majority of mostly non-technical publishers out there may want to learn more about the nefarious operations of the few really slimy ones, since these bad guys seriously threaten the AdSense golden goose. (They also threaten the long-time future of Google and other crawler-based, PPC selling search sites, too, but that is another post...) This post is about the *probably inevitable percentage of waste in PPC campaigns due to clickfraud*, NOT about Google, or any other particular PPC operator. Still, I must comment on the issue of Google's and other leading PPC services' publicly-stated views on the relative prevalence of clickfraud. If it can be shown that from 20% to 40% or more of a search companies PPC revenues are of a (possibly criminally) anti-competitive nature, or are simply outright fraudulent, we'd expect that company to be nervous, right? We'd not be surprised when they try to buy off the potential fraud claimants with a $90 million dollar court settlement, for starters. We'd then assume they'd do everything possible want to stop clickfraud immediately. Well, it might seem so at first. But then, we have to think about the potentially massive sell-off in G's stock, along with the (less vulnerable) shares of Yahoo and MSoft, *if and when it can be demonstrated, then, the tough part, simply explained to lemming-like investors, that perhaps 50% of net PPC earnings are unsustainable in a truly mature interactive economy*. Finally, our experience with Google's PPC service is not that uncommon, apparently: the Search Engine Marketing Professional Organization (SEMPO) announced a major study of click fraud recently: http://snipurl.com/sempo [sempo.org] Along with Google and the PPC operators, the fast-growing SEM industry has apparently awakened (publicly at least) to the huge threat of clickfraud, and understandably doesn't relish having to explain to advertisers and marketers why perhaps 30%-50% of a given campaign's SEM budget is being wasted, or even stolen outright. Hmmm, I wonder if complicity in and funding of demonstrable fraud constitutes corporate mis-management or Board negligence... David Yancey Managing Partner -- 22Graphic -- http://www.tootoographic.com CEO -- Adjunction LLC -- http://www.vivante.com ==== BILLBOARD =================================== From: Cheryl Berry Subject: htaccess > Rewrite is a cool toy. I use it at internetdesign.com - the > whole site is completely dynamic, none of those pages > really exist! They are all database calls. Here is how I did it... - John Smart, LED 2232 Whew! You really ARE Smart, John ;-) I use includes and dynamically driven content and am always looking for new and innovative ways to engineer a site. This is a whole new animal, though. While some of this information is Greek to me (sorry if we have any Greeks in the group) some of it makes sense but not all - can you help? If pages are technically non-existent and viewable results can vary from person-to-person, bot-to-bot and slow vs. high speed connections, how do you (a) analyze the productiveness of a site that utilizes this engineering and (b) how do you receive top rank indexing without getting sited as a spam site? Aren't you after all, spoofing the bot? Is there some sort of standard for setting permissions on this file to lock it down if it's not being used and what are the security loopholes with htaccess? Thanks! Cheryl Berry
-------------------------------------------------------
The LED Digest is sponsored by pair Networks:
pair.com for Hosting | pairNIC.com for Domains
© Copyright 1995-2006 Orange Wheel, LLC. All Rights Reserved.
-----------------------------------------------------------------
"Carpe diem, quam minimum credula postero."
Lat. "seize the day, put no trust in tomorrow"
- Horace
|
