[Users] [Bug 3288] New: Set default message view NOT threaded.

[B. S.]

On 14-09-20 11:27 AM, Brad Rogers wrote:
> On Sat, 20 Sep 2014 09:37:32 -0400
> "B. S." <bs27975 at gmail.com> wrote:
>
> Hello B.,
>
>> Sorry - not so. By definition, users have already had their out of box
>> experience. Nothing here suggests any changes for them.
>
> Depends on how the software sets things up.  It can be that software
> doesn't set instructions in the config file unless/until the default is
> changed.  Under such circumstances a change of default behaviour will
> change things for people that have not altered the default.  That's
> *always* bad.  If CM writes a setting at install, then yes, existing
> users remain unaffected.

(1) "It can be that software doesn't set instructions in the config file 
unless/until the default is changed."

There is no default / config file if the software has never been 
installed. Thus, prior users are not impacted as prior users have had 
their out of the box experience already, and nothing proposed impacts 
them in the future. Merely future out of box experiences, as I said.

(2) I absolutely agree with what you're saying. I am saying a different 
default is more appropriate for more people, in today's world and 
devices, going forwards. I am also not saying that due consideration not 
be given to appropriate implementation. Such as accounting for details 
as you suggest. Which at first blush don't seem insurmountable, 
reasonably typical, actually - to satisfy all the good use cases you 
well point out.


>> And, I daresay, there are many more users to come than there are
>> currently.
>
> Frankly, I doubt it (although thee will be some more).  More and more
> people are using a web browser for email, not an MUA.  In fact, the move
> seems to be to use a browser for everything.

I would have said so too, some while back. But I suspect things are 
starting to switch the other way. Especially with new devices where data 
connectivity is not always 24x7. I don't disagree this is a moving 
target, but wireless (cell) data rates are still too stupid expensive, 
and it feels like a point of resistance is being encountered. At least 
in Canada. Apparently cell handset (therefore tablets too) conversion is 
not nearly as high as the providers would like - the pitch is more 
content everywhere, but many are deciding that given the cost they can 
do without content everywhere (thus offline increasing). I'll try saying 
that differently - the original adoption rate of cell is not being 
mirrored in the adoption rate of newer / faster / more expensive data 
plans, and this is causing great consternation among the providers as 
sales increases are not happening as fast as they or investors would 
like or are used to. The massive investments in content is not 
triggering the desired ROI, ultimately leading to providers competing on 
price - which is a margin squishing exercise, lending content providing 
investments counter-productive. [Similar as to why reality TV has taken 
over the airwaves - production costs.]

- granted, providers are gleeful over tablets ... a second device to 
sell / provided connectivity to. Tablets may duplicate but will never 
replace cell, given voice connectivity desired everywhere, and (pocket) 
size being a factor. Tablets are replacing additional desktops, not 
additional handsets. And, I would hope, not replacing desktops entirely. 
Pry my local storage speed, copper connectivity, and keyboard out of my 
cold dead hands. [As you probably picked up on.] (-:

- FWIW, turns out, or is becoming more prevalent, only live current 
content (sports) is ultimately going to matter. i.e. Smaller (content) 
use case than everyone all the time, making provider's wishful thinking 
starting to become ... oops. (Over size of investments made.)

- I believe people are starting to realize ... only so many hours in a 
day, and why would I watch that event on a PDA rather than on a wide 
screen TV. Poorer quality too, given the screen size and data requirements.

I don't disagree that browser as app presenter is becoming more 
prevalent, especially as browsers become more capable. (Although even 
now HTML5 isn't exactly ubiquitous.) But this is, after all, merely the 
presentement. Replacing a qt/gtk display doesn't take away from all the 
rich processing goodness / back end present within CM. Whether messages 
are present threaded or not still applies.


>> The advantages to the new user have already been listed - no down side
>> for them, only upside.
>
> I disagree.  Although it's not me that needs convincing, but the dev
> team.

Fair enough - but I find it interesting 'bug' reports get mirrored to 
the list. Never encountered such before, but is definitely fascinating. 
Allowing the user community to inherently discuss pros/cons, and 
providing devs with more ready input than they otherwise might have. 
AND, I assume helps guide which changes are of more interest, and 
therefore what priority should be assigned to things. Interesting and 
fascinating.

Let alone different aspects of the request.

e.g. A visual indicator / icon of being in threaded mode or not would 
seem useful, while leaving the not/threaded default debate to the side 
for that moment. As would a config setting for not/threading upon new 
folder creation. Even if current default is not changed, such a config 
setting would leave things to per user choice (always a good thing) on a 
go forward basis.

Let alone, one way to deal with this would be to ask the question at 
install time - do you prefer threading or not. [Which is actually the 
big thing, I suppose - the unpleasant surprise the new user encounters 
after the fact. And it is always after the fact before a new user has 
sunk into the ecosystem far enough to understand what has been done to 
them.]

I don't disagree that it depends upon what you're used to - my point has 
been it wasn't what I was used to, unexpected, and caused a great deal 
of i/o time unnecessarily at migration / conversion time - where the 
instant gratification / initial impression to keep using or not is 
formed. And I think that my experience will be more typical on a go 
forward basis, given today's users, devices, and clients.

It has also now occurred to me, this also could be a per-folder 
properties setting, thus allowing an initial setting via 'apply to 
subfolders', and finer grained control after the fact.

But that last is independent of a visual cue of not/threaded mode, and 
default for new folders. It is more apparent that you're not in threaded 
mode when you want it, than that you are in threaded mode when you 
don't. (Can't prove a negative.)

Good discussion, thank you all. I never imagined, given my use case and 
the typical use case of the hundreds around me, that the request would 
be so controversial.

It is a little weird, however, to be dived upon so vigorously - 
presumably any project would want to foster a growing and participating 
community, not drive that participation away with aggravation. [Been 
doing this for decades, so such doesn't bother me, but it would most 
others I know.]

Cheers to all.