[dev] Significant changes

[Jan Schneider]

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

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>
>>> 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.
>
> But as you just mentioned - how does this help usability?  You will  
> still have to wait at each subfolder level for it to load.  And the  
> contextmenu code won't work well if the folderlist for any given  
> level has too many entries to fit on the screen heightwise.

It would help because you don't have to keep the mouse button pressed  
while waiting for the sub-menu to expand. But I see the potential  
issues too of course.

> In other words, this is not an element that could easily be added.   
> I'm not against the idea, just giving a fair heads up.
>
>>>> - 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.
>
> Delay is currently 0.3 seconds (DimpBase.js:144).
>
>>>> - 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?
>
> Javascript actions are triggered on certain compose fields - i.e.  
> resizing of the compose window when elements change size -or- sanity  
> checking of input.  This is the kind of stuff that would need to be  
> hard-coded in the javascript code.
>
> If we are just talking about adding fields and then allowing a hook  
> to be called at send time to potentially alter the sent message  
> based on this field, this is an acceptable solution.

Yes, that's the purpose of this request.

Jan.

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