← Back to team overview

unity-design team mailing list archive

Re: No more dodge windows in Unity?

 

>
> On 14. feb. 2012 13:35, Mark Shuttleworth wrote:
>
>>
>> In other words, instead of maintaining multiple, shallow codepaths, we
>> are able to maintain fewer, *deeper* codepaths. Perceived quality doesn't
>> come from the number of options. It comes from the level of refinement of
>> the options presented. And quality is our goal.
>>
>>
the people who are upset by this (myself included) feel like they've had
the most refined, highest quality option taken away from them in favor of
less refined options.
it should be easy to see why we feel that way since a launcher that gets
out of the way when you are less likely to want it but ready and waiting
when you're more likely to want it is by nature a highly refined option.
was it perfect? no.  was it the best for everyone? no again, but neither is
always visible or autohide even with the mentioned improvements though i
don't doubt that it's better than it used to be.
i also don't doubt that dodge windows would have benefit from the same
improvements though making the changes to one code path is obviously going
to be less work than making them to two.

in the end we're upset because we're still going to be lacking the
refinement that dodge windows offered to us even if that *refinement*
doesn't seem to offer you any evidence of being a huge *benefit* over
autohide.
does autohide even offer any real benefit over always visible? i doubt it
but i'm sure there are plenty of people who would rather not have their
launcher *always* visible. if someone is going to change from the default
it's all about user preference not user benefit.  it's because they like it
more rather than because it's so much more beneficial. the benefit is the
launcher itself not the way it's presented as long as form follows function.


we're obviously not getting dodge windows back in it's old form so how
about mixing in some of it's functionality with the remaining two options?
have that functionality turned on and off by one setting that affects both
options.
have it make always visible hide when a window is maximized and for
autohide have it either visible when there isn't any window open or have it
dodge windows.

for a number of us this would make the unity autohide the best autohide on
the planet and it might even make using always visible bearable if not my
preferred option as well.
that way you've still got just the two codepaths but it adds at least some
of the refinement dodge windows offered back into the mix.


i fail to see how the question becomes *"is [dodge windows] *so much more
productive* for the insiders that it justifies keeping it around confusing
the outsiders?"* instead of *"is there a way to make dodge windows less
confusing for outsiders?"* or even just "*since dodge windows is confusing
for 'outsiders' and as such can't be a default, is the refinement it offers
worth keeping in one way or another for the 'insiders' who would still
enjoy it as a non-default?"*
*
*
i don't see how "this is bad for new users" directly means "this is just
bad and we should get rid of it completely."
i haven't seen anyone argue not having dodge windows as the default. i've
just seen people argue having it removed.

i can't imagine that there were no ways to make dodge windows less
confusing for "outsiders" in the first place but i also think that mixing
it's functionality into the two remaining options would be better than
leaving it as it's own option or not having that kind of thing offered
anymore.

we get why dodge windows can't be a default.
we get why it's better to have fewer codepaths to have to keep up and
refine.
we don't get why the dodge windows functionality has to be completely
removed.
a user having to fiddle a bit with things in order to figure something out
is not a bad thing as long as they can still figure it out relatively
easily.
which brings me back to not being able to imagine that there's no way for
dodge windows to be made less confusing for "outsiders".

-- 
Josh Strawbridge

Follow ups

References