Phone Inbox UI: Dynamic Scroll or Paging

27 Oct 2006 - 1:06am
7 years ago
4 replies
714 reads
Amnon Dekel
2005

I am in the midst of an argument with my Engineering department about how to
implement an inbox in a cell phone based application. On the web version we
are implementing a page based inbox- (the standard i.e. see the first N
entries. To see more click on Next). I am fine with that.
On the phone, I want them to implement it differently: show me the current N
entries (depending on the phone- between 5 and 10 lines), but keep the next
and previous N entries in cache, so that the user can "scroll" continuously
(phone based scrolling is not really scrolling- it is done by multiple
clicks on the down or up key) and not force them to click on a next page
button (which will steal valuable real estate and make their experience
choppy). I feel that paging on the phone is not standard and is different
from what users already know (i.e. their SMS inbox). One thing to remember-
this is a native phone app, not a browser based experience.

I will be happy to hear your comments.

--
:::........::::...::......:::....::::...::............:::::
Amnon Dekel
Cell: +972 54 813-8160
:::........::::...::......:::....::::...::............:::::

Comments

27 Oct 2006 - 1:19am
Håkan Reis
2006

Take a look at Operas approach on therir mobile browser. Most phones
today have a 4-way navigator key. Up and down would scroll. Opera uses
left/right to page, that way you don't need any special next/prev.
buttons.

I used it myself and after just a while I find it easier to page than
scroll. The result is that you don't get lost, and have to scan the
lines again and again to find where you were and what was the nex line
to read. This is especially true whe you read the full messeage. I
find that it's almost always easier to relocate the reading when you
page than when you scroll.

/ Håkan Reis
Dotway AB
http://blog.reis.se

27 Oct 2006 - 1:23am
Amnon Dekel
2005

Yes- I know this approach and love it - on their mobile browser. But this is
not a standard way of interacting inside native phone applications.
Additionally- in many cases I use the right and left keys to move
horizontally across tabs so this doesn't work.

Thanks

On 10/27/06, Håkan Reis <hakan.reis at dotway.se> wrote:
>
> Take a look at Operas approach on therir mobile browser. Most phones
> today have a 4-way navigator key. Up and down would scroll. Opera uses
> left/right to page, that way you don't need any special next/prev.
> buttons.
>
> I used it myself and after just a while I find it easier to page than
> scroll. The result is that you don't get lost, and have to scan the
> lines again and again to find where you were and what was the nex line
> to read. This is especially true whe you read the full messeage. I
> find that it's almost always easier to relocate the reading when you
> page than when you scroll.
>
> / Håkan Reis
> Dotway AB
> http://blog.reis.se
>

--
:::........::::...::......:::....::::...::............:::::
Amnon Dekel
Cell: +972 54 813-8160
:::........::::...::......:::....::::...::............:::::

27 Oct 2006 - 1:35am
Håkan Reis
2006

I am with you on that, i guess the inbox should be in the line of a
integrated app and not an addon app, like opera is. The least you
should do is provide scrolling with up and down key. That should not
be changed. It's the behaviour you expect as a user. You _always_
scroll with up/down keys.

Are there any possibility to use the soft-keys? It all depends on what
you got to work with when it comes to free key resources. Also when
displaying a list of mails you probably have the number keys to your
disposal, I know they are harder for the user to learn and to
visualize.

/ Håkan Reis
Dotway AB
http://blog.reis.se

27 Oct 2006 - 8:19am
Barbara Ballard
2005

With the caveat that how Engineering makes this happen (keeping stuff
in cache, etc.) is irrelevant, and that you said "native" not
"downloaded", I would try the following strategies:

1. Use volume up/down to allow page scrolling - a nice feature for
experts with no cost to novices

2. Provide a text entry box at the top of the screen. Push - hard -
to get your Engineering team to provide dynamically updated results.
Now you have to figure out whether to provide all JKL results, or just
J results upon single press of the 5 button.

3. In applications that do not have obvious web-based (to the user)
fetch operations, avoid next/previous. Address books that are
synchronized with some remote data are likely to be LARGE, and you'll
need to support those users (unless your users are different than
typical phone users). Going through those 5 or 10 at a time will not
encourage use. Scroll instead, with the understanding that scrolling
is not going to be the primary access for users with larger address
books.

On 10/27/06, Amnon Dekel <amnoid at gmail.com> wrote:
> I am in the midst of an argument with my Engineering department about how to
> implement an inbox in a cell phone based application. On the web version we
> are implementing a page based inbox- (the standard i.e. see the first N
> entries. To see more click on Next). I am fine with that.
> On the phone, I want them to implement it differently: show me the current N
> entries (depending on the phone- between 5 and 10 lines), but keep the next
> and previous N entries in cache, so that the user can "scroll" continuously
> (phone based scrolling is not really scrolling- it is done by multiple
> clicks on the down or up key) and not force them to click on a next page
> button (which will steal valuable real estate and make their experience
> choppy). I feel that paging on the phone is not standard and is different
> from what users already know (i.e. their SMS inbox). One thing to remember-
> this is a native phone app, not a browser based experience.

--
Barbara Ballard
barbara at littlespringsdesign.com 1-785-550-3650

Syndicate content Get the feed