[thesite] comments on test.evolt.org

aardvark roselli at earthlink.net
Fri Jun 29 07:35:22 CDT 2001


> From: "isaac" <isaac at members.evolt.org>
> 
> > no, my comment was that the people who read the comments,
> > who know they are there and scroll down to see them, will find the
> > feature useless... it's an assertion, yes, but i suspect it's pretty
> > accurate...
> 
> my only point was that you are making a pretty broad assumption. i am
> a person who reads the comments, knows they are there, scrolls to find
> them, but would still use the expand/collapse feature if it was
> implemented. i am sure there are a few others.

yep, i'm making a very broad assumption... and there will be others 
who don't fit, i'mjust applying the 80/20 rule...

> however, as i've also said previously, that proportion obviously not
> enough to justify the extra code and visual clutter. i can live with
> that.

ok...

> one particular reason i've noticed a problem with the number of
> comments on articles is that i've returned to read new comments or
> post replies to the article in question around 20 times (mostly after
> receiving a "new comment alert" by email). for the majority of those
> occasions, i've had to scroll through screen after screen of comments,
> and/or had to locate where i was up to. you may not have had this
> experience, i don't know.

no, i just fly to the bottom and work my way up...

> > ok... what are we doing?  i am enjoying this discussion as i think
> > it's helping us feel out what features we want to see, but what are
> > we gonna do?
> 
> dumping expand/collapse feature. considering methods of dealing with
> lots-o-comments for the future.

gotcha, which is what the other email was, just as a new thread...

> > > is serving up content based on feature more appropriate then?
> > > aren't we already doing this in a small way with the stylesheet?
> >
> > no, we aren't serving conditionally... we serve a CSS file,
> > period... we also serve <label>s and other HTML4.01 stuff that not
> > all other browsers know, regardless of the browser, but that also in
> > no way reduce functionality of the site as a whole... we don't serve
> > that or the CSS based on browser... i don't know why you're hung up
> > on that, but it's not analagous by any means...
> 
> css, html4, etc are enhancements appreciated by a select few. you
> don't appear to have a problem with that. netscape3 users for example
> still have to download that extra code (however tiny it is) without
> the benefit.

there are two answers to this:

- the CSS is linked, and so doesn't incur any extra bandwidth for 
non-CSS browsers... the extra HTML4 tags are few and far 
between, and their *lack* of support by the browser does *not* slow 
the user down at all... whereas a non-JS or 3.x browser has to 
manually select and wipe the text in the login boxen...

- the expando-boxen relies on browser detection, something to 
which i am generally opposed (but not completely) on this site... i 
just think it will cause a lot of hassle down the road, and still 
doesn't account for JS-disabled browsers, and the occassional mis-
detection...

it is my belief that the code should come off the server the same for 
everyone, built to support the lowest baseline, and have features 
added to support the higher-end, without detracting from the 
usability of the lower-ends of the scale...

> my point is that a richtext editor is similar. it's an enhancement.

yes it is, and it's also not part of the meat of the site... the article 
submission page is targetted at a smaller audience, not a general 
audience... i feel we have more room to play there...

> your problem must exist with us detecting and placing enhancements
> based on browser rather than feature detection, right? i'm sure that
> can be implemented.

exactly...

> the inclusion of a richtext editor for IE5+ or ie5/nn6+ or whatever,
> or even based on the features required for it to work, does not reduce
> functionality of the site at all.

no, the inclusion doesn't... but if it's inclusion followed by lack of 
support in any way slows a user, then it might not be a good 
idea... the 'feature' isn't a bad thing, it's just an issue of how it's 
implemented...

> by default, users would use the textarea. if they wanted, and if their
> browser supported it, they could choose to use the rich-text editor
> instead. but the choice remained (much like a netscape4 user choosing
> to browse evolt.org without css or something.
> 
> make sense?

much better... i never assumed you would force that on the user 
anyway... if that happened, i'd be raising concerns...





More information about the thesite mailing list