fpgroups.com: A raw chat room is now available

[Fairlight]

Confusious (fp at casabellagallery.com) say:
> 
> Nothing you can mention is absolutely bug free and 110% guaranteed to satisfy 
> every user.  

I'm not talking bug free.  I'm talking about what I consider poor design.

> I know it is pretty raw and in massive need of work.  

You have that part right.  :)

> I will not use any of the solutions you suggest simply because I rather
> write the code, own the code, control the code, do as I please with the
> code.  Most importantly, understand the code.

Fair enough.  I've done my share of projects for precisely that reason.
That, and wanting nice features like asynchronous ICB chat when every other
client that existed was purely synchronous.  I -wrote- a curses-based
chat program.  Having written a chat program and having used many, I feel
qualified to accurately judge other chat programs.

> I am not trying to replicate any IM, AOL, Google Chat, Yahoo Chat, nor   
> any of these long time running chat rooms you are so fun of.             

Fond.  But that's not the point.  The point is that -part- of good user
interface design is giving the user something they expect--or that at least
makes sense.  If I program in Perl/Tk, the widgets don't have a native
look & feel, but I can replicate a layout.  And convention says that you
put your chat history (conversation) above, your entry below, a submit
button to the left or right of the entry point, and a list of participants
as a side pane to either the left or right of either the conversation pane
or the entire lot, depending on the interface.  People know how to use
that.  I looked at yours and was nonplussed for 5 seconds before I realised
what you'd done.  Even then, it took an actual test to see if things were
going to post at the top or bottom.

Breaking the mold can be a good thing.  Absolutely atomizing it with a 5
gigaton nuke is not necessarily similarly good.  :)

> As far as glitches or bugs, even filePro is not free of those :), let
> me not get started with *NIX, WIN, Perl, and the 100s of other OSes and
> world famous applications ...

Again, this isn't about bugs.  And I agree with you about bugs.  

This is about basic design and usability.  And I'm telling you that I don't
consider it a usable interface.  Raw might describe it fine--depending on
your definition of "raw".  If by raw you mean that it mostly works, it's
just a bit rough around the edges, you're way off.  If by raw you mean, "I
have a proof of concept, it's nowhere near easily usable for the average
user, however," then you're about on.

Seriously...I've been doing this for a long, long time.  I've used damn
near every chat program since '89, and some even before that in the BBS
days (when AOL made chat system, actually--don't ask how they DEvolved
later).  If I, a self-proclaimed "power user" feel that the interface is
cumbersome (let's just stick to lack of text input re-focus upon send), you
really think your garden variety user isn't going to ask, "Where's my
cursor?  Why can't I type again?  I'm stuck!  HELP!!!!"  Except they can't
ask until they figure it out because they can't type again.  I'm talking
about catering to the lowest common denomenator here.  The text input area
of iVocalise is dead simple and we've had to explain it to dozens of
people, and it -does- keep focus unless you unfocus it.

> You are a tough cookie to please (if not impossible).  I would not expect
> you to ever like anything written by anyone but yourself.  

Ah, rubbish.  Recently discovered fine software I absolutely love includes
pretty much all of Serif's major packages.  They're inexpensive for their
class, supremely powerful for their class, and the support is decent.
Stability is also pretty damned high considering the complexity of product.
CoffeeCup is another place whose software I like a lot for the same reasons.

Pulling that "argument" out of your hat is practically an ad hominem
attack, except it's too lame to even be called an attack.  Sounds more to
me like a reason not to take my advice/suggestions, or to discount them as
unreasonable.  Go ahead and shortchange yourself--no skin off my nose.  You
want this to -work-, however, or at least have a prayer of working, you'd
do well to listen to at least half of what I'm telling you.

Further, it really frosts my cornflakes when someone asks for input and
then bitches about the input they get.  If you ask, you have to take what
you can get--unless you're paying for it, in which case you can demand any
answer that meets your satisfaction.  I just happen to call it like I see
it, and -when- have you known me to pull a punch with anything?  You just
don't like what you're hearing.  Neither would I, if I'd plunked even 1-2
days into getting it working as it is now.  Not liking what one is hearing,
nor needing to put more work into something doesn't make the feedback any
less valid.

"Do you want polite, or do you want sincere?"  --Unknown 

> I did say it was 'raw'.

I was expecting something in the neighborhood of usable by someone with
less than infinite patience.  You're not only not even in the neighborhood,
you're about 5 miles out from the suburbs with just the text area focus
issue alone, nevermind the rest of my feedback.  Without that, it's just
not something I can see anyone tolerating unless they're of the "I only
know how to use the mouse" generation.

> As per privacy, what privacy?  It is an open chat room.  If you want to
> have a private conversation, pick up he phone or meet at your local park.
> The site itself is meant to be a communal site, not meant for two people
> to lock themselves in a private chat room.  That in itself goes against
> the very principal I am trying to work on "unity" and "openly share" with
> all.

When someone starts spouting incorrect answers to things and you want to
correct someone else's impression of how it works without getting into a
public pissing contest over it, you'll appreciate the need for /msg.
Amongst other reasons.  Let's see...exchanging phone numbers or email
addresses in private, talking about sensitive or confidential data with
someone that's there but not wanting anyone else to see it--just the person
you trust.  There are a slew of reasons.

> As per the error, I visit some of the web's most famous sites and I get
> them there too ... and they have $$$$$$$$$ (those are Billions) to fund
> these sites.  

Like the $1.7 YouTube, whose comment reply system has been hosed for over a
week now?  Who can't even afford a simple status indicator when doing AJAX
calls for ratings or comment submission?  Yeah, I know about some of these
places.  What is -really- ironic are the number of places selling web
design and programming services whose own sites generate errors.  :)

Just because the rest of the world has more resources and can get away with
doing it wrong is no justification for not getting it right yourself.
That's where places like Serif and CoffeeCup excel--they nail details the
giants like Adobe totally let slide to the side.

> Following your advise, I will move forward, modify it slowly and steadily
> and hopefully, it will grow to a fully functional, lovable, fast,
> friendly and very popular chat room.

If you have a prioritised list, the first thing on it should be instating
a keyboard re-focus to the textarea right after a message has been sent by
the interface (as opposed to anyone having sent one--I'm talking about the
user clicking on or hitting enter on the send button, which is actually two
events to trap...I'd personally stick it in the beginning of the AJAX that
does the actual submission).

Speaking of which, I just had a thought, but I didn't test it.  Did you
handle the case of multiple submission?  I just tried testing, but it won't
even post.  I keep getting "problem saving chat data".  I'll assume you're
working on it.

Okay, screw testing.  I'm -looking- at the code, and I guarantee you that
the way it's written right now is wrong.  The AJAX has no limiting factor
to prevent a race condition.  I'm imfamous for sending multiple short
lines of text, sometimes as afterthoughts.  Your code would basically use
the "xo" variable for the request.  However, on subsequent submissions, if
another was asynchronously in use, the active request will be overwritten
and will basically be "interrupted" and will not finish or trigger a
callback.  Think of it this way:

xo - Send #1
xo - Send #2 before #1 is finished.  Oops, overwrote xo object/callback/status.
xo - Send #3 before #2 is finished.  Oops, overwrote xo object/callback/status.
xo - Send #4 before #3 is finished.  Oops, overwrote xo object/callback/status.
xo - Send #5 before #3 is finished.  I happen to be last in line, so I'm
the only one of five messages that is actually fully acted upon properly.

You need to disable the submission functionality on starting the process of
submission, and clear the status and re-enable it when the callback is
triggered and processed.

Since I'm looking at the code, your comment about writing the code,
etc., falls rather flat as an argument unless "Jose Lerebours" somehow
translates to "@author JPA".  Strangely, I see no L in there for Lerebours.

> You will be missed the days you do not log on and for the 23Hrs 55Min
> remaining on the days you do :)

I have no idea what you mean there.  I'm not parsing the grammar well
enough to derive the meaning intended, apparently.

Consider me nitpicky if you like.  But if you ask for feedback, either
listen to it as one should, or admit you're fishing only for praise.  If
the latter, you're doing it for the wrong reasons.  I've no wish to write
such a system.  I was -trying- to help you.  You're apparently not
interested in that help so far.

mark->
-- 
The latest synth mixdown...
http://media.fairlite.com/Isolation_Voiceless_Cry_Mix.mp3