[thesite] comments on test.evolt.org

aardvark roselli at earthlink.net
Fri Jun 29 00:40:14 CDT 2001


> From: "isaac" <isaac at members.evolt.org>
> >
> > 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.

yes, and that was a very poor implementation... using an otherwise 
link-free region, denoted only by color bar (which has another 
meaning in this site), as a giant hyperlink while it still holds at least 
one real hyperlink is just a bad idea... the hit state is too large to 
the expando-box, and too small for the hyperlink... and stacking 
them like that is just a bad idea... no, that had to go, so that 
argument's pretty hollow...

anyone who doesn't agree with that assessment, let me know, but 
i stand by it...

> > 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?

we've addressed them all... we've tried a few things on content, 
we've worked on the member/admin roles, we're re-doing tagwear... 
but those were all pretty much a quorum... we *all* felt that there 
was an issue in each of those points, even if it were small... OTOH, 
i had not heard any complaints on too many comments until the 
development started... as such, i didn't see a problem that needed 
to be solved... 

that doesn't mean development shouldn't have started... you saw 
what you felt was a problem, and you prototyped a solution... i just 
think you've created a complex solution to a lack of a problem...

> > 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?)

yeah, that's something we'll have to address... icons with titles/alts 
might help, but that will require discovery for first-time users... 
anyone have real-world examples of any of those...?  if you do keep 
the expando-thingie, then it really should move to the right edge of 
that box and sit there... it opens things up on the left and doesn't 
purport to be a hyperlink in a barrage of real hyperlinks...

> > 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.

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...

> 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".

yeah, i can see value in that, but i'd like to see it as en evolt box on 
the right, much like we've prototyped for admin... doing it on a per-
page basis seems silly, since 9 times out of 10 there'll be nothing 
new... but coming to the home page and seeing a list on the right 
will make me go look at them...

i didn't address it because it didn't seem on-topic for this, and we've 
already strayed a lot...

[regarding the login box]
> > 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.

agreed... i just try to minimize the need for users to learn how to 
use a site... if there isn't a common model that exists, i look at 
why not (perhaps it's not necessary) and look at the common 
implementations if it does exist to see what works...

> > 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).

you discount that extra second too quickly... after you run a few 
user tests on something and notice people respond to something 
that behaves differently than they expect, you'll see they often 
decide that it's *broken*...

don't discount how users react... what may seem silly to you can 
be a big deal to others... by writing it off as silly, you discount the 
value of your users' opinions, and when they sense it, they lose 
faith in the site as a whole...  write that comment off if you want, 
but it's proven itself a lot to me, and i'll at least fight for it...

i *was* surprised, though... it wasn't in my code... that's not good 
or bad, that's just how i saw it...

> > 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*

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?

[regarding the login box again]
> > 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.

see above about lost seconds (how many seconds for a page load 
before users wander off?)... although that feature doesn't save me 
any time on subsequent visits... if i'm logged in via the cookie, it's 
moot... if i'm not, it saves *no* time, it does not speed up my 
mouse, my access, or anything else... it just labels fields i've 
already discovered... careful how you qualify how it saves time... 
you still have to click in the box no matter what is or isn't there... 
our non-JS users and older browser users, OTOH, always get 
slowed down... and that, IMO, is A Bad Thing... it's tantamount to 
the upgrade or screw off campaign...

> 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).

in one of my cuts of the HTML, it had the two fields labeled with 
text... i think it was discarded when it was plugged into the CF... 
dunno why, since i think it was more efficient and friendly... which 
might be why i don't see that on multitudes of other sites...

> 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.

regular users will use it once... then their cookie will handle it after 
that... you haven't sped anything up... labeling a field in the text 
box vs. outside of it doesn't speed a thing up... unless you can tell 
me how it makes me go faster by moving my mouse, reducing or 
increasing my hit area, or any other Fitt's Law application...

> > 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.

and it's good you did that... and it's good you guys prototyped it... i 
love that we do that, i think it's the best way to test things... if i 
hadn't seen it i might have thought it was less bad of an idea...

> > 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?

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... hell, the login box is a 
perfect example of being mean to our non-JS and 3.x users... 
*that* isn't served conditionally, but should be given how it affects 
some users... that's mostly rhetorical... i'm not asking it to be 
removed or to serve anything conditionally...

> > 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?

um, so i can decide which tool to use, provided i'm given a 
choice... how else does one choose how to work?





More information about the thesite mailing list