I’m a long time Apple fan, but the system they created for checking iPhone availability is a complete disaster. The way they have it set up sounds really great. You go online to apple.com/retail after 9pm each night and check your closest store and the next closest group for availability the next day. The problem is the stores don’t get shipments at the end of the day. They get shipments at some point during the day and put the phones on sale. Therefore when the website told me that my store would not have iPhones tomorrow, that was not true. Then they inevitably sell out of the phones before closing and once again at 9pm when you check the site it says they will have no iPhones the next day.

The situation Apple has created for themselves is that they only way to determine if your store has stock is to either go to the store, or more likely call them constantly to find out if they have gotten a shipment. This has got to be really fun for the employees at the store!

There is a simple fix for this situation. All the stores have to do is keep the shipments that they get during the day in the back until the following day. Then at 9pm the site would be correct in saying the the store will have iPhones in stock the next day. That way you don’t have to call the store, and if you really want a phone, you can show up when the store opens and your likely to get one. This is a simple fix. I would have expected more from Apple.

While I absolutely love the new 2.0 software on my iPhone, I can’t help but be disappointed by the lack of good documentation on why the software won’t work with my Exchange Server account. There also seems to be a bunch of misinformation regarding if you need a “Business Plan” on your AT&T account or not.

I’ve had to step back to my working IMAP configuration for the time being until I figure this one out. I’ve posted a thread over on Apple Support, but that doesn’t seem to be going anywhere.

I’ll keep you posted, and I ask you all to do the same. Post your tips & suggestions and I’ll continue to compile them.

This past week while working on a project I ran into the most frustrating IE7 bug I’ve encountered to date. I have tried to recreate it in separate environments from the site I was developing but up to now have been unable to do so. However, in hopes of helping someone tortured by this bug down the road I will give my best guess as to what is causing it and explain how I fixed it.

First off, the bug looks like this:

Alright, the first thing is that this bug comes into play only in IE7 (IE6 works fine). Second, it seems to occur only when there are html elements nested inside an anchor tag and these elements are told to change their background properties on the :hover phase of a parent element. This most often happens with nested list drop down menus like the example above. Third, the elements that act buggy are positioned absolutely within the :hover(ed) parent element. Once again this only really occurs with drop down menus.

In the code below the element that gets the bug is the anchor element within the nested list items.

<div id="navigation"><ul id="nav">
<li><a href="" title=""><span>Solutions</span></a></li>
<li><a href="" title=""><span>Investors</span></a><ul>
	<li><a href="" title="">Buggy nav item 1</a></li>
	<li><a href="" title="">Buggy nav item 2</a></li>
	<li><a href="" title="">Buggy nav item 3</a></li>
</ul></li>
</ul></div>

What happens is that when a top level navigation item is hovered over the drop down appears, however, because a top level nested element had a background image change on the :hover state the drop down list loses its padding. In essence, the ul > li > ul > li > a element will lose its padding and end up looking like the buggy menu above. Although once the user rolls over this anchor element it will once again regain its padding and jump back into place.

When would this occur?

Good question. The most likely occurrence of this would be if you had a navigation menu that required a lot of imagery. For example, a menu with which you were forced to use a span tag to get one extra background image. And then on the hover you wanted the span background image to change, perhaps to point an arrow downward instead of sideways. Therefore the user would know which top level item they had hovered over even if the mouse was placed on the nested sub-menu below. In this case you’d probably have some CSS like this.

#header ul#nav li.active a span,
#header ul#nav li:hover a span {
   color: #fff;
   background: url(/images/icons/downward-arrow.gif)
   no-repeat 15px 50%;
}

Alright, so basically you decide to help the viewer see what nav menu they’re on by changing the span background property to have a down arrow. Unfortunately all you end up with is a buggy IE7 drop down menu. What’s the best fix? In this case the best fix is the apply that downward arrow to the li background and just have the span item go transparent instead of change the image on the fly. One added bonus to this method is that you won’t have to load that image on the hover state. Still, this means that if you’re using the li background already you will be forced to find another way to highlight the top-level navigation item.

What’s really going on here?

Apparently when IE7 tries to re-render a background image on the :hover state, nested absolutely positioned elements are reset to their default value causing them to lose padding, etc. Hence, the best option is to avoid making IE7 redraw background images when there are absolutely positioned nested elements. Instead, rely on background colors or transparency for effect, or apply the effect to the li background.

Last Thursday we had several hours of straight interviews, all but one of them were outstanding candidates. The first round of interviews for us is a “get to know” session. In 1 hour we have to get at the essence of the person. We actually put a good chunk into the person’s “blink factor.” If we aren’t feeling just a little bit of love in the first 2 minutes, then the candidate is going into an uphill battle.

After the “blink factor” we really want to know the person. How did they come into their career choice? What are they passionate about? Are they multi-dimensional? Are they a ridged or free-thinker? etc… Then we start analyzing the skill and experience level. Resumes don’t amount to much; just because a candidate lists every single program they’ve worked on doesn’t mean they are qualified for the job. Likewise a track-record of short job stints doesn’t mean they hop from company to company. In fact, one of the candidates in the last round of interviews didn’t list a job which lasted longer then 1 year. However, during the interview it became clear this candidate was very passionate about his line of work and the stints were not by choice but by circumstance.

The next part of the evaluation is the 4 staple questions which apply to everyone we hire at Imulus:
1. How do you rate your organization skills?
2. From 1 to 10, where are you with your writing skills and can we see samples?
3. Do you like formal meetings or ad-hoc gatherings?
4. How do you like to be managed?

Sure, they can lie their way through these questions but if they make it back to the second interview then the WHOLE OFFICE will have a shot at uncovering the real truth. At that point someone will smell bullshit. Anyone at Imulus has veto power, it needs to be a unanimous decision.

The last part of the evaluation is asking the question, is this person the best fit for the job? I would have hired several candidates if we were looking for an mid-level .NET person or Web developer, but we are looking for senior level experience. With just interviews and references to go off of it’s often tough to gauge how the candidate will respond to a real-working environment with our office dynamics, workload and management style. This is the part of the interview where I believe you have to trust your gut. I’m a big believer in quantifying data and looking at things scientifically but sometimes that feeling in the pit of your stomach is often the best judge of a situation.

I’ll guess you’ll see shortly who we’ve decided on.