Quoting Gunnar Wrobel <wro...@horde.org>:
Zitat von Michael M Slusarz <slus...@horde.org>:
Quoting Gunnar Wrobel <wro...@horde.org>:
The problem you describe obviously originates from the fact that
it was unclear to the user that she selected *all* messages.
Looking at our UI I must admit that this is hard to see. We
display the note "358 messages selected" but it is a faint gray
and may be difficult to see. I wonder if we could make this more
obvious. Do people think that this might be an option?
I'm not sure if making the message count in the preview box darker
is going to help out. I would argue that making it darker will
make it more difficult to read the screen in general - I think it
is at an appropriate color level now.
Design-wise I agree. I was wondering if it could make sense to push
a notification saying how many messages were selected. But somehow I
assume there are reasons that disallow this :)
A notification message? That seems a bit extreme for an action as
basic as selecting messages. I don't want to see a notification every
time I open a message that says "You have opened a message!". Not
tremendously useful. Notification messages are generally for things
that happened outside of the view/knowledge of the user.
Another issue I forgot to mention before about using the preview space
- several of the commercial clients using IMP use that space to
display things like ads or their localized help content. So the only
reason there is a message count is in there is to break up that large
empty space - it's essentially space-filler.
The cue that is visually stronger is the marking of the messages.
Our list viewport is sized so that it only displays full messages.
There is no visual hint that might tell the user that there were
more messages selected than what she sees on the screen - apart from
the faint grey note and the scroll pane on the right.
There are historical reasons (mainly browser limitations) why we use
the javascript scrollbar vs. a browser scrollbar. In short, it
prevents a user from killing the server. And last time I checked,
those limitations are still relevant.
Other mail clients tend to display a list window that also displays
half messages - which may serve as a visual indication "that there
is more than what is currently displayed in the list window". I
don't want this for Imp and only add this to explain what I try to
describe above.
See above. Whenever I see an interface that has "half messages" I
personally feel like that UI is broken. Tabular data needs to be all
or nothing.
So I feel some minor tweaking in that area might be helpful.
UI improvements more than welcome. Maybe tweaking of scrollbar theming?
This is MORE than most OS's do to indicate that, for example, all
files are selected in a folder.
Yes, I looked at how some of the alternative mail clients handle
this and it is usually not that much more obvious. The web mailers
have a tendency to work page oriented anyway but that is again
something I don't want for Imp.
Especially since this feature (no paging) may be the single best thing
about our dynamic interface. The killer feature, if you will. And
from a personal standpoint, it took a LONG time to get this to work
correctly and stable.
The fact is that you can scroll through the mailbox list, and 99.9% of
the time will see a seamless scroll - even though only a small
percentage of messages are loaded at initialization time. So not only
is this the preferred way to look at the list, it puts no more load on
the server than paged views. Which is really cool IMHO.
I do however believe that we should take any such incident where
users report a problem with our UI serious and should try to figure
out if improvement is possible.
I agree, but having done this now for many years (I am getting old) I
have learned that just because users complain about something doesn't
mean a change is necessary. There will always be a certain percentage
of users that complain about something with the code - you can't make
everybody happy all of the time. The art is determining the valid
calls for improvements from the baseline noise.
Looking at the massive amount of work that has gone into OS UI
development, their time-tested solution to prevent unwanted deletions
is to have a Trash folder, which requires a two-step process. So
seeing as how we have that solution, that to me is the proper answer
to this issue.
People may disagree, but I just don't see a pressing issue here.
Maybe part of that is just that I haven't heard of a solution yet that
doesn't hurt more than it helps. I think this would be more of an
educational/help thing than anything necessarily wrong with the UI.
(Speaking of - this is the one thing I wished we had more of. People
may not be willing/able PHP/javascript coders, but a fantastic way of
giving back is to help with documentation. We don't seem to get a
bunch of this assistance.)
michael
___________________________________
Michael Slusarz [slus...@horde.org]
--
IMP mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: imp-unsubscr...@lists.horde.org
