http://www.theworkingweb.com/ Written by Andreas Huttenrauch - Internet Strategy Consultant and Web Architect. Information on Specification development, Website design, project management, interface design, e-commerce, marketing, and general information to overall guarantee the success of your web project (or at least prevent it's failure). For larger-scale projects, you cannot afford not to plan - if you fail to plan, you plan to fail. Get clear on your requirements before you exponentially blow your budget on scope-creep and other unintended, unwanted, and avoidable circumstances. en-us http://www.theworkingweb.com/publicBlogDetail.php?id=38 Real time search is the hippest topic on the search marketing landscape right now. Here's a rundown of what it is and how you potentially could use it for your business. http://www.theworkingweb.com/publicBlogDetail.php?id=37 The FTP protocol (file transfer protocol) is used to send and retrieve files from remote servers. FTP is very old and was not designed with security in mind. Unfortunately with every FTP transaction, hackers can intercept your username and password. Recently there has also been a significant increase in PC-bourne spyware which collects this information and sends it to hackers. Thousands of websites on the Internet are compromised on a daily basis, which results not only in expensive recovery costs to the owners, but also major inconvenience. So why do people still use FTP? Actually that question is not easy to answer. I would hazard a guess that most still use FTP simply out of habit. Change takes effort, and if something worked in the past, there is always the expectation that it will continue to work until otherwise indicated. There is a very secure way to send and retrieve files from remote locations. To move files to a server, the SFTP (Secure FTP) protocol is preferred as your login credentials are encrypted, as are the files being sent. Basically what happens with SFTP is that first a secure tunnel is set up with SSH and then the FTP session happens inside of this tunnel transparently. Most FTP clients and website editors are able to communicate with a server using SFTP by simply changing a setting in your connection information to use SFTP instead of FTP. The interface doesn't change and the way the user performs their tasks does not change either. Since it's so simple to secure your file-based communications, why don't more people adopt this? Even better - the FTP protocol should simply be switched off at the server level. That would force people to use SFTP and eliminate a whole lot of hacking. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=36 The other day I got a call from a friend who was very concerned that their current web designer was taking the main business owner for a ride - taking advantage - etc. It appears that the web designer is way behind in schedule on delivery of the project. When I reviewed the delivery milestones with the prospect, it turned out to be an extremely simple project - one that could easily be produced and delivered in under 20 man-hours. A natural logical progression from where we had been, was to next move onto the subject of price. I couldn't believe what their web designer was charging for such a small project - almost double of what I would consider average and reasonable rates. And on top of this, the designer was weeks behind on schedule. So we started digging a little deeper. When we hit upon the real issue here, I was flabbergasted. It turns out that the web designer had to contract to third parties the HTML coding part of the project. If you're going to call yourself a web designer, then surely you should know HTML??? I've worked with plenty of graphic designers in the past that didn't know HTML, but they disclosed this right up-front, and called themselves graphic designers and not web designers. HTML is the entire BASIS of the Internet. I would feel very uncomfortable knowing that the person in charge of designing our street system in the city did not know how to drive. I guess the moral of the story is: do your own due diligence. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=35 I recently came across this webinar by Tim Ash which covers some of the most important overlooked considerations in landing page design. Quite frankly I think this material is rather relevant to almost every page on a website. Too many times I've seen designers break the efficacy of a page in favour of prettiness. Thanks for such a great webinar Tim. http://www.theworkingweb.com/publicBlogDetail.php?id=34 Those of you who know me or have been following my thoughts for the last couple of years, would know that I'm a HUGE advocate of Google Adwords. There is no other advertising medium that is as scalable, adaptable, and timely. Pay-per-click in general is the most real-time medium for advertising - you can collect data and make changes to your campaign with immediate results. Over the years I've also learned how to fine-tune Adwords campaigns to deliver only the most focused stream of traffic. I've also developed a knack for tweaking landing pages to convert visitors into paying clients or customers and maximize ROI. All the exiting stuff in business. How to minimize the money going into the machine and maximize the money coming out. When the recession hit in 2008, there were initially not many indicators that it would affect the pure Internet world that much. Our web design company was doing better than ever, and all of our partners reported equally optimistic results. The general consensus was that with tightening budgets everywhere, the Internet would be the most cost effect marketing plain and therefore any remaining budgets would be diverted there. Since early 2009 though I have noticed something about our Adwords campaigns. Although conversion rates have generally been down since mid-2008, there has lately been a large increase in solicitations from other vendors. How else would they be finding us other than our advertising? So, nowadays your advertising money is not only buying prospects, it's also buying solicitations. This is a raw deal. I don't want to pay Google for clicks from people that are going to end up bugging me. I want to pay Google for clicks from people who want to buy from me. Unfortunately there is not much we can do about this. Rewording your ads to keep vendors away will also reduce potential customer click-throughs. All we can do is weather the storm. Once the economy is back on track, vendors will be busy again, and our ads will be mostly for prospects. Unless of course, Google comes out with a Pay-Per-Sale advertising system. That way each lead would be more expensive, but you wouldn't have to pay for solicitations. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=33 Too many website owners get disappointed with the cost and/or delivery of their web project. Most often this happens when either one or both of the client and the developer have little experience in the process. Let's take a Zen-like look at a typical web/software project: A proprietor has a lawn and needs the leaves raked so he asks a young sweeper, "How long would it take you to rake my lawn?" The sweeper replies "How big is your lawn?" "I don't know," answers the proprietor. "Then I don't know, either," says the sweeper. The proprietor goes away, measures his lawn and determines that he has a hundred square metres of lawn. When he tells the young sweeper, the sweeper estimates "About two hours". So, the proprietor agrees to have the sweeper rake his lawn. Two hours later though, the lawn is not finished. "Why are you not done?" the proprietor asks the sweeper. He gives a solemn look, and replies "Because a breeze picked up and started to blow the leaves around". "Why didn't you bag the leaves as you went along?" "I didn't think of that," replies the sweeper. In the end, it takes the sweeper over three hours to rake the lawn which he originally said would take two hours. So what went wrong? Two things: The proprietor did not ask for what he wanted. After all, he didn't want a sweeper to rake his lawn for two hours --- he wanted a lawn with no leaves on it. The sweeper lacked experience and did not take into consideration all potential circumstances. Although he can rake 100 square metres in two hours, this is based on doing the work in an unchanging environment, a vacuum, as it were. As we all know, in the real world, things never work out exactly as planned. Two hours of practiced time can take three to five hours in real life. The experienced sweeper would know this and account for it in his estimate. This creates a pricing conundrum which is shared in the web development world. If the sweeper had quoted five hours to rake the lawn, the proprietor probably would not have used him. He would have instead searched for the sweeper who said he can do it in two hours, and then had the exact same problem that he had here. The experienced lawn owner and the experienced sweeper should both know the nature of raking leaves, and should both understand that to do the job properly may take longer than expected. What may appear to be a higher estimate of five hours at the end of the day may in fact be done in less time and at less cost and aggravation than paying the cheaper sweeper to keep going until the job is eventually completed. It won't do the proprietor any good to get the cheapest/less-experienced sweeper because, in the long run, was he really cheaper? The moral of this story: It's important that the proprietor be clear on what he really wants accomplished at the end of the day and he must further understand how much he is prepared to spend to get the job done correctly. To put this in web development terms, if spending less is more important than getting a properly engineered website, then it is important that the website owner tells the developer up front "you have two hours to get done what you can - and what is not done, we must either live without or pay more for the full job." Always ask yourself "What is the real goal?", and build your plan around the answer. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=32 Today I was just surprised again by a recurring theme when discussing requirements with clients. It seems to happen regularly that a client doesn't automatically think of the other side of a requirement they may have. For example, if the requirement is for a basic shopping cart with a hierarchy of product categories, allowing one-time purchases, there are the following immediate requirements: - be able to add / edit / delete categories - be able to add / edit / delete products - run reports on details of all successful sales Now, for a simple example like this one, it may be a little obvious, but for more complex scenarios, it may not be. On top of the absolute immediate requirements, there a bunch of nice-to-haves which should be considered: - run demographic and purchase trends reports - have a follow-up mechanism for abandoned carts - possible financial summary and trend reports Today's specific example was on a basic online auction system, and when presented with an estimate the client asked "but why so expensive? I'm just asking for a basic bidding system.". Naturally the answer was a resounding "yes" to questions such as: - Can sellers have a reserve price? - Can bidders set a maximum price and have the system auto-bid for them (like eBay)? - Should we keep a by-the-second bidding history? - Do you need full details of each transaction? - Do you need to be able to police the auctions? The list goes on and on. The point I'm trying to make is that many things that look simple on the surface get quite complex. Don't think only about what the user will be able to do interacting with the site, think about what the site administrators and business owners will need to do with the data. Sometimes I'm surprised when the opposite happens though. And it does happen (although not that often) where a client comes in with an idea they think is terribly complicated, and it turns out the solutions is really simple. It reminds me a little of the concept my dad had about taking a girl out on a date when I was younger. When I begged for an advance to take a girl to a movie, he'd give me $5, but when it was for a burger, he gave me $20. Even 25 years ago, a movie was way more expensive than a burger. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=31 Microsoft has launched a new search engine called Bing. It is intended to take business away from Google (of course). The engine is very sophisticated and does way more than just return search results. Intro video: http://www.decisionengine.com/Default.html Actual engine: http://www.bing.com/ Try a few searches in images and notice their interesting lack of accessibility standards. It looks like Microsoft has decided to become pro-frames. How awful. The map search has the same problems. However we CAN learn something from Bing. Try a video search. At first I got a fright when a video thumbnail started playing on mouse-over, but after a few times it was pleasant feature. They don't play the whole video on mouse-over - just little collage pieces - but it gives you a much better idea of the content than just a thumbnail does. Kinda cool. The search results on the web end of things is also a nice improvement on Live and Google. Each result now has an AJAX popup that appears to the right on mouse-over, which shows more relevant content from the destination page, including some navigation options on the destination page. The biggest skull-scratcher though is why they often use the meta description as the content of the individual search results. Google abandoned this eons ago. In my testing I got results where the meta description was not even relevant to the page content, and yet the meta description is what was used in the results. Search results form sites like Amazon now include additional secondary links which single out things like reviews. That is a nice feature as well. Taking market share away from Google will be no easy feat - especially by Microsoft since their perception in the marketplace is not favorable. However it must be said that this is a good effort and may make a dent in Google over time. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=30 Every so often I get a prospect with an interesting project who does not want to be all that involved in the project life cycle. By "all that involved" I actually mean "involved as little as possible". Often times they cite things to the effect of "but you're the expert in this field". While this may be correct, my rebuttal is always "but YOU'RE the expert in YOUR BUSINESS". A project's success is often measured by it's outcome (weird huh?), and if it is driven by someone who knows not too much about the business, the outcome can be disastrous. The project sponsor on the business side is the business expert and the IT consultant is the technical expert. It takes a highly collaborative process to engineer an outcome which is both viable from a business sense and workable from a technical standpoint. If you're sponsoring a high-budget project and basing your future career on it's outcome, wouldn't you want to be involved? Not only involved in the planning and design phase of the project, but at every step of the way. Your project team can give you daily progress reports with key performance indicators which would allow you to adapt and make decisions about the project daily and in real-time to ensure the successful completion, financial viability, and end-acceptance of the project deliverables. I realize that for some project sponsors, the IT and web fields are out of their comfort zones, but that's no reason to avoid contact. Roll up your sleeves. Get involved. Together we work best. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=29 One of the subjects of debate that comes up often when resourcing a project is whether to get consultants from major consulting firms, or to contract independent consultants. Consulting Companies Stronghold There are some advantages to going the company route. If you find a reputable firm, they should have policies and procedures in place to replace a consultant should something happen to the person you engaged (eg illness, winning the lottery, etc). Additionally, if you require multiple consultants or developers, the fact that they have previous working experience in the same team, is an advantage. However when it comes to functional consultants or web consultants, there are major disadvantages to the company approach. Any consultant who has a team or history with a team, will most likely propose solutions and/or design specifications around the knowledge and skill set of the team. His/her prime responsibility is to employ his team. The client's specific needs are only the second priority. Consultants from large firms are also generally very expensive as the partners of the firm need to have their pockets lined well. Independent Tenacity When it comes to independent consultants, their recommendations and designs are not influenced by their own team's skillset. They truly can act in the client's best interests. Independents are usually less expensive than large firm employees, but more importantly, they are often way more tenacious. Employees in large firms get the large firm mentality and, being part of a large wheel, move more slowly and more rigidly. Independents are often more knowledgeable, and due to having to find their own engagements and contracts, are often much more tenacious and flexible to changing environments. Don't forget that many independent consultants became independent for a reason - usually because they used to work in a large firm and saw opportunity to do things better. Bottom Line Whether you engage a large firm or independent consultants (or a mixture of both) is a decision only you can make. However, know that there are many advantages to hiring independents. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=28 Back in the 90's, the Internet was still very slow and limited. For just about every IT project, all developers would need to be in the office where their project was taking place, or at least in a satellite office that was connected by VPN or similar. It amazes me that the IT lead mentality has not changed much since then. Most IT leads heading up a project still insist on having all team members locally present. Local Seat Warmers There are some good reasons to have developers locally on a project team. Communication can be a lot easier in person rather than over the phone. Additionally, having everyone physically in one location creates more of a team atmosphere. However there are way more downsides to having a physically present team. Firstly, there will need to be a location to fit everyone in temporarily. Then, each team member will need a desk, computer, software, etc. This is hugely expensive. There are also travel costs which add up very quickly. Each travelling consultant will require compensation for flights, taxis, hotels, and meals. Some factor these expenses into their rates, but either way it's the client that ultimately pays for these costs. Also, if the project runs over a longer period of time, there could be complications with the government when dealing with income tax for contractors. Make sure you check with your local laws since many government revenue agencies (IRS in the USA) will consider a contractor to be an employee under certain conditions, and will then require source deduction payments from the so-deemed "employer". I've been on a project of a provincial insurance company where they actually budgeted $600k per year for these special tax assessments. I guess government agencies can afford this. Remote Options Since the early 2000's, the Internet has made telecommuting a real option, even for large projects. Video-conferencing today can literally make you feel as if you're all in one room together. Telephony in North America is dirt cheap with most long-distance calls only costing cents for the minute. Added to this are teleconferencing options which are equally inexpensive. There are also excellent desktop sharing applications on the market which allow you to deliver online presentations and collaboratively work on the same computer. Bottom Line It's way more expensive to have a local team than a remote team. I mean *exponentially* more expensive. If there's resistance to changing the development concept on a project, start small, with just one remote developer, and slowly make the shift to a partially remote team as your needs dictate. You'll be happy you did. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=27 Over the last ten or so years, there have been some interesting shifts in working hours for consultants. Although the traditional 40 hour work week seems to be still very ingrained in people's minds, we have seen many consulting shops move to a 4 day workweek, especially for travelling consultants so they can spend a full two day weekend with their families. Traditional Full-time I have been on many large projects where the expectation has always been like that of a regular job. From the consultant's point of view, this creates incredible income security, but for the client, this could be a massive waste of money. There's no way any project can keep a consultant busy for 8 hours a day, 5 days a week, and however many weeks the engagement is for. Most consultants end up wasting a lot of time "making puppies" in activities like surfing the web and personal tasks. There are a few diligent people who will endeavour to find "make-work" projects, but even this is wasted funds for the client. Flex Alternative We have to remember that consultants are vendors and the expected work hours should be treated as such. You only engage vendors as required. Why on earth would you pay a consultant to sit around and do nothing? I pride myself in being one of the best web architects in North America, and as part of this pride, I need to be providing value at all times. Many old-school IT leads still resist the whole flex-time idea though. There is a fear that a consultant will suddenly be needed and then no longer available. This however can simply be negotiated as terms of the engagement. If you need me when my plate is full, let me know and I'll re-juggle some priorities. A lot of consultants do not make themselves available by the hour for logistical reasons, but all consultants have a time granularity they're willing to negotiate. Bottom Line Don't waste money to make budgeting easier. If you have a 6 month project, your average consultant will cost you around $100k over the course of the whole project. If the consultant's utilization rate is 50%, then you're basically flushing $50k down the toilet. What if you engage 10 consultants on a project? What does this add up to? -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=26 I was leafing through a copy of "Project Management for Dummies" the other day. Even though I'm a certified Project Manager, I still like to read this kind of stuff. Sometimes there's some really interesting tips one can pick up. When it came to the section of anticipating the most common project mistakes, I was not only pleasantly surprised, but also motivated to write this post. This book echoes my personal experiences frighteningly well. I've been involved in many projects in a non-PM role (disclaimer necessary - it wasn't my fault what you're about to read). On many of these projects the biggest mistakes are a perfect mirror of what the book says. The top 2 points being: 1) Jumping directly from the conceive phase to the perform phase. That means you have an idea of what the project will be about, but no proper plan. Likely you're under time pressure and/or budget constraints. There will be hundreds of excuses to skip the planning stage and just jump into work right away. That's like starting to program a website without a decent spec. I'm not saying this is not possible, however I have seen projects costing 3-4 times their budget because of this. Not to mention delayed go-lives, and sometimes even total abandonment. 2) Omitting the start phase completely This means you have a plan, but you fail to define procedures and relationships, formalize tracking and reporting systems, assign manpower, etc. I've seen what happens when a key player on a project leaves - it's messy - trust me. You need to be able to accurately measure and communicate where you're at in the project, and have lots of fail-safe procedures just in case. The person who came up with the phrase "expect the best, but plan for the worst" did so with reason, I'm sure. The above 2 points can account for 15-20% of a project's cost, but leaving them out can open you up to exponential increases in project cost later. On a $100k project, you may be tempted to save $20k and jump right into the work, but you'd be better off taking that $20k and buying lottery tickets. Maybe you're lucky and win a few million - enough to pay for all the scope creep and emergency measures to keep the project going. I'm not trying to be cynical, but I've been witness to many real-world projects. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=25 The swine flu is an influenza virus strain that pigs have. Previously it could only be passed from pigs to humans, however there is a current mutation which is spread by humans to humans. In computer terms, a virus is a piece of malicious code that self-propagates over the network and Internet. There are many variations of viruses from simple harmless ones, to major viruses that spread like wildfire and kill your computer. (like Windows?) Traditionally, computer viruses were Windows PC-based, copying executable code from one computer to the next. Although there are many anti-virus software applications on the market today, the new breeds of virus are getting tougher and tougher. Although not officially called the swine flu, I use the analogy because viruses are changing their hosts in sneaky ways. One method which is extremely nasty is using websites to spread. Some of these nasties, once executed on your PC, will monitor all your FTP activity. They recognize when you connect to websites for editing purposes and inject malicious code into the code being sent up. Naturally the danger of your password being sent to someone untrusted via email is extremely high since FTP handles passwords in plain text. The malicious code on the website could then propagate to all visitors of the site. This is usually attempted with JavaScript in an iframe to hide the fact that the site is not exactly what was uploaded to the infected webmaster who's uploading it. In the past, this kind of activity would have been limited to techies only, but these days there are many software products on the market that allow non-programmers to edit their website content with ease, and some use FTP as their communication protocol (like Contribute). My recommendations for everyone who works on or with the web to stop the spread of Internet-based viruses and increase the security of websites you work with are as follows: Always have a good firewall between you and the Internet. There usually is one built into most good routers, but make sure anyway. Never use plain FTP when uploading or download files. It is a garbage outdated protocol, which is less secure than wet paper bag in a hurricane. Use SFTP instead. If you manage your own server, disable FTP altogether. Clients should use SFTP. If you're a programmer, make sure any web apps you code are up to security standards and best practices (ie prevent SQL injection, etc) If you utilize any open source or third-party widgets or plug-ins on your site, make sure they remain up-to-date with all patches and updates that are released as soon as those updates are released. Always have good and up-to-date anti-virus software running on your PC's and servers. It should never be out of date for a minute. If it wants to restart your computer for changes to take effect, do it immediately. Don't be tempted to wait until you have some time because you're busy right now. Always have good and up-to-date anti-spyware software running. Change passwords regularly for all your sites. Even every month is good. Only use strong passwords of 8 characters or more with a mix of letters and numbers, and both upper case and lower case. Wherever possible, lose Windows altogether. Linux is much more secure - not to mention faster. Don't use the same old password for every site. If your password does somehow leak out, you want to be assured of minimal damage. Never ever ever send passwords via email or IM. Email can be read by every server that passes it along (use something like MyMessageSafe.com instead). It's *YOUR* safety and security. If you work on client sites, then it's *YOUR* integrity at stake. Be safe, -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=24 Here are 5 important points to consider in preparing to launch a new website. Getting visitors to your site is no easy feat, so once they get there, you want to make sure that they act on your content. 1. Plan: Decide what the initial goals of your website are, what you wish to gain from having it, and how you wish to budget your site development and growth over the next two years. Doing your research and planning what your website content will consist of is key to receiving the final outcome you expect from your website. One of the best ways to do this is to create a storyboard. Although this process can be lengthy it is of great benefit to you in the long run. It will aid you in the creation of a solid Request for Proposal (RFP). If your RFP is not solid, then you will receive a variety of quotes from vendors, which will be based on their interpretation of the RFP and their perceived risk. A well thought out RFP, on the other, hand will show exactly what your expected outcome is. If you gave it to multiple developers or web companies every one would give you a quote based on exactly the same end product. With a solid RFP, you will also receive the end-product that you expected. 2. Target Audience: Be aware of who your visitors will be and how you will appeal to them. Before finalizing any design and content for your website, take the time to get to know your audience. Who will be visiting your site? What are these people looking for? What are their needs? Their interests? Perhaps you may even want to consider if these people are educated or uneducated or their geographic locale and if that matters to you, or what is their socio-economic status? Will this have any bearing on how you design your site? How can you appeal to this demographic? You must adapt your website content and graphics as specifically as possible to the visitors that you wish to attract to your website. You will need more than a superficial knowledge of your target audience. 3. Content: Gather the information you need to share with your target audience and have it ready for your web designer. Trust me! Waiting for client content is where the biggest development delays occur. There needs to be a balance between content and clicks. This means that if the website is full of too much content, your audience may lose interest very quickly due to too many clicks to find the information they need and because of information overload. Having to read through heaps of content can disinterest even the most avid web searcher. So, make your point, convey your information, and be precise. 4. Pages: How will your information be managed and broken out over the site? Don't rely on your designer to interpret your content and guess. He WILL get it wrong. Once again, this comes back to planning and research. Make sure to create a sitemap. Sure, you may not know what information will fit best on each page, or what the best design layout is but at least provide your designer with an outline of how you would like all of your information laid out, what the information groupings will be, and where information should be placed. Your designer can decide what is best graphically for your site but only you are the expert of your own business and its information. If you rely solely on your designer to group information and lay it out for you, you will not necessarily be pleased with the end result. Do your homework and take the guesswork out of the process. 5. Action: What do you want visitors to your website to do? All websites have a persuasive purpose whether it be to get someone to subscribe, to sign up for something, to inquire on a topic, or to buy something. It is imperative to focus on what your call to action is for your website. Try to do this by categorizing what the three most important things that your website allows people to do? Focusing on the task, on the action that you want people to take, is a great way of achieving clarity. It allows you to cut through the filler content and get a greater focus on the most pertinent content. The web as a whole is continuously under construction. Just like each of our businesses, we are growing and expanding continuously and therefore it is understood that we are forever changing and developing it. Don't you think it would be a wise choice to research and plan for that development now? Naturally there are many more points to consider, but the above should get you started in the right direction. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=23 Well, Google has finally done it. They've pissed me off. I've been a big fan of Google since the late 90's and have enjoyed watching this small geeky search engine transform itself into a publicly trading behemoth. The search results have been better than those from competing engines, and the product & service offering Google has is actually quite good. Over the years there have been instances where Google was a little slow to adapt to market needs, but they always did catch up eventually. One thing that seemed to take forever for Google to implement in their Adwords Pay Per Click service is day-parting (day parting is where you can change your ad bids depending on the day of the week or time of the day). Through my company, Globi Web Solutions, we implemented an automated day-parting service for our clients using Google's API and and a bunch of cron jobs. It was not terribly complicated or pretty, but it made us one of the only players in the market (initially anyway) that had day-parting for Google Adwords. Aside form such things, Google also has made numerous large-scale, high-impact changes to their algorithms which caused many people to panic - especially on the organic search side of things. My position on these changes has always been "so what did you expect would happen?". There's been a proliferation of abuse and spam in the engines, necessitating them to take action. Hell, as a searcher, I don't want to get pages and pages of spammy results either. But in March, Google actually managed to piss me off. I'm a huge fan of their Adwords PPC service. There's no other way to get targeted traffic to your site instantly and be able to react and adjust your campaign without any lag time. Add to this Google's Analytics software, and you can get an in-depth look at your traffic and analyze it within the context of your PPC campaign - nice. In March though, a new rule was applied which only allows you to have a 1-to-1 relationship between Adwords and Analytics accounts. In other words one Analytics account can only be linked to one Adwords account and vice versa. At Globi we often run PPC campaigns for our clients. In most cases everything is as expected. We set up the account and then the client logs into the account to enter credit card and payment details. Historically we have had clients without credit cards though, and for these, we would run their campaigns within our own account, and then they would reimburse us the Google expense. One would think there should be no problem to such a situation, however after a few of these later, we have multiple client websites, each with their own Analytics accounts, but with their PPC be controlled through our own Adwords account. For anyone else in this boat, let me express how much I sympathize. Once the mess is sorted out there will be some data loss and other fallout. In hind-sight of course, Google's decision does make sense. They have enabled Adwords Manager accounts for many years now, plus you can have multiple administrative users in one account. There really is no reason why each client would not have their own Adwords account as well. Oh well - all's well that ends well. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=22 The easiest way to define Best Practices is as a collection of policies and guidelines based on large amounts of education and industry-specific experiences. Such knowledge could take many years for one person to accumulate, but with official and published practices, this knowledge is distilled into small and digestible components. Individual programmers, designers, and developers, can benefit hugely from such an official rule set as they can completely by-pass the experience one would have to gain to acquire this knowledge, and can perform at best practice levels with a fraction of the education required to develop them. In short, if you follow the adopted best practices, you can perform at the same level as a developer who's got 20 years of experience plus a relevant education including a few degrees. For the employer who has a programmer, developer, or designer on the payroll, the cost-savings here should be quite obvious. For the individual, the promise of the knowledge without the accompanying pain that experience always dishes out as part of the education process. The benefits get even more important when dealing with a team of programmers, developers, and/or designers. People in general will always perform to their level of standard, using their most comfortable skill-sets, to produce end results which fall into their perceived acceptable parameters. In other words, they'll do what's easiest and most familiar. Problem here is that everyone will end up doing something a little different from the next. This is not a good situation in a team environment. If every team members adheres to adopted best practices, you can be assured that they all play by the same rules, and deliver end results falling into the same accepted parameters with the same levels of quality. Most importantly it's like having built-in knowledge sharing across the entire team of even the most advanced concepts. From a management perspective it also removes all challenges from team members wishing to run on the bleeding edge. Any time a new idea comes forward (like "why don't we do it this way?") the answer can be a simple "'cause it's not in our best practices" and then can be tabled for review with the next update. If software programming, website design, or web development is a service you offer your clients, then having official best practices is an added marketing tool - it raises you above your competition in many cases where they don't have any or only limited documentation. As fun as gaining experience can be, sometimes a cheat-sheet can be more cost-effective. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=21 I came across this post today, and just had to share it. I don't usually post other-people's content and try to deliver original ideas, but this was too good not to pass on. Jeffrey Zeldman, one of the founders of The Web Standards Project, explains what are web standards and why are they important? The history he brings up is really interesting. This also ties in very nicely into why we need Best Practices for Web Development. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=20 Outsourcing defined Outsourcing is giving a piece of work to an outside team of your organization to complete. In the software and web development world, many of us have heard of outsource channels like India, who promise highly educated programmers at very low costs. Cost savings The cost saving is often real at first glance. The quality of programmer that costs you $100 per hour in North America can be had in India for $20 per hour or less - a mere fraction. Extrapolate the savings to a project of over 1000 man hours - that means $100k local vs $20k off-shore. That's huge. Problems There have been many problems with outsourcing to off-shore teams in the past, the major ones being communication issues, and lack of control. Very often projects which would have taken 100 hours to complete locally suddenly take 300 hours off-shore. This takes a significant bite out of the savings in outsourcing to begin with, and if this means you need to chain on another project manager to deal with the off-shore teams, then your savings are pretty much gone. You may as well just save yourself the headache and develop in-house right from the start. Solutions There is a very significant and obvious problem shared with just about all failed off-shore projects: They all failed to plan correctly. The solution to effective outsourcing is proper and detailed specifications. Once you have a spec that leaves absolutely nothing to the imagination, developers have no choice but to deliver what you asked for. Even crude pictures drawn with pencil and paper can help to control project scope, but the more detailed the spec, the tighter the controls. Take the gamble out of outsourcing to off-shore teams by giving those teams detailed specs. -Andreas http://www.theworkingweb.com/publicBlogDetail.php?id=19 It will be interesting to see which of the current social networks will survive the next year or two. There are many different types of network sites which aim into the social sphere. Some let you store your favorites or bookmarks online, and share them with the world, Others let you publicize your current status or what you're currently up to. Some let you keep your contacts online and share connections with others. Many of the social sites are quite thin in their feature set, like Twitter, which makes one think they'll die first. Who needs yet another account to log on to? Yet some are very feature-rich - to their detriment. You can do so much with Facebook, including getting viruses. The original intent of these social network sites likely was well-intentioned. Creators of these sites were looking for new ideas to capture market-share, and then sell advertising down the road. Some of the sites even ended up being useful to their members, which gives them a big boost in longevity. One day it was realized though that pages in the social spheres were coming up higher in search results. Likely Google et al thought that a vote from a popular social site is important enough to boost rankings, and that the social sites themselves are important enough to rise to the top of the SERPs. This is where social undoing started. Suddenly social networks became an SEO strategy. First there were off-shore services where you could pay 5c-10c per link for someone in India to bookmark your pages in the Diggs of the world. Then came software to do this automatically for you. Every time you publish a new page to the internet now, you can ensure that it is publicized by every social networking site in the world. Isn't that great? Well, if you consider that there are MILLIONS of new pages being published to the internet EVERY DAY, that means a lot of noise. At some point, the signal-to-noise ration will tip to the noise side and we will have to start ignoring the signal. What does that mean to us? Since the majority of content on social networking sites will be spam, we will start to use them less and less. The major search engines will eventually start to ignore social networking sites altogether due to their spam content. With software to publish to social networks on our behalf while we humans sleep, our computers will be well connected and socializing amongst themselves. Of course they won't buy anything offered by advertisers, so the advertisers will start to use these sites less, and that means less revenues for the site owners, which can only lead to the obvious. Since some of the social networks do still work, I'm not saying to abandon them. However, keep the big picture in mind and don't use these sites purely for marketing reasons and expect a huge ROI. Why is it that when someone sends us an email about Viagra we call it spam and get mad, but when we need to do some marketing for ourselves, so many low-cost, low-work, promising high-impact solutions look so appealing? -Andreas