How about subtly altering the color of every other post?

February 25, 2002 12:54 PM

I have trouble sometimes telling posts apart when people use multiple paragraphs. How about subtly altering the color of every other post to improve readability? For example alternating white and light grey.
posted by phatboy to feature requests at 12:54 PM (32 comments total)

Also, just checked, on my server which uses the apache mod_gzip for inline html compression, the metafilter front page compresses at 3:1. Would this help with bandwith?
posted by phatboy at 1:00 PM on February 25, 2002

hmmmm neat idea..

Yeah, I notice I got lost on what of matt's posts on metatalk .. where he skipped a paragraph ;D
posted by a11an at 1:20 PM on February 25, 2002

Sorry, but that's really aggravating to look at. Maybe a better idea would be to subtly shade the background of the signature at the end of the post. Such as -

posted by Whoever at 1:30 PM PST on February 25 .

The above is a simple table color hack, but it would look better if it was intergrated into the style sheets (right now it bleeds out on the top). But I think this is much easier on the eyes.
posted by SweetJesus at 1:36 PM on February 25, 2002

This sounds (and admittedly to my surprise, looks) like a good idea. It doesn't disrupt the color scheme to a noticeable degree, and it makes it a little easier to differentiate between posts. I have nothing to add except that I would love to see it implemented.
posted by Hildago at 1:38 PM on February 25, 2002

Works for memepool.
posted by luser at 1:55 PM on February 25, 2002

whoever's thing, I mean.
posted by luser at 1:56 PM on February 25, 2002

Here is two more tries for fun, one based on SweetJesus', and one using indents.

I think my version of SweetJesus's idea may be a bit too garish.
posted by phatboy at 2:18 PM on February 25, 2002

The coloration difference would be the better option, but you need colors that don't make my eyes bleed, and the problem with indentation is that it makes it look like some posts are hierarchically nested within others... it's not intuitive at all.
posted by insomnyuk at 2:33 PM on February 25, 2002

a thin line border of a different color around the 'posted by' message would probably work just as well, rather than throw off the familiar color scheme used on MeFi. When change messes with familiarity and usability, change is bad.
posted by insomnyuk at 2:36 PM on February 25, 2002

I would rather add a bit more (perhaps 6-10px) of vertical space between posts, or get rid of vertical line breaks altogether on metafilter instead of using different colors or making the posted by lines more obvious. I like that the page reads as somewhat continuous, and introducing too obvious of a discontinuity doesn't seem like the best idea.
posted by mathowie at 2:44 PM on February 25, 2002

today's hilarious take on usability here
posted by victors at 2:53 PM on February 25, 2002

phatboy, gzip compression would ease the bandwidth load, while increasing the processor load. Unfortunately, the processor is what is currently overloaded (as far as I know), so that would only make matters worse.
posted by whatnotever at 3:45 PM on February 25, 2002

whatnot: Good point. Interestingly plastic which is perhaps operating under similar constraints is using mod_gzip. Their front page compresses by a factor of five.

I am just amazed that mod_gzip is not more widely used. It seems to be a godsend for websites on slow connections and modem users.
posted by phatboy at 3:54 PM on February 25, 2002

Yeah, but what browsers support Gzip? Just Netscape, right? In which case, why bother?
posted by kindall at 4:04 PM on February 25, 2002

Kindall: All http 1.1 browsers support gzip. As I understand it it is part of the protocal standard. The module automatically detects compatibility and uses it as needed.

From the mod_gzip page:
mod_gzip uses the well established and publicly available IETF ... Content-Encoding standards in conjunction with publicy available GZIP compression libraries such as ZLIB ... to deliver dynamically compressed content 'on the fly' to any browser or user-agent that is capable of receiving it. It is a software based solution that runs perfectly in conjunction with any Apache Web Server on both UNIX and Win32 platforms.
...
mod_gzip does not require ANY software to be installed on the client side. There is no accompanying 'Plug-in' or 'Client Proxy' of any kind. All you need is your current HTTP 1.1 compliant browser. All modern browsers released since early 1999 are already capable of receiving compressed Internet content via standard IETF Content Encoding if they are HTTP 1.1 compliant.

I don't want to sound like an advocate here, I just think that this is a impressive and free piece of software, which if used more frequently would improve the web. It may be irrelevant for here, but for many (mainly text-based) sites it would result in a much zippier browsing experience.

posted by phatboy at 4:11 PM on February 25, 2002

Doesn't it just trade zippiness in the network (slow file size) for sluggishness on the client end (decompression time)? So fast machines with slow connections profit, machines with fast connections lose.
posted by rodii at 4:20 PM on February 25, 2002

I'm amazed that mod_gzip isn't more prevalent, too. I'd never even heard of it until a couple of weeks ago, and was deeply skeptical that a change that trivial could be that beneficial. But lo and behold, site bandwidth usage is down by about 60% overall - trending towards 80-90% in the repetitive-tag-infested forums - and it's been completely transparent to end-users. Impressive stuff.

rodii: In my experience, the added time to decompress is trivial compared to the time saved in downloading the smaller page, even at DSL speeds.
posted by youhas at 4:37 PM on February 25, 2002

rodii:

decompression time is not noticable. I can't really tell the server effects except to say they are pretty minimal.

All of the front page files test files I have listed here (i.e. this) are compressed on the fly using mod_gzip, i.e. they are recompressed from text every time the page is sent. These are hosted on a 150 Mhz pentium I laptop with 32 megs of ram, not exactly a powerhouse. They are sent over a 128 Mbit DSL line. In the cases here, there is a 3:1 compression advantage, with the front page going from 40 Kb to 13.8 Kb. This effectively triples the rate which data can be sent, and also triples the speed at which a user recieves a document.

For machines which are CPU limited, this obviously doesn't help, but for any limited rate connection it should benefit everyone. Other than CPU use, there is no downside. Incompatible old browsers are automatically served uncompressed content. Even CPU usage can be mitigated for static content by configuring mod_gzip to cache compressed files, so that they are not recompressed every time.

Apologies for "moderating the thread". This is something I have an interest in.
posted by phatboy at 4:39 PM on February 25, 2002

phatboy: is this is something that the server is set up to do? (in other words, not something that I could do in coding my site, which is hosted elsewhere?)
posted by rebeccablood at 5:00 PM on February 25, 2002

rebeccablood: aye, its a server config thing

just for the record, there are occasional problems with gzip'd content with ie 5 for mac behind certain proxy server configurations (you end up with a page of binary data in the browser)
posted by sawks at 5:16 PM on February 25, 2002

rebecca:

It is a free add on to apache, you need access to the server to install it. It takes about 3-5 lines in the config file to set it up. See my above message for the site. Your site seems quite zippy, so you probably don't need it. Of course, if you are paying /mb it would help. I suppose you could ask whoever is hosting it to add it in, but they might not be agreeable to screwing with their configurations.

For anyone who is interested, to install, you download the module and stick it into your libexec dir, and then configure via httpd.conf. here is the relevant parts of my httpd.conf:

# load the module
LoadModule gzip_module libexec/mod_gzip.so
# add in the module
AddModule mod_gzip.c

#turn on server side compression
mod_gzip_on Yes
#I think this buffers dynamic content so it can be compressed better
mod_gzip_dechunk yes
# set this so all text mime types are compressed, no images etc will be processed.
mod_gzip_item_include mime text/*
#temporary workspace, not used because of next line.
mod_gzip_temp_dir /tmp
# Turning this on will keep the compressed files cached to improve CPU usage.
#I dont think this works for dynamic content.
mod_gzip_keep_workfiles No


#the following statement will set logs to report compression ratio:
LogFormat "%h %l %u %t \"%r\" %>s %bi :%{mod_gzip_compression_ratio}npct" common


There are more options, but this works : ). There is a ton of info at the mod_gzip homepage.
posted by phatboy at 5:16 PM on February 25, 2002

If your site is virtually hosted, and has mod_gzip, I believe you can use the .htaccess method.
posted by riffola at 5:24 PM on February 25, 2002

Kuro5hin's move to gzip
posted by holloway at 8:24 PM on February 25, 2002

Can Microsoft IIS do gzip?
posted by holloway at 8:51 PM on February 25, 2002

or iPlanet?
posted by gen at 9:01 PM on February 25, 2002

The alternating lines sounded like a good idea, but I had the feeling that I wasn't scanning the page in the same way for links as I was before. I think that Matt's idea of adding a just noticeable amount of extra space between threads would improve the user's sense of place without sacrificing readability.

However, your example doesn't include any posts with multiple paragraphs. I'm not even sure that the extra space thing has not already been implemented to some degree.
posted by xammerboy at 9:09 PM on February 25, 2002

I'd like to see an example of a thread page, not the front page, in order to cast an opinion. The thread pages are the ones I usually get lost in, because nearly every comment has multiple paragraphs -- it's hard to tell when a new comment starts.
posted by jennak at 10:48 PM on February 25, 2002

This is something I just found for a google search for IIS gzip, but I know IIS has a built in gzip equivalent. Andrew that runs Diaryland.com and Pitas.com recently made the switch on his apache servers, to save on bandwidth with very positive results. He even dug up all the MSDN pages about IIS' equivalent, but I never got around to implementing it. With the site serving out almost 100Gb of files a month (and it's almost all just text), it would probably keep the pipe from maxing out during the busiest parts of the day.
posted by mathowie at 11:29 PM on February 25, 2002

More on IIS 5.0s gzip
posted by holloway at 12:26 AM on February 26, 2002

You don't think a bit of red would make things stand out then?
posted by Spoon at 6:37 AM on February 26, 2002

Alternating color might lead to segregation of postings, similar to the 212 vs. 646 area code problems in NYC. "I was going to post that, but I wanted white text instead of gray."
posted by joemaller at 1:31 PM on February 26, 2002

You don't think a bit of red would make things stand out then?

I wouldn't bring that up if I were you, Spoon. Not now that you're in everybody's good graces. :)
posted by MiguelCardoso at 7:41 PM on February 26, 2002