[JDEV] Emoticons: guidelines

[Dave]

Reply inline:

 - Dave

Richard Dobson wrote:
> 
> 
> ----- Original Message -----
> From: "Dave" <dave at dave.tj>
> To: <jdev at jabber.org>
> Sent: Monday, April 22, 2002 2:17 PM
> Subject: Re: [JDEV] Emoticons: guidelines
> 
> 
> > Reply inline:
> >
> >  - Dave
> >
> > People who are behind firewalls and proxies can upload their favorite
> > emoticons to GeoCities, and have their clients put in references to
> > there automatically.
> 
> And you expect normal people to this ?? (normal people as in
> non-programmers/web devs, people like new computer users, new people to the
> internet who just want to chat to their friends)
How do you suppose the file transfer thingy in Gabber works?  Does the
end user have to implement it all himself?  I don't think so.

> It also requires that people have their own webspace if they want to use
> emoticons.
...not any worse than file transfer - and if you use any of the
more-likely-to-be-found emoticons (like smiley.png), odds are that the
guy receiving your message has a corresponding icon for it, so you can
use a local URL, or use the j.o URL (or the URL of another emoticon
repository on the 'net) ... using URLs to locate emoticons is a very
clean solution, because URLs _are_ standardized, unlike emoticons. . .

> And if you mean a client should auto-upload them, then that is completely
> unnecessary complexity for something simple like emoticons.
Any given client has ten million choices about how to implement emoticons
if you use something standard like HTTP IMG tags.  With your proposal,
emoticons can only be implemented in one way, and if you want to use
a cool emoticon you just downloaded from your friend, then ... well,
buddy ... you're out of luck, since (assuming your emoticon is even
included in the standard), your buddy probably has a different image
for that emoticon, so if your emoticon has some subtle little feature
that gives extra flavor to your message (what emoticons are intended
for), that extra flavor will be lost in transit.  What's worse, is
that people who use one client will think that the emoticons should
look the same on their chat windows and on their buddies' chat windows.
With your proposal, there's no way for a user to make sure that happens,
short of sending inline images.

> All that needs to be done is standardise a standard set of emoticon codes so
> each client will know what emoticon should be used.
...and anybody who wants to use a "non-standard" emoticon will be severely
out of luck :-(

> 
> >
> > > And what about the unneccessary bandwidth it takes up, not just in the
> xml
> > > but having to download those images,
> > Well, if you _really_ want to use whatever emoticon the recipient
> > already has (presumably, from his own Jabber client installation),
> > you can just use src="envelope.png" src="mail.png" along with any other
> > likely names the graphic is likely to have, and maybe include a default
> 
> Using the filename to try and tell what emoticon is being used is completely
> unworkable, and I dont think I have to explain why, but if anyone requires a
> clarification feel free to email me.
If the j.o repository has specific filenames associated with specific
images, clients are likely to support that convention.  If you include
the j.o URL as a backup src attribute in all emoticons you send that also
have a home at j.o, then any emoticon _not_ implemented with the same
filename on the recipient's system will be drawn from the j.o repository,
which is just fine.

> 
> > src="http://somewhere/myenvelopeimage.png" attribute, in case the guy's
> > client doesn't have any such icon.  This still prevents the formation of
> > a "standard" set of emoticons for Jabber, that all clients must support,
> 
> Why does it stop the formation of a standard set of emoticons ??
It's stops the formation of a standard set of emoticons, simply because
it obviates the need for a synthetic standard.  You'll notice that none
of the other IM systems agree on a "standard" set of emoticons, either.
The reason is simple: ANSI and the ISO have refused to get involved
(not that I can blame them: emoticons are - by their very nature -
very emotional, and emotions are hard to standardize).

> As long as
> the icons that are being used represent what they are supposed to.
...but the icons shown in AIM and in MSNM for the same smileys in text
look radically different, and convey different emotions - you can easily
confuse somebody by implying one thing in the text of your message,
but sending an emoticon that conveys an entirely different message :-(

> All we
> are trying to standardise here is a way for each client to know what each
> emoticon code means not a single standard set of emoticon graphics.
Well, for those applications where "any" standard smiley will do,
send an IMG tag with a src attribute for smiley.png, and (if desired)
a backup src attribute for img.j.o/emoticons/smiley.png or whatever.
For all other applications, you can use whatever smiley you want.

> 
> > and whose interpretation (and therefore the implementation of the icons
> > by different clients) is guaranteed to lack uniformity.  It also means
> > that every time we add "standard" emoticons, clients without support
> > for that particular emoticon will be left in the cold.  We can always
> > have a "reference set" of emoticons at http://img.jabber.org/emoticons/
> > and have clients make hyperlinks referenced there by default, but we're
> > maintaining the capability for anybody to send any emoticon he may want
> > to send, without being limited by the "emoticon approval process" that's
> > going to develop if we try to standardize emoticons directly.
> 
> Yep there can always be a reference set of emoticon graphics for client
> dev's to start from or use.
The repository at j.o would serve as a de-facto reference set.  Anybody
else could also set up a (Jabber-independent) emoticon repository, as
well, and people would then be able to point their src attributes there.
Now, if ANSI ever standardizes emoticons, we'll be able to use whatever
repository they recommend as the reference implementation.  The point
I'm making here is that emoticons should be left to de-facto standards
as much as possible (since they're not directly connected with the
Jabber protocol - and _shouldn't be_ chained to the Jabber protocol),
but emoticons are images, and therefore we need some method of sending
inline images in order to directly support emoticons.

> 
> >
> > > for something like emoticons isnt it
> > > better just to have a way of defining that something is an emoticon and
> what
> > > it represents so particular clients can display emoticons that better go
> > > with a particular clients graphical style,
> > I demonstrated above that this isn't a concern if we use an HTML IMG tag
> > (since if the sender wants you to use your default emoticon for something
> > - i.e., it's not important that you see the exact same emoticon that
> > he sees when he composes the message - he can list a local (assumed to
> > originate on your machine) URL before the URL of his emoticon).
> 
> But again using filenames is unworkable, filenames of emoticons will
> unlikely be always the same.
...but again, if j.o does it one way, you can bet that most client
developers will do it the same way, creating a de-facto standard ... de
facto standards are good because they can be changed quite easily when/if
somebody with the authority to standardize emoticons ever steps forward
to do so :-)

> 
> >
> > > and also whats to stop abuse of
> > > this by either embedding enormous images that take ages to download or
> an
> > > image with silly dimensions,
> > Karma stops many bad things in the Jabber world :-)
> > ....and the silly dimensions problem can be solved client-side by anybody
> > who wishes to restrict the dimensions of incoming images.  I see no
> > reason to use an infrerior solution simply because the more general
> > solution requires a bit of protection on the part of the receiver.
> 
> Im sorry but I think embedding a massive bit of HTML code into the message
> everytime an emoticon is encountered is the inferior solution, that should
> be restricted to the reason previously stated as it dramatically increases
> the size of the xml.
How often do you use emoticons other than the standard smileys?
The standard smileys are already treated by many IM programs (and I
believe I heard of a Jabber client that does the same), and there's
no reason why every client can't support them right out-of-the-box.
The other ones like heart.png or whatever aren't used enough times in
any single message in order to inflate the XML packet size by much (and
if we use that crazy regexp-mapping-rules idea where each message with
emoticons includes a whole extra section describing those emoticons,
you'll quickly find the overhead of including _any_ emoticons in any
given message will far outweigh the overhead of including an emoticon
or two every message - sorry for calling that idea crazy, but it sounds
extremely convoluted IMHO).

> 
> >
> > > also i will cause problems where people use a
> > > lots of emoticons within a message,
> > Yes, I'm sure you will cause a lot of problems, sending too many emoticons
> > within a message ;-P
> 
> it will cause problems, you know what i meant.
I know ... I just like poking fun at people ... I'm in a bad mood today,
and yesterday, and the day before, and the day before that ... it's not
directly your fault ;-/

> 
> > However, naming "standard" emoticons doesn't lessen the load on the
> > receiver's client's rendering engine - or even on his 'net connection,
> > if he doesn't store emoticons locally.  (Even a client that _does_ store
> > some emoticons locally is likely to reference another repository out
> > on the 'net, unless it decides to include some method for updating its
> > local repository whenever new emoticons are "standardized" ... or unless
> > the client developer decides to use update.jabber.org to broadcast
> > a "new" version of his client every time a new emoticon is added.
> > As you can probably guess, the situation has the capability of getting
> > rather silly.  I'd strongly suggest not trying to standardize within
> 
> Why does it have the capability of getting silly, and why cant a client have
> update functionality that can include updating its emoticons as well as the
> rest of its components ??
Simply put, I'd say you're adding a lot more complexity to your average
client than I can ever hope to add with my proposal to use _standard_
HTML IMG tags.

> Also when did I ever suggest that naming standard emoticons lessens the load
> on the receiver clients rendering engine??
In the part of your message that I was replying to in the above message
(which you deleted for some odd reason), you mentioned that my proposal
increases the load on the recipient.  I can't see how it increases the
load on his 'net connection (the original thing that crossed my mind
when you talked about "increased load"), so I had to look around and
see what you were likely to mean.

> All I said was that it unecessarily takes up bandwidth.
Apparently, my initial thought _was_ right, after all :-)

> 
> > Jabber something which isn't even a standard outside of Jabber: let
> > people go with whatever conventions they like, and the world will be a
> > much better place.  If the ISO ever decides to standardize emoticons,
> > I'll be the first to recommend using the standard in Jabber.)
> 
> Setting standards and protocols is what allows everything to communicate,
> whats wrong with standards ??
If Jabber decided to standardize a VoIP protocol, do you think it'd help
the Jabber protocol suite?  It'd simply make Jabber less compatible with
any competing VoIP protocols; now, if the ISO decides to standardize
a competing VoIP protocol, the Jabber protocol suite sustains a rather
heavy blow in terms of compatibility.  Emoticons are at the stage that
VoIP was at more than a decade ago - no standards yet.  Wise guys (no pun
intended) don't try to standardize stuff they don't have the authority
to standardize.

> 
> > > something like emoticons i dont think is
> > > best delt with by embedding it in this way.
> > Obviously, I'd tend to disagree ;-)
> 
> Of course you would, it doesnt mean you are right, emoticons are a client
> feature and should have the ability to be turned off, which in your method
> they cant be without turning off all embedded images,
Well-authored IMG tags have ALT attributes which provide a very
good replacement that can be adjusted on a case-by-case basis so the
replacement text conveys the intent of the sender.  Having emoticons
replaced by stuff like :love: (or worse, :luv:) will leave people wishing
(a) they didn't disable emoticons; or (b) their friends didn't insist
on sending them these stupid emoticons.  I'd much rather let stuff
like ":-)" which is used in email as-is stay as-is, just as in email,
and let the receiving client replace that sort of stuff on its own.
Anything more complex is better handled as an actual image (what it
really is), rather than trying to disguise it as a replaceable regexp :-(

> also there is no way
> of stopping the sending person from sending them in the xml in the first
> place,
How about sending:
<message to="annoying_emoticon_sender at whereever_he_happens_to_be" type="normal">Please stop sending me these stupid emoticons.  They add nothing to your messages, and simply make my Jabber client work overtime to find and display appropriate images.  There are a bunch of relatively standard emoticons which you can use as-is, but please don't bother me with all that MSN crap.  (Crap is a technical term - it refers to this shit you keep sending me.)</message>
to whoever refuses to purify his XML streams to you?
Seriously, how does your system "[stop] the sending person from sending
them in the xml in the first place?"

> which especially in your method consumes excessive amounts of
> unnecessary bandwidth
How's that?  If people feel constrained by the number of "standard"
emoticons available, they'll just send them all as inline images, anyway.
If we include too many emoticons in our "standard," most clients won't
bother to inflate their installation with them all, but will instead
download them all on demand, anyway.

> which on things such as GPRS devices is a very
> expensive thing, and for such devices you want to use the least amount of
> bandwidth possible,
I'm all for bandwidth conservation (and wildlife conservation, and oil
conservation, and fun conservation, etc.) ;-/

> also those sort of devices can currently display .png or
> .gif, only .wbmp, should these be not allowed to use emoticons? No everyone
> should be able to.
I'm sorry, but I don't speak English too well.  Maybe you can clarify that?
Just bear in mind that if you're trying to tell me that the Portable
Network Graphic format isn't standard enough (but the proprietary GIF
format (or worse, the Windows BitMaP format) is, presumably), I won't
hear of it: Jabber is an open standard, and including proprietary image
formats in it is bordering on heresy.

> Also what about the MSN transport, to allow emoticon
> compatibility using your method would put much more load onto the msn
> transport than necessary.
MSN is screwed up; face it.  Also, I believe MSNM allows you to send
inline images.  (If it doesn't, it's _really_ screwed up.)  Either way,
letting that fact affect our Jabber standards (basically, screwing up
the future of IM simply because Microsoft sucks) would be somewhat less
than perfectly wise.

> 
> >
> > >
> > > This is another good enhancement but I think is better for embedding
> images
> > > that are only going to be sent spairingly, like someone sending a
> picture of
> > > their cat or something inline in the im client, like the AIM image
> sending
> > > feature.
> 
> > Well, if we're going to need this _even if we use "standadized"
> > emoticons_, we'll be opening this "can of worms," as you put it, anyway.
> > We might as well avoid having the "standardized" emoticon system
> > altogether, since it's strictly a slightly incompatible subset of the
> > HTML IMG tag approach.
> 
> I never said "can of worms" at all anywhere so I didnt put it like that.
No, you never said "can of worms" (until the sentence directly above this
one): you only noted the intricacies of each worm coming out of the can
of HTML IMG tags.  I believe I've shown most of our worms to be rather
harmless, but I'm sure I'll get another salvo in the mail just as soon
as I'm done firing off this message.

> Its not a slightly incompatible subset of the HTML IMG tag at all,
Well, it's not compatible ... and it _is_ a subset of the HTML IMG tag.

> your
> particular suggestion has that solution but I dont think that by any means
> it is the best solution, it introduces many more problems than any other
> solutions.
problems == can of worms, BTW ;-P

> 
> >
> > >
> > >
> > > Rich
> > Dave
> >
> > >
> > >
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> > >
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> >
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>