[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