Usability suggestions

[GoogleCodeExporter]

Hi,

I posted some suggestions on the sourceforge web, but Google Code seems to
be the official rsReader web now, so I copy the suggestions here.

Thanks

___________________________________________________________

Great open source application, good work!

I'd like to contribute to the proyect by giving some usability suggestions,
to make the aplication easier to use.

The application has 3 levels of navegation:

1. list of feeds
2. list of articles (of a feed)
3. text (of an article)

The tipical navigation will consist of:

- select one feed
- select one article
- read the article
- select other article
- read the article
- select other article
- read the article
...
- select other feed
- select one article
- read the article
- select other article
- read the article
- select other article
- read the article
...

Perhaps, sometimes the user will select to open the article on the mobile
browser, but this will be unfrecuent. The usual navigation will onsist
nearly-exclusively of the 3 commented levels of navigation (feeds, articles
and texts).

So, we should make that navigation as easy as possible, by minimizing the
number of key pressings. Currently, when we are in the level 2 (list of
articles) or in the level 3 (text of an article), we have to press several
keys to go to the previous level:

- Options key
- Down arrow key
- Ok key

So 3 key-pressings are needed to change to the previous level. I think that
only 1 key-pressing should be required.

From the point of view of usability, probably the most intuitive solution
is to use arrow keys:

- Use right/left arrow keys to enter next/previous level of navigation.
- Use up/down keys the to do the same thing they do used now (to highlight
other element in the list, or to scroll the text).

There are two special cases, that can be solved easily:

- If we press the left arrow key in the first level (list of feeds), there
is no previous level. But, there is no previous level only in the
aplication. In the mind of the user, the previous level is the screen
previous to launching the aplication. So the action can be to quit the
application.

- If we press the right arrow key in the last level (text of an article),
there is no next level. But, again, there is no next level only in the
aplication. In the mind of the user, the next level is the screen of the
mobile browser, showing the article page. To avoid to unvoluntary open the
mobile browser, I would make before a question to the user, "Open in the
browser?" or similar. The question could also be configurable at settings.

Ah, I forgot old phones (that only have up/down arrow keys, and don't have
right/left arrow keys). That phones usually only have 2 function keys: left
function key (normally used to open an option menu) and right function key
(normally used for Ok/accept). Well, for those phones (and for new ones
too) I would use:

- The right function key would have the same efect than the right arrow
key. It's the actual behabiour.

- An element of the option menu (opened by the left function key) would
have the same efect than the left arrow key. It's the actual behabiour too.
But, instead of being the second item on the option menu, I would place it
as the first item, to avoid one key pressing (the down arrow key) to select
the item.

- As an improvement of the last point (an option menu element (the first
element) to go to the previous level), we could make the left function key
to act as the ok (the right function key) when the option menu is open. In
this way, we would only need to make a double-click (well, double-press) on
the left function key, in order to change to the previous level.
Double-pressing one key is faster (and easier) than pressing one key and
then other key.

Well, that's all ;). I think that those suggestions (specially, the
right/left arrow keys suggestion) will increase greatly the usability of
RSSReader.

One final point. A tinny explanation could be added to the web page, on how
to "copy" (yes, that is the word for the common user) RSSReader to the
phone. For example:

HOW TO COPY RSSREADER TO THE PHONE

To copy RSSReader to the phone, you will need some communication
method between your computer and your phone to be working (cable,
bluetooth, or infrared), and copy the midp20_RSSReader.jar file
(that is into the <zip file> (link)) from the
computer to the phone. If you have an old phone (that uses MIDP
1.0), copy midp10_RSSReader.jar. The detailed steps are different
from one phone to other, so please read the manual of your phone
and the help of your communication program.

Alternatively, you can use your phone browser to download
RSSReader directly from this web. Just enter this url:

http://mobilerssreader.sourceforge.net/midp20_RSSReader.jar

If your phone is old, use this url:

http://mobilerssreader.sourceforge.net/midp10_RSSReader.jar

In that way, the installation of the application will be more clear and
easy for potential users.

Hope all this will help. Thanks for your work!

Original issue reported on code.google.com by freesoft...@yahoo.es on 30 Sep 2007 at 4:46

[GoogleCodeExporter]

Thanks for your suggestions.  On the next release I have changed the back key 
to be 
the first in the item menu to help reduce a little bit.  I now allow an option 
to 
have back be first on headers (RSS items) form as it is not needed as one can 
use 
select to open the item so open does not need to be the first choice.  
Unforunately, 
it's hard to have things based on left/right etc as it requires a custom field 
or 
canvas.  I'm looking into deriving some GPL code to do this.  I have also 
updated 
the sourceforge documentation.  I'm having trouble with the Wiki as I'm not 
used to 
it.

Original comment by ibunto...@gmail.com on 13 Nov 2007 at 4:11

[GoogleCodeExporter]

Thanks.

I've tested the new version (midp20_jsr75_RSSReader-10.7), and it's really 
useful the
new "Back" action for the main key at the article text.

The optimal thing would be the arrow key navigation, as I commented, since it's 
more
intuitive. I know a bit of java (not too much), and probably it's possible to 
assign
events to key-pressings.

If it's hard to assing events specifically to the arrow keys, I propose a 
suggestion
to solve the problem in the meantime (while you find a way to use the arrow 
keys):
Use some number keys to simulate the arrow keys (as games do):

    2 - up
    8 - down
    4 - left
    6 - right
    5 - ok

In this way, the user will navigate the three levels (list of feeds, list of
articles, text of an article) by using those number keys, as if they were the 
arrow keys.

Is it easy to add code to use those number keys as arrow keys?

Thanks!

P.S. What's the difference between "midp20_jsr75_RSSReader-10.7.jar" and
"midp20_RSSReader-10.7.jar" files? I've tested the first one.

Original comment by freesoft...@yahoo.es on 21 Dec 2007 at 9:43

[GoogleCodeExporter]

In regard to the navigation, the next version will cut down on another selection
the next version will have the option on the headers/items to give back higher 
priority in the menu as the open is redundant as using select does the same 
thing.  
In regard to catching the keys,
the problem with J2ME is that it does not allow you to catch key actions for 
the 
standard objects like list, form.  In order to catch these actions, you must 
handle 
your own drawing of each line with wraparound and scrolling.  I found some GPL 
code 
that does this, but it needs to be adapted for this application.  J2ME has less 
than 
JDK 1.0.

The differences between the two programs.
I guess that I have not explained this as well in the documentation.  The jsr75 
version allows you to get feeds and OPML, etc from the file (memory) system 
which is 
allowed by JSR 75 (Java Service Request 75).  You are allowed to browse the file
(mem0ry) using the menu command 'Find Files' which browses the file system to 
find 
the file.  This makes it easier to import an OPML/HTML or get RSS file from 
memory.  
This is more useful for import as you don't have to put the OPML on a web site. 

This is usefull if you have your OPML saved on a PC and can put it into phone 
memory.  Otherwise, you would have to put it on the web (which is a hassle).  
One 
drawback is that some phones force you to give access to access directory which 
can 
be frustrating.  If you can enter the memory path yourself (file:///...) there 
would 
be only one request.

The one without jsr75_ 

Original comment by ibunto...@gmail.com on 29 Dec 2007 at 1:42

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

Hi,

I have started the changes to allow keys to do navigation although I have found 
that 
on some devices it does not work, but on others it does.  These will be in 
1.12, the 
next major release with the caveat that if the device does not support it, it 
can be 
turned off.  The navigation keys are based on game actions or numeric keys.  
Although unlike what you have I have  left/right (or 4/6) as page up/page down 
and 
up/down (or 2/8) for up one line/down one line.

Regards,

Irving

Original comment by ibunto...@gmail.com on 9 Dec 2008 at 9:08

• Changed state: Started
• Added labels: Type-Enhancement
• Removed labels: Type-Other

[GoogleCodeExporter]

Great! Navigation with arrow keys will be a good improvement in usability. 
Thank you
for your effort.

This summer I've been using last version (1.11.2), and I have MORE USABILITY
SUGGESTIONS. Yes, I don't get tired of suggesting ;-). Well, I love usability, 
it's
my hobby, and I enjoy when giving usability suggestions for opensource 
applications.

Here they go:

1) When reading the content of an article, the down/up arrow keys are used to 
show
next/previous page of the article. That's ok. But I've seen that, depending on 
the
position in the article, sometimes the scroll is not an entire page. For 
example:

- In my phone (a 2-years cheap Nokia), the screen shows 8 lines of text 
(configured
with little font size).
- If I open the content of an article, the first 8 lines (1 to 8) of the 
article are
shown: 5 lines with the title, and 3 lines of body.
- Then, if I press the down arrow key, the next 8 lines (9 to 16) should be 
shown.
But what is shown is lines 7 to 14. This means that the scroll has been 6 new 
lines
(scroll=+6), not 8. So not an entire page.
- If I press the down arrow key again, then lines 15 to 22 are shown. This is
correct, an entire page (scroll=+8).
- If I press the down arrow key again, then lines 20 to 27 are shown. This is 
not
correct (scroll=+5).

Apparently the incorrect scroll happens only when the part shown (or the part 
to be
shown) contains different text formats (for example, the bold format in the 
title or
in the "Link:" and "Date" texts). If the part shown and the part to be shown 
both
contain the same (and unique) text format, then the scroll is done correctly.

The scroll should be always equal to the screen size. A partial (and, even 
worse, a
changing) scroll makes the reading more difficult.

2) Keep the ligth on: Some phones (like mine) turn the light off to save 
battery, so
some key must be pressed frecuently to keep the light on while reading (in my 
case,
every 10 seconds). There is no configuration on the phone to change this, so the
application (rssReader) must keep the light on. This can be optional (a 
configuration
option). I've seen this functionality in eBookME (an opensource javaME 
application to
read books on the phone), which allows to keep the light on and to select the
intensity of the light (it's great).

3) Notification of end of updating: Sometimes, depending on the type of the 
internet
connection (GPRS o 3G), the feed updating process ("update all" command) can 
take
some time (perhaps 1 minute or even more). So I usually select the "update all"
command, then put the phone on some place (for example, a table), and do other 
tasks
(prepare some food, organize the room, etc). Every 20-30 seconds, I go back to 
the
phone, and see if the updating has finished. If not, then I go back to continue 
the
other task. So it would be useful the rssReader to notify me (with a blinking 
of the
screen light (like when receiving a call), or/and generating some sound (or a 
simple
"beep")) that the updating process has finished. In this way I would avoid to be
polling the phone (a waste of time). This could also be a configuration option.

4) Content of next article with only one key: In our wish of reducing the key 
strokes
required to use the most common features of rssReader, I think that this 
suggestion
will be a great improvement in usability. I propose that, when reading the 
content of
an article, only 1 key will be pressed to show the content of next article (for
example, with the "3" key, or even better, with the "ok" key (with "Next" text 
in the
screen)). In this way, the user won't have to go back to the article list, 
select
next article, and open the article (3 key pressings in total). Only 1 key 
pressing,
and instantly next article content will be shown. What if the user doesn't like 
next
article? No problem, he only will have to press the key again, and he will see 
next
article content. It's inmediate! Like the remote of a tv ;-). The "Copy link" 
command
(currently assigned to the "ok" key) can be moved to the options menu (left 
function
key). In addition to asigning "Next" [article content] to the "ok" key, the same
command ("Next" [article content]) can also be asigned to the "3" numerical 
key, and
previous [article content] can be asigned to the "1" numerical key. In this way,
we'll have an easy (and simetrical) navigation of the third level (article 
content),
while also using the most accessible key (the "ok" key) to do the most frecuent 
task
(show next article content).

5) River of contents: The previous suggestion (#4) will make users nearly to 
forget
the list of articles (second level of navigation), which will be used only
ocasionally (to find a concrete/already-read article). But the user will still 
have
to use the list of feeds (first level of navigation) to choose other feed and 
read
its articles. Currently, the "river of news" command gives a total list of 
articles
(a "total second level" of navigation). What I propose with a "river of 
contents" is
a "total third level" of navigation (to forget the first level too). This can 
be done
in two ways:

- With list of articles: By implementing the "Next" command for the "ok" key (as
suggested in #4) also when reading the content of an article in "river of news" 
mode.
Probably this is easier to be implemented, because the required changes are 
minimal.

- Without list of articles: By adding a new "River of contents" command to the 
first
navigation level (list of feeds), after the "River of news" command. This would 
show
directly the article contents, without a list articles. And it has the "Next" 
command
for the "ok" key too (to go to next article content).

Perhaps the first way (with list of articles) is more intuitive, due to 
similarity
with the normal use (no river mode).

6) Next page at list of articles: At second navigation level (list of 
articles), the
up/down arrow keys only scrolls by 1 article (+1 or -1). This is ok, because 
every
article has to be selectable. But sometimes, when looking for an article, I 
don't
want to select any article of the shown ones (in my case, 8 articles), I want 
to see
the next part of the list (the next 8 article titles). This can be done by 
asigning
next/previous page of article list to some keys. For example, "3" key for next 
page
and "1" key for previous page.

Well, I think those are sufficient suggestions for now ;-). Specially 
suggestion #4
can be a big step in usability for rssReader. Thank you for your work.

Original comment by freesoft...@yahoo.es on 17 Sep 2009 at 9:34

[GoogleCodeExporter]

Hey guys, any comments on my last suggestions? Please give me some feedback.

Original comment by freesoft...@yahoo.es on 19 Nov 2009 at 8:08

[GoogleCodeExporter]

Hi.  Sorry for the delay, I didn't notice your previous reply.  I'll look at 
it.  I'm 
taking some of ebookme for paging, but ran into some trouble trying to have 
more than 
one item on the same page.  For ebookme by contrast, there is only one item, 
the 
document, on that page.  So, it's much easier to implement.  I'll look at the 
other 
ideas.  I might have to fork the version as the easiest way to do some things 
is to use 
Sun's new LWUIT which is Swing like, but cannot run on the older phones.  So, 
the fork 
would use LWUIT.  I may decide not to if I can get what I have working.  I 
might not do 
changes in the list as that is harder unless I did the fork.

Original comment by ibunto...@gmail.com on 19 Nov 2009 at 11:36

[GoogleCodeExporter]

Ok, don't worry for the delay ;-).

If possible, please implement the main suggestion (#4, "go to next article with 
only
one key") first. Probably it's easy to be implemented, with minimal changes to 
the code.

Thank you for your effort.

Original comment by freesoft...@yahoo.es on 20 Nov 2009 at 8:10

[GoogleCodeExporter]

I have done the next item from an item.  I haven't had time to release 1.11.3 
yet.  I 
guess that I could release a dev version.

Original comment by ibunto...@gmail.com on 20 Feb 2010 at 9:18

[GoogleCodeExporter]

Do you know much about usability for people with disabilities?  I would like to 
write software that's easier for 
disabled people to use.

Original comment by ibunto...@gmail.com on 2 Mar 2010 at 3:48

[GoogleCodeExporter]

I released 1.11.4 RC1 which has a next item feature.

Original comment by ibunto...@gmail.com on 10 Mar 2010 at 1:40

[GoogleCodeExporter]

I intend to do some of your other changes:

1.  I will keep the light on with intensity.  
2.  I will flash the backlight optionally for a specific duration when update 
all is 
complete.   By the way, you should use update modified all as it does a 
conditional 
get of the feed.  The conditional get uses less bandwith as many of the feeds 
will 
not change.

Original comment by ibunto...@gmail.com on 15 Mar 2010 at 12:07