New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Quoting
I mean, honestly: IT SUCKS!
Either you have people quoting above full-quotes or inline. Or both mixed.
If you have a conversation within a team, you have to use different colors or initals at the beginning of a line, or your have to manually count ">>>>".
How is it no one came up with a better idea yet!?!
Why doesn't a client
Why is there no client that parses email and tries to sort the quoting-mess out into something readable, useful?
Ok, those were just very few points where I think there is really A LOT room for improvement. And I am not a developer, I did not brainstorm for an hour, those are only the kind of things I would consider so obvious.
But still no one seems to even try.
How much evolution has been in Thunderbird, or in eM or in Sylpheed within the last 10 years? How much new code, not counting security fixes, how many new functions?
My subjective impression is that the great majority of users dumbly top-quote, which (if true) means that any sophisticated quoting system would get lost on them. Seriously, very few users do any anything but dumbly top-quote, and the result is a long footer of increasingly embedded email messages, and after a while, one has no idea what point is being replied to by the other person, and this difficulty is compounded if there are multiple people replying. Education, more than anything, would be needed here.
Well, heck, Thunderbird was ported to GTK3, which was pretty impressive in itself. ;-)
There's some progress here, for example, Notmuch ( https://notmuchmail.org/ ), which uses Xapian ( https://xapian.org/ ), and which is used by some email clients ( https://notmuchmail.org/frontends/ ). See also sup ( http://sup-heliotrope.github.io/ ). But, yeah, no Skype integration.
True.
But: In Top-Quote it is as easy as it gets to understand who wrote what.
So it's easy to parse. The client can easily understand who wrote what in what order.
Question is: what does it do with that knowledge?
Can I, based on that understanding, provide benefit to the user?
Suggestion:
If the vendor of a product that has so much room for improvement (see above) resents to calling for "education" instead of improving his product...
...well then this product rightfully deserves to die.
Aha.
None of the problems listed above are solved in Thunderbird.
So either the team lacks a vision for their product / ideas how to make it better (see above).
Or they are completely occupied with maintenance (= porting stuff from wherever to wherever for whatever reason) so that there is no time for improving.
Either way, I can't see why I should be impressed.
I mean, honestly: IT SUCKS! How is it no one came up with a better idea yet!?!
display older stuff smaller than newer stuff
then allow you to formulate an answer
and in the end (to stay compatible to other clients) just put things together as they were initially (what I suggest is only for local display, not altering the message as such).
I see what you're saying. In such a system, bottom-quoting would become the preferred method of quoting.
My remark about education wasn't entirely serious. The old idea is simply that bottom-quoting makes quoting manageable without any sophisticated tool.
Yeah, of course I din't take you completely seriously :-)
However, even with bottom-quote, there's room for improvement.
more ">" lead to uncontrolled linebreaks, messing with quoting.
This would be really easy to correct in the client (which is the poit where the additional ">" get inserted). Just put the text together again, line-wrap freshly and apply the ">>>" again.
And as said: when you have a conversation with more than two people, then bottom-quoting will still be a messy thing:
who was ">>>"? Was that Paul? No, Chris was ">>>>", but wasn't Petra ">>>>>"?.. and so on.
Again: stone-age technology, never matured.
Yeah, I see.
At the same time, what you're suggesting would require much more (automated) intervention by the email client into the formatting of the messages, and since the participants in a conversation may use (radically) different email clients and have different preferred settings for line length (i.e., where to break the lines), what looks clean to one participant could easily look messy to another. What you're suggesting would work better if all the participants in the conversation were using the same email client.
Sylpheed +1
I'm using it 5+ years for 15 accounts without trouble.
Something like this
|>>> blabla bla bla one two three
|> rest of first line
|>>> bla bla one two three
|> rest of second line
looks terrible in any client.
And if I'm not completely wrong then there are some common criteria on "# of caracters per line". Just take the same / smallest number for "characters before line break" of any of the main clients, and re-format to that max size.
It will look better in any client. No matter what you read it with.
Also, why not combine all emails and requirements to them into single inbox with Gmail Web Client or UWP app?
It will solve almost everything what you wrote in the post above, not sure about Skype (Skype in 2018, seriously?)
Why would they need to evolve? Organizing and displaying emails is a pretty finite thing.
Don't think so.
I see software evolving all the time and usually it's in the direction of becoming an unusable turd.
I am curious how do you usually have to wait for your results?
My brain can handle that pretty well.
Yeah, it's nice at least some stuff doesn't get fucked up by layers and layers of complexity and needs a top end system to run. Do you have stocks of some hardware producer by any chance?
File a feature request. I guess it's so brain dead easy to add that checkbox many authors would have no problem adding that.
Err this exists like forever? How do you think i sort my emails?
Scary idea. Do not want.
Yeah, sure. Lets just bloat the client with library bindings to read just about every file format under the sun. Brilliant idea.
What exactly is the problem?
Sucks. Next one.
Oh my... such idiots. How could they.
Because noone including you build it.
Yeah, true, i guess there could be something of a thread view in one large page. Don't think i'd use but at least it isn't horrible.
Ugh.
Please write it and tell me the name so i can avoid the waste of time trying it.
Plugin territory.
Because everyone uses all that.
Yeah, it's called telling people to not be ignorant morons. Seriously quoting isn't to blame for the donkey in front of the screen.
>- parse who wrote what part in a conversation
Because it would require well formated input and bloat the result. All that parsing would fall flat with the type of users you describe above.
> - automatically display that nicely with people's pictures and graphically easy to distinguish who wrote what
I think i just puked a little.
> - perhaps having "older" quotes (Deeper >>> levels) shown in small print to allow the eye to fly over? And on mouse-over you could display it larger again?
>
Again you could file a feature request for your favorite bloat client that supports such bling bling but well, aou rather rant about it.
See note on parsing and donkeys above.
You should be become one. Would be fun watching the trainreck.
Of course.
Leave Sylpheed out of this please. It's a great client and your line of thinking would do nothing but destroy it.
For some reason, there exists the notion that "email clients are for email only".
Nope, that's not true if you're using it in a professional capacity. If a mail client does not support calendars and you get an invitation, now you have to track it manually. Compare that with a mail client that has calendar support, like eM. Invitation comes, it pops out on my calendar, I get alerts 12 hours before the meeting etc.
Doing "one thing only" is totally worthless if you can't "pipe".
I don't think that most modern email clients use hard line breaks for composition, and for reception, they vary.
Anyway, I can see that your suggestions above may make sense in certain business contexts, especially where assumptions can be made about the email software that people are using.
(I think that I'll leave this thread now.)
Yes, it's usually held by people that want to use it for email only and not want a ton of feature bloat on top.
Genuine question: Is there even a definition what constitutes such invitation and isn't there a more fitting modern alternative? With eMail being a 30+ years old technology that's more or less kept alive by duct tape and the impossibility of a global migration tucking stuff on top of it seems a bit awkward.
Well, not really. I see it as quality assurance.
Features being called (sic) bloatware is like games called "minimalistic" as a positive because they didn't have the talent/budget for any kind of decent graphics.
A software either provides features or it doesn't. Most email clients simply don't. Why? Cause it's a genuine mess to develop/support them, as you mentioned (the "duct tape"). So the sad excuse ends up being "you don't need that feature". Because, why would you need to track your future interactions with other humans, pen and paper not enough?
I don't know the technical details, I haven't created any caldav integration. But if eM has figured out how to implement the feature nicely, it's safe to assume it's not an unsolvable issue in software engineering.
When someone sends me an invitation, it presents it nicely formatted in my inbox with an accept/decline button. Once accepted, it becomes an entry into the calendar - and the calendar is an aggregate of all my email accounts calendars (unless I don't want to). So, with one application, I have a unified inbox and a unified calendar, plus the inbox understands how to handle things that eventually belong in the calendar in a user-friendly way.
Yes. So the situation is this: we have a complicated mess and a need for efficient, co-ordinated communication. Software is the solution to that. Not "lack of software because it's complicated".
I take it as a base requirement that a program does what it says it does
So, interoperability is the question. And if a software wants to be "one thing only, done well", it should somehow support interoperability. I don't suppose I need to stress that in a forum where people understand what the UNIX philosophy is.
Try this: https://i.imgur.com/IOz8xtq.png
A mail client is not an entertainment product though.
Well, believe it or not i get by without calendar or pen and paper but then your usage pattern might be way different. Tbh i try to avoid doing anything of importance by email anyways as it's pretty much the most insecure und unreliable form of communication available (yeah i know gpg but who uses it and you still leak metadata...). It is what it is and it does what it does but seriously, why anyone would want to improve it is very much beyond me.
Sure it's possible. Pretty much everything is possible.
I see how this might be convenient if you need it.
I didn't say software wasn't the solution. I was rather questioning if tucking features onto what basically is vintage software was the solution. New software might very well be the solution.
No, i instantly got the reference but it's superfluous here. You can take Sylpheed as an example. To me it's just perfect. I can honestly say it does everything i want it to and that's very probably all i'll ever need. Additional features add no value for me. They just bring in the risk of lowering overall quality. Anyways, the mailbox format being as simple as it is integration with other applications wouldn't be hard at all.
Exactly. It's a productivity product, which makes it really important to be ... productive. So now you see why features are important.
Oh, I absolutely believe it. I also know people who code in vi (no colors, no auto-complete), vi. And this isn't even a good example that I wrote because vi actually has features
I believe it really is clear. If one has no need for a feature, that does not mean that people in general have no need for it. And in the case of email/calendar/contacts, there's a ton of people who actually need those features.
For example, I don't need a truck because I don't do agricultural work and whatever little of that I do, I can take care of it manually. Trucks are far from bloatware, just because I don't have a use for them.
Exactly, there is no disagreement here. To you, it is. And that's great. To extrapolate that to "it should be perfect for everyone" is what I object to.
Yes, but that only concerns features that actually improve my productivity. Sure these are my needs. Yours might different but that doesn't change the fact that i don't want those features because there is a chance they translate into negative value for me.
I think you didn't get what i was getting at. Email is a garbage technology dragged along from the beginning of time. Increasing it's lifetime even further is nothing to be proud of. You can put anything you want on top of it but the core will stay rotten.
Sure but the opposite isn't any less true.
I am not sure where i said that. I admit to a certain extend i think like this so even if i didn't say it i understand i might come across this way. Tbh i was just in the mood to write a snarky reply to @southy's whiny rant how his life is miserable because every developer is stuck in the stone age. Yeah, i often dislike modern approaches but in the end i am happy as long as my stone age stuff is left alone since this is what enhances my productivity and not tiny mugshots of my conversation partners, clever techniques to circumvent problems in front of the screen, handholding while adding attachments, AI to make sure my most important emails end up somewhere where i'll never want or find them or addition of privacy invading cloud technology.
In respect to the comments about „calendar integration“:
Yes, I am fully aware of the notion of „one program per problem“. Which is why I had the (one) idea about this clearly separated in my posts. Both approaches have their right to be.
But: The vast majority of my complaints and suggestions were genuinely „email-only“.
And yes, most of what I suggested can (to best of my understanding) be applied within the mail client only, without a need to modify the protocols or world around it and stay fully compatible.
Is the whole concept as email is inherently flawed? Sure.
Do we at least get the best possible within this context? NO!
THAT is what I’m complaining about.
Microsoft Outlook on Windows 10, Thunderbird on Ubuntu.
Best email client is Web Interface!
Postbox works like a charm for me, give it a try - https://www.postbox-inc.com/
Have you tried Tools ->Settings ->Notifications.
eM does everything I could ask for.
Another vote for thunderbird.
I am using Mailbird Pro - so is a paid license - and I am happy
The core function of a mail client is to communicate with a mail server to receive and send mail.
Everything else is software built around the mail client to add functionality -- composition window, address book, searching, etc.
Beyond the core functions there's little standardization and lots of proprietary solutions -- e.g. MAPI, a Microsoft thingy, and the various calendar integrations and 'invites'.
Claiming that 'all email clients are crap' is akin to saying that Notepad is shit for desktop publishing.
I think what @southy and others are looking for is a new communications/productivity app (that integrates email as one component). Probably commercial software. Find a few thousand users who want exactly the same feature set, pool your money and approach a developer.
+1 for Mailbird, great e-mail client