[imp] migrating users from traditional to dynamic interface (message deletion)

[Michael M Slusarz]

Quoting Gunnar Wrobel <wrobel at horde.org>:

> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>> Quoting Gunnar Wrobel <wrobel at 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 [slusarz at horde.org]