The UI/UX for news vs email is defined by the mail/news *client*. The protocols are effectively similar (in terms of how the client can *build* that UI and the quality/feel of the UX).
An email client can "peek" on the server to see how many messages are present meeting a specific set of criteria (e.g., raw count, unread, unseen, etc.). So, checking to see what *might* be present on the server requires only the lightest of touches (no data traffic).
A "message" can be decomposed into headers, body and attachments. So, the client can elect to defer downloading portions of the "message" that are not of interest to the user at the present time.
It can choose to examine *just* the headers of those (or some SUBSET of those) *without* bearing the cost of transferring the entire message body (incl attachments). Again, allowing the email client to only impose the cost of looking at those things that may be of interest to the user to keep traffic light.
As such, it can present "summary information" about the mailbox's content to the user WITHOUT actually fetching that content:
- originator of message
- intended recipient
- subject
- date/time
- size
- whether it has been read or not
- whether it has been *seen* previously (i.e., "new")
- if it has been *answered* (replied to)
- if it has been deleted
- if it represents a draft (not yet intended to be "sent")
- the identities of any "co-recipients" (Cc)
- the GLOBALLY unique identifier of message to which it is replying (if any)
- the presence of attachments (if any)
It can allow the user to *search* the messages on the server (read or unread) without having to download all of that content just to find which message(s) are of interest. For example, all UNSEEN messages containing the text "Order Form". Or, any message containing "meeting with client". Coupled with the summary information above, this lets the client refine his interests. Handy for a slow connection or one where you "pay for traffic" (e.g., "data plan") -- why download messages with huge attachments? Perhaps just download the *message* and leave the attachment for later!
It can allow the mailbox user to create folders *on* the server in which to organize received (AND PENDING) messages -- handy if you want to start composing an email using a colleague's computer and finish it, later.
With all of this information available *before* the body is even present on the local machine, the email client can present that summary in any way the user deems appropriate. E.g., want to *thread* your email conversations? ("View | Sort by | Threaded" in Tbird) Want to list them in the order they were sent? Or, sorted by sender? Recipient? Examine only those that contain the text "Monthly Invoice for Services Rendered"?
[Try doing that last one with a USENET client! I.e., you would have to download EVERY message body and perform the search "locally". So, you have to *rely* on folks to always put information that you might want to search for in the *subject* line if you want to avoid looking through all that body text! Search for "bug fix", "workaround", "update", "new release", etc.](POP can't do many of these but can do some -- with a bit of creative coding. NNTP can't do many of them, either.)
If you're not *providing* support, then the choice isn't yours to make! :>
Because *mail* and *news* are very different media -- with very different capabilities.
I can wish a friend "Bon voyage!" by:
- telephoning
- sending a greeting card
- sending a letter
- sending a postcard
- sending a telegram
- sending an email
- taking out a full-page ad in the newspaper
- buying a "spot" on a local TV/radio channel etc.
*All* will get my message across. Should he choose to reply, would he really want to use the same medium that *I* did?"Thanks, Don! See you in two weeks. I left a house key under the mat..."
News (USENET) is a broadcast medium. Email is a point-to-point medium. I.e., to *approximate* a broadcast, you would have to email to a LIST of known recipients -- you can never broadcast to "The World at Large". The flip side of that is you can never know who has *seen* your USENET message (email will at least tell you if it has not yet been *delivered*, assuming you don't enforce return receipts).
Think about that difference and you will see the multitude of things that you can do with email that just have no counterpart in USENET.
Web portals try to walk a middle ground -- giving you the worst of both worlds...