[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: [imp] migrating users from traditional to dynamic interface (message deletion) Michael M Slusarz Wed Feb 15 01:00:51 2012

Quoting Gunnar Wrobel <[EMAIL PROTECTED]>:

Zitat von Michael M Slusarz <[EMAIL PROTECTED]>:

Quoting Gunnar Wrobel <[EMAIL PROTECTED]>:

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 Slusarz [EMAIL PROTECTED]

IMP mailing list
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: [EMAIL PROTECTED]