Online user registration and update service?

[divanova]

Hey there,

I am running out of ideas and would appreciate if somebody can help/advise on this issue. What I need to do is the following

1. Install our product
2. Register user
3. With update service send updates only to the registered users

Sounds simple? OK but how do I implement it. I have the following proto solution:
1. Install the product as usuall
2. Prompt at the end of installation (before finish dlg) if the user wants to register for updates and if so open the IE to our site where we do the collection of data including email
3. We send back an email to the user with a code in it
4. On updates I create a condition and prompt the user for the code he/she got from us
5. Validating the code it'll show them the updates for our product

What do you think? Calling all for an oppinion ...

Cheers,
Dannie

[Brad_Peterson]

This is more of an interface or design strategy than it is an update one.

That being said, I have the same needs you do, to install, register, and if needed, update our product.

Looking at your registration solution, it seems too complicated. It may work for your user base, but I know many of ours would get turned off or confused by that.

Here's what we do in place of 2-5. We have a registration screen in our program which asks them for some of their information. They then hit the register button, and our program then sends the info to our server. We validate it, and send back a response. The users program receives this response, and mentions that the product is registered.

One added benefit this has as well is that the installation simply needs to launch the program when it's complete. This would launch the registration window, and after registration, it takes them straight to the program. Your solution would have to have them manually check their email and then manually load the program.

After that, our program loads in it's normal fashion. During this time, it checks for any new updates that may be available.

Again, these are just ideas to throw at you to help you out in determining what you need.

Edit: I just saw you need to only push updates to *registered* users. I'm guessing from that you may have some users who are just demoing your product, but haven't registered. So, you only want those who have registered to get the updates. If so, I'd simply just add a file or add a registry setting when a user registers. Then, I'd have your program check to see if that file or registry setting exists, and if so, then check with Update Service to see if an update is available. (The reason I'd have your program first check if that setting exists before checking with Update Service is that you don't want to add unncessary users to your Update Service user count, which could cost you big money). Also, when checking with Update Service, I'd also have Update Service also check against that file or registry setting again, just to make sure.

[divanova]

Hey Brad,

Thanks! Your way sounds much more user friendly and I am guessing that 9 out of 10 users would register with it (it is not pain in the butt like my idea :rolleyes: ).
The only thing I kind of want to avoid is the whole second application that needs to be written to connect to the server and validate the user registration. But on the other hand if I go with only adding a file/reg key to the user's pc on registration (during installation) how do I retrieve his/her data - email and name for example? This is valuable information to have for the marketing people. I guess I need to write something that would pull it out on the first update? ... Otherwise that would be my choice too, it would save me lots of headaches.

Cheers,
Dannie

[Brad_Peterson]

I'm a bit confused by what you are asking, but I think the answer is simply to custom build what you need.

It sounds like you need to collect their email address, name, and other info on registration. Well, when they register, they're connecting to your server, so why not have your program pass their other info like email address, name, etc. to you when it validates. Then, you can store that on your end in some database. That's what we do.

If you need to keep track of usage, that's a different story. But again, it's a custom situation, so you can build whatever you need.

[CChong]

If I understand your original idea, you have to write the following code:

a) As part of installation, write a custom dialog which offers

• A link to launch a browser to your website. This website will let end-user enter registration information

.

b) During Check for Updates, a custom condition (which you have to write in VBScript or java) is added to each update(s).

c) The custom condition is written in VBScript (or java). In this code, you will

• Prompt user to enter for the magic code received in the email earlier.
• Send this information to a web service on your website.
• Based on return code, show or hide the update to be shown to the end-user.

If the above is correct, I would like to share my thoughts here-

a) It is lot of work on your part to implement a custom condition in VBScript.
b) If you have 3 update(s) you will be prompting for the magic code 3 times.
c) Alternatively, during installation,

• Write a custom dialog to capture registration information. (Not through a website).
• Write a custom action to ping a web service on your server. The Web Service receives user information and returns the magic code. You really do not care about the magic code returned, all you are interested is whether the registration is performed.
• Based on magic code received, use Profile APIs to create profile for the ‘registration’. Please refer to the Update Service documentation for more information.
• At time of check for updates, create a condition against profile information. You can also choose to write a code value in the registry and author a condition against a registry value. If you use profile information, you can also get some reporting out of it. Please refer to the documentation for more information.

Other points to consider:

a) What should we do when the end user is not connected to internet? Or your web service is down for some reason.

b) If you do not want to write a web service, just capture the ‘registration’ and use the profile APIs to register 'registration' information with the agent.

c) Profile information is automatically sent to Update Service servers and retrieved through reporting.