From: Philippe Verdy (firstname.lastname@example.org)
Date: Thu Jun 01 2006 - 23:28:13 CDT
From: "Donald Z. Osborn" <email@example.com>
> What concerns me in this area is not
> the evolution of language or the (sometimes annoying) "SMS language" as
> Philippe puts it, but that some cellphone companies may not find it worth their
> effort to
> provide support for a fuller range of character & language options based on
> misinterpretation of the ASCII workarounds that people have adopted (for
> reasons of display & keyboard). The tool fits the practice but also shapes it,
> and with better (and better standardized) support for extended and non-Latin
> characters, who's to say how people now and in the near future will
> make use of these capabilities?
I don't think that telcos would not be interested in supporting and implementing a capability detection mechanism, notably if it helps them providing services that target their customers more exactly, using new features that will effectively be rendered correctly, but that will be easy for cutomers to use (without wondering always if their mobile phone is compatible with the service).
With this tool, the telco could unify the management of SMS messaging, using Unicode internally in their network and for interacting with the web and other computing platforms.
The absence of the capability in the advertized phone profile would indicate legacy GSM support, and users would still have to specify their preferences, but its presence could boost the sales of newer phones with easier access, and mobile services that DO work as intended.
Another option, if the phone does not advertize the information, is to use the hardware phone identifier (stored separately in the phone electronic itself, rather than in the small removable smart card that contains the subscriber identifier): these two codes are already advertized to the network. So this would allow users specifying the exact model of their phone (and its known capabilities) in the telco website, within the subscriber preference area.
With this information in the telco database, the SMS messaging system can infer immediately which charset the phone supports when receiving messages, so the internal common Unicode-based encoding inthe network can be converted to the more restricted charset, using possible fallbacks for missing characters. Such profiling operation would beused aswell whensending messages: the SMS messaging server would know whichencoding is used and would convert it to Unicode before transfering it to the SMS recipient (a email address, a web service, or another mobile phone)
Gradually, the legacy GSM charset would fade out. And for customers, they would no more worry about SMSmessagesthat can't be read by the recipient. (Note that when receiving SMS messages that can't beread exactly, the GSM platform may contain an URL to visit on the web for reading the complete message, or could contain a link to request a MMS version, where the text is rendered as a scrollable bitmap). The recipients would still have the choice to get the extra information if they want (the telco could maintain a copy of the SMS received on the mobile phone by posting it in a email box readable on the web using a PC, or using the web navigation feature of the mobile phone)
There are ways to make the life of SMS users easier than it is for now. I do think that many people do not like SMS due to its limitations (I am one of those people, who don't like SMS and use it extremely rarely, most of my uses are for receiving SMS messages, but I almost never send any, as I hate composing them using 9 keys, even with the integrated dictionnary assistant; but if SMS was muchlessboring than it is now, may be I would use it). For now I refuse to pay the excessive price due to the telco foreach 128-bytes only SMS message (multiply the cost by the number of blocks...)
Telcos should really reduce the cost for SMS (from which they get too much profit, given that its usage has exploded but its price has not been so much reduced), and notably should put less severe size restrictions for paying only 1 SMS instead of several ones. This way, the encoding size issue would become much less critical, and even UTF-16 would become fine for all SMS messages. And finally this would also help making the real transition to MMS, or to online web/iMode/Docomo services with more added value for operators and service providers.
The GSM charset looks like a dinosaur now, that just appears to slow down the adoption of more advanced mobile services. Now, going to a more modern platform would help people accepting using less boring mobile services. Even on a more modern platform, this won't stop users from composing messages in "SMS language", but now this will be really their own choice, not something more or less imposed by old technological issues.
There are even people that reject the idea of using SMS messaging, simply because of the language it uses! I am also part of them, eventhough I still don't web services on my mobile phone, as I prefer browsing the web on a PC or on a mobile PDA connected to a 3G network or Wifi hotspot; composing SMS or MMS messages on a mobile phone is much too long and too complicate for me, I just prefer calling someone vocally, or sending him a message into a vocal mailbox: it's much faster, more intuitive, and even less expensive as I can give more information using a natural language. It's notable that I also rarely use instant messaging on a PC, for the same reason as SMS: poor language, absence of correction, but also lack of archival and classification of messages (that scroll too fast and require constant and addictive surveillance) and disruptive in my own time schedule.
This archive was generated by hypermail 2.1.5 : Thu Jun 01 2006 - 23:34:04 CDT