RE: [SM-DEVEL] New Features

[Jose F. <jos...@so...>]

> Jose Fandos said:
> > To me, the use of the number of *unread* messages in the trash
folder
> > as a warning for a possible deleting mistake is a feature invented
to
> > give reason to something that has none.
> 
>      No one claimed it was a designed feature, merely that it had a
use.

Yes, it does. It might only be useful for unread deleted messages, but
those might have a higher degree of importance than the ones that have
been read.

Having said that, there are people who find dust balls useful. 
 
> > It was never put there to serve a purpose. It was there out of
> > inheritance. The trash, in computer interfaces, *is* a folder, so it
> > inherits all folder features, even when it shouldn't.
> 
>      I won't claim (and neither should should you) to know the
thoughts
>      and desires of the coders that put it there.    See above.

I just thought that to be the case :D. Thinking about how it came to be
developed... and figuring out that the starting point was not to show
unread messages in the deleted folder and then having that extending to
the rest of the interface... just the other way around. But, if it was
intentional, the issues raised still should hold valid for the sake of
the argument, in my humble opinion. 

> > Now, what you mention is just a complete different problem that if
so
> > regarded, should be fixed. That is, when people delete messages,
read
> > or unread, a warning pointing to that fact could show somewhere.
That
> > would be helpful. And what better place than where we now have those
> > nagging numbers telling us nothing worth? Let's place red text under
> > the trash folder for the next five minutes, 10 seconds, next login,
> > whatever -- would need to give it a bit of thought. Let the warning
> > spell it out "You have deleted 10 messages" -- read or unread.
> 
>      If you make a habit of purging your trash after deleting things,
>      then it *is* a useful tool.  If the trash shows unread, you know
it
>      is from a recent action, not an old one.

But one of the things I like about computers is for them to take
repetitive work out of my way. ;) 

> >>      I won't bother to argue with you how useful it might be, but
the
> >>      point is there.
> >
> > Wow! Sorry to bother you. :p If in doubt, the more reason to argue
> > about it. :)
> 
>      That's just it.  There is no doubt in my mind that it is useful
to
>      know when you have deleted unread messages.  My point was
>      that if you disagree, we can have no useful discourse, as I
simply
>      believe that incorrect.

I am more than eager to be convinced otherwise. It will save me the
trouble of seeing those numbers under the trash folder as a problem.

> >>      I agree that the solution of making it an option "Show unread
> >>      count in Trash" is the better one.
> >
> > I'm a bit lost here. Do you mean to have it as an option for the
> > administrator when setting up SM? If so, I kind of agree.
> 
> > If it is an option in the user options by default, I don't agree ;)
per
> > reasons that I brought up before. Still, I am all for having this
> > option together with as many more as you can fit all in a far, far
away
> > plugin.
> 
>      If you're going to talk about interface design of config options
>      instead of UI of the tool's frontend then here you go:
> 
>      The admin should have the option of enabling:
>      a)  Never display unread in trash
>      b)  User choice to display or not
>      c)  Alwaays display unread in trash

That's really good.

>      The user's config option to show it or not should be in a
>      separate section of Options, labeled "Advanced Options",
>      where we should also shove other config options that are
>      very useful, but confusing for some users.  (Unsafe images,
>      POP Fetch Mail, etc)
> 
>      The admin should be able to enable/disable the entire lot of
>      Advanced Options in config.
> 
> > Yes. That's sensible. Oh, wait, but that leaves the users in the
hands
> > of the administrator :D
> 
>      When is that ever *not* the case?  ;)
> 
>      -Rick
> 

Jose

> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
> 
> --
> squirrelmail-devel mailing list
> List Address: squ...@li...
> List Info:
https://lists.sourceforge.net/lists/listinfo/squirrelmail-devel
> http://squirrelmail.org/cvs