Opinions: Warn about online registration checks?

[JT]

Hi,

I would like opinions on a shareware issue. If shareware uses an
online database to hold registration codes, which get copied locally
and therefore only needs to check online if the shareware is not yet
registered or if the registration code was lost, should there be an
"Is it okay to go get your lost registration code?" message box? I've
been told that certain firewalls will disallow everything until you've
allowed it. I imagine that even if you ask this question, you're
going to have to let it fail once before you can tell the firewall
what to allow. The other option is to have the shareware display a
splash screen that indicates checking for the registration code as
it's doing so.

So the ultimate question is, "Should the shareware display an
interactive message box that interrupts the flow of the software
before doing an online database check instead of seamless operation?".

Thank you for your opinions.

JT

 

[Peter Duniho]

[...]
So the ultimate question is, "Should the shareware display an
interactive message box that interrupts the flow of the software
before doing an online database check instead of seamless operation?".

It's my opinion that you're actually asking two different questions.
One has to do with how you notify the user, if at all, that you're doing
some network operation. The other has to do with how involved you want
the user in allowing that operation to proceed (ie, tell him in advance
or just wait for a failure and ask him to fix it).

I think that the answer to the first question is that you should only
check the registration in response to an explicit command from the user.
This could be a "register" command in a menu, a button on a splash
window, a "I can't perform this command until you register", whatever.
I think that's much better than just implicitly checking the
registration, especially if the implicit check could potentially occur
over and over until the user has actually registered.

As for the second question, I think that you really only have one
practical choice: perform the operation, and provide useful information
to the user if it fails. In most cases, a firewall or proxy won't
actually block outbound client network traffic, and your operation will
succeed without trouble. At the same time, most users aren't network
configuration savvy. So you'd probably just wind up confusing most users.

In the unusual case that outbound network oprations are blocked, if I
recall correctly in Windows Vista if the firewall is blocking access,
the user will be given a way to authenticate as the admin and open the
access automatically, and the easiest way to get this to happen is just
to try. In Windows XP SP2, the firewall offers a similar UI except that
you have to be logged in as admin for it to work (otherwise you just get
a "contact your admin" message).

In other words, in the large majority of cases, there's really nothing
for you to warn the user about. You definitely should offer some help
topic covering basic network configuration issues, but I don't think
there's any need to direct the user to that until something fails.

Pete

 

[JT]

[...]
So the ultimate question is, "Should the shareware display an
interactive message box that interrupts the flow of the software
before doing an online database check instead of seamless operation?".

It's my opinion that you're actually asking two different questions.
One has to do with how you notify the user, if at all, that you're doing
some network operation. The other has to do with how involved you want
the user in allowing that operation to proceed (ie, tell him in advance
or just wait for a failure and ask him to fix it).

I think that the answer to the first question is that you should only
check the registration in response to an explicit command from the user.
This could be a "register" command in a menu, a button on a splash
window, a "I can't perform this command until you register", whatever.
I think that's much better than just implicitly checking the
registration, especially if the implicit check could potentially occur
over and over until the user has actually registered.

As for the second question, I think that you really only have one
practical choice: perform the operation, and provide useful information
to the user if it fails. In most cases, a firewall or proxy won't
actually block outbound client network traffic, and your operation will
succeed without trouble. At the same time, most users aren't network
configuration savvy. So you'd probably just wind up confusing most users.

In the unusual case that outbound network oprations are blocked, if I
recall correctly in Windows Vista if the firewall is blocking access,
the user will be given a way to authenticate as the admin and open the
access automatically, and the easiest way to get this to happen is just
to try. In Windows XP SP2, the firewall offers a similar UI except that
you have to be logged in as admin for it to work (otherwise you just get
a "contact your admin" message).

In other words, in the large majority of cases, there's really nothing
for you to warn the user about. You definitely should offer some help
topic covering basic network configuration issues, but I don't think
there's any need to direct the user to that until something fails.

Pete

Thanks for your reply, Pete. And by the way, I'm looking for lots of
opinions, so if anyone has one, please let me hear it.

As for the repeated tries, it would happen once per session of the
application (at startup). It would only happen if there was not
already a local copy of the registration code, meaning the application
had not been registered yet or the code was removed from the storage
location.

 

[Peter Duniho]

[...]
As for the repeated tries, it would happen once per session of the
application (at startup).

I do understand that. My point is that as a computer user, I have no
interest in having some software I'm using attempt to access the
network, never mind the Internet, unless I have specifically told it to.

That's not to say automatically accessing the Internet isn't appropriate
in some cases. Some programs allow the user to enable a "check for
update automatically" feature. Other programs are specifically about
network access, and so the simple act of running the program is
sufficient indication from the user that network access is desired.

But nothing about your description so far suggests the behavior you're
asking about falls into those scenarios.

It would only happen if there was not
already a local copy of the registration code, meaning the application
had not been registered yet or the code was removed from the storage
location.

I understand that. But I don't think it's appropriate for the
application to check a central registry every time it boots, even if
it's not registered.

If there's some advantage to checking that registry, the user will be
motivated to explicitly tell the program to do so at the appropriate
time. There's no need for the program to make that attempt
automatically when the software is started, and there are various
usability and privacy issues associated with doing so that are violated
when your program makes that automatic access.

Opinions do vary, and I hope others who have some will weigh in with
their own thoughts. Then you can judge for yourself which philosophy
has more merit with respect to your own ideas and goals.

To sum up my own philosophy: software should only do what I tell it to.
Automatic behaviors themselves should only be enabled inasmuch as
either the software simply doesn't make sense without them, or inasmuch
as I the user can control whether they happen. This is true generally,
and it is especially true when dealing with features that involve the
software interacting with entities outside of my control (such as a
centralized registration database).

Pete

 

[JT]

[...]
As for the repeated tries, it would happen once per session of the
application (at startup).

I do understand that. My point is that as a computer user, I have no
interest in having some software I'm using attempt to access the
network, never mind the Internet, unless I have specifically told it to.

That's not to say automatically accessing the Internet isn't appropriate
in some cases. Some programs allow the user to enable a "check for
update automatically" feature. Other programs are specifically about
network access, and so the simple act of running the program is
sufficient indication from the user that network access is desired.

But nothing about your description so far suggests the behavior you're
asking about falls into those scenarios.

It would only happen if there was not
already a local copy of the registration code, meaning the application
had not been registered yet or the code was removed from the storage
location.

I understand that. But I don't think it's appropriate for the
application to check a central registry every time it boots, even if
it's not registered.

If there's some advantage to checking that registry, the user will be
motivated to explicitly tell the program to do so at the appropriate
time. There's no need for the program to make that attempt
automatically when the software is started, and there are various
usability and privacy issues associated with doing so that are violated
when your program makes that automatic access.

Opinions do vary, and I hope others who have some will weigh in with
their own thoughts. Then you can judge for yourself which philosophy
has more merit with respect to your own ideas and goals.

To sum up my own philosophy: software should only do what I tell it to.
Automatic behaviors themselves should only be enabled inasmuch as
either the software simply doesn't make sense without them, or inasmuch
as I the user can control whether they happen. This is true generally,
and it is especially true when dealing with features that involve the
software interacting with entities outside of my control (such as a
centralized registration database).

Pete

Hey Pete,

You make a very good argument, and I think your opinion will prevail,
especially in these times of questionable web sites and potential
virus propogation. Hopefully, I will at least get many people
supporting your opinion. I'd still like to see if anyone can provide
an argument for the other side. However, I think it would only be in
favor of avoiding annoyance and having a "Wow, it just worked without
me having to do anything." kind of experience.

Other programs are specifically about
network access, and so the simple act of running the program is
sufficient indication from the user that network access is desired.

I don't want to tie this to a specific type of program, so I want to
leave it open to purely stand-alone applications as well as
applications that access the Internet.

Once again, your opinion is very much appreciated.

JT

 

[JT]

[...]
As for the repeated tries, it would happen once per session of the
application (at startup).

I do understand that. My point is that as a computer user, I have no
interest in having some software I'm using attempt to access the
network, never mind the Internet, unless I have specifically told it to.

That's not to say automatically accessing the Internet isn't appropriate
in some cases. Some programs allow the user to enable a "check for
update automatically" feature. Other programs are specifically about
network access, and so the simple act of running the program is
sufficient indication from the user that network access is desired.

But nothing about your description so far suggests the behavior you're
asking about falls into those scenarios.

I understand that. But I don't think it's appropriate for the
application to check a central registry every time it boots, even if
it's not registered.

If there's some advantage to checking that registry, the user will be
motivated to explicitly tell the program to do so at the appropriate
time. There's no need for the program to make that attempt
automatically when the software is started, and there are various
usability and privacy issues associated with doing so that are violated
when your program makes that automatic access.

Opinionsdo vary, and I hope others who have some will weigh in with
their own thoughts. Then you can judge for yourself which philosophy
has more merit with respect to your own ideas and goals.

To sum up my own philosophy: software should only do what I tell it to.
Automatic behaviors themselves should only be enabled inasmuch as
either the software simply doesn't make sense without them, or inasmuch
as I the user can control whether they happen. This is true generally,
and it is especially true when dealing with features that involve the
software interacting with entities outside of my control (such as a
centralized registration database).

Pete

Hey Pete,

You make a very good argument, and I think your opinion will prevail,
especially in these times of questionable web sites and potential
virus propogation. Hopefully, I will at least get many people
supporting your opinion. I'd still like to see if anyone can provide
an argument for the other side. However, I think it would only be in
favor of avoiding annoyance and having a "Wow, it just worked without
me having to do anything." kind of experience.

Other programs are specifically about
network access, and so the simple act of running the program is
sufficient indication from the user that network access is desired.

I don't want to tie this to a specific type of program, so I want to
leave it open to purely stand-alone applications as well as
applications that access the Internet.

Once again, your opinion is very much appreciated.

JT- Hide quoted text -

- Show quoted text -

Still want more opinions! Here's a wrinkle.

What good does it do for an application to ask a user if it is okay to
do something if when the user says, "Yes", it does something
completely different?

Is that a realistic question? What is your opinion on asking before
performing an online database registration check?

JT

 

[Peter Duniho]

Still want more opinions! Here's a wrinkle.

What good does it do for an application to ask a user if it is okay to
do something if when the user says, "Yes", it does something
completely different?

Are you saying that something I wrote makes you think you would
implement code that would do that?

I hope not. The scenario you're suggesting is an example of poor UI,
and I didn't write anything that should have been interpreted as
suggesting that you do something like that.

Is that a realistic question? What is your opinion on asking before
performing an online database registration check?

I don't see the connection between the two. Of course, you already know
my opinion on the latter.

Pete

 

[JT]

Are you saying that something I wrote makes you think you would
implement code that would do that?

I hope not. The scenario you're suggesting is an example of poor UI,
and I didn't write anything that should have been interpreted as
suggesting that you do something like that.


I don't see the connection between the two. Of course, you already know
my opinion on the latter.

Pete

Hey Pete,

I'm just playing devil's advocate. I'm sure you don't trust emails
saying that you've won the Uganda lottery and all you have to do is
pay a processing fee. Is it any safer to trust software that says,
"Now I'm going to check our online database." when it could very
easily then extracct sensitive information from your PC and send it to
the database instead. I just think that havng a message box
indicating what you're intending to do gives the user a false sense of
security. I'm not saying you shouldn't do that anyway. I just don't
know what good it really does.

I'm sorry if you think that this is a one-to-one conversation. I
would love to get responses to this from 5000 different people.
That's why I keep asking the question. I don't want this topic to
slide into obscurity just because I happened to post it just before a
weekend and many more topics were posted after it. I wish there was
an opinions and polls group for .NET.

I do appreciate your interest in this. At least I got one response,
but if all I wanted was one opinion, I already had it: mine. That's
not a very good cross-section and mine is usually way different from
most peoples' opinions. But don't stop responding if you still have
things to clarify.

JT

 

[Peter Duniho]

I'm just playing devil's advocate. I'm sure you don't trust emails
saying that you've won the Uganda lottery and all you have to do is
pay a processing fee. Is it any safer to trust software that says,
"Now I'm going to check our online database." when it could very
easily then extracct sensitive information from your PC and send it to
the database instead.

It was not at all clear from your post that you were describing a
situation like that.

It's true, you can make your application say anything you want, and then
whatever you want. But I thought we were discussing reasonable behavior
here, things you might actually implement.

The fact that I _could_ lie to people doesn't stop me from making
statements to people that they can trust to be true. Likewise, just
because your application _could_ be badly behaved is no reason to avoid
having it be well-behaved.

I just think that havng a message box
indicating what you're intending to do gives the user a false sense of
security. I'm not saying you shouldn't do that anyway. I just don't
know what good it really does.

First, the fact that you _could_ do something other than what you say
you are going to do should be irrelevant. It is always possible to lie.
Good software doesn't, and if you've established trust with your user,
the fact that you _could_ be lying doesn't matter, as long as you
_aren't_ lying. Of course, part of establishing trust with your user is
being explicit about what you're doing and doing only what the user asks
you to do.

That said, you seem to be focusing on one narrow part of why it's
important to ask the user before using the network, if using the network
is not an implicit part of your application's operation. Yes, it's a
potential security and privacy issue that the user should be in control of.

But also, the mere act of accessing the network can sometimes have
unintended effects. One example is a computer that is using dial-up
networking. Simply by making an attempt to use the network, Windows
will by default pop up a connect dialog. Yes, the user can cancel that,
and your network i/o will fail (and hopefully you handle that
gracefully). But it's an annoyance to the user to have to go through
that every single time they try to run your application.

The point isn't just to let the user know what you're doing. It's to
give the user _control_ over what you're doing. Good software doesn't
surprise the user, and it doesn't do things that the user hasn't asked
it to do.

Only if the user explicitly does something that requires the network
should you use the network. That puts control in the user's hands. I
would extend this to say that you shouldn't even be asking the user if
it's okay; you shouldn't be trying at all, unless the user has
explicitly done something that requires network access.

So, if the user tries to use a feature that requires registration,
verify with the user that they want to try to access the registration
database. If the user chooses a menu command that explicitly says to
access the registration database, obviously no prompt is necessary. But
do not automatically try to access the registration database just for
the sake of accessing it, not even by prompting the user first.

I'm sorry if you think that this is a one-to-one conversation.

I have no idea what you mean by that.

Pete

 

[JT]

It was not at all clear from your post that you were describing a
situation like that.

It's true, you can make your application say anything you want, and then
whatever you want. But I thought we were discussing reasonable behavior
here, things you might actually implement.

The fact that I _could_ lie to people doesn't stop me from making
statements to people that they can trust to be true. Likewise, just
because your application _could_ be badly behaved is no reason to avoid
having it be well-behaved.


First, the fact that you _could_ do something other than what you say
you are going to do should be irrelevant. It is always possible to lie.
Good software doesn't, and if you've established trust with your user,
the fact that you _could_ be lying doesn't matter, as long as you
_aren't_ lying. Of course, part of establishing trust with your user is
being explicit about what you're doing and doing only what the user asks
you to do.

That said, you seem to be focusing on one narrow part of why it's
important to ask the user before using the network, if using the network
is not an implicit part of your application's operation. Yes, it's a
potential security and privacy issue that the user should be in control of.

But also, the mere act of accessing the network can sometimes have
unintended effects. One example is a computer that is using dial-up
networking. Simply by making an attempt to use the network, Windows
will by default pop up a connect dialog. Yes, the user can cancel that,
and your network i/o will fail (and hopefully you handle that
gracefully). But it's an annoyance to the user to have to go through
that every single time they try to run your application.

The point isn't just to let the user know what you're doing. It's to
give the user _control_ over what you're doing. Good software doesn't
surprise the user, and it doesn't do things that the user hasn't asked
it to do.

Only if the user explicitly does something that requires the network
should you use the network. That puts control in the user's hands. I
would extend this to say that you shouldn't even be asking the user if
it's okay; you shouldn't be trying at all, unless the user has
explicitly done something that requires network access.

So, if the user tries to use a feature that requires registration,
verify with the user that they want to try to access the registration
database. If the user chooses a menu command that explicitly says to
access the registration database, obviously no prompt is necessary. But
do not automatically try to access the registration database just for
the sake of accessing it, not even by prompting the user first.


I have no idea what you mean by that.

Pete

Hey Pete,

In order to correct some misconceptions I would have to start
describing specific behaviors of specific applications, which I think
would give me results that would not necessarily fit the general mold.

What I mean by a one-to-one conversation (one on one?) is that it's
just you and me, not the hundreds and thousands of people I was hoping
to hear from. I'm sure that no matter how popular your opinion is,
you don't speak for every developer and end-user in the world. Not
everything I am posting is directed to you. I don't care if I get
5000 people saying, "Pete's right, you dope." I want to see that.

JT

 

[Peter Duniho]

In order to correct some misconceptions I would have to start
describing specific behaviors of specific applications, which I think
would give me results that would not necessarily fit the general mold.

It is quite common for a designer of software to think "well, those
rules are fine for other applications, but mine is special". However,
that sort of thinking is practically always wrong. The general rules
exist because of some basic usability issues, and they apply in
practically every case.

There's already too much annoying software out there. Why add to the
problem?

What I mean by a one-to-one conversation (one on one?) is that it's
just you and me, not the hundreds and thousands of people I was hoping
to hear from.

But why did you write "I'm sorry if you think..."? That implies that I
for some reason believed it to be true. I certainly do not, and nothing
I wrote should be construed that way (nor do I see how it could have been).

I'm sure that no matter how popular your opinion is,
you don't speak for every developer and end-user in the world. Not
everything I am posting is directed to you.

To some extent, nothing you are posting is direct at me. We have these
public conversations as a way of including others, and in that sense
nothing that either of us write is intended for the sole consumption of
the other party to the conversation.

On the other hand, inasmuch as I'm a reader of this newsgroup, there's
nothing you can post here that is not at least partially directed at me.
That is, whatever you write, I am a potential member of the audience
of that message, and I may well reply. Even if you did not intend it as
a direct response to something I wrote.

I don't care if I get
5000 people saying, "Pete's right, you dope." I want to see that.

Well, I would guess you're not going to see that. I think if anyone
else felt like they had a vested interest or opinion regarding this
thread, they would have replied by now.

It's _possible_ you suffered a little from the weekend effect, but many
of the regulars here still monitor the newsgroup, at least to some
extent, over the weekend. So I'd be surprised if that was a fatal flaw
in your timing or anything like that.

Pete

 

[JT]

It is quite common for a designer of software to think "well, those
rules are fine for other applications, but mine is special". However,
that sort of thinking is practically always wrong. The general rules
exist because of some basic usability issues, and they apply in
practically every case.

There's already too much annoying software out there. Why add to the
problem?


But why did you write "I'm sorry if you think..."? That implies that I
for some reason believed it to be true. I certainly do not, and nothing
I wrote should be construed that way (nor do I see how it could have been).


To some extent, nothing you are posting is direct at me. We have these
public conversations as a way of including others, and in that sense
nothing that either of us write is intended for the sole consumption of
the other party to the conversation.

On the other hand, inasmuch as I'm a reader of this newsgroup, there's
nothing you can post here that is not at least partially directed at me.
That is, whatever you write, I am a potential member of the audience
of that message, and I may well reply. Even if you did not intend it as
a direct response to something I wrote.


Well, I would guess you're not going to see that. I think if anyone
else felt like they had a vested interest or opinion regarding this
thread, they would have replied by now.

It's _possible_ you suffered a little from the weekend effect, but many
of the regulars here still monitor the newsgroup, at least to some
extent, over the weekend. So I'd be surprised if that was a fatal flaw
in your timing or anything like that.

Pete

Okay. Then I'm a little disappointed that more people didn't chime
in; not that I go reading every post either. I'm glad that you
replied, though.

Feeling magnanimous? I'm struggling with another real-world problem
in another post called something like "Can't disable double-click in
RichTextBox". I'm worried it may be a lost cause, but I'd love a
suggestion.

JT