Text Messaging Application Design

[Jon]

On 10/18/07, Justin Wong <stryderjzw at gmail.com> wrote:
>
> I think what we need to do is start by doing some task analysis. We should
> put away all the different preexisting mental models, such as inboxes and
> other things, and focus on the tasks involved in a Text Message application.
>
>
> Does anyone want to start?
>
> BTW, I think this email thread was hijacked. :) Should we continue in this
> thread or start another?
>
> Justin



Justin,
I think it might be a wee bit difficult to "put away all the different
preexisting mental models".  As the saying goes, learn from your mistakes.
We should take a good look at what there is already, what we like and what
we don't.   Two possible options is the "box & message" method (inboxes,
outboxes, single messages) and the "thread" method.  There may be more
options out there, but I can't think of any others off hand.  Personally, I
do love gmail and how how it handles message threads (in fact that is what I
am using right now).  I also agree with the previously mentioned hate for
having to dig up the last message you just sent to a person, in order to
understand the context of their reply.

Here's where the trouble comes in: _Limited screen real estate_. I'm not
saying that this is an impossible and insurmountable problem, just one to
keep in mind.  Gmail does have a mobile interface (I've used it on my 8125),
its not bad.  I have my issues with it, but it is browser based after all.
This limited screen real estate comes in two fold.  1) on the "home" screen,
as to how many and how much of the messages we can display.  Gmail displays
the sender, the subject and the first 100 characters of the message (on my
1440x900 screen resolution).  In a mobile interface we have less room, but
at the same time the SMS messages are much shorter.  For my personal usage,
you could including the sender and the full message for all my messages on
the home screen, and I wouldn't have a problem - I just don't send that many
text messages.  But for those that do send alot of messages - this would be
a terrible idea.  I remember reading an article recently about a girl who
sent/received something like 7,000 text messages in one single month.  That
averages out to a message sent or received every 3 minutes, 12 hours a day,
30 days a month.  (OT: Its scares me that kids have this much free time, and
this girl isn't alone.)  2)  What do we do with the other messages in the
thread?  Do we summarize them like Gmail - which seems silly because there
is so little to a message?  Or do we display the entire messages, just
having fewer on screen.

Another problem to keep in mind is that Gmail tracks threads by subject and
SMTP headers, to my knowledge we don't have the same options in an SMS
message.  Are we going to assume that all messages to/from the same user are
a "single" thread?  I happen to think that isn't such a bad idea.  Also, how
many/old messages are we going to display, and how long are they going to be
kept.

Here is my example use case:  One particular friend I may text once a week
and just a few messages tops.  During the conversation a thread view would
be useful, but next week when I go to send them the next message - do I
really care about what last weeks thread was?  No, probably not.  If I'm not
paying close attention to the screen while reading the latest message (and
lets be honest, most of us are multi tasking when we text), I may see an
older message and assume it was new.  I may "answer" a message that was
actually from last week.

I realize I've spent a good deal of time here comparing to Gmail and using
threads as an example.  I'm just going with what I know and what can be
shown to others.  If someone else has some examples of a "good UI" for a
messaging applications, please include a link or screen shots.  I'm just as
interested in seeing what others think is a good idea - maybe something
really nifty will pop out.


-Jon
PS. Sorry for the rambling ^_^
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.openmoko.org/pipermail/openmoko-apps/attachments/20071019/35e44b1e/attachment.htm