[dev] Significant changes

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> 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.

That would probably help during further discussions with the client.

>> - 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).

Good point. Theoretically the context menu sub-entries could be loaded  
on demand too. Actually I sometimes miss this functionality too. I  
find it a bit easier to pick a folder through the context menu, than  
having to drag and hold the mouse button until the folder opens, loads  
the sub-folders, and so on. With the context menu you click and can  
wait until the menu opens, you don't have to hold the mouse button.  
This is a usability improvement IMO.

>> - 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.

There is a delay? Maybe that's the issue. I don't see a delay, or it's  
too short to not be triggered nonetheless, if navigating through the  
list. Maybe it's sufficient to make the length a user preference.

>> - 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).

Good point.

>> - 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.

I don't see a need for it either, but fact is that many people like to  
have one, and I don't see any issues adding this to the sidebar  
according to the same pref that already adds it to IMP's menu.

> 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.

To the top menu that they want to have.

>> - 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.

Good point.

>> - 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).

Agreed.

> 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.

Is it not the complete form that's being submitted when a message is  
sent? I.e. do we sent the fields individually as necessary?

>> - 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]
>
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>



Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/