Version 1.9.0-322-dev - "work in progress", not in Google Play

[Philip]

Hi Kostya

Is there any possibility that the ability to reflow on zoom will be re-instated as an option?

I've reverted to Build 320 for now, and it would be sad if this was the last version of Aquamail that I could ever use :-(

[Kostya Vasilyev]

Auto-fit itself could make text lines overlap sometimes (if the message's markup specified explicit "line-height" that's too small for the increased font size).

We don't currently have any plans to restore "reflow on zoom in".

[Philip]

Thanks for clarifying. That's a real shame.

I'll go back to K9 for now until I decide which mail client best meets my needs.

Good luck to you and AquaMail for the future.

[dkmackie]

It is too bad that features are being removed. All that has been requested was to leave "reflow on zoom in" as a settings option. I doubt anyone would mind if no future "improvements" were made to the feature and those that don't like the behaviour could choose to disable it. Seems like a fair compromise to those that value the functionality.

Sent from my SM-G935V using Tapatalk

[Kostya Vasilyev]

Re: I doubt anyone would mind if no future "improvements" were made to the feature

I've said it before: we regularly had complaints about "zooming causing a jump" - makes sense too, if you're zooming in on something specific (a certain piece of text) then you want that "something" to remain on the screen when you've completed the zooming in gesture.

And it didn't.

So yes this is an improvement.

The broader picture is like this:

For quite some time now, there has been a standard way to make web pages and emails to adapt to narrow screens.

This is called "CSS Media Queries" and Aqua Mail fully supports those (unlike the Gmail app...).

A lot of messages these days do use this tech to automatically adapt to screen size (width).

Zooming or reflowing are not required.

Next tier: emails that do not use "CSS Media Queries" but still can be adapted to the smaller screens by Aqua Mail.

Works with a fair share of messages quite nicely.

Zooming or reflowing are again not required.

And the remaining tier: emails that use rigid HTML markup (tables) and so cannot adapt themselves and cannot be made to adapt.

This is where it may be necessary to zoom in depending on the message (some may remain readable even zoomed out). And previously we had reflow and now we don't... and I don't think there are many email apps that can reflow HTML messages.

---

And then there is something I'm somehow failing to understand: in order to zoom in, one had to touch the screen, with two fingers, so most likely you're using two hands (holding the phone in one, and using the other hand for the pinch zoom gesture).

What's so hard then about scrolling if necessary?

And then there is vertical scrolling, nobody seems to mind that?

[StR]

Kostya, thank you for the detailed explanation.

I haven't had a chance to evaluate this new behavior as I only had 1.8.x and earlier versions installed on my devices, and based on your explanation I hope this design decision will proof to be advantageous for majority of cases. (There've been a few cases where I originally disliked your decision, but liked it when I saw its implementation.)

But I just wanted to comment on one well known paradox related to the seemingly obvious argument such as "we regularly had complaints about ... " when it applies to a long-existed feature. It is obvious that good developers constantly listen to the complaints (and other feedback) and try to address them. And they should.
However, several well known cognitive biases are hidden here, of which the most important are probably negativity bias, and selection/sampling bias: you base your decision on the voice of only those who are unhappy and thus louder.
After you've made the change, you would be getting complaints from those who were happy with the way it had worked before. Based on those, can you correctly evaluate that the number of users who are unhappy with the change? My suspicion that the answer is likely "no!".  And there are several reasons for that. There is a potential problem with the "silent majority" in that case, especially if you announce, that this change is ultimate and will never be reverted: Some people don't want to waste their time and energy if they see it's a final decision, and either suck it up or leave silently. But that doesn't necessarily mean that the change satisfied more people than got people unhappy.
(And there is a possible "change bias" after the change is made.)

And then there is something I'm somehow failing to understand: in order to zoom in, one had to touch the screen, with two fingers, so most likely you're using two hands (holding the phone in one, and using the other hand for the pinch zoom gesture).

What's so hard then about scrolling if necessary?

And then there is vertical scrolling, nobody seems to mind that?

If that was not a rhetorical question but a genuine one, let me try to provide my point of view which is in part based on what I know from cognitive research related to visual design and reading.
First a few facts, rules (not absolute, but defining the baseline), ...; most of these seem to be obvious once stated, but listing them here would help to provide my view.
1. For very short sentences (as in on-screen, say, PPT presentation), one should avoid anything longer than 2 lines (especially in rapid technical presentations). This means that besides avoiding long sentences, it is undesirable to have narrow text-boxes that force extra line wraps.
2. The length of a text line should not exceed a certain viewing angle so that the reader does not need to move the eyes (or even the head) sideways excessively.
3.  Every jump of eyes from the end of the previous line to the beginning of the next one is a small disruption to reading. Frequent jumps due to extremely short lines can complicate/slow down comprehension (parsing) of complicated content with lengthy sentences. This can be significant when the line width becomes 1-3 words (as sometimes seen in newspapers, text wrapped around an image). (That's why for longer texts, the line length shouldn't be too short to avoid frequent jumps.)

Horizontal scrolling exacerbates the problem of the necessity for the eye focus to jump across the line wrap, as the eyes loose the line you were reading (skipping ahead, or returning to the already read one).

How does this apply to reading e-mails? In my opinion, it depends on the content and size of the text. If it is only 1-2 lines, it might be more beneficial to scroll horizontally. (That way, you also avoid scrolling vertically mid-sentence.)
For a [significantly] longer text, narrow lines (= higher frequency of jumps) become less of an evil compared to horizontal scrolling. (Of course, this is until the line is so narrow that many single words get wrapped. For that reason, when I need to zoom in and the text is reflowed, I am usually trying to switch to the landscape format.)

Also, for long texts, you already need to scroll vertically; that's unavoidable. Scrolling in 2 direction while reading is much more disruptive for tracking the text with your eyes, puts more strain, requires more attention for parsing and comprehension.


PS. An aside Re: vertical scrolling.
The was a recent switch in the website design paradigm, where the earlier concept of avoiding vertical scrolling by having multiple pages has been replaced with long (sometimes "infinite") vertical scrolling. I don't know if it is based on a noteworthy research, or  just a fad.

And previously we had reflow and now we don't... and I don't think there are many email apps that can reflow HTML messages.

That was one of the advantages of Aquamail. I just read a message in Gmail app (I have one account still using Gmail app, because Aquamail doesn't have per-account configuration for syncing/not-syncing on mobile network, and I need only one account to sync and notify quickly on any network.) - it was a long message and I once again confirmed that I strongly dislike scrolling horizontally.

There is actually one additional problem with that: swiping accidentally to the next/previous message (or pulling out the "side cabinet" in case of Gmail -- that's not a problem in Aquamail).


Speaking of reflowing in other e-mail clients, - I don't know about Android based once, but it's a standard feature of Thunderbird on Windows (both when you zoom in and when you just change the window width). And yes, when you zoom in, the focus changes, and an image/text can move aside. But it is seldom a big problem (there or in Aquamail of many years).

[StR]

I've just installed 1.9.0-stable-348 on a Samsung tablet (Tab 4), to actually test the lack of reflow when zooming.

First, there is still a "jump" in the position within the message when zooming, even though there is no reflow. I observed this on a plain-text message,with both 2-panel and 1-panel UI.
The easiest way to reproduce it is on zooming out.
Say, I zoomed in on the message so that the top of the message is visible. Then I am zooming out. Under certain conditions (essentially, if I am just "pinching out" without moving the text at the same time), the top of the text is getting hidden under the headers panel (this is strange, I am zooming out, so, things should not be disappearing, right?). Then, when I release the pinching fingers, the text jumps to show the top of the message body.
A similar jump occurs in the middle of the message, but it is a bit harder to reproduce every time.

I also found that under certain conditions (position within the message), it jumps in a similar manner when zooming in as well.
 I actually suspect that the actual culprit for the focus jumps (which exist despite the reflow turned off) still exists, even though the lack of reflow might not trigger it as often.  (If this guess is correct, and you can find and fix the culprit, you would turn the reflow back on.)

Kostya, if you cannot reproduce this, I will try to find a way to shoot and upload the video.

I have to go now, I will comment on the lack of the reflow in this new version later.

[Kostya Vasilyev]

Then, when I release the pinching fingers, the text jumps to show the top of the message body.
A similar jump occurs in the middle of the message, but it is a bit harder to reproduce every time.

Yes there may still be an occasional jump. But overall it's better than before.

About "text sliding under the header and only then the header getting resized".

The alternative (to avoid the issue altogether, and to *maybe* avoid scroll jumps too) is in the below attachments.

Does not look too good to me.

[StR]

Here are some additional thoughts on reflow while zooming.

Kostya, having re-read your long explanation  a few more times and a few previous posts in the thread, I realized that you might have different types of use cases in mind compared to what I have (and how I, and probably a few others use it). While discussing the need to reflow, you are talking primarily about the initial reflow of messages to fit them on the screen (before any zooming). I am talking about a different need.

Recently, I started using reading glasses especially when I am tired or when it is dark. However, I don't always have them on me. My phone is small (and one of the reasons I am not upgrading my Droid Razr M is that the current phones for VZW are mostly large).
So, occasionally (and, unfortunately, more and more often), I need to read text e-mails or embedded images (e.g. to get the address or phone number from the flyer for the event I am going to) that have small text, and I need to zoom in. (Larger fonts work but not always, as discussed before.)

So, the fact that Aquamail has zoom capability is great. It is an "accessibility" feature in this case.

While the recent change has no affect on reading the image, it has a huge effect on reading long(-ish) text emails.
Reading long test while needing to scroll horizontally is painful (as I described in my previous post in this thread). That's why I feel that disabling reflow after zooming is a regression. Aquamail has been praised for being "accessible", and I know that you, Kostya, have been listening to the needs of people for whom accessibility is important. And the argument that "there are [not that] many email apps that can reflow HTML messages" was actually talking about what makes Aquamail special: it allows things you cannot do with other email apps.
So, I hope you would re-consider your recent decision and would bring the reflow-after-zoom functionality back, as an option.

Also, for the users that have been using this feature, the way the recent change appears is that in an attempt to fix some annoying but relatively minor {*} issue, you've killed an important feature that users have been relying on for many years of using Aquamail.

{*} I had experienced that jump of the focus. I probably even reported it once (at least I was considering doing it), when I had a problem seeing an "inline" image because it was jumping from one line to another after reflow.
But it was a much less important inconvenience than the lack of reflow after zoom.


I have tested the new version with this feature, and I've found a few more reasons why horizontal scroll while reading a message is bad. First, every so often, while scrolling horizontally, I've been accidentally swiping to the next/previous message.  Even worse, with the 2-panel UI, while scrolling all the way to the left, I accidentally swiped beyond the panel boundary, to the message-list panel, and deleted a message (a different one). After some panic, I realized that fortunately, for this account, I had a copy of that message elsewhere.


The still remaining jumps that I reported in the previous post - I don't know how much of a problem they are, - I haven't tested this on messages with an image. The reason I reported them is to show that removal of reflow has not fixed the issue of focus jumping, at least - not completely (while an important functionality has been eliminated).

Thanks for listening (reading).

PS. Just in case: on the tablet, I wouldn't need zoom. But I was testing on it, as I didn't want to mess with the existing version on the phone.

[Kostya Vasilyev]

Just going to address one specific point that you made:

Re:  need to read text e-mails or embedded images (e.g. to get the address or phone number from the flyer for the event I am going to)

Images specifically.

Previously, zooming in on embedded images was often impossible -- you'd zoom in, the app would reflow the message, and the image would be shrunk back to the screen's width again -> NO zooming in on the image.

Now zooming in on images actually does work.

[StR]

Previously, zooming in on embedded images was often impossible -- you'd zoom in, the app would reflow the message, and the image would be shrunk back to the screen's width again -> NO zooming in on the image.

Now zooming in on images actually does work.

Thank you for that clarification. (I thought zooming on the images had worked; I was probably lucky with the e-mail structure, or didn't have that many images to zoom in onto).
That's definitely a helpful change.
(From your previous description, I had thought the recent change was only related to the positioning of the image within the screen, aka jumping, which I had experienced before.)

Too bad this change came at a price of killing another useful functionality.

[Kostya Vasilyev]

Re: Too bad this change came at a price of killing another useful functionality.

Embedded (inline, linked) images, by their nature, are part of message content.

And so they did rewrap together with message content. I can't think of a way to rewrap the "container" and avoid scaling images -- except when (and this can happen too) when the structure of HTML code is such that they don't. And we don't have any way to control the HTML code inside messages, it's "whatever is received by the user".

And yes we had complaints about that too.

[Philip]

My use case, much as above, is to be able to quickly read an email when the text is too small - scrolling horizontally would be a major pain, and I have no interest in maintaining the current position or viewing images.

I appreciate that some users may have complained, but it seems like a retrograde step to remove a feature than many users DO find useful (and they may well be the silent majority) in order to appease these users rather than to offer it as an additional option.

I wonder how many end users (who do not use development builds) will complain when the next version hits Google Play, and they find that a valuable and useful piece of functionality has been removed from an application that they have paid for.

[das1996]

@Kostya

As mentioned earlier, why not let the user decide.  Allow a toggle that either enables the current functionality without reflow, or uses the old reflow method.  User gets to choose and is happy about having the choice rather than having a new designed forced on them.

I don't care much for images in my emails.  In fact, on a given day, I can count on one hand how many emails I actually download in their entirety.  To me, ease of readability is more important than image scaling.

I have similar issues with most browsers.  In fact, only opera supports text reflow on android well.  I do have chrome and dolphin, but those two are secondary, for sites that don't work or render on opera (rare).

[Kostya Vasilyev]

Re: I wonder how many end users (who do not use development builds) will complain when the next version hits Google Play

We'll find out.

Re: many users DO find useful (and they may well be the silent majority)

That's a big problem actually - there are too few people voicing their opinions about what they do like and do find useful.

Re: a valuable and useful piece of functionality has been removed from an application that they have paid for

Almost makes it sound like removing features is all we ever do, and that this one was the only good feature we ever had.

Re:  In fact, only opera supports text reflow on android well.

Chrome has something called "reader mode" (wish this was available for use "inside" apps, but it does not seem to be).