I’m a high-stress individual. I stress out about everything. Little stuff, big stuff, stuff I have no control over, stuff I have control over, my stuff, your stuff, his stuff, her stuff… I stress about everything.

I don’t know if this is a function of my ultra-type-A personality, my distinct need for a vacation, or what, but it is certainly the case.

As usual, things are just not letting up for me.

I just bought this house I’m living in - my first house - and I’m still coming to terms with the additional financial burden it places on me as well as the general issues of home ownership. (Note to you “condo” people out there - this has nothing to do with the yard work and everything to do with the things that anyone deals with when not renting: taxes, mortgages, indoor maintenance, home improvement, etc.) It’s taking some time to adjust.

With that goes this bathroom situation. For the life of me, I can’t get a drywall contractor to call me back or be available. The ones who call back are booked for the next two months; the ones who aren’t booked are unreliable. Having no closure on this thing is killing me. I can do minor handiwork around the place, but when it comes to something larger like retexturing a wall, I’m not quite ready for it. So the bathroom sits in this near-unusable state of limbo, waiting for completion. I need it finished.

At work, I’m getting a crash course in being a manager. Over the course of the last week I’ve gotten two contractors in that generally report to me (technically they report to the project manager, but I’m the one assigning tasks and following up on them). I’ve never really had to deal with that aspect of development, and making sure they have enough to do, answer their questions, keep track of the project, and develop on the project (all the while interviewing other contractors for additional positions) is not something I was prepared for. I guess we all evolve to that point eventually, I just wasn’t prepared, you know?

Not only that, but I’m coming on a time where I have a career decision to make. I’ve pretty much topped out where I can go in the IT organization so I have to decide: Do I stay where I’m at and enjoy the various perks that go with being in IT (among those being a nice big cube - like double the size of other cubes, a good boss who’s also a great friend, and a reasonable amount of autonomy on projects) or do I do a somewhat-lateral shift over into the product development group where there will be more of a chance to grow (both professionally and financially)? I’m thinking I’ll be making the move, but pondering on that is a stressful thing, like getting a whole new job.

This morning on the way to work my “check engine” light came on. This happened a back in May, too (though in the server move I lost that blog entry). The first time, it was the oxygen sensor. Who knows what it is this time? They can’t get my car in until Tuesday, which, it being Friday now, is three days of waiting and “driving moderately” until I can get there. The dealer, of course, is on the other side of town (which means possibly two hours away, maybe more, in the morning), so I get to look forward to that come Tuesday. Not to mention the last time it was in, a whole bunch of other service (new brakes, etc.) had to be done, too, so it was an unexpected bill of several hundred dollars - right after moving into the new house. I can only anticipate what it’s going to be this time.

I won’t even get into the other moderate financial speedbumps (usually in the form of unexpected bills - things like having to purchase a washer and dryer when we moved in because we didn’t think about the fact we didn’t own those appliances) we’ve run into as of late. When it rains, it certainly pours.

So here I am, getting ready to phone screen another job applicant (which stresses me out because not only do I hate the phone, I hate talking to people I don’t know over the phone). That’s where it sits.

I suppose I had better get on with stressing about how to avoid cardiac arrest by this time next year.

I’m working on a project at work where we use a combination of ASP.NET user controls, CSS, images, and JavaScript to offer a “theme” sort of effect. Change the set of user controls, etc., and magically the site takes on a new look.

As a demonstration, I implemented two different “themes” for the site - one being a “fluid” layout (sizes and positions of objects on the screen being relative to the browser window width) and the other a “fixed” layout (everything absolutely positioned and sized).

I am a big proponent of the “fluid” layout, particularly in corporate sites. I feel that there are too many sites out there that absolutely size everything, and while it may look like a nice print-based brochure, I feel that having half of my screen left in white space because the site designer fixed everything at 800 pixels wide and I’m running my monitor at 1600x1200 is a little less than optimal. Not to mention the accessibility issues surrounding absolute font sizes.

I got asked a question this morning and I couldn’t handle it any more. “On the ‘fluid’ themes, will we ever be able to avoid [text] wrapping? For example, on [the fluid theme we implemented, if you] change to largest fonts, make your browser about the size of an 8x6 screen and it wraps out the wazzoo. It will be hard to say ‘that is how it is’…”

My (slightly edited) response:

In a fluid theme you will never avoid text wrapping. NEVER. I realize this is a difficult thing to accept and it’s why many places don’t implement it. That said, text wrapping is a natural occurrence that should happen.

Look at some examples in your everyday life that you don’t think twice about… and might consider it crazy if text wrapping didn’t occur:

• Outlook
• Amazon.com
• Word

Using a fluid layout is a paradigm shift. People need to stop thinking in terms of “do all these things line up pixel by pixel” or “how much exact control can I exert over my web site to make every single experience 100% identical” and move into the idea that people with different monitor resolutions, font size settings (which may override ours, whether we like it or not – check out the “Accessibility” button on the “General” tab on the Internet Explorer “Internet Options” menu… Tools -> Internet Options), and other needs will have to be accommodated. What happens when a blind person comes in with a screen reader? Are they going to care that some error message might wrap to the next line? What about browser compatibility? We already know different browsers render things differently… do you really want to fight and tweak with every single browser out there to make sure text doesn’t wrap?

The solution is not to fight against it but to design for it. Embrace it, assume it will happen, and accommodate for that.

I realize in the fluid theme we’ve made some strides towards that, but as you’re also noticing, we’re finding some shortcomings with it that we failed to design for. I don’t have all the answers here. Maybe we need to step back and take some actual time to redesign it. Maybe we need to step back and look at the whole way the site works in relation to themes and invest time in making that more robust. We probably need a graphic designer who knows how to work with the web, and we need them to create a more robust “fluid” layout.

I can’t stress enough that the focus should not be on how to avoid text wrapping but how to design to it. Maybe error messages should all show up in validation summaries at the top of the page rather than in text next to the field with the error (and then just display a little error icon next to the problem field). Maybe they show up on the next line (or on the line above the field) rather than next to the field where wrapping is disturbing.

Side note: Consider this: when you say “I don’t want the page to be less than X pixels wide” you’re once again working in pixels. If any measurement you mention has the word “pixels,” “points,” or “picas,” or any unit other than a relative percentage based on the browser size, you’re back working in “print mode.” Print mode is fine when you’re talking about how you want a given page to print out when the user clicks the “print” button. It’s much less okay if you’re trying to work in a fluid mode. Instead, try something like: “I want a three column layout with a header and footer. I want the header to have the site logo and some navigation. The logo appears above the navigation tabs. The font size in the main navigation tabs should be ‘x-small’ and the sub navigation tabs should be size ‘xx-small.’ Column 1 should be 15% of the browser window width, Column 2 should be 65%, and Column 3 should be the remaining 20%. The text in each column should be size ‘small.’ The footer text should be ‘xx-small.’” Right there, I just defined a complete site layout using relative positioning (“above” or “below,” in relation to headers and footers) and relative sizing (percentages or relative font sizes). Never once did I provide a hard measurement for any of the items that would appear on the screen.

I realize that’s not a simple task. It is giving up a lot of control over the page layout. The user is the person who reaps the benefits of our forethought, though, and isn’t the user the ultimate, end customer we need to please?

We can go around and around with this all day for the rest of our lives. It’s one of the never-ending battles - Google for “fluid layout” and you’ll find everything from discussion groups to usability studies

• between web designers. The long and the short of it is, you can’t have your cake and eat it, too. There are benefits and drawbacks to both fluid and fixed layouts, and based on the layout type you choose, you need to design to it and embrace it for what it is.

…I do realize I am not currently practicing what I preach. I need to redesign my site, and when I do, it will be a fluid layout.

Here’s an interesting tidbit for you. We are currently trying to do some work via the search web service in SharePoint Portal Server 2003. (You may have seen my test app that I wrote for checking out searches and results via that web service.)

Seems there’s an internal debate at Microsoft over which team should be handling our support call - the SQL Server team or the SharePoint team. See, we’re having trouble getting metadata returned correctly when executing full text searches. At first we thought it was an iFilter problem or maybe something weird with our setup…

Turns out SQL Server handles full text queries differently based on the platform it’s installed on - Windows 2000 server vs. Windows 2003 server. I didn’t get any details on exactly what the differences are (I’m only peripheral on the case; another developer here is actually talking directly to the support folks), but that’s the situation.

One would think that it shouldn’t matter what platform the product is installed on, it should consistently handle queries the same. Maybe different optimization or something, but the actual syntax possibly being different? It boggles the mind.

I’m working on some ideas to enhance Solvent and I’ve realized that one of the things I want to do will require some low-level shell programming.

I hate low level shit.

Looking at MSDN, it seems that the only real way to do it is to use C++ (because of the ridiculous amount of weird pointer stuff that’s happening).

I tried pInvoking my way to freedom and leisure. There’s only one problem with that: When there are marshaling issues, I’m not a COM person… I don’t know how to fix them. I live in a higher-level programming world: garbage collection and high-level data structures and no fussing with memory allocation issues. It’s been like seven years since I’ve dealt with anything C or C++ related.

Try as I might, though, I can’t get myself quite DllImported into the Windows Shell.

As such, this weekend I went out and bought Visual C++ .NET - Step By Step. I’m only on like the second chapter (no time!) but I’ve skimmed through the rest.

Lots has changed since I last worked with this stuff. ATL? Funky reserved words (__gc, __value, etc.)? Maybe that’s standard stuff that has always been around, but then, I learned C++ in Solaris on SPARC workstations, which means I read a little about MFC but never had opportunity to use any of it.

(By now, all of you VC++ people out there are shaking your heads. Gimme a break; I’m [re]learning!)

It’ll be good to come up to speed on it; if anything, an interesting exercise in crash-course style learning. Who knows… I might even read the whole thing instead of just enough to get my project done. Heh.