[dev] Significant changes

[Chuck Hagenbuch]

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.

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

-chuck