Tickets :: Comment on [#12473] Allow undelete message option

* Your Email Address
* Spam protection	Enter the letters below: .__ .__.. . ..__ [__)[__]\| \|__\|[__) \| \| \|\|___\| \|\|
Comment	> Undelete is intentionally left out of smartmobile. And I don't see > any reason otherwise. > > First - you make the common mistake of saying "this feature exists in > a different view of IMP; it should/must appear here." There could > not be further from the truth. While true that we can't have any > particular ACTION behave differently among the views (i.e. clicking > Delete in smartmobile must behave the same as clicking Delete in > basic), this has nothing to do with which FEATURES we allow. > > In the smartmobile case, it makes ZERO sense to show deleted messages > in a mailbox. You are given limited screen real estate and network > connectivity - it only makes sense to show messages to users that > they think are "interesting". By previously marking a message as > deleted, they have explicitly made the statement that the message is > no longer "interesting" to them. > > In other words: "Undelete" is not a base action, like > delete/move/reply. it is instead an action that helps manage a > mailbox. Smartmobile is not designed UI-wise to manage a mailbox. > It is designed to allow quick access to messages and the ability to > do a few of the basic things needed to quickly handle the message > data. > > And I shudder to think of the cascading effect of adding this. Once > you allow Undelete, you require messages to be visible in the mailbox > view - undesirable, as mentioned above. Some some people will want > the ability to turn this off dynamically, so now you have to add a > button to allow toggling of hiding messages. And then people are > going to want the ability to expunge the messages, since they can now > see them, so you need to add an Expunge method (and the modal > warnings required to prevent accidental clicking). There is really > no more room for 3-4 more actions in the current layout as it is. > > These might be allowable in a "tablet" view, but never a > "smartmobile" view. Since we only have one view that encapsulates > both, we have to tailor the UI to the latter.
Attachment
Watch this ticket

Saved Queries