I thought the original problem was the truncation of the limited message size due to dealing with identifying the sender.
You can add whatever you want to the end (e.g. the domain name) and that will resolve your identification issue. This won't solve the truncation issue in anyway so I'm not sure what we're trying to solve here. SMS limits you to 140 characters. You can use some of those characters to identify a sender - I think you want to use the least amount of characters to do this. Whatever your solution entails will result in 140 - (# of characters needed to identify user) = # of characters leftover for message If we start bringing in icons - we're talking about things that are totally out of the realm of SMS messaging. Can you pass icons in SMS messages? No. We're now meshing a solution which assumes a certain client into the discussion which distracts from the constraint of the SMS message. If you wanted to have icons - then how would a client know which icon to display? If you were using the SMS message as the transport, you would have to use part of the 140 message limit to pass some identification. Same issue as before. If you want to solve the issue - lose the SMS constraint. Otherwise it's just a discussion on trade-offs in usability (how user-friendly is it?) versus functionality (how many characters can I have in a message? How do I deal with truncation of messages?) At some points given the length of usernames and domains, you'll have to place SOME limit on it or you may find yourself without space for your message (again if you want to stick to the 140 character world of SMS). Need to rewire the context (e.g. not SMS) if you want to talk about better solutions than what's been discussed. On Wed, Jul 30, 2008 at 3:50 PM, Bob Wyman <[EMAIL PROTECTED]> wrote: > On Wed, Jul 30, 2008 at 4:37 PM, Ayende Rahien <[EMAIL PROTECTED]> wrote: > > At the end user UI, this is a simple issue, > > associate an icon with each service, which > > doesn't take a lot of room. > > Or use Susan (twitter.com) > > To associate an icon with each service, you would first need to know all > possible services. But, in a federated system, it is unlikely that you could > know this since not everyone will know all services that are federating at > any one moment. Can you imagine that your idea of using icons would work for > email? (I don't think so.) You might build some sort of "icon fetching > service" but that would be a mess. (You'd have connectivity issues, problem > with unregistered icons, etc.) As a result, what you're probably forced to > do is something like what we have in email today: > > Susan <[EMAIL PROTECTED]> > > But, since that is the display convention, why not use it as the input > convention as well? Users will appreciate the symmetry. > > bob wyman > >
