[dev] Significant changes

[Jan Schneider]

Zitat von Michael Rubinsky <mrubinsk at horde.org>:

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

I think the main point is to not hide any html output in libraries.  
We've done that quite a lot in the past and that's where they  
struggled with older Horde versions.

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

Yes, of course, it didn't make sense to mention this one here.  
Sections are disabled if a feature doesn't exist. And if that's not  
sufficient, CSS can be used to hide more.

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



Jan.

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