If You Want IE6 to Die, Kill it

July 22, 2008 By Leave a Comment

Internet Explorer causes web developers a lot of problems. Specifically supporting older, less CSS/standards friendly versions like 6.0. Internet Explorer 6 still requires a lot of hacks and fixes to get working properly and in some cases can limit your design. Complaints about Internet Explorer 6 (IE6) in the web development community are a dime a dozen, everyone wants to complain about IE6 but nobody seems willing to do anything about it. If IE6 needs to go away, let’s do our part to help, stop supporting it.

Is IE6 Support Really Needed?

A lot of people will showcase their attention to detail and thorough craftsmanship by detailing the different types of configurations they use to test their markup. Every version of Internet Explorer, Windows XP, Vista, Firefox 2 and 3, Safari on OS X, Safari on Windows, the list goes on.

I’m not sure if this time is always well spent. Sure, it’s nice to be able to say that you got your code working in all of the “major” browsers but what’s the trade off? Hours of time spent tweaking and tweaking your CSS looking for the fix to that magical bug causing some slight visual discrepancies in IE6 on Windows XP? Doesn’t sound like a good use of my time.

Analyze Your Access Logs

Here are some statistics I have compiled from three sites that I either built or maintain. One site is a lower traffic informational site, another is a medium traffic wealth building program membership and e-commerce website and the last is a high traffic travel website that receives a lot of traffic from paid search on Google and Yahoo.

I have combined the log files since June 1st, 2008 and used some basic unix commands to count the number of times certain user-agent strings were found.

Here are the results as a percentage of each user-agent:

  • MSIE 7.0 – 50%
  • MSIE 6.0 – 30%
  • Firefox (2,3) – 12%
  • Safari – 4%
  • Others – 4%

Not surprisingly, Internet explorer has a huge lead over the Firefox, Safari the “others” combined. What is worth noticing is that IE6 users only make up 30% of the total traffic.

Does the Page Render Well Enough?

Are you are spending time trying to line up two divs that are a couple of pixels off, reducing the font-size of a certain element by a few points or trying to get that margin to be exactly ten pixels instead of twelve pixels?

Stop, now, you are probably wasting your time.

A LOT of people who use Internet Explorer use that browser because it came with their computer and they don’t know or care about alternatives. They are not concerned with web standards and CSS compliance. If a website looks and feels like most other websites they are not going to notice some extra padding or misalignments of three pixels here and there.

These visitors, like most, want to find the information they were looking for or accomplish the task they set out to complete. They are not interested in the minor design bugs that might be present on your site.

Chances are your website would be better, for everyone, if you spent that “IE6 bug fixing” time improving the general usability and information architecture of your site. Wouldn’t that be a better use of your time?

But My Client Insists

A site you have designed for a client has a couple of visual flaws in IE6. Your client mentions them to you and insists that they be corrected. They are using IE6 to preview the site as you work and everything on must be perfect before they are willing to launch.

Ask them which item they are willing to forgo on their priority list to account for the time you will spend fixing that IE6 bug. Instead of giving in suggest that you complete all of the other major functionality, launch the website and then if it is still a problem you can fix it later.

If they have server logs from a current website or a sister website, analyze those and see what type of user-agent break down you’re dealing with.

Remind them that there are certain aspects of the website that will help them accomplish their greater goals and that these are more important than minor visual flaws.

Fixing IE6 Bugs Does Not Make you Special

Congratulations, you solved some problem related to IE6 rendering that someone else already solved. You do not get a prize, you do not get respect you do not get to boast. Please, find another way to boost your twitter update count other than beating the oh so dead IE6 horse.

Everyone is as sick of hearing about it as you are of solving it. It is like the ever-present bad beat story of web development.

Stop Supporting in order to Stop Complaining

You are in control of your own IE6 bugs, after all you wrote the HTML/CSS that is causing them. If people were serious about never wanting to deal with these problems they would take it upon themselves to never write code that causes them.

Here are some things to keep in mind when stressing about IE6:

  1. Test early and often – Check your code at major design milestones to see if you have gone off track.
  2. Learn from past mistakes – Which HTML/CSS combinations got you in trouble the last time?
  3. It doesn’t need to be 100% – Determine an acceptable level of IE6 compliance and stick with it.
  4. Analyze your visitors – Don’t waste your time fixing problems for a small audience

IE6 is not going away for a while, even as IE7 ships with each new copy of Windows. There will still be a lot of people using IE6 and that’s okay, the web doesn’t need to work 100% of the time for everyone in every scenario. I am okay with a user in IE6 seeing a slightly different amount of padding around a box or a little extra border at the bottom of my header.

Perfect the Important Things First

You should strive to make fixing IE6 bugs the last improvement possible. Doing so ensures that your usability, architecture, design and content are the best they possibly can be. If you can achieve that level of excellence your clients will love you, their sites with thrive and you will have something to to tweet about.

Filed Under: Development, Riffs Tagged With:

Designer v Developer Death Match

July 11, 2008 By Leave a Comment

There’s been some interesting buzz going around about the role of designers and developers in the modern web development process. The demi-gods at 37Signals sparked some controversy when they posted about why they skip photoshop. Andy Rutledge posted an entry on his Design View blog about how to be an employable designer. James Bennett summed everything up nicely with his Designers and Developers: FIGHT! entry.

I’m surprised (and not at the same time) from the reaction from both designers and developers. Both want to keep their “I know something you don’t know” status while insisting that their jobs and skills are important. However, once we inject some professionalism into the debate it becomes clear why combining talents is the best scenario.

The Geek Ethos and Jock Revenge

Part of the greater geek ethos is that you’re a superior being who has used your talents to amass an amazing amount of knowledge and skill in a particular field. You step on those ignorant fools who can’t normalize a database or implement a design pattern. You have sacrificed your time and energy (and encounters with the opposite sex) to get to this level and Linus willing you will not have some pesky designer approaching your level of geekliness.

There is something about your average programmer, developer, dba and general nerd that gives them an inferiority complex where knowledge of a subject and skills in a work environment are treated like a zero sum game, “you cannot has mai skeels!”.

Study the Basics, Master Their Use

In the modern web development work flow, the best results occur when designers and developers work side by side to produce the end result. If the separation between the two is too great, there will be an obvious disconnect between the design of the finished product and the development of the finished product. Like a puzzle missing some pieces.

To achieve this melding of talents both designer and developer need to go beyond their comfort zones and learn something new from one another.

Designers

  • Learn basic HTML
  • Learn basic CSS styling and layout concepts
  • Learn how your developer’s program interacts with your design (the V in MVC)
  • Learn the basic concepts of your developer’s programming language

Developers

  • Learn the basics of information architecture, usability and visual hierarchy
  • Learn the basics of spacing, margins and padding for elements on the page
  • Learn how to use white space
  • Learn the basics of design (line, type, shape, contrast, texture etc.)

Ignoring Ego for Fun and Profit

If designers and developers can get past their own desire to be the most important person in the process and realize that their own personal short comings are what matter, the world of web development will be a better place. You will be amazed at how successful you are when you’re on the same page as your designer. It’s not enough to complain that the other person doesn’t know what you do and that they don’t respect your skills, drink your own medicine and learn what you don’t know if you want to become a better piece of the puzzle.

Filed Under: Development, Riffs Tagged With: , ,

The Secret to Greedy (but ethical) Hourly Billing

July 11, 2008 By Leave a Comment

The typical client project goes something like this:

  1. Provide estimate
  2. Complete work
  3. ???
  4. Bill time spent
  5. Profit

So why do so many people insist on killing their project’s profitability with endless tweaks and freebies? Take a page out of Gordon Gecko’s playbook and get a little greedy with your billing, your bank account will thank you later.

Selling Value

There is part of the project estimation process that is directly related to the sales process. Before you even get to the estimation process you should have a firm grasp on what exactly you’re estimating. Most importantly you should know what the value of this new work means to the client.

If, during your sales process you make an accurate determination of the client’s perceived value, you will be able to adjust your estimate accordingly to maximize billable hours and thus profit. If you cannot determine the value of this new work in the client’s eyes you will either charge too much (seemingly providing too little value) or charge too little (reducing your profitability).

Isn’t That Unfair

“I quoted 25 hours for this project, but only spent 15 hours working on it, isn’t it unfair to bill for 25 hours?”

Attention Beatnik: put down the bongos and look around. See this building, see these computers, those dreams and aspirations? See those hardworking employees. They are not concerned with the weight of your conscious, they are concerned about improving their lives and producing something of value for your clients.

I believe in the basic premise of supply and demand. At all points in the supply curve there are people willing to buy. You need to start thinking of your estimates and price quotes as a point on that curve and your client as the person who wants to buy at your price.

The client has accepted the reality that their project will be completed in the time you have quoted

But I Under Promise and Over Deliver!

I’ve got four words for ya.

More importantly, over delivering on your budget (by billing less than you said) is an empty gesture for your client and a step backwards for your profitability.

  1. If your clients are the type of people who love you for saving them 3 hours of billable time you need to find less budget oriented clients and more value oriented clients
  2. Not billing part of a project does nothing to send a long lasting, relationship building message, it’s as warm and personable as the GAAP
  3. It’s not personal, it’s not thoughtful, and it’s not remarkable.

Extra Time is Not Time To Waste

If you’re 40 hours into a 50 hour project and everything is complete and ready to go, do not spend those extra 10 hours adding little things and beautifying the project.

“But I want to make the project as good as it can be!”

That’s what those FORTY hours you spent earlier were for. If you’re done with a project, you’re done with a project. If the things you’re wasting time adding at the end are really necessary they would have been in the project to begin with. If you’re concerned about your quality of work to the point where you need to go back after a project is “done” and fix it, you need to take a serious look at your production process.

“But I’m billing for the extra time, so why not make things better?”

The project is done, ship it, bill it and move on with your life. You need to be jumping on that next project where you can put those extra few hours to good use.

You Run a Business, Not a Charity

If you have some moral qualm with charging people what they’ve agreed to pay then perhaps you should get into the non-profit business where you don’t have to worry about making such difficult decisions (or money).

If you’re still having trouble coming to grips with this idea, consider these karma boosting ideas:

  1. Donate a portion of your profits to charity (like Authentic Jobs does)
  2. Donate money, equipment or services to support a local community group related to your industry
  3. Spend some money educating your employees
  4. Purchase thoughtful gifts for each of your clients (not at christmas either, make it “for no reason” gift)

What Would Gordon Do?

Gordon Gecko would remember that:

  1. Your building something of value for your client
  2. Your client wants to give you money for this value
  3. Your dreams and aspirations are important
  4. You’re responsible for other people
  5. There is nothing wrong with being successful
  6. All assholes speak in absolutes*

*(You don’t need to bill 100% of your estimates 100% of the time)

Filed Under: Development, Marketing Tagged With: , ,

Who Needs The Show Action Anyway

June 23, 2008 By Leave a Comment

We all know that Rails has seven standard REST actions, index, show, new, create, edit, update and delete. Usually there are only views associated with four of them, index, show, new and edit with new and edit usually being the same. This all makes perfect sense for the public facing part of the application, but what about the administration portion of your app? Do you really need that show action? Are you going to be displaying the information in the same way as the public facing side of things? I’m starting to think that skipping the show action in the administration portion of the application is not a bad idea.

Context Is Key

One thing that I’ve noticed with your average “show” action in the administration portion of the web app is that it ignores the context in which the administrator wants to see the data. Rather than displaying what the public user will see, the admin show action is usually just a basic display of the information from the record.

For example, say you’ve got a content page that you have the ability to edit through the administration area. When you’re done editing it, you want to check the formatting, colors, links and general look of the page. Unless you’re using the same CSS styles and layouts for the public facing portion of the site and the administration portion of the site, you’re not going to be able to get a good idea of what it’s really going to look like. Sure you could recreate the public facing styles and part of the layout in the administration area but that’s jumping through a lot of hoops and getting out of DRY land.

If the information that you’re displaying isn’t view/layout dependent (like a user record) then there is probably no harm in having a simple show view that looks different in the administration area and the public facing area. However, if the information ends up being styled and displayed differently between the two areas, it might be worth for going the show action in the administration area.

How Rails Can Help

You’ve decided that it’s important to always view the public facing version of a resources show action when you’re in the administration area, luckily Rails makes it pretty easy to implement this functionality.

1. Add a new member route to your existing resource

  map.resources :pages, :member => { :preview => :get }

2. Add the new preview action to your controller

1
2
3
4
5
6
7
8
9

  class PagesController < ApplicationController
 
    # ...
 
    def preview
      @page = Page.find(params[:id])
    end
 
    # ...

3. Tell your action which layout to use

1
2
3
4
5
6
7
8
9
10

  class PagesController < ApplicationController
 
    # ...
 
    def preview
      @page = Page.find(params[:id])
      render :action => "pages/show", :layout => "public"
    end
 
    # ...

4. Add your new “Preview” link somewhere in your Administration area

1
2

  # show.html.erb in app/views/admin/pages/show.html.erb
  <%= link_to("Preview", preview_page_url(@page), :target => "_blank") %>

This assumes that you’ve got the public facing show template in app/views/pages/show and a layout file named “public”.

Now you can edit your records in the administration area but view them in the context that makes the most sense. While I might not do this to something like a user record or order receipt, this is definitely a good idea for blog posts, content pages and other administrable content.

Filed Under: Development, Ruby On Rails Tagged With: ,

Blog Improvements and Updates

June 21, 2008 By Leave a Comment

Tonight was the night of much needed updates and improvements to this here blog. It’s been a while since I spent a considerable amount of time doing anything major, but I did make some kinda-sorta-major updates, but those were mainly to the back end system. Hope everyone who’s visiting keeps enjoying it (or starts?)!

Thumbs Up!

Thumbs Up!

What’s New

  • Added comment display to post preview
  • Added post photo credit url field
  • Added post preview field
  • Added view all method to posts controller
  • Added view all link to post index
  • Added E-Mail link to sidebar

What’s Improved

  • Improved comment formatting display on post show
  • Improved photo display on post preview and show
  • Upgraded to Rails 2.1

What’s Changed

  • Changed popular post list display
  • Changed Photo re-size options

What’s Fixed

  • Fixed a problem with my paperclip plugin not being in my git repo correctly

In The Future

  • Add an AJAXy post-preview for the admin area
  • Add some styles so that the comment’s display better (damn reset.css)
  • Automatically post my git commit messages (_that_ should keep me honest)
  • Automatically tweet new posts via Twitter API (fun exercise)
Filed Under: Development, Ruby On Rails Tagged With: ,

Paperclip and Amazon S3

June 19, 2008 By 8 Comments

I recently added the ability to give each one of my posts a photo. It makes the entire site a bit less boring and gives it some human feel. I found the excellent paperclip plugin from the thoughtbot guys. This allowed me to easily attach pictures, have them resized and display them along side my posts. However, I ran into some problems with managing the upload files, no worries, Amazon S3 to the rescue.

Capistrano Deployment Problems

Each time you deploy your updated rails app with capistrano, it checks out the code in a new time-stamped directory and symlinks it to a “current” directory. The problem with this setup was that each time I updated my code, the uploaded files would be wiped out. I had a few options:

  1. Tell paperclip to store the files above the document root
    • Pretty simple, have to change the deploy recipe a bit
  2. Change my deploy recipe so “save” the files that have already been uploaded
    • Kinda cumbersome and a little “wrong” feeling
  3. Tell paperclip to store the files on Amazon’s S3
    • No changes to my filesystem or deploy recipe!

Paperclip Setup

In my Post model I’ve got

1
2
3
4
5
6
7
8
9
10

  has_attached_file :photo,
    :styles => {
      :tiny => "35x35",
      :preview => "175x175",
      :large => "300x300"
    }, 
    :storage => :s3,
    :s3_credentials => "#{RAILS_ROOT}/config/s3.yml",
    :path => ":attachment/:id/:style.:extension",
    :bucket => 'lengelzigich_blog_buckit'

I’m telling the paperclip plugin to resize my uploaded image in a few formats and also telling it that I want to store the files using S3 rather than the file system. I’ve added my amazon S3 key/secret code to a simple yaml file and I’m all set. Almost.

Install right_aws gem

Didn’t realize this right away but needed to install the right_aws gem.

Filed Under: Development, Ruby On Rails

Adaptive, Iterative and Agile Development is Fantastic

June 14, 2008 By Leave a Comment

The ability to work in short bursts of agility leads to amazing results. The ability to quickly adapt to changing needs brings satisfaction. The ability to combine all of these with Ruby on Rails makes for a happy developer. Adaptive, iterative and agile development with ruby on rails is fantastic!

Some Monkey Guy

Some Monkey Guy

What I Want Right Now

When I “launched” this blog a few weeks ago I had the ability to create categories and write posts. That’s it. No comments, no tags (still don’t have those) no permalinks, no photos no nothing. Just a really simple system of posting in various categories. This was fine for a while, but I wanted more. So, as time permitted I slowly added new features. Here’s a rough timeline with some made-up version numbers

1.0 - posts and categories
1.1 - user accounts
1.2 - polished admin interface
1.3 - permalinks
1.5 - comments
1.6 - admin comments
1.7 - new comment notifications
1.8 - photos

Together these would have taken a while, but as separate pieces they were simple digestible easy to complete tasks, perfect for my workflow.

Ship It, LDO

I would have loved to have all of these things and more when I launched originally but it wasn’t in my time budget so I had to break it up this way. I just needed to get something up and running, so I went with the most basic of basics. Turns out, I found some things that I could do with out right away (tags, search, ratings) and found some things that I wanted (permalinks, comments, photos). Everything bubbled up according to it’s importance and so far everything feels just right. When it doubt, just ship it. Like duh, obviously.

Rails Tie-In

If you haven’t realized quite yet, Ruby on Rails makes this agile/iterative approach super easy. Between migrations, built-in helpers and BDD I was able to add all of this new functionality piece by piece knowing that I wasn’t going to break anything I already had. Plus it didn’t take very long (learning curve not withstanding).

In a world dictated by client requests and boss-based to-do’s I don’t often get the chance to work like this, but for now I’m cherishing every moment.

Filed Under: Development, Ruby On Rails Tagged With: , ,

NiftyCube Corners and IE7

June 10, 2008 By 2 Comments

I recently started on a project that called for rounded corners. Some areas where supposed to be “fluid” which present a problem with my usual rounded corners method. However I’ve used NiftyCube Corners in the past so I was able to find an easy solution.

CSS Background Colors and IE7

I spent a lot of time trying to figure out why none of my rounded corners were showing up in IE7 but they worked fine in FireFox and Safari. I finally stumbled upon the fact that IE7 cares about how you define your background colors while the others do not.

My CSS looked something like this:

1
2
3
4
5
6

  div#box{
    background: white;
    margin: 0 auto;
    width: 30em;
    padding: 1em;
  }

This did not work, and it’s because I specified the background color using a word and not the hex code. I changed it to #FFF and all is well. So make sure to check this if you’re NiftyCube Corners aren’t working in IE.

Final CSS:

1
2
3
4
5
6

  div#box{
   background: #FFF; /** <----- CHANGED **/
    margin: 0 auto;
    width: 30em;
    padding: 1em;
  }
Filed Under: Development Tagged With: ,

Learning Best Practices, Idioms and New Languages

June 5, 2008 By Leave a Comment

A few days ago I was listening to an episode of the StackOverflow Podcast and Jeff Atwood said something interesting about how he did a lot of reading as a kid but didn’t do much discussing about said reading with other people. The problem being that he had a lot of words that he wasn’t sure how to pronounce outside of how he had originally determined they should be pronounced. I was thinking about how this translates to code constructs and programming styles and how it’s easy to get stuck in your newb ways.

How Do You Say That?

I’m sure we’ve all experienced what Jeff was talking about, you’re reading something and you come across the name of a person or a place and you’re not really sure how to pronounce it but for the sake of moving through the material your brain comes up with something and you continue to use that each consecutive time it comes up in the material.

It’s only the next day when you’re talking about the text with a friend that you hear their alternate pronunciation of the word. Sometimes neither or you are sure what the correct pronunciation is, but you now spend the rest of the conversation saying each pronunciation, so as not to be rude, when referring to the word in question.

Learning PHP

A lot of programmers start out learning PHP. It’s easy to learn, make something, lots of resources etc. etc. However, I think that you tend to do a lot of the “brain deciding how to do this previously unknown thing” decision making while you’re learning. There was a post on The Daily WTF today about somebody who basically re-implemented the functionality of $_GET using their own hacked together POS method. It’s good for a laugh sure, but it’s not that unreasonable when you think about it.

Imagine you’re learning PHP and you’re like most geeks, introverted, you want to accomplish this goal of learning a new language, but you’re not planning on spending any time discussing it with other people. This is especially likely if you’re not learning in a work environment with other people. Since you don’t know a lot of the idioms, best practices and commonly used syntax you end up figuring things out and deciding that’s just how it’s done. I only use PHP in this example because of its wide use and forgiveness when not sticking to accepted practices (are there any?).

You find ways to do things and you stick with them, for good or bad, until you find out a different way.

Quit Being an Introvert

Do yourself a favor and get over keeping to yourself, you’ll be a better programmer and you might learn something about social interaction.

  • Join mailing lists (*and participate*)
  • Join forums (*and participate*)
  • Attend local in-person live events
  • Find some AIM/YM/MSN/Gtalk buddies who you can bounce ideas off of
  • Seek the advice of the more experienced
Filed Under: Development, Ruby On Rails Tagged With: , ,

The Battle Between the Right Way and The Working Way

June 3, 2008 By Leave a Comment

I’ve this got awesome full stack framework at my disposal, various books, videos, articles and open source examples, yet rolling my own commenting system was a challenge in and of itself (otsn: is this the same as ‘unto itself’). I thought I had things working for me with my nested routes and simplistic system, however I guess it goes to show you that even the simplest systems can be massively complicated and confusing in the right hands.

Posting to Nested Routes and Displaying Errors

I’ve got some nested routes:

1

  map.resources :posts, :collection => {:feed => :get}, :has_many => :comments

Posts have many comments as you’d expect. So this gives me nice URLs like /posts/5/comments/new and named routes like new_post_comment_path. Easy enough. The problem I ran into was following this common rails convention:

  1. Form is displayed when GETting a Controller’s new action
  2. User enters information in form
  3. Validation fails
  4. “new” action is re-rendered from the Controller’s create action

This is simple and not even worth mentioning for most scenarios, however I got myself in a bind when I tried to apply it to my posts/comments scenario.

  1. Post’s “show” action is rendered (PostsController)
  2. Comment’s form is displayed (PostsController)
  3. User enters information into Comment’s form and it’s posted to /posts/:post_id/comments (CommentsController)
  4. Validation fails and “form” has to be re-rendered (CommentsController)
  5. WTF now?

I can’t just re-render the PostsController’s show action (I messed around with rendering the template with render :template but that didn’t really work). I can’t render the PostsController’s show action again and hop down to the Comment’s form (I tried using :anchor and all sorts of shit, no luck). At this point I was really stuck, couldn’t really figure out what to do next, rails confidence shattered, ego bruised, internet more browsed… eventually I gave up for a few days.

The Right Way and the Working Way

There’s something about Rails that makes me want to do things the “right” way. I don’t even know what that means half the time, but something about the community, the examples, the general vibe of everything suggests that there is usually a “right” way. Sometimes I think I get a little too caught up in this. Coming from PHP where there isn’t really a “right” way, I think part of me is searching for some structure and validation where I can have some confirmation that not just BSing my way through a problem is a good solution.

I got to a point with this problem where I basically gave up. I shelved the problem for about three days, just kinda ignored the whole thing. When I finally came back to it, I had this genius idea to not be fancy and just display the Comment’s form on it’s own if validation fails. This works in that it solves my problem, it’s not totally out of this world usability wise and it has allowed me to move on to solving other problems and making new improvements.

When you’re at a crossroads of doing something the “right way” and the “working way” you need to ask yourself if it’s worth forgoing the “right way” in favor of the “working way”, often times you’ll find that the “working way” is “right” enough and you’ll save yourself a lot of time and frustration, saving your energy to tackle more important problems.

otsn: off topic side note, LDO

Filed Under: Development, Riffs Tagged With: ,
« Older Posts
Newer Posts »