[dev] Significant changes

[Michael M Slusarz]

I'll focus on DIMP - don't have strong fields on the other topics/apps.

> DIMP
> ----
>
> - Add top menu bar that duplicates context menu functionality for  
> folder and message management and takes the prefs and the custom  
> entries.
>
> Jan: We already have this for messages, and adding this only for  
> folder actions is waste of screen estate. I don't like duplication  
> either. OTOH this better resembles a desktop client. It could also  
> replace the somehow awkward top tab bar.

Agreed.  Waste of screen real estate.  I know people are obsessed with  
the idea of making web apps look just like desktop apps, but that  
shouldn't be the case.  I can point to a bunch of well-written  
articles on this subject.

> - Clicking on a user/email link should open the compose window  
> directly because this would be the user's expectation. Address book  
> functionality should be a separate icon again.
>
> Jan: I never was happy with the two-item-only popdown either, but it  
> makes more sense now that it also shows the email address (I think  
> the client didn't have this yet in the version they reviewed), and  
> especially if we would add more items like black/whitelisting (why  
> do we have this in the message menu instead of there anyway?). I  
> don't see a WTF factor for users either, because even if they expect  
> the compose window to open right away, they immediately see and  
> understand how it works instead. And honestly: how often do you  
> compose messages by clicking on an address, instead of using the  
> reply functionality or open a compose window directly?

 From personal experience, I rarely click on addresses to send  
e-mails.  It is not overly burdensome to do a tiny bit of extra work  
to send a message in these instances.  And UI-wise it is a  
straightforward action (i.e. if you click on address, and context menu  
comes up, user knows that they need to additionally click on New  
Message link).

I don't particularly like separate icon, and it just adds complexity,  
slowness and reduces estate.

> - Moving/copying messages by (context?) menu too.

How?  I'd rather not have a full folder list in a context menu.  And  
the theoretical advantage now of DIMP - we theoretically don't need to  
load the full folder list when logging into DIMP (as opposed to IMP  
where we have to because of various folder dropdowns which need to  
contain all folders).

> - Redirect is missing
>
> Jan: should probably be added to the forward menu?

Makes sense.

> - Missing option to deselect all messages
>
> Jan: It's as easy as clicking on a message. Could still be added by  
> toggling the "Select All" option though.

Makes sense to add the context menu toggling action.

> - Show either date or arrived column per preference.
>
> Jan: Doesn't make sense to me.

Agreed.  You can already sort arrival vs. Date.  The # (message  
sequence( representation is not all that useful (I've been thinking of  
removing it from IMP for awhile now).

> - Setting default behavior of reply button
>
> Jan: I think the current smart behavior is a huge improvement over  
> that. I'm not sure if they have this in their version already, or if  
> they noticed at all.

Further feedback would be great on this.  But I spent quite a bit of  
time planning before implementing the newer auto-reply features so I  
feel that current auto reply it is pretty good, especially with the  
option to "undo" the auto reply selection once you get to compose  
screen.

> - Make all context menu actions available through a second way.
>
> Jan. No, thanks.

Nope.

> - Only mark messages as seen after opening for a (configurable) time  
> period, so that they aren't marked seen if you just navigate through  
> the mailbox.
>
> Jan: Yes, please.

I don't feel nearly as strongly about this as Jan or mjr do.  This is  
the whole point of the delay when using arrow keys to navigate through  
list (maybe this can be increased?).

 From a technical standpoint, this is a lousy idea.  You would now  
need 2 separate AJAX requests for every message viewed - one to load  
content, one to set as read.  Setting a flag is not a tremendously  
heavy operation, but it isn't trivial either - given that you need to  
initiate the whole Horde environment to do this.  You have now  
effectively doubled the number of requests sent to the server.

I personally have never (or at least very rarely) had a situation  
where I have messages I have needed to go back and set to unseen.  But  
I think this may also be dependant on a user's reading style.

> - Ability to hide mime part details like download option for certain  
> mime types.

This is probably something that could be added to mime_drivers.php config.

> - Customization of help message when no message is selected.

This is already in a template.  I don't know how much advantage we  
gain by moving to yet another template file (at some point you will be  
sacrificing configurability for speed).

> - Add explicit "empty trash" link to sidebar.

Oppose.  And I still am entirely confused about the need for a  
prominent Empty Trash button on anything other than the Trash mailbox  
view.  It has always struck me as something solely for OCD people.

What are the justifications?  For people with quotas?  In that case,  
by definition they shouldn't be using Trash.

The Purge Trash login task should do all necessary pruning a user will  
ever need.

> - Find a better place and icon for the folder actions button.

Like where?  Saying "find a better place" is worthless.  Actual input  
is needed.

> - The search icon should start the search instead of opening the  
> context menu.

Where do you put the context menu?  Right-clicking on the entire  
search bar is not intuitive.  The search icon is also where other mail  
apps, like Thunderbird, put the options.

> - The search context menu entries are too confusing and should be  
> moved to the advanced search instead.

NO.  IN GIANT CAPITAL LETTERS.  The purpose of the Show Only/Don't  
Show options is to quickly provide a filtering search, like the menu  
we used to provide in IMP.  Once you move this to advanced search, you  
destroy the whole purpose of quick searches.  And there absolutely  
needs to be a place to quickly change the search field for quicksearch  
(this was the single biggest shortcoming of the quicksearch in DIMP  
1.x).

The whole idea is to provide some basic, common searching tasks  
without the need to open another screen.
> - Improve usability of advance search.
>
> Jan: Sure, ideas?

Sure.  Again, ideas would be helpful.

> - Allow to add custom fields to compose window.

What custom fields?  Again, this is difficult because various  
javascript would also have to be changed.  I've mentioned before - by  
their very nature, AJAX applications are going to be much less  
customizable than a pure HTML counterpart simply because there are  
several independent components (PHP, HTML, javascript) working  
together that can not be altered in a single place.

> - Option to replace HTML editor with a custom editor.
>
> Jan: I think we are done with this discussion, right?

Yes.  HTML editors are not something that can just be dropped in, at  
least without abstracting both the server and browser/HTML code to  
such an extent that it would become unmaintainable.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]