css comments edit

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.

sql, sharepoint comments edit

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.

net, vs comments edit

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.

Just looked at my stats. The number two search phrase that leads people to my site is:

you don t have to be rich to be my girl

What in the…?!