[dev] Significant changes

[Michael Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

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

   mjr: This would be a great step in getting better user  
documentation. Speaking for myself, I would be more apt at documenting  
new features if it didn't involve editing the xml files we currently  
use.  Thoughts off the top of my head would be to have a standardized  
link format while allowing the admin to set the hostname portion.  
Maybe our default documentation could slowly be migrated to the wiki,  
or maybe it could be shipped with the distribution. Either way, moving  
away from the xml files would be a plus IMO.


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

mjr: Indeed :)  Though as we move more towards a MVC architecture, and  
utilize more view templates, this should at least make it easier to do  
- though they would still be editing "php scripts", they would at  
least be template located in an easy to find place etc... Beyond that,  
I don't see this really happening.

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

mjr: I guess as long as it's configurable, and ON by default I'm ok  
with this.  Though, like Jan, I really don't see the use case.   
Personally, whenever I don't see a success notifaction, the first  
thing I do is to re-open whatever it was I edited to make sure that  
the edit was saved successfully. This would be a step backwards in  
usability.


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

  mjr: Agree with Jan.

> - Moving/copying messages by (context?) menu too.
>
> - Redirect is missing
>
> Jan: should probably be added to the forward menu?
>
> - 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.
>
> - Show either date or arrived column per preference.
>
> Jan: Doesn't make sense to me.
>
> - 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.
>
> - Make all context menu actions available through a second way.
>
> Jan. No, thanks.
>
> - 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.

   mjr: +10

> - Ability to hide mime part details like download option for certain  
> mime types.
>
> - Customization of help message when no message is selected.

mjr: Probably not a big deal to implement, but I'd be hesitant to  
start a trend here. In other words, what makes this dialog text more  
special then others - I can see this leading to other people asking  
"Why can't I tweak the text in *this* dialog, since I can do it in  
this other one?"

>
> - Add explicit "empty trash" link to sidebar.
>
> - Find a better place and icon for the folder actions button.
>
> - The search icon should start the search instead of opening the  
> context menu.
>
> - The search context menu entries are too confusing and should be  
> moved to the advanced search instead.
>
> - Improve usability of advance search.
>
> Jan: Sure, ideas?
>
> - Allow to add custom fields to compose window.
>
> - Option to replace HTML editor with a custom editor.
>
> Jan: I think we are done with this discussion, right?
>
>
> Ingo
> ----
>
> - Add option to disable/enable all rules at once.
>
> Jan: We already have an option to deaktivate the whole script,  
> though this only works with server-side filters.
>
>
> Kronolith
> ---------
>
> - Add option to disable calendar section in the sidebar.

mjr: Probably easy enough to do, but wondering why? If it's to avoid  
being able to turn on resource intensive calendars (like the  
timeobjects) wouldn't it be better to allow disabling the feature  
that's causing the issues at the source? i.e. Allow a configuration  
switch to turn on / off each applications' listTimeObjects api? I  
guess maybe for maximum flexibility we could do both?

>
> - Delete option directly from the calendar views.

   mjr: this would be nice...


Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
URL: <http://lists.horde.org/archives/dev/attachments/20100223/e463c197/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: PGP Digital Signature
URL: <http://lists.horde.org/archives/dev/attachments/20100223/e463c197/attachment-0001.bin>