Mail 2.0: Basic flaws in quoted text behaviour
Posted by Pierre Igot in: MailMay 8th, 2006 • 1:13 pm
Here’s a screen shot taken with the insertion point (I-beam) at the beginning of a line of quoted text in an e-mail message in Mail 2.0:
And here’s the exact same location after having pressed the Return key once to insert a return character:
What’s wrong with this picture? Something very simple: I said I only pressed the Return key once. Yet obviously Mail decided to insert two return characters instead of one!
I repeated the procedure just to make sure, and it definitely wasn’t a mistake (accidental double keystroke) on my part. For some reason, in this particular situation, Mail decided to insert two return characters instead of one, with the result that my quoted text now contained a useless empty line with quoting.
I don’t care what the reason for this is. The reality is that it is purely and simply wrong. There is no excuse for inserting two return characters where the user only meant to insert one.
It is really amazing that, after all this time, Apple hasn’t been able to “fix” Mail. I was part of the AppleSeed process with early betas of Tiger. The message composition tool in Mail 2.0 was screwed from the very beginning. After multiple bug reports, they fixed the most glaring bugs and flaws.
But there are still many “smaller” bugs such as this one that have not been fixed. And, frankly, there is no sign of them getting fixed any time soon. At this point, bug reports about such “minor” flaws simply remain unanswered.
This is thoroughly disappointing, especially on the part of a company that prides itself on its attention to detail. No matter how slick your interface might look, if you can’t even get basic text composition behaviours right, something is seriously wrong with your software development process and with your priorities.
May 9th, 2006 at May 09, 06 | 10:07 am
[…] Pierre Igot (read his “Talking Mail.app” interview) at Betalogue describes the odd way in which Mail handles format=flowed text. […]
May 9th, 2006 at May 09, 06 | 11:49 am
I think you’re being a little naive about the way that flowed text actually works. This feature is perfectly reasonable text-flow behavior. Flowed text is actually just an interface conversion of the old ‘>’ character that we all remember from email clients of olde. If you only insert one return character the next line starts the user typing before the ‘>blahblahblah’ which cannot be logically interpreted in flowed text. By inserting two and moving the cursor up a line the user the flow can be preserved.
What you describe as a ‘useless empty line with quoting’ is the original ‘>’ from the line that you pressed return on. While you may not think this attractive, ask yourself- is it good text-composition behavior to DELETE a character when the return key is pressed? Because that’s the only way you can avoid this given the mechanics of flowed text.
The Mail.app team has exceptional attention to detail. They also have, apparently, a better comprehension of the mechanics of email than you.
May 9th, 2006 at May 09, 06 | 12:39 pm
It’s hard for me to believe that you can seriously think that the behaviour I described above is “attractive” or makes any sense. It might make sense from the perspective of the person who knows about the underlying mechanism of quoted text in flowed e-mail—but I am looking at it from the perspective of the end user. How can the end user be expected to believe that inserting two return chars when he presses the Return key once makes sense? This is absurd.
It is with such an attitude that we end up having computer software that only software engineers can understand and know how to use.
And if you really believe that Mail has benefitted from an “exceptional” attention to detail, you have a lot of on-line reading about people’s experiences with Mail to do.
May 9th, 2006 at May 09, 06 | 7:35 pm
When I type the return key anywhere within quoted text I only want a line break there, clearly separating the original quoted text into two new blocks above/below the insertion point. That’s what usually seems to happen when return is typed at the end of a displayed line within a quoted text, but not elsewhere in the line (as Pierre’s example demonstrates).
The “quoted empty lines” that extend flowed text above/below the new insertion point are superfluous for me in this context because I’m not adding new text to them. And deleting those unwanted “phantom” lines can be tricky.
The return key behavior within quoted text is further complicated depending on whether that text is flowed or wrapped. I’ve done a few tests while composing this but it would take more thorough analysis to know whether there’s a consistent, predictable behavior. It quickly got weird; definitely not what I’d describe as “attention to detail” from a usability perspective.