manicottiK
Member
- Nov 24, 2011
- 661
- 3
- 18
I do think that there are two issues here and that one seems like a defect and the other seems like an unpopular choice.
Regarding the read/unread flag and moving items, I repeated what the OP said then took it a step further. I read a message on the phone, returned to the list of messages, synced so that the server did know that the message was read. Then I opened the message again, moved it, and resynced. When I synced on my desktop Outlook, the message was marked as unread. This seems like a defect.
Regarding the lack of sync on delete, MS seems to have designed things around a use case that I think of as my "wake up a do email" chore. I get up in the morning, grab my phone, open email, and start deleting all of the crap that came in over night then reading the good stuff. Since it is likely that one delete is going to follow another and that one read/unread status change is going to follow another, it is more efficient from a battery and network perspective to do a "lazy" sync after it's clear that I'm finished the larger "do email" chore than it is to sync immediately upon each action. I don't know how much lag the phone allows before it syncs these cached changes, but it is long enough that I sometimes get to my laptop and see messages that I know I deleted.
The suggested work-around is to manually sync after your "do email" chore (not after each delete/read/move) if you need the server and other sync'd clients to see those changes immediately.
An improvement that MS could make that would still preserve most of the battery and network efficiencies would be to check for queued updates and to automatically invoke a sync for them when the email app is left (either to go to the Start screen, to another app, or to the lock screen). That would still result in just one sync operation, but it would mean that our computers matched our phones pretty quickly. It would not let you use your phone in front of your computer and watch Outlook update live. Some of you may want that, but I would argue that the functional need for that seems like it isn't worth the battery usage. Android may do it, but maybe that's part of why we mock them for their battery life issues.
Regarding the read/unread flag and moving items, I repeated what the OP said then took it a step further. I read a message on the phone, returned to the list of messages, synced so that the server did know that the message was read. Then I opened the message again, moved it, and resynced. When I synced on my desktop Outlook, the message was marked as unread. This seems like a defect.
Regarding the lack of sync on delete, MS seems to have designed things around a use case that I think of as my "wake up a do email" chore. I get up in the morning, grab my phone, open email, and start deleting all of the crap that came in over night then reading the good stuff. Since it is likely that one delete is going to follow another and that one read/unread status change is going to follow another, it is more efficient from a battery and network perspective to do a "lazy" sync after it's clear that I'm finished the larger "do email" chore than it is to sync immediately upon each action. I don't know how much lag the phone allows before it syncs these cached changes, but it is long enough that I sometimes get to my laptop and see messages that I know I deleted.
The suggested work-around is to manually sync after your "do email" chore (not after each delete/read/move) if you need the server and other sync'd clients to see those changes immediately.
An improvement that MS could make that would still preserve most of the battery and network efficiencies would be to check for queued updates and to automatically invoke a sync for them when the email app is left (either to go to the Start screen, to another app, or to the lock screen). That would still result in just one sync operation, but it would mean that our computers matched our phones pretty quickly. It would not let you use your phone in front of your computer and watch Outlook update live. Some of you may want that, but I would argue that the functional need for that seems like it isn't worth the battery usage. Android may do it, but maybe that's part of why we mock them for their battery life issues.
