Wanted: UX Developer

Posted in jobs,seattle by Kris Gray on September 12th, 2007

We want you!

If you…

  1. Can write Javascript
  2. Write structured HTML
  3. Can style said HTML with CSS

Consider yourself a front-runner for a shiney new job! Apply kgray at eproject dot com.

No comments

Bad Communication, and the Golden Zone.

Posted in development by Kris Gray on September 7th, 2007

So I had written a post about communication, and I want to go back and affirm that there good and bad communication, the type I was promoting was the good kind, obviously, but what are the dynamics of this bad joo joo you speak of?

This situation exemplifies a bad conversation

  • Dev Zero Cool looks up and sees Dev Skywalker coding away, obviously lost in the zone.
  • Dev Zero Cool decides to ask Dev Skywalker if he knows what the valid values are for the background-color property of a div.

Now you don’t need a blog to tell you this isn’t a good thing. But why did this happen? What can you do about it?

Don’t get caught up in that Dev Zero Cool asked such a stupid question, besides the fact that he asked something that could have easily been answered by a Google search, or an MSDN reference, was that the close proximity of the two developers promoted conversation, any conversation. It is just as likely Skywalker would ask Zero Cool about his fantasy football team or lunch plans and the situation would be reversed yet just as damaging.

Realizing you can’t solve this problem is key, you don’t want to kill all semblance of non work conversation as along with it would go your company culture (if you had it to begin with), but you can add road blocks. Roadblocks are great because your not preventing people from having great conversations, your just making it so people actually have to get out of their chairs, do something that takes just long enough for them to do a sanity check on themselves and make it take effort to bother another developer.

Note: If you make this to much of an effort, people will not want to talk to each other, very, very bad. There is a golden zone here for you to exploit!

Essentially, we are talking about offices, though if you were lavish enough, you don’t need the walls, you just need enough space between two developers desks so that they would actually have to walk over to one another and talk. (800feet ought to do it) Offices are great cause two developers could be right next to each other without disturbing one another, and then still have the obstacles of doors, walls, people in hallways, etc.

Managers HATE developers talking about offices, its very difficult for a manager to tell a developer that they don’t need an office while you are in theirs and they would be loath to relinquish such accommodations. Yet they don’t really have many good options, they can’t tell everyone to go home for two weeks while they tear down the cubicles and put up walls, even then they will almost never have enough space along the walls to give offices (with windows) to everyone. Which you know is what everyone really wants. But thats a different topic.

This is one of those great, spend money, get a productivity gain subjects. Which when considering developer productivity, how many topics fall under such a category? Training? sure. Equipment? You bet. Ummm, strippers? No, not quite. You’ve gone through great expense to find some of the best developers your money can buy, you shouldn’t have them working at anything but the peak level.

No comments

Mozilla Rounded Corners

Posted in development by Kris Gray on September 1st, 2007

So I’ve been battling with an implementation of rounded corners that used a div around another div, utilizing the :before and :after pseudo elements to insert two of the rounded corners, then the backgrounds fill out the other two corners. This really turned out to be a fantasy as it utilized the !important hack, and the box could only expand with the content inside of it because of the way the :after pseudo element works. In the end your doing of lot of heavy lifting to produce something with a lot of problems.

Hello Computer

But… what if I could give you a class, that would add a rounded border to any element you desire in Mozilla, while degrading to a box with square corners in every other browser, while needing no images and no extra HTML?

Well thats been a reality for quite some time thanks to the Mozilla proprietary CSS properties.

.round {
/* The Magic */
-moz-border-radius: 10px;
/* For CSS3 */
border-radius: 10px;
/* Box Styling */
border: 1px solid #333;
background-color: white;
width: 200px;
height: 200px;
padding: 10px;

Here is what you get for the following HTML

<div class="round"></div>

For Mozilla:
Rounded Corners in Mozilla

For everyone else
The same style in IE7

If you examine the class, you’ll see easy rounded corners are coming in CSS3. You may also notice the boxes are different sizes, but this is because there is a 10px padding added to the element and the box model for IE says that the 200 height accounts for he padding, where as Mozilla adds the extra 20px’s (10 for top and 10 for bottom) to the height making the box 220px high.

Now we do have the slight problem that this only shows rounded corners for Mozilla, which is one of the smaller percentages of browsers, yet in regards to my situation at eProject, we only are particularly supporting Mozilla and IE. Even then, the ease of this implementation is certainly worth the trade-off that IE people don’t get the softness of rounded corners.


Conditional Comments, just do it.

Posted in development by Kris Gray on September 1st, 2007

So earlier this week I developing some CSS code, that I needed to mandate a minimum with, that grows as the content in it grows. Firefox has a nice min-height and a height attribute, so I use the following code.
#ExpandBox {
min-height: 34px;
height: auto;

But if I use that code in IE, it will ignore the min-height attribute, and basically treat the height property as its own min-height, collapsing the box to the size of a pea. To get around this, I used the !important hack.

#ExpandBox {
min-height: 34px;
height: auto !important;
height: 34px;

Since Firefox understands important as the end all be all, it ignores further decelerations of the height attribute, where as IE doesn’t exactly see it that way, so it uses the next height attribute. Since IE will auto expand anyway, we basicaly have success. Yaay me.

Now everything works perfectly fine here, but now take out the ability to use the !important flag in the future and hold everything else consistent, DOH now I’m screwed.

We’ve got some solutions to this, the best one probably being conditional comments.
<!--[if IE]>
<link href='ieonlyoverrides.css' rel='stylesheet' type='text/css'/>

So this lets me declare a seperate #ExpandBox decleration that overrides the general one for standards compliant browsers.

I’ll be the first to admit I dispise having to do this in a seperate file. Why can’t we just do this in the CSS file? Well, principally, we would like to try to avoid IE only checks in the CSS stylesheet (well, really anywhere, but particularly in the stylesheet). Its capability checks we should do, so that if IE all of a sudden started supporting the !important flag as FireFox does, were still golden, we don’t have to change a thing in our previous code. Yet if we had an IE check in there, well, they are spread all through the file and there’s no getting around adhearing to those rules.

If you’ve got a style guide in your system, and you want it to degrade nicely for IE, you will sooner or later need to implement this type of feature. You avoid having to use hacks, you won’t need to try to shove all the degrade code in the same class, and well, you can easily erase the ieonlyoverrides.css styles and see how your browser reacts every time there is a new version of IE.

1 comment