Tag Browsers

DHTML “Fun” — Scrolling Tables

A project I’m working on at the moment is a financial application (woo! party!) that displays huge tables of data. When I say huge, I mean it’s possible the byte-weight of the data will be greater than the weight of everything else combined.

So, in searching for a way to make these tables more usable, I came across two examples of interesting DHTML:

First is ActiveWidgets.com (Mike found this one). They sell really very sophisticated JS widgets that do a very good job of displaying and allowing you to interact with a table, in ways normally reserved for Excel or the Windows Explorer window. They work in both IE and Mozilla (not Safari, however), but cost quite a bit if you want to use them commercially.

Second is a CSS-based solution, Pure CSS Scrollable Table with Fixed Header. While I would love to make use of it, it depends on fixed column widths, which is not an option for me.

Third is this, much simpler one. It successfully locks down the header rows and column while scrolling the rest of the table. In IE only. But, that’s ok for now for two reasons: 1. The project is an internal application and is being built for IE6 only. 2. I can use Mozilla’s correct implementation of TBODY and overflow: auto to achieve the scrolling without JS.

I’m going with the third method. I’m also going to add some touches like subtly highlighting the row and column you’re hovering over, and allowing the user to click a cell to lock the highlight, so they can scroll around some more, but still find their way back.

I’ll post a prototype when I have it ready.

MSNBC’s Redesign — Typically Shortsighted

In case you didn’t know, MSNBC.com has recently been redesigned. I’m going to leave the qualitative design critique to the designers, but I thought I’d point out a few glitches that speak to a larger problem.

The MSNBC Home Page

All my technical explanations are inferences — I’m lazy and I don’t feel like digging through the site’s multiple style sheets.

Auto-Selecting a Form Field

Here’s a pet peeve of mine: 9 times out of 10, when a web site automatically grabs the cursor’s focus and puts it on a form field in the page (usually a search or login field) it’s a mistake, and it makes me gnash my teeth.

Why? Well, from a purely philisophical standpoint, it’s never a good idea to take control of browser functions usually reserved for the user. It often causes confusion and resentment. From a practical standpoint, it messes me up.

Like a lot of people, I use a number of keyboard shortcuts and commands while I browse — the most frequent example being the use of the delete (or backspace) key instead of clicking the back button. When the focus is shifted to a text field, this stops working because the cursor has switched to “text edit” mode and is trying to delete some text in a field that I may not have even noticed.

This is annoying because my browser stops behaving as I expect, meaning:

  • I have to figure out why;
  • I have to correct or work around the problem.

While neither of these are significant challenges, they are an interruption of my train of thought; they derail my browsing experience and act as speed bumps.

Motivations

I’m guessing there are two main motivations for doing this:

  1. To save the user time;
  2. To call attention to a feature they (the site’s owner/developer) feel is important — a subtle “ahem.”

These motivations, while they may seem logical in theory, are problematic in practice.

The Road to Heck…

Motivation #1 makes an assumption that is likely to be false, e.g., that they can anticipate what my next use for the keyboard is going to be. They may expect me to use the search field, but more often than not I’m going to have other plans.

Even if they have correctly anticipated my next action, it’s still likely to be ineffective: I’m guessing that most web users (especially experienced web users) look with their eyes and the mouse at the same time, meaning that by the time my eyes have located the text field I’m looking for, the mouse pointer is right there with them. At the most, Motivation #1 has saved me a click, that’s assuming I notice the focus is already in the field, which isn’t a given. [In my opinion, only Safari, with its blue outline around active form fields, assists the user in any meaningful way in detecting active form fields.]

Motivation #2 is faulty because if I can’t tell what’s important just by looking at the page, they might want to re-think their IA and/or design a little. They’re just bypassing the shortcomings in their interface by taking over my browser.

Lomography ScreenshotBesides, is it really that important? When I’m browsing Lomography.com, is it really important that I log in? The placement and appearance of the login fields on the site don’t suggest any particular importance to me, or tell me what benefit there may be to logging in (plus, there’s a “remember me” checkbox, meaning that folks who want to stay logged in will be, and don’t need the feature).

Counterpoint

That having been said, there are times when automatically putting the focus on a field isn’t a bad thing. It just needs to be handled strategically.

Take this scenario: I click on a link that says “Log In.” I am brought to a page, in which the majority of the non-white space is taken up by the login form. In this case, it’s a very safe assumption that I want to use the form to log in. (The MyComicsPage.com sign in page is a good example of a page that could safely make this assumption.)

Google ScreenshotA good example everyone can relate to is Google’s home page. As soon as you get there it moves the focus to the most important element on the page, the search field. This, I’d be willing to bet, is another safe assumption.

No More CSS Hacks?

There’s an article over at Stylegala entitled No More CSS Hacks. It describes a method of using server-side script to detect a user’s browser type (instead of the traditional client-side methods) so you can write browser-specific CSS without resorting to javascript or CSS hacks.

At first glance, it sounds good. Thinking on it a bit, the examples they show would be a slight nightmare for the way I work. On a regular basis, I build fairly large, very corporate CSS-driven sites with challenging CMSs (read as: I work with integrators that aren’t always 100% familiar with HTML, much less well-formed HTML) and challenging designs (read as: designs that look good, but aren’t always conceived with ease-of-production in mind).

The upshot being I write long, dense, complicated CSS files that, on a good day, can be hard to parse (by humans, I mean).

Fortunately, I’m able to keep my CSS hacks to a minimum. The only hack I ever need these days is the IE underscore hack. If you’re not familiar:

div.foo {color: red; _color: blue;}

In IE, the color applied is blue, in all other browsers, red. The really nice things about the underscore hack is that it’s unintrusive, yet easy to spot by eye. It can be placed immediately following the item it’s overriding, so I can easily tell what is being “fixed.” In addition, making sure to throw IE6 into quirks mode means I get IE5 & 6 compatability at the same time, and the high quality of the other browsers we support (Firefox, Safari) means that I only have to hack for IE. (Not to say I don’t have other browser-related problems, but I’m able to fix them without CSS hacks.)

Anyway, back to the point. Applying the server-side techniques as they’ve laid them out, would make my CSS files a swamp of unreadable code, which isn’t acceptable, seeing as I often have to hand projects off to other developers (not to mention the client) once the initial development has occured.

That having been said, I do see a very graceful way to make use of server-side browser detection: Sniff for browsers in the HTML file, not the CSS file, and instead of writing browser-specific CSS, write a call to browser-specific CSS files. So, along with styles.css you can also have ie.css and safari.css and firefox.css, which are only written when the server detects those browsers.

It would still mean changing the way I write CSS a bit. Instead of the underscore hack, I’d write something like this:

div.foo {color: red;} /* color overwritten in ie.css */

This way I (or a future developer) wouldn’t have to be intimately familiar with the alternate CSS files, and wouldn’t go insane because I can’t figure out why the text is STILL RED in IE. (Believe me, I’ve torn out many a hair trying to debug something that was being overwritten farther down in the CSS file.)

It’s conceivable that CSS files might become a mess of comments, but which is better — a mess of human-readable comments? Or a mess of computer-readable PHP?

FOUC Safari?

The Flash of Unstyled Content (FOUC) has traditionally been an IE/PC problem, and one with a solution.

Recently I’ve been seeing it in Safari, once or twice a day many times a day. Anybody know what the deal is?

Inderal 20 mg
Cost generic toprol
Buy hydrochlorothiazide triamterene
Generic caduet
Hytrin 2 mg
Plavix vs alternative medicines
Lamictal discount prescription
Buy cheap zyprexa
Alternative to evista
Discount premarin
Tamox clomid hcg buy
acomplia purchase
Is simvastatin a generic for lipitor
Allergy to flagyl alternatives
Levaquin 500 mg u s pharmacy
Erythromycin 400mg
Buy quinine medicine
Spy monitor
How to tell if ur girlfriend is cheating on you
Best cell phone spying software
Buy ultram er
Ultram 15 mg
Ultram 300mg
Urantiapharma generic ultram
is your husband cheating on you
signs women are cheating
signs your spouse is cheating
how to find out if spouse is cheating
why women cheat on their husbands
Buy confido
Natural viagra cialis
dealing with cheating boyfriend
how to find your husband cheating
problem with wife
nexium prices canada
canadian pharmacy online tramadol
generic cialis
buy tramadol online
buy synthroid online
order tramadol online
buy vibramycin
buy toradol
buy lidocaine
buy celebrex
buy flagyl
lasix furosemide
canadian family pharmacy
cialis online
tramadol 100mg
nexium generic
buy nolvadex
how to catch a cheating wife
generic viagra
Canadian Family Pharmacy
buy nolvadex
buy bactrim | buy bupropion | coumadin | buy bactroban | buy actos | buy strattera | buy topamax | buy plavix | buy nolvadex | buy lipitor | buy lasix | buy xenical