A friend of ours sent us an email with some information about a cool event coming up called hackUTOS – A Code Festival. It looks pretty cool and it will be interesting to see what kind of things can be hacked and created at this event.
For more information:
Having been the creator and manager of several WordPress sites, there were a few things this blog was lacking so I took some time to update them. This was one of Code Greene’s first WordPress site and was built in early 2009, so naturally it was a bit outdated. Here are a few things to notice as you read that have been updated.
1. Custom Font Replacement: We had been using sIFR, but shortly after we built this site, cufón came around and we fell in love. Any custom fonts you see are now generated by cufón.
2. Dynamic Sidebar: The old sidebar was hard coded. I took that out and made each section it’s own widget which allows to move them around easily if needed and also add third-party widgets should we choose to do so.
3. RSS: I created a FeedBurner RSS so be sure to update – http://feeds.feedburner.com/TheCodeDojo
4. The Clan: Under The Clan section in the sidebar, you can now click on one of the names and it takes you to a new page with that persons bio and all the posts they have written.
5. Facebook Fan Page: We started a Facebook Fan Page – you can become a fan here: http://www.facebook.com/CodeGreene
6. Custom Share Icons: Mike built us custom share icons to fit our ninja theme. Thanks Mike!
7. Contact Page: Rather than sending you, the user, to codegreene.com to fill out a contact form, you can now send us your requests by going here: http://dojo.codegreene.com/ninjas-for-hire – so drop us a line.
A few subtle changes will be coming in the future – let us know what you think!
Editors Note: Quintin Smith is the Business Development Manger at White Label SEO and has been kind enough to write a post for Code Greene on his specialty – SEO.
SEO is an interesting process. We here at White Label SEO would like to talk about how important SEO is to your overall success of your website. We would like to thank Code Greene for this opportunity to post a message about SEO to their blog. Thanks Code Greene! One quick word on Code Greene. We have dealt with numerous web developing firms and Code Greene is one of the best. Thanks guys!
So how do you work on optimizing your site. There are a lot of things that need to be done. How is your content? Is your content keyword rich? Are you putting links in the proper places of your site etc? All of this is important, but when it comes to starting a successful campaign you need to know YOUR COMPETITION! At White Label SEO we evaluate your competitors. Why is this? Well, for a few reasons. First, your competition might be large. You may have a lot of competitors that have been doing SEO for awhile so it is important to know who it is and what kind of traffic they are receiving and what keywords they are using. This is all important information to know when it comes to keyword selection and the success of your website. Research your competitors. Once you understand what your competition is doing you can start to build your keyword list that you otherwise may not have chosen if you haven’t looked at your competitors.
Search Engine Optimization is not like PPC. The results are not instant. It takes time and work to get in the top SERP of the engines. Knowing your competitors will help you gauge your success and help you determine your goals. The greatest way to turn an ROI on your site is through organic SEO. So you need to expect to spend a good amount of investment on your own developing your site and creating a web page that people want to link to. This is just a quick start for people that need to gain some insight on SEO. Know who you are up against and build your site and SEO campaign based off that knowledge. We wish you the best of luck in your efforts of climbing to the top of the search engines.
Quintin Smith – White Label SEO
For SEO Services, please contact Quintin and quintin@whitelabelseo.com
This edition of Sharpening the Blades features an article from Mike about using jQuery, CSS and image sprites to create stylish forms, an article from Benjam about Passwords on the web and Mark chimes in with an article about the possibility of HTML5 in Internet Explorer 9.
Mike, Get your form on with Uniform
We’ve all been there. You finish an amazing design using some sweet custom form elements that perfectly match the theme of your design. Then after a few frustrating attempts, you realize that some form elements just can’t be styled. Or if they can, not consistently. So you throw on a border, maybe a background image, and hope for the best as dreams of your custom UI vanish into nothingness. But fear not! Using the clever jQuery script Uniform and some CSS sprites, your form designs can once more be glorious! Works beautifully in all major browsers (degrades gracefully in IE6).
Benjam, The Problem with Passwords
Being in the Web Development industry for a while now, and having had a few third-party scripts that were on my site hacked, I have become more and more interested in web security. Passwords are on the front lines to that. Being a user of Web technologies, I’m also interested in usability and choice, and when it comes to showing or hiding passwords (what? you can do that?) I’m in the boat of give the user the choice. This article nicely explains a few examples that offer people the choice to show or hide their passwords, both of which are very useful.
Mark, Microsoft to Double Down on HTML5 in Internet Explorer 9
Doubling down seems like the wrong approach to me. If I were the CEO at Microsoft I would instead of thinking of trying to put their foot down harder, they should instead learn to bend in the winds of the market and work on compliance with the other browsers. Though I hate to say it even forced upgrades like Firefox does would be good, to keep people current and reduce the amount of cross browsers compatibility problems Microsoft gives developers. I don’t think Microsoft realizes that by making developers lives bad by trying to be different they are actually building up a mass market of developers who hate them because it is so difficult to make cross compatibility easy and affordable.
This weeks edition features an article about customizing WordPress for beginners, designers who can’t code their own designs and the best way to handle content management systems for sites that matter.
Chad, The Beginner’s Guide to Tricking Out Your WordPress Blog
I liked this post/entry about WP because it was built and geared for the beginner. Once you installed it now what. I find these type of articles interesting because sometimes they are just so simple that I don’t even think of them. And it helps me to explain or think of other things that I feel our clients may want or need.
Mike, Web Designer’s Who Can’t Code
Twitter exploded in a debate this week when Elliot Jay Stocks boldly tweeted:
“Honestly, I’m shocked that in 2010 I’m still coming across ‘web designers’ who can’t code their own designs. No excuse.”
The world is full of talented designers trained in a wide array of media, but just like other mediums, the web offers its own constraints and limitations. Knowing how to code definitely gives you an edge, even if you don’t code the site yourself. Image resolution, measurements, typography, and browser discrepancies all play a role in what is possible, and help determine the collective best practices of the web. So does a good architect need to know how to dry wall? Maybe not. What about a fundamental understanding of construction and engineering? Absolutely. How much does a good web designer need to know about their craft in order to build a successful website? What do you think?
Mac, Content Management for Sites that Matter
I liked this article because it gets right at the core of the cost/benefit trade-off that many people don’t think enough about when building their web site. Either there’s a significant value to the work you’re doing on your site, which justifies spending some money on it and getting it done right, or there isn’t a significant value to your site, so why bother? I don’t 100% agree with them about the WYSIWIG comments, but I’ve never tried to tell a client to assume it would look identical in TinyMCE and on the public site. We’ve generally had to train them to be very careful to keep it simple. Use bold if you want, make some lists, paragraphs, links, and stuff like that, but don’t try and do anything funky or you’ll end up disappointed. Another annoying thing about TinyMCE is that even when you tweak the HTML manually in their HTML view, it often wants to “automatically fix” some of the things you did. I was trying to leave a <br /> or two between a couple of separate lists if I remember right, and it kept either taking it completely out, or turning into a paragraph, constantly leaving too much or too little whitespace, even though the HTML I manually entered would display exactly how I intended.
Lately I have been thinking about all the wonderful clients I have had a chance to work with. Each one has characteristics and qualities that make them unique and fun to work with. However, clients never cease to amaze me with their downright silliness and ignorance.
My favorite conversations with clients are the ones where we discuss browsers and the difference between them. I chuckle every time I hear, “I am using IE6.” I frequently applaud the client who uses Firefox because they have taken the time to educate themselves and while I don’t want to get into the reasons we use the browsers we do, just noticing what browser you use is half the battle. You’ve probably read the post by a Google employee about browsers. If not you can read it here. His post got me thinking about comparing clients to cars.
For those of us in the web industry, we frequently laugh at people who just don’t know how to use the web, but how many people are laughing at us because we don’t know how to do something? You might argue “But we (society) spends so much time online, how can someone not know how to use it?” I would argue the following.
How much time do we spend in our cars? Obviously this number depends on your commute, area, etc., but we spend a substantial amount of time in, caring for, washing, and feeding them that we should probably know more about how they work. How many mechanics laugh at us because we can’t change our own oil or replace our brakes? How many AAA repair men does society employ because society doesn’t know how to change a flat tire?
How much time do we spend in our house, but don’t know how to lay carpet or do any sort of plumbing? How many of us know what kind of carpet we have? What is the brandname of your couch? What kind of pipes do you have? These questions are simple for those who are educated and experts in that industry. Compare that to browsers or websites. How many plumbers laugh at you and I because we have weak pipes? How many painters cringe when they see the paint we have? We might say, “But it works just fine!” True, however, IE7 “works just fine” but how many of us cringe when we hear our clients are using it?
How many times has a client come to you saying their site is broken, only to find out it is a user error? It’s natural to sit back and just laugh, but how many of us have made a user error when we “pushed” instead of “pulled” on the door at a restaurant?
When it comes down to it, we are no different from our clients. We may know more about the web, browsers, computers, etc., but they may know more about neurology, public relations, and even cars. We make the same mistakes, just in a different aspect of life, so please, just be a little more patient with your clients.
Swakker is a company that makes iPhone, iPod Touch and iPad apps. They wanted a site to show off what they do best and give a place for their users to easily communicate with them. They came to us with a short timeline because they wanted to get the site up quickly because they had already ordered an ad in Rolling Stone. We quickly got into gear and were able to give them a nice WordPress theme that they could easily edit.
On the homepage, we built a gallery of images with thumbnails. When a thumbnail is clicked, the large image appears. We also built a quick overview section to show off the latest apps. In this section, the user can easily find out information about the new apps without leaving the homepage. A custom sidebar with custom widgets can be found throughout the site.
The apps page is a fully custom page built dynamically with custom fields and normal WordPress posts. The client can enter in the thumbnail, content, video url, features and a url for the link to iTunes. The news page functions like a typically WordPress blog, giving Swakker the chance to update their followers. The gear page is built using pages and children pages to help Swakker build their brand by selling clothes online through PayPal.
Last but not least, the gallery page is built to show off what users have made using Swakker apps. A nice place to get a daily dose of creative inspiration.
Check them out on the web or in iTunes.
Robert McArthur approached us looking to completely redesign their website. While their old design served its purpose, it’s time had come. Their portfolio had grown and service list had expanded. They wanted to add more information while still maintaining a simple, yet compelling design.
It’s always interesting working with artists from other fields, be they architects, photographers, illustrators, or otherwise. They each have a unique take on their work, and their perspective often transfers well to the web. Robert was no exception. During design meetings, his ideas and explanations were an invaluable asset to my design toolbox. The new background, for example, preserved the same earthy brown as the old website, but also brought in an actual hand-sketched blueprint Robert had used in one of his plans. The typography, decorations, textures, and other detail decisions were all passed through Robert, and each received individual feedback and revisions.
Robert McArthur Moodboard
I think the new design really speaks for itself and all parties involved are happy with the result. This is also the first time we’ve used the fixed background and I think the result is amazing. Check it out and let us know what you think!
The old adage that “an ounce of prevention is worth a pound of cure” couldn’t be more true in web development. Through recent experiences we’ve found out that it is well worth the effort to go to extremes in planning something out before you build it. Spending an extra 4 hours in planning can literally save 40 hours of development later, if not more. If you’ll indulge me, I’ll share a few stories to illustrate my point.
A project some of us have been involved with had a budget of X, and a scope of Y. It seemed simple enough that the planning was skimped, and the client wanted to get things moving quickly, so everyone just plunged in. Before you know it, there are things that we told would be done one way, and now they’re changing it and wanting it another way, and features A, B and C come out that they never mentioned to us until long after the budget was fixed. We try to make it work, and scope is now 2-3 times where it started out. Time goes on, and it turns out that the final client wanted something different than the decisions and instructions we were given, and wanted features D through H as well. Red flags have been raised several times, and some renegotiation gets 3X the budget to go along with what at the time was 6X the scope. Everyone is unhappy, because more information keeps coming out that we weren’t given, and the client got something different than what they were expecting because the expectation wasn’t made clear at the beginning, when the planning should have happened. Of course now everything is late too, and still not done the way they wanted, so features I through M make it into the mix, along with major changes to 8 of the existing new features. 8 times the original scope and counting, for 3X the original budget, and nobody is very happy.
What did we learn from that? We need to be much more strict about the planning, no matter how much they beg us to just get started, hoping that getting started sooner instead of planning more will get them to the desired destination faster. That’s like getting on the freeway and driving, so that you arrive faster at your destination, before you bother to figure out which direction the destination lies, and what paths might make sense for getting there on the timeline and budget you’re hoping for.
We often share with people a metaphor about their website is a building, and the plans are the blueprints. It’s relatively easy for an architect to move a wall on a blueprint, because he can just change the plan. But once the blueprint is in the hands of the construction company, and they’ve built the building part way, or all the way, it’s harder to move the wall. A client often thinks “I only need to move the wall 6 inches” but unfortunately that doesn’t change the fact that it is a wall, and would probably need to be torn down and rebuilt in the new location. Granted, not every change is moving a wall. Sometimes they want a window over here, or a door there. Sometimes they want to switch around the plumbing or the electrical. Some changes aren’t as major as others, but they all make some kind of difference when you have to redo or undo something. If they have us paint the room red, which we do, and then decide they want it blue, it will probably cost about double at that point to repaint. If they change their mind before the room has been painted, it isn’t a big deal, unless we already bought the red paint for them. The timing of the decision makes all the difference in what costs are sunk and what work has to be done, undone, or redone to make the changes they want.
The big lesson for me has been that it isn’t unreasonable to spend 4 hours planning a project estimated to take 40 hours, or 10 hours on a project that will probably take 100 hours. It is time well spent, because in the end you get done faster, you can be confident that you understood what they wanted, and it is much more likely that it will be done right. When you can get it done right, on time, and on budget, you’ll have happy clients.
This morning Mark and I attended a great talk by Eric Smith, CTO and Co-founder of Control4, at the UTC CTO P2P Forum, titled “Outsourcing: What not to do.” The short version of the story is that a few years ago Control4 decided they should try outsourcing. They spent about $700,000 setting up a nice 50-man shop in Bangalore, with a good Indian HR manager and a guy from here that moved over there as a technical manager for the shop. In about a year and a half, they spent about $3,000,000 on the facility, and ran into a bunch of problems. They couldn’t hire and keep the top notch developers because they weren’t a big name company, and they had a lot of churn and turnover due to the 20-25% annual growth in average salaries. They had a hard time being clear enough and specific enough in their specs and task lists to get it built right the first time. The 12.5 hour time difference made things very hard for communication. On some projects, they had to go back and forth 17 times with changes, bugs, clarifications, etc. before it was done right.
When he talked about the results they got from this $3M, 1.5 year investment, he said that only about 30% of what the team produced was able to be salvaged and used. The other 70% had to be rebuilt from scratch. One of the most telling things he said was that by the time they got all the kinks worked out and the team there was working at full speed, the production they saw from the Bangalore office was about what they would have had if they had kept their technical manager here in the States and hired one more guy like him. Two top notch guys (for argument sake, say you’re paying them each $150K per year, a total of $300K/year plus their office space and any other administrative overhead) would have yielded the same output as a 50 person team costing $2M per year. He didn’t say, but if that doesn’t already factor in the “30% usable output” then the difference is even more drastic. Don’t forget that another cost besides the money is the time it takes to get to the right solution. If 1.5 years is what it would take to do it right, then 1.5 years to get it 30% right means you still have a lot of work to do and a lot more time (1-5 years) to really get it done, which in a competitive market can leave you in the dust.
One really sad thing is that this story is hardly unique. Many people we’ve talked to who have tried outsourcing projects (to India, Russia, or anywhere) have run into similar problems and worse. Most of the outsourced web development projects we hear about didn’t get in that deep of course, but the principle is the same.
So what is the moral of the outsourcing story? It really is the same lesson many others have learned: Cost, or hourly rate, isn’t the only thing that matters. Sure your outsourced developers are cheap, but what do you get for it? What’s the quality and quantity of their output?
Mark tells a great story about a guy who has a brain tumor. continue reading “Outsourcing, Brain Surgery, and The 9′s”
The Code Dojo is the veritable repository of random musings from the development team at Code Greene.
We write about web development trends, tips, best practices, and our projects — all in the spirit of "kaizen", the Japanese philosophy of continuous improvement.
Code Greene Facebook Fan Page
Need a website?
Get a free consultation to see what we
can do for your business.
The Code Dojo is authored by Code Greene, a group of web developers in Salt Lake City, Utah. We specialize in developing high-quality custom websites and applications using PHP, XHTML, CSS, jQuery, and Ninjutsu.
For more information, visit our website:
