[Users] [Bug 3288] New: Set default message view NOT threaded.
bs27975 at gmail.com
Sun Sep 21 11:14:24 CEST 2014
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
> 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
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
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
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.
More information about the Users