[thesite] comments on test.evolt.org

isaac isaac at members.evolt.org
Thu Jun 28 20:24:34 CDT 2001


>
> i can't prove that, i can't test it, but given how much work you have
> to do to get onto the hit area for each comment you might want to
> see and expand it in order to do a quick scan, as opposed to just
> plain scrolling, it seems overengineered..

the original implementation by jeff allowed you to click anywhere in the
comment title bar. it was a very quick process.

> solution to a 'problem' identified by the two people doing it... i've
> heard no other complaints that the comments are a problem as
> they are...

there have been few complaints re lack of content, gap between member and
admin, dark design of original tagwear, etc - but does that mean they're not
worth addressing?

> i'm less concerned about the code and more concerned with the 4
> or 5 different hyperlinks with completely different functions in the
> same 50px area... that's a lot of activity in a compressed space...

yeh, that is something to also address. the permalink could be tacked onto
the comment title as a small icon or something. however, it's a difficult
concept to describe in a word or icon. even "link" doesn't do it perfectly
(what's it a link to? i know, but do first time readers who haven't seen a
blog before?)

> yes, and i think you'll see the people who actually care to read the
> comments would find the feature useless... what part of the thread
> do you think i've missed?

not all find it useless. the majority.

i've seen no additional discussion about whether we need to address what
comments have been added since last read. not even a +1/-1 or "it's easily
possible, but would require too much code to do it properly".

> would happen other than user discovery... you may not understand
> why that is a bad thing, but that's ok, it's just a different
> perspective...

it is a negative side, but something that a regular user learns from after
their first one or two attempts.

> yes, but you need to consider how it worked the first time... if you
> didn't know it was there, you click-dragged and the text
> disappeared... that's *bad*.... it behaved in an unexpected way
> without warning you...

you're speaking as though it caused you to die of shock. you wasted an extra
second the first time. it gave you a partial heart attack. whatever. after
that, it saves time. anyone logging in has a membership, and therefore
they're more likely to be using that login frequently (if not setting a
cookie to remember them).

> i think having a set number of comments result in an all-collapsed
> state is much worse... it would happen on so few articles that the
> user wouldn't learn how it works until they get to the right article...
> yes, they will have seen the +/-, but they won't have seen an all-
> collapsed state, and it will take them a moment to understand
> what's going on...

that's fair enough, and it's reasoning like that which suggests heavily that
we should discard the feature. *shrug*

> on your second visit... you've just qualified my point... and it
> doesn't speed me up any more than if there were no text in there at
> all... hell, the fields are labeled, i find the text frivolous
> given how it  behaves... but that is a completely different issue...

you lose 1 second on your first visit. you save 1 second on all subsequent
visits.

how else are they labelled? it says login, and presents 2 boxes. if there
wasn't text in there, i'd be guessing that it wanted user/pass (although
alot of logins use email/pass instead).

so, we need the text in there. as i've explained, regular users are the ones
more likely to be using that login box. and thus more likely to benefit from
the time saving of subsequent visits.

> you outlined a problem that *you* perceive as a problem... have we
> heard complaints from users?  from anyone else?  is it really a
> problem?

i am a user. i considered it a problem. it had to be raised in order to find
out if it was worth addressing. it obviously isn't.


> me... i do think that client-side scripting brings just too much risk,
> and i think conditionally serving page content goes against how we
> tried to build this... i always felt we should have write-once run
> anywhere code, and serving up pages based on browser is exactly
> the opposite of that...

is serving up content based on feature more appropriate then? aren't we
already doing this in a small way with the stylesheet?

> yep, i hated it... i hope that's not the one we're gonna use (no
> offense jeff, it's a great tool, but it's not how i work)...

why would you care if that was the one we'd use if you weren't using it, and
using it was a voluntary choice?


isaac





More information about the thesite mailing list