hacked package on server

Brian Mathis brian.mathis@gmail.com
Mon Jul 16 19:44:00 GMT 2007

On 7/16/07, Igor Peshansky <pechtcha@cs.nyu.edu> wrote:
> Ugh, top-posting...  Reformatted.
> On Mon, 16 Jul 2007, Brian Kelly wrote:
> > -----Original Message-----
> > >From: Christopher Faylor <cgf-use-the-mailinglist-please@XXXXXX.XXX>
> > >Sent: Jul 16, 2007 11:52 AM
> > >To: cygwin@XXXXXX.XXX
> <http://cygwin.com/acronyms/#PCYMTNQREAIYR>.  Thanks.
> > >Subject: Re: hacked package on server
> > >
> > >On Mon, Jul 16, 2007 at 10:30:52AM -0500, Louis Kruger wrote:
> > >> I also have a complaint:  the dialog that notifies the user of the
> > >> failed MD5 is not well designed.  The dialog asks "Do you want to
> > >> skip the package?" and has a yes and no button.  I read it quickly
> > >> and pressed no before thinking about it, the package went ahead and
> > >> tried to install.  I think there should be a little more effort to
> > >> restrain the user from performing a dangerous action such as
> > >> installing a package with a wrong MD5.
> > >
> > >Good point.  The message should probably be
> > >
> > >Do you want to not skip the package (No/Yes)?
> > >
> > >cgf
> >
> > This would be "more" helpful:
> >
> > Do you want to not skip the package (No/Yes/Maybe)?
> >
> > The "Maybe" can then consult a random number routine to decide whether
> > or not to do the operation.
> Jeez, guys.  Haven't you learned ANYTHING in a UI design course?
> The main purpose of the UI is to give the user a warm fuzzy feeling and to
> overwhelm him with critical information to the point of being incapable of
> making rash decisions like this.
> Therefore, the message should read thus:
> Do you not want to not skip the abovementioned package?
> And the buttons should read "Yes", "No", and "I need more time to decide",
> the last one being in the middle and more prominent.  It would also help
> to have a fake countdown running somewhere in the window, with large black
> digits.  Guess which button the user will go for?
>         Igor

Yes, everyone now has been quite hilarious on this part of the matter,
but I think it's time to get past the arrogance and, god forbid,
consider that a user's reported problem, oh my god, might actually be
a problem!

Any time there's a report of a user having a problem with an
interface, *especially* one that's _supposedly_ so easy and obvious,
why not address it?  Or why not AT LEAST take a thought and say to
yourself, "if something is supposed to be so simple and obvious, and
yet someone is having a problem with it, maybe *I* am making an
assumption about the simplicity of it?"

In this case, a user running an installer is in the frame of mind of
*installing* things, not *skipping* things.  So when they are asked a
question, they should be asked questions about *installing*, not
*skipping*, and the answers should be taken in that context.  "Yes"
should do the install, while "No" should not.  Switching the context
to "skipping" causes the type of confusion that is going on here.

If it's so minor, be glad that someone actually reported it and now
you have the chance to make the project better.  Most people would
just get confused, stop, reread, hopefully make the right choice, and
move on, but retain the impression that it's hard to use and
confusing.  This may affect their decision to use it in the future, or
their decision to recommend it to others, etc...

Isn't that a much more intelligent response than, "Wow, our users are
such idiots!  I'm so much better than them because I'm a such a smart
computer guy!"

PS. This same concept applies to the recent discussion about
documentation, and all the previous ones as well.  If something is not
obvious enough for people to find it, then it should be made more
obvious (or at least some consideration given to the request).  One
does not have control over the ways people approach a problem.  This
project does have control over how/where documentation is located, and
the ease of finding it.  Focus on what you have control over.

Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

More information about the Cygwin mailing list