Important issues we still need to discuss

[Anne/yojibee]

Hi all,

there are a couple of discussions we still need to have.

1. Message length
The last time we talked about this, there seemed to be an agreement
that we need to set a max character limit on the messages. Most of us
seemed to agree that 140 is too short.
David's comment (shortened): "Amazon URLs are 180 characters and I
think we have to make sure we create a user experience that does not
penalize users of long-URL services."

2. Shorten URLs
If we limit the message length, we should probably think of shortening
the URLs.
(and in that case, how?)

3. Ability to send attachment with messages
Should the users have the ability to upload and display media. And if
yes, limited to only certain file types? (for instance .pdf/.doc/.xls
etc)

- Anne

[S. Kirsten Gay]

Hi All--

Had a short conversation with my BF--who is a techno geek and electrical engineer--about this recently. He pointed out that 140 is what will fit in one cell phone "burst" which assures that the whole message is transmitted together. If the message has more that 140 characters, there are much higher chances of a critical fail, where only half of the message is relayed. Obviously, we can build software that can stitch these back together, but that doesn't help if the other half of the message doesn't arrive. 

While texting with the Verizon networks, we have noticed two relevant things.

1) text messages can be delayed up to 6 hrs

2) our phones allow entry of about 500 characters. The text box entry is 1 box, but the messages arrive in bursts. We think they arrive in reverse order, meaning the first part of the message is delivered first. But, that means that like micromessaging desktop clients, the content of the message is displayed with the newest on top. I am not so concerned about the order. I think most users will cope, but, in combination with message delays, it could mean scrambled messages. 

From a business perspective, it would be better to have some more characters, just so folks can write complex ideas in full sentences. "Problem, question"  "statement, proof" "problem, action"

I also believe the cell phone integration is very important and compelling from a business perspective, and that users will not always be on html/air/iphone clients.

It's a difficult question. I am wondering if different enterprises would have different answers. For example, would the legal industry need more characters but the medical industry have to limit it to one burst for data integrity?

Would it be possible to craft the system so this was a setting that the company would select? Or is that too much trouble?

-Kirsten

---

From: Anne/yojibee <yoj...@gmail.com>
To: esme-dev <esme...@googlegroups.com>
Sent: Monday, November 3, 2008 4:12:08 AM
Subject: [ESME-dev] Important issues we still need to discuss

[Hirsch, Richard]

I think the idea of having a character limit that is dynamic is intriguing but we also have to remember that character length is tied to a variety of very technical matters (database column lengths, etc.). 

Therefore, it might be difficult to configure on the fly. I might suggest creating a scale for companies to use. For example. Min 140 max 500. Database columns could then be set to max length and then the UI could respond dynamically based on the limit set by the configuration.

 

One question: Can a company set the character limit just once (perhaps, during an initial configuration)  or can it do it multiple times - which I wouldn't recommend.

 

-D.

---

Von: esme...@googlegroups.com [mailto:esme...@googlegroups.com] Im Auftrag von S. Kirsten Gay
Gesendet: Montag, 03. November 2008 12:53
An: esme...@googlegroups.com
Betreff: [ESME-dev] Re: Important issues we still need to discuss

[S. Kirsten Gay]

I was thinking a company would make that decision just once, at configuration. Perhaps the database columns could be configured to match to increase efficiency? (not my gig, just a thought)

---

From: "Hirsch, Richard" <richard...@siemens.com>
To: esme...@googlegroups.com
Sent: Monday, November 3, 2008 7:04:59 AM
Subject: [ESME-dev] AW: [ESME-dev] Re: Important issues we still need to discuss

[Dennis Howlett]

Kirsten raises a very good point. There are 2 aspects to this: technical and business. I saw a possible use case in disaster relief situations where I'd assume the main method of communication would be via mobile phones. Similarly, in field service situations mobile will be preferred. Those use cases alone would seem to limit input to 140 chars as a guarantee of transmission.

Alternatives and qu's:

1. Is there any reasonable way to develop a mobile client that could overcome the 140 char limitation? If so then which mobiles would we wish to support (eg S60, Blackberry, others?) Would this overcome the potential SMS delays and character limits to which Kirsten refers? How about developing for the OperaMini client? Does that solve the problem?
   
2. If we offer alternative input limits, is that a one time config? If so what happens if circumstances change?
3. If we offer a scale, where are the end points: 140, 255 (which I think is where Yammer stops and which I personally favor having used it) 500 (which I think is straying into email territory?)

Thinking about the way people will use ESME in a business context leads me to think that shorter is better as presumably people will develop their own means of communicating in a shorthand that works for them.

If it is of any use, I have contacts that can open doors at Nokia...

D -:)

--
This message is: private and confidential [ ] bloggable with prior permisssion [ ] bloggable without permission [ ]
Dennis Howlett
t: +34 953 708 636 (int'll)
m: +34 607 482 739 (int'l)
skype: dahowlett

[David Pollak]

On Mon, Nov 3, 2008 at 1:12 AM, Anne/yojibee <yoj...@gmail.com> wrote:

Hi all,

there are a couple of discussions we still need to have.

1. Message length
The last time we talked about this, there seemed to be an agreement
that we need to set a max character limit on the messages. Most of us
seemed to agree that 140 is too short.
David's comment (shortened): "Amazon URLs are 180 characters and I
think we have to make sure we create a user experience that does not
penalize users of long-URL services."

My concern has to do with the user experience in terms of input and the way characters are counted.

Let me take a detour into addressing to 140 character SMS issue.  I think that our target market will have rich enough cell devices that we need not worries about SMS message length.  I expect that all of our target users will have a BlackBerry, iPhone, Nokia, or Android.  Each of these devices has a rich development environment and the ability to have powerful IP-based (not SMS based) client.  I'm already putting the pieces together for BlackBerry and Android clients.  We've had a volunteer to do an iPhone client.  Finding someone to do a Nokia client should not be hard.  Yes, supporting 4 clients is a non-trivial issue, but the richness of the user experience I think will outweigh the costs.  Also, the end-user costs associated with doing IP are much much lower than SMS and the market-to-market varience in costs is much more narrow (how many countries are not served by Twitter for SMS?)

I put no weight at all on the SMS delivery issue, even if we do natively support SMS.  ESME is not about guaranteed delivery for messages.  It's about the message stream.  If there's a 450 character SMS that gets gummed up someplace in the cell carrier because only 3 of the 4 packets make it to your phone, it is what it is.  Also, how often does that happen?

Currently, ESME stores messages in a Text database column as well-formed XML that includes the message, the tags, and the metadata.  When a message is to be delivered, the row is retrieved and the XML is parsed.  From a practical standpoint, there's no cost associated with varying the message length.

But, from the user's perspective, there's a huge issue.  If we count each URL and each #tag and each @dpp (which will be @dpp.esme or @rhirsch.siemens when we have federation) as a single character (or 6 characters or whatever the "count" is), then we have an issues related real-time parsing of the message and giving the user feedback as to how many characters the system thinks is in the message.  The parsing mechanics for messages is non-trivial and will evolve as we add access control, etc. to message.  Counting real characters is pretty easy to do with the existing web client.  We periodically send the message from the browser to the server, parse it and display the count.  It'll be a tad-bit jumping with the count (the resolution will be 1-3 seconds rather than key-stroke-by-keystroke), but users will get feedback as they approach the character limit.  A similar mechanism can be exposed on the APIs so that the Flash, etc. clients can do the same thing.  But as bandwidth between the client and server becomes slower and more latent (e.g., iPhone running on GPRS), doing a lot of communications with the server is going to be less optimal.

The issue is not a technical issue, but a user-experience issue.  As I said before, I am reluctant to make strategic decisions about ESME without working through the issues.  The user experience issue here is huge.
 

2. Shorten URLs
If we limit the message length, we should probably think of shortening
the URLs.
(and in that case, how?)

ESME already shortens URLs.  That's been in the codebase for nearly three months.  We display the full URL so people know where they're going (this could be "shortened in the middle"), but all URLs in the system are shortened and it's up to the client as to how to display the URL.
 

3. Ability to send attachment with messages
Should the users have the ability to upload and display media. And if
yes, limited to only certain file types? (for instance .pdf/.doc/.xls
etc)

So, we don't want long messages except if they're long messages?  While Present.ly does this, I'm not sure it's a reasonable feature.  It feels too much like email attachments.  It also feels like it's moving ESME towards Scribd territory.  I'd much rather see an optional "side service" that handled media.  That would allow the core ESME server to be small and focused.

There's also no limit to the size of the meta-data that can be associated with the message.  If we want to have an XML <-> MIME mechanism, we can attach stuff to messages that look like MIME, but are transmitted as XML.

Personally, I'm in favor of a side-service, but if others are strongly in favor of it being part of the core ESME service, the plumbing is already there... we just have to put a UI on it.

Thanks,

David

- Anne

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[vdichev]

Agreed, there are two sides: technical and business (let's rather call
it user-centric).

Making the technical restrictions dictate the rules was never the
right thing to do (remember "640K should be enough for everyone"?).
The width of the database column or the SMS length limit are very
minor considerations in the long run. Think about it: just because
using micro-messaging for disaster relief situations is slightly more
complicated with over 140 characters doesn't mean you shouldn't use
more than 140 characters in any other context as well. When did any of
you participate in disaster relief situations and is this really a
major target scenario we want to create ESME for? Even then, if you
know you're sending a message of disaster, just make it short (as
you're likely to do anyway in this situation).

To be precise, 140 characters is only the limit for 8-bit messages. If
I want to use my native cyrillic alphabet, I have to use 70 for one
"burst". So should ESME use only 70 characters if you want to use
Unicode just to cater to SMS restrictions? From this point of view
this seems shortsighted.

Strongly encouraging the user to use a certain convention is an
entirely different matter. If you look closely, you'll notice that
even Twitter does not impose a hard 140 character limit. You can send
a much longer message (the web interface is hardly a major
restriction), it's just not displayed in full. ESME could do the same.

To address the concern that messages could grow to email length, let
us look at instant messaging. In many IM clients the message limit is
much longer than 140 characters (450 in ICQ initially, then increased;
XMPP has virtually no limitations to write a standard email-sized
message). Still, in IM clients we rarely ever reach any significant
message size. The reason we write long emails is because the delay is
much longer than in IM- one is perceived as a couple of minutes stale,
the other is instant.

And then, even if ESME does "degenerate" into email size, so what? It
will still be different than email, if not for any other reason than
for the fact that you (the reader) choose what to read, not the one
who sends the message. Trying to fit the user into a mold could easily
be a dead end which is hard to escape. Twitter initially tried to make
a platform more appropriate to blogging than messaging, but its users
had something else in mind; Twitter is still trying to cope with the
consequences of its initial design.

So to summarize: encouraging users to write short messages is one
thing, enforcing an arbitrary limit based on a standard created in
1985 seems backwards. I know that most agree that 140 is too little,
so I don't mean to criticize anyone, but to call for more focus. Do we
want a micro-messaging platform for the business user who wants
Unicode and structured metadata or do we want to hinder everyone just
to make sure that a message isn't truncated in an emergency situation?

Vassil

On Nov 3, 4:00 pm, "Dennis Howlett" <dahowl...@gmail.com> wrote:
> Kirsten raises a very good point. There are 2 aspects to this: technical and
> business. I saw a possible use case in disaster relief situations where I'd
> assume the main method of communication would be via mobile phones.
> Similarly, in field service situations mobile will be preferred. Those use
> cases alone would seem to limit input to 140 chars as a guarantee of
> transmission.
>
> Alternatives and qu's:
>

> 1. Is there any reasonable way to develop a mobile client that could

> overcome the 140 char limitation? If so then which mobiles would we wish to
> support (eg S60, Blackberry, others?) Would this overcome the potential SMS
> delays and character limits to which Kirsten refers? How about developing
> for the OperaMini client? Does that solve the problem?

> 2. If we offer alternative input limits, is that a one time config? If so

> what happens if circumstances change?

> 3. If we offer a scale, where are the end points: 140, 255 (which I think

> is where Yammer stops and which I personally favor having used it) 500
> (which I think is straying into email territory?)
>
> Thinking about the way people will use ESME in a business context leads me
> to think that shorter is better as presumably people will develop their own
> means of communicating in a shorthand that works for them.
>
> If it is of any use, I have contacts that can open doors at Nokia...
>
> D -:)
>

> On Mon, Nov 3, 2008 at 2:42 PM, S. Kirsten Gay <kirsten...@yahoo.com> wrote:
>
>
>
> > I was thinking a company would make that decision just once, at
> > configuration. Perhaps the database columns could be configured to match to
> > increase efficiency? (not my gig, just a thought)
>

> > ------------------------------
> > *From:* "Hirsch, Richard" <richard.hir...@siemens.com>
> > *To:* esme...@googlegroups.com
> > *Sent:* Monday, November 3, 2008 7:04:59 AM
> > *Subject:* [ESME-dev] AW: [ESME-dev] Re: Important issues we still need to

> > discuss
>
> > I think the idea of having a character limit that is dynamic is intriguing but we also have to remember that character length is tied to a variety of very technical matters (database column lengths, etc.).
> > Therefore, it might be difficult to configure on the fly. I might suggest creating
> > a scale for companies to use. For example. Min 140 max 500. Database columns
> > could then be set to max length and then the UI could respond dynamically
> > based on the limit set by the configuration.
>
> > One question: Can a company set the character limit just once (perhaps,
> > during an initial configuration) or can it do it multiple times - which I
> > wouldn't recommend.
>
> > -D.
>

> > ------------------------------
> > *Von:* esme...@googlegroups.com [mailto:esme...@googlegroups.com] *Im
> > Auftrag von *S. Kirsten Gay
> > *Gesendet:* Montag, 03. November 2008 12:53
> > *An:* esme...@googlegroups.com
> > *Betreff:* [ESME-dev] Re: Important issues we still need to discuss

> > ------------------------------
> > *From:* Anne/yojibee <yoji...@gmail.com>
> > *To:* esme-dev <esme...@googlegroups.com>
> > *Sent:* Monday, November 3, 2008 4:12:08 AM
> > *Subject:* [ESME-dev] Important issues we still need to discuss

[Dennis Howlett]

I agree that the end user experience has to be top of mind.

@vassil and @dpp seem to be arguing pretty much the same thing (which seems to dispose of the 140 char discussion) but I'm not 100% clear in my mind what @dpp is proposing regarding the (mobile?) user experience.

If I've heard correctly it sounds like we could be much closer to a resolution on this than we have been on the past.

D -:)

[David Pollak]

+1

I think that social pressure should be the thing driving ESME use.

[David Pollak]

When I get my Android phone and have a little time to put together an Android client, I'll send around a screen shot. :-)

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us

[S. Kirsten Gay]

Agreed with below. A couple of points:

 

We can make UI that works with any of the solutions. 

I believe that most of the #ESME teammembers are working in higher-end technology environments where phones like blackberries and iphones are the norm. However, the applications where simple SMS sized message might be relevant are places like India where a cell phone is often the only connection and SMS the only option beyond voice (please correct me if I am wrong), and non-technology focused companies who might drop $100 USD on a phone per employee but not $500 USD (something like Ford Motor company for employees who care for machines, medium small shipping companies with a small fleet of trucks). 

It's really a question of what market we are going after. If #ESME wants to focus on the SAP's, Siemens, Apples & Colgates of the world, then the longer text is probably the way to go.

-Kirsten

---

From: vdichev <vdi...@gmail.com>
To: esme-dev <esme...@googlegroups.com>
Sent: Monday, November 3, 2008 4:41:52 PM
Subject: [ESME-dev] Re: Important issues we still need to discuss

[vdichev]

I'm not all against SMS, and these are valid concerns, but my point
was that even if there is no hard 140-character limit, ESME would
still be usable for SMS. Just enforce a convention to write shorter
messages. If there is a hard character limit, that does change the
experience for the desktop/iPhone/Blackberry/Android/etc user. My
thinking was that we are planning to use a wide variety of input
sources for the messages, and for instance the NetWeaver logger
integration makes no sense with short messages- sometimes only the
package + class name can fit in that.

Again- it might make a lot of sense to put a limit on the displayed
message on the UI and truncate the rest. After all, considering that
ESME has actions, the UI is far not the only way to view a message in
ESME.

On Nov 4, 2:45 am, "S. Kirsten Gay" <kirsten...@yahoo.com> wrote:
> Agreed with below. A couple of points:
>
> We can make UI that works with any of the solutions.
>
> I believe that most of the #ESME teammembers are working in higher-end technology environments where phones like blackberries and iphones are the norm. However, the applications where simple SMS sized message might be relevant are places like India where a cell phone is often the only connection and SMS the only option beyond voice (please correct me if I am wrong), and non-technology focused companies who might drop $100 USD on a phone per employee but not $500 USD (something like Ford Motor company for employees who care for machines, medium small shipping companies with a small fleet of trucks).
>
> It's really a question of what market we are going after. If #ESME wants to focus on the SAP's, Siemens, Apples & Colgates of the world, then the longer text is probably the way to go.
>
> -Kirsten
>
> ________________________________

> From: vdichev <vdic...@gmail.com>

> ...
>
> read more »

[billfernandez]

I hope you don't mind if I contribute some thoughts to this
discussion.


SHORT MESSAGES ARE CRITICAL

I suggest that the key virtue of micro-messaging that you can skim a
large number of messages, ignoring the ones of no interest, and
completely grasping the interesting ones, quickly and with little
thought. Thhis is possible because the messages are short.

A short-message limit forces writers to communicate efficiently
(lowering the cognitive load on the readers) and allows readers to
approach reading with the mindset of "scanning headlines" -- allowing
them to quickly process a message stream and then turn their attention
back to other tasks.

If we allow messages to be long, then we lose these two key
properties. In particular, if users find, because some messages are
short and others are long, that they are constantly having to switch
back and forth between the two cognitive processes of "scanning
headlines" and "reading texts", then I believe most users will find
ESME unrewarding and will not use it.

Therefore I would strongly suggest that we enforce a short-message
limit, probably in the range of 140 to 256 displayed characters.

I aslo suggest, since we are anticipating the ability to create
federations of ESME servers, that we adopt a single, ESME-wide limit.


DISPLAYED CHARACTERS ARE MORE IMPORANT THAN BYTE COUNTS

While it is very imporant to keep the number of displayed characters
in a message small, it doesn't matter as much how many bytes are used
to store or transmit a message. Therefore if a message is stored in
double-byte Unicode, or includes as metadata long URL strings, etc.
that's OK.

It has been mentioned that a 140 byte chunk may be the largest that
can reliably be bursted using the SMS protocol, and the question has
been raised as to whether we should optimize for SMS. My current
thought is that it should be possible to provide simplified, degraded
support for SMS (e.g. by allowing SMS messages to break into multiple
bursts, or to be smarter and just strip out value-added metadata, etc.
before sending to an SMS channel), and to provide full-feature support
over IP to custom smartphone apps.


EMBEDDED URLS

I think it's important to be able within an ESME message to refer to
internet-accessible resources, and the best form of reference is the
URL. Since URLs can be very long, and we want ESME messages to be
very short, I suggest that we do what HTML does with the anchor tag:
Let the message author specify a short, human-readable label for the
link, and only display this short label in the displayed text of the
message. Store the URL itself as metadata to the message.


ATTACHED DOCUMENTS

I feel very uncomfortable with the idea of allowing document
attachments to ESME messages. I feel that a large percentage of ESME
messages will act as pointers to information; much of it internet
accessible, and most of that in URL form. I think that simply
allowing any URL to be gracefully embedded in an ESME message (as
described above) elegantly and flexibly supports a vast range of
possibilities.

On the other hand, to support attachments, we open up a Pandora's box
of issues that I don't think really add to the value or rationale for
ESME. For example:
size of documents, types of documents, storage capacity, server load,
transmission bandwidth, access control, retention policies, government
regulations regarding messages and their attachments, and what do you
do when it's not a document that you want to attach, but access to a
database or web service, etc.?

I think being able to embed URLs allow ESME messages to point readers
to virtually any kind of internet-accessible resource, and also push
all legal, policy, access control and technical management issues onto
the servers of those resources.


FWIW,
Bill Fernandez

[Darren Hague]

Bill,

For my part, I agree wholeheartedly with what you say, particularly
the URL/anchor part, which makes a lot of sense. Of course, what you
have written pertains mostly to the experience of the users who are
reading the messages. The next challenge is to make this work for the
users who write the messages.

As regards message length, we could have a convention, implemented in
any clients which are a part of the project, which uses something like
a traffic light system as feedback: up to 140 characters would be
green, 140-255 characters would be yellow, and over 255 characters
would be red (and the client would either not permit the msg to be
sent, or would only display 255 chars in any received messages - I
prefer the former). As you say, this would correspond to the
characters in the message as seen from the readers point of view.

To encode URLs, we could adopt the Wiki-style syntax of [http://
www.google.com|Google Search], and for "raw" URLs we could enforce a
32-char limit, with ellipsis if there are excess characters, e.g.
http://www.amazon.com/Universal-Worklist-SAP-Netweaver-Portal/dp/1592291465
would be shown as http://www.amazon.com/Univers...

I completely agree that it would be a bad idea to deal with
attachments within ESME - a much better place is a WebDAV-enabled
repository. Otherwise, we're back to the other great problem of email:
trying to collaborate by sending multiple versions of the same
document around. I believe attachments are a fundamentally bad idea,
which only exist because email pre-dates http.

Thanks for joining in the discussion,
Darren

On Nov 6, 6:14 pm, billfernandez <myfriendscallmeb...@gmail.com>
wrote:

[vdichev]

Thanks a lot for the insightful tips, Bill.

> DISPLAYED CHARACTERS ARE MORE IMPORANT THAN BYTE COUNTS

For me a lot of your advice revolves around this. Technical reasons
are much less important than how the message is perceived by the user.
I am really interested if there is a study about an optimal message
limit, it could be revealing (vaguely remember reading about one, but
can't remember where). This leads to

> EMBEDDED URLS

This is a real gem. It can be both shorter and more meaningful than
URL shortening services. ESME does shorten and cache URLs already, but
for me this sounds both simple and efficient.

> SHORT MESSAGES ARE CRITICAL

For the majority of messages I agree, this is critical. Still, I
remember Scoble's old article about breaking Twitter's rules (http://
scobleizer.com/2007/09/23/the-10-rules-of-twitter-and-how-i-break-
every-one/)- guess which is rule number 1. There's always one in 100
messages where you can't fit. I'm wondering if it's possible to have a
way to discourage use of long messages but not make it impossible
altogether. In ESME a lot of the messages might not be typed by a
human, but generated/relayed/pulled, so there must be a way to get to
that type of detailed information if you want.

Another concern I have is that short messages force you to use
abbrvtns omit punctuation and generally sound like a teenager. This
might not be very appealing in a corporate environment.

As I see it, Twitter's way of doing things is not much different than
what you implicate with links- that ESME messages should be just
headers pointing to more information. Namely, up to 140 characters of
your message appear on the timeline, but there's a link to the full
message text, if you want to see it. Not a big cognitive difference if
the message is a link to a rather short blog entry- you scan the
headers and click on a link if you want to see "more..." text.

Federation and message limits? Again, could be solved by truncating to
a fixed limit and providing a link to the full text.

I don't know if there are better ways to encourage short messages-
make each message in a scrollable text box (way too ugly) or make the
font size bigger for shorter messages (ok, I'm kidding). The fact that
I can't think of better ideas doesn't mean there's nothing better.

So while I'd hate to have huge messages float around, I'd also hate to
not be able to pack more info once in a while. The big question is, is
it possible to reconcile both views?

Thanks again,
Vassil


On Nov 6, 8:14 pm, billfernandez <myfriendscallmeb...@gmail.com>
wrote:

[billfernandez]

@darren, @vassil --

o I noticed Twitter changing the color of it's characters-remaining
readout as I approached the limit. This is like Darren's "traffic
light" idea.

o Whatever we decide, I think it's critical that the UI optimize for
entering messages quickly and easily and simply. I think that
supporting special cases for that one in a hundred message that just
can't fit in our limit will make the UI for the ninety-nine out of a
hundred messages that much harder and more complicated: to the
detriment of all.

o I'm also worried that having short-form and long-form messages (or
variations on this theme) would start us down the non-productive path
of: "Hey, short-form messages are kind of like a TITLE, right? and
long-form messages are like a DESCRIPTION, right? So why don't we let
messages be written and accessed in four stages just like documents in
document management systems: TITLE, DESCRIPTION, ABSTRACT, FULLTEXT?"

o I think it would be easy (though I haven't tried it yet) to break a
long message into multiple sub-messages. I do this with IM and SMS
all the time. Why not in ESME? E.g.: Message-1 = "Hey, have you
heard...", message-2 = "...I got a new phone!" OK, there are some
disadvantages to breaking a long message into shorter ones, but it's a
painless way to handle the one in a hundred case, right?

o I also think that it's crucial that we force users to be terse,
rather than making it easy for them to be sloppy and undisciplined.
By enforcing a short limit we put the load on the (single) writer to
be concise, rather than putting the load on the (many) readers to
access and analyze.

o Like personalized license plates, SMS text messaging, Instant
messaging, and others, micro-messaging communities of necessity use
shorthand and abbreviations in their messages. That we associate
these lexical shortcuts with teenagers is because teenagers are the
largest user community for these forms of communication. the point is
that these language adaptations are inherent qualities of short-
message communication. Anyone (event the corporate CEO to wants a
personalized license plate) will have to learn not only to abbreviate,
but to recognize shorthand codes used within the community. Indeed,
even in this long missive I've used UI, ESME, SMS and CEO rather than
spelling out the associated terms.

o I am finding the Twitter 140 character limit a bit too cramped. I'm
wondering if 200 characters would be better? (But I'm afraid that 255
characters would be too long.)

[Darren Hague]

Heh - I just noticed that Google Groups truncated my "long URL"
example to 70 chars and added ellipsis dots. Well, if it's good enough
for Google... :-)

On Nov 6, 11:50 pm, Darren Hague <dha...@fortybeans.com> wrote:
> Bill,
>
> For my part, I agree wholeheartedly with what you say, particularly
> the URL/anchor part, which makes a lot of sense. Of course, what you
> have written pertains mostly to the experience of the users who are
> reading the messages. The next challenge is to make this work for the
> users who write the messages.
>
> As regards message length, we could have a convention, implemented in
> any clients which are a part of the project, which uses something like
> a traffic light system as feedback: up to 140 characters would be
> green, 140-255 characters would be yellow, and over 255 characters
> would be red (and the client would either not permit the msg to be
> sent, or would only display 255 chars in any received messages - I
> prefer the former). As you say, this would correspond to the
> characters in the message as seen from the readers point of view.
>

> To encode URLs, we could adopt the Wiki-style syntax of [http://www.google.com|Google Search], and for "raw" URLs we could enforce a
> 32-char limit, with ellipsis if there are excess characters, e.g.http://www.amazon.com/Universal-Worklist-SAP-Netweaver-Portal/dp/1592...
> would be shown ashttp://www.amazon.com/Univers...

[David Pollak]

Let's get this discussion restarted on the Apache esme-dev mailing list!