[dev] Significant changes

Jan Schneider jan at horde.org
Tue Mar 2 13:09:08 UTC 2010


Zitat von Chuck Hagenbuch <chuck at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> I have a request from a long-time client who already sponsored a  
>> bunch of features in Horde in the past. They request the  
>> feasibility of a bunch of changes for Horde 4 applications to help  
>> them decide if they can keep using Horde in the future. Since some  
>> of the changes are somewhat massive, I'd like to discuss them here  
>> to hear your opinions about those, whether they make sense to you,  
>> whether they conflict with other expectations, etc. I added my own  
>> opinions below where applicable.
>
> Cool. Weighing in on things I strongly agree/disagree with...
>
>> General
>> -------
>>
>> - Add possibility to add custom help pages, or link to custom help system.
>>
>> Jan: IIRC we already discussed this in the past, especially whether  
>> to move online help to the wiki, and I don't see any problems with  
>> that (the custom link, not the wiki help) if implemented cleanly.
>
> Yeah, a better help system including customizations would be very nice.
>
>> - Layout theming without changing PHP scripts.
>>
>> Jan: Well, we can always dream :) We all know how limited this is,  
>> even with our recent CSS-only designs.
>
> Yeah. We'll keep working towards it for our own sake as much as  
> anything, but...
>
>> - No success notifications (if disabled in prefs) unless the result  
>> of the current action is not immediately clear to the user.
>>
>> Jan: This shouldn't be hard to implement, though it doesn't make  
>> any sense to me. Notifications are not very obtrusive and are a  
>> usability bonus IMO.
>
> Seems very subjective, and dependent on the meaning of "immediately  
> clear". On a more ajax-like application you assume state is saved  
> often without an explicit button; then a notification is unexpected  
> since you didn't take an explicit action. But I'm breaking my strong  
> agree/disagree rule on this one - I don't really care either way.

I guess it would make sense as a rule of thumb to not show any  
notifications if the action changed anything else in the interface.

>> 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.
>
> I'm with Michael S. here on duplicating desktop look not being a good idea.
>
>> - Moving/copying messages by (context?) menu too.
>
> Not sure the use case here - how is this more usable? And how does  
> it jive with other requests to duplicate things outside of context  
> menus?
>
>> - 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.
>
> I *love* the smart reply functionality, fwiw. Also in Safari right  
> now the others don't work if you're blocking popups, but that's a  
> separate issue.
>
>> - 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.
>
> The current delay works for me. I agree with Michael S. that having  
> a 2nd request here doesn't make much sense.
>
>> - Customization of help message when no message is selected.
>
> Isn't this the same as the first request?

No, since that help text is not from the help system.

Jan.

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



More information about the dev mailing list