Philosophy of minimal disturbance of existing users
joesab2005 at gmail.com
Sat Sep 15 00:00:00 UTC 2012
On 9/14/2012 13:49, Kent James wrote:
> As another user interface issue, I just tried some new Daily runs, and
> immediately notice that my menus are gone.
Kent, I know that your main dev branch is Aurora due to your extension
work, so you might be excused for not noticing this ;-)
But I see no reason that very few (if any) devs run trunk as their
everyday use build.
The theme guys BTW are the best at offering pref alternatives for most
new features, while others are not so quick to respond.
Decisions on what features land and which go away is perceived as
one-sided by most users that I know.
I'm sure you are aware of this, but here is a quick example:
Asa d declared the view switcher UI "Heavy and Ugly" and it was gone
within a week.
On the other hand, long time users wanted a small option to the
attachments box display, and it took 5 months to get in.
It takes the most persistent personality type to hang in there and lobby
for certain bug fixes.
The casual bug filer is in most cases not of this ilk (My bug is the
most important bug ever filed) I try always to be kind in bug triage.
> That forces a dramatic change in the way that I am used to working.
> While I understand the reasons behind it, and probably agree with
> them, for the typical user who had gotten used to doing things a
> certain way, this is just an annoyance. Today may not be the day that
> I really wanted to stop what I was doing, and figure out how to turn
> the menus back on. The reaction of most existing users, IMHO, is going
> to be a mild round of cussing at the arrogance of developers who are
> constantly pushing change on users who really don't want it. (Now I've
> been the guy getting cussed at in the past, and there are times that
> change is needed, I understand that).
> Why not instead adopt a philosophy of minimal disturbance of existing
> users? Couldn't we instead enable the menubar by default for existing
> users, and only disable it by default for new users?
Migration assistant was very necessary for TB3.1 due to the number of
changes. But maybe we could use a simpler approach when there
How about something like this:
When a new feature is available, offer the feature at startup, but don't
finalize the pref until shutdown. This does require a hidden pref for the
feature, and all the added code complexities that implies. Maybe that
could be a temp pref for the first few weeks of a new feature.
> And follow that through when possible for all user interface changes
> that have a major impact on existing users?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the tb-planning