Sharpening the Blades: Styling Forms, Problem with Passwords and HTML5 in IE9

03.05.2010   |   0comment

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 Uniformuniform
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 Passwordspasswords
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 9internetexplorer
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.


Sharpening the Blades: Tricking out WordPress, Designers who can’t code and Content Management

02.19.2010   |   0comment

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 Blogtrickingoutwordpress
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 Codedesignerswhocantcode
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 Mattercontentmanagementforsitesthatmatter
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.


Just be a little more patient with your clients

Tim,on the topic of  Browsers, Business, Web Development
02.12.2010   |   0comment

ConfusedLately 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.


Sharpening the Blades: Custom WordPress Dashboard, Wireframing and Communication

02.05.2010   |   0comment

Tim, 10 WordPress Dashboard Hackscatswhocode
This is a nice article that shows you how to get a customized WordPress dashboard. The article calls them hacks, but I would call them customizations. One that I have tried and loved is adding your logo on the dashboard page next your blog title in the top left hand corner of the dashboard. It’s a nice little touch that goes a long way.

MikeHow Wireframing Makes Your Website Designs Betterbriancray
The value of wireframing comes down to a simple idea: Wireframing forces you to think about your user interface design decisions in terms of user needs first, instead of in terms of what looks good.” While wireframing requires a little extra effort in the initial planning stages, it pays huge returns in the long run. We redesign less frequently, hit deadlines sooner, and best of all, greatly mitigate scope creep. So take your foot off the pedal, assess your client’s business objectives and user needs, and translate concepts into a tangible wireframe. You’ll be glad you did.

LukeFor Better Productivity, Communicate Lesscommunicateless
I agree with Joel Spolsky in one of Lifehackers latest posts when he says that adding more people to a project will only slow it down. I think this is especially true in web development. Once deep into a big project a web developer knows where things are and how they are related. If you throw five of them at the same project at some point they would end up stepping on each others toes. There is a chance that if things are planned out right each developer could tackle a specific task and then they could put all their pieces together to make the final piece. To do that though a lot of planning and meeting together would have to happen. This will probably lead to more disagreements and toe stepping. For those reasons I think getting the few people needed on the project and keep them there is the best way to accomplish a web dev project.


Sharpening the Blades: Document Ready, Admins and Automagic in CakePHP

01.19.2010   |   0comment

This edition of Sharpening the Blades features articles about creating admin sections with CakePHP,  how $(document).ready( ) can slow down your site, and the wonderful things CakePHP can do “automagically.” Hopefully these articles will help you sharpen your coding blades.

Chad, Creating an Admin Section with CakePHPcakephp-admin
I have come across James blog just recently (about 2 months). The guys blog is great. He does so much with CakePHP that it is great to see what he is doing and what he can do. But the reason I suggest this specific post is because it seems to be the first stumbling block that every developer comes across while using CakePHP. This article specifically will explain how to get an Admin section set up and working. I consider this one of the must needed to know things to develop correctly in CakePHP.

Benjam, Don’t let Document Ready slow you downdocument-ready
Everybody wants to have a faster loading website, and I am certainly guilty of putting every DOM related jQuery snippet into the $(document).ready( ) function.  This post showed me that this wasn’t absolutely necessary and gives good examples of when and how to break out of the document ready mentality.

Mac, The Dark Side of CakePHP’s Automagicautomagic-cakephp
I’m not sure I like the title of this article so much as I like the article itself, but it does point out some useful information about the “automagic” things that CakePHP does for you. Some of the things they discuss are definitely features that were designed very wisely, even though the article seems to disagree with me on that. There are definitely some automagic things in Cake that they mention that drive me crazy too though, and I don’t really see the necessity for the seemingly poor decision made by Cake’s developers. My biggest peeve they mention are the behavior it has (or had, this may have been fixed/changed now) for many-to-many relationships (a.k.a. HABTM). It is really a pain in the neck when your relationship table has other data in it, like the date/time when the relationship was added, or by whom, or a quantity, etc.


Kaizen in 2010: Stock Cliches, HTML5 Forms, & Web Advertising

Tim,on the topic of  Fun, Web Development
01.05.2010   |   3comment

One of the main focuses of our philosophy at Code Greene centers around the Japanese philosophy of continuous improvement known as “kaizen”. The web offers tremendous opportunities to learn from our peers, and sharing articles with each other has really helped us keep our blades sharp. Here are a few of the best articles we’ve read recently, submitted by members of our team:

Luke, Stop Using Stock Photography Clichés

stockI liked this article because I could really relate to the author. I am super sick of stupid stock photography. This type of stock photography has become meaningless to the user. Especially if the user has seen the same photo in other places before. As users, we are so used to seeing two business people shaking hands that we overlook it immediately, without giving it a second thought. Useless.

Mike, A Form of Madness

formForm design is awesomeness, but coding them? Not always the case. Luckily, there’s good news for form coders the world over with HTML5 on the brink of greater support. This article comes from an up-and-coming book all about HTML5. The author introduces some cool new tags and attributes that we can start using right now, including: placeholder text, autofocus fields, spinboxes, sliders, date pickers, and more! Exciting stuff.

Tim, On Web Advertising

adThis is something I have been very curious about lately, so to find this was a refreshing way to start out the week. It was nice to get Chris’s perspective about online advertising and I know he knows about it because all his work uses it.

What have you been reading recently?


Whirly Bin

Luke,on the topic of  CakePHP, Web Development
10.29.2009   |   0comment

We recently launched a small ecommerce site for Whirly Bin. They sell all sorts of stationary. They needed a super simple shopping cart. Instead of hooking in our custom cart in CakePHP we hooked it up to PayPal. Whirly Bin can add new products and upload photos and descriptions for those products through a simple admin section we created with CakePHP. Whilry Bin was great to work with and we got the site designed, built, and up really quick. Check out their site.


Easton Baseball & Softball

Tim,on the topic of  News, Web Development, WordPress
09.29.2009   |   0comment

We partnered with Omelet to create the new site for Easton Baseball & Softball. Omelet did the design and we built the site. Easton wanted a WordPress site, so that is what we gave them. This theme is extremely custom but at the same time it is really easy to use when adding new products or pages.

Easton Baseball
eastonbaseball

Easton Softball
eastonsoftball1


Steel Encounters Inc.

Tim,on the topic of  News, Web Development, WordPress
09.25.2009   |   0comment

Steel Encounters came to us wanting to be able to manage their photo galleries in an easy way. Initially they were having an employee upload the images and then write code to insert them into galleries. We suggested they use WordPress with a custom theme to get their site to function they way they wanted and make it easy to do so. All the galleries on this site are managed through the default WordPress gallery function.

Visit Site

Screenshot of Steel Encounters


Planning, Planning, Planning

07.30.2009   |   4comment

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.