On Fri, 2010-10-01 at 14:51 -0400, Orcan Ogetbil wrote:
> On Fri, Oct 1, 2010 at 1:28 PM, Bill Nottingham wrote:
> > Orcan Ogetbil (oget.fedora@xxxxxxxxx) said:
> >> What I am trying to say is, a redesign of an interface _usually_ have
> >> valid reasons. Those users who don't want their menu items moving
> >> around want to live like automated machines. Forbidding such changes
> >> promotes lazyness.
> >>
> >> If the update removes features that existed in previous version, that
> >> is another story. I support you forbidding this type of change.
> >>
> >> But I really don't buy this "users shouldn't be disturbed by moving a
> >> button from left to right". If the user is disrupted to what they are
> >> used to, he needs to learn not to (be disrupted). Do we really want to
> >> serve a closed-for-learning community? :(
> >
> > It's restricting the arbitrary application of change to the user to
> > times when they are well able to deal with it. If I'm running F-13
> > and trying to create a slide deck, and run into a crash, I want the
> > update for the crash to just fix that crash. Not fix that crash and
> > reorganize the slide interface so I need to relearn it for the slides
> > I'm in the middle of. If this change is restricted to the next
> > major release, I'm expecting some amount of change, and therefore are
> > better able to process it, we're better able to document it, and so
> > on.
> >
> > Taking your suggestion to its extreme, we should promote learning and
> > resist automaton behavior by randomizing the menus at each click, changing
> > the default MTA once per release, and so on.
> >
>
> Random changes are different than planned-by-upstream changes. I don't
> think I would like to have randomized changes. But I am all in for
> planned changes that people thought about.
>
> Our views are very very different. But I don't need to reiterate my
> opinions. I am sure you got them.
+1
Usually upstream does not push random changes - usually the changes are
useful in some way and improving user experience. If the upstream is so
stupid to push really random changes in their minor releases (I do not
advocate here major releases updates from upstream in released Fedoras)
then probably the package should not be part of the Fedora at all or the
package maintainer in Fedora should be able to backport individual
patches for bug fixes. But disallowing any changes in user experience
and minor updates from upstream in released Fedoras is unreasonably
strict.
Also when getting back to the infamous KDE 4.0 in Fedora 9 - when the
decision was made to ship KDE 4.0 (regardless of whether it was bad or
not) in the final release - it would be really stupid to disallow
updating KDE packages to new upstream versions that changed user
experience (mostly by improving it).
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
