Why not become a lifetime supporting member of the site with a one-time donation of any amount? Your donation entitles you to a ton of additional benefits, including access to exclusive discounts and downloads, the ability to enter monthly free software drawings, and a single non-expiring license key for all of our programs.

You must sign up here before you can post and access some areas of the site. Registration is totally free and confidential.

Not sure if this is the right place to post opinions on this stuff, bur, regarding the first video:1 - when you create a bridged account, I think it should say not only the site it is bridged with (in this case, twitter) but also the username. I can easily see a situation where you bridge an account with someone else's twitter account (which was left logged in on your browser).2 - I find the "bridge this external account with an existing YUMPS account" workflow a bit confusing, I do understand that you are trying to reuse the same login screen, but somewhere there should be an indication that you are logging in again to your <existing> yumps account. For example, what happens if I loggin with my facebook which is not yet registered, select the option for bridging with an existing account, and then login with twitter which is also not yet registered? I'm rambling, but the conclusion is that the whole process is a bit confusing and I'm not sure if it's very useful, since you can also bridge accounts after you logged in with the existing account and go to account management.

Regarding the second video, I see that you request a password for changing the email. But from what I understood, it is possible that someone did not create a password (because they logged in with a bridged account). What happens then, the user has to create a password?

Also, on a related matter, when a user creates an account, she must specify an email and a username. While I can see that this is useful for forums and other stuff, in a situation where you just want to differentiate users, giving a username and an email sounds like an overkill. I'm thinking of a blog, for example, where the user is required to login to comment on articles. But more complex examples could be found: for a forum, you could allow people to create new posts without requiring a username and email (their username would become the same as the one from twitter, for example). I think people would be happy not to have to give their email to post. (obviously, the system should present some disclaimer saying that if they don't provide an email, they will not be reachable by the forum admins).

1 - when you create a bridged account, I think it should say not only the site it is bridged with (in this case, twitter) but also the username. I can easily see a situation where you bridge an account with someone else's twitter account (which was left logged in on your browser).

2 - I find the "bridge this external account with an existing YUMPS account" workflow a bit confusing,

well some of this is unavoidable, though i could split it into separate screens based on whether you want to:1. create a new local account2. create a new account based on a bridge to facebook,etc.3. login to your current account with local password4. login to your current account with bridge

I think the confusion you are seeing is because the login page will let facebook,openid, etc. users just click on their logo to proceed, whether they have an existing account on the site or not.

So if you click on the facebook icon on the login page, and you have already created an account bridged with that id, it logs you in. If you haven't yet registered, it will then let you register.

I think your biggest confusion was when i showed how you could connect the bridge to an existing account that you hadn't yet logged into yet in that session (ie facebook linked to account created with twitter). I could hide that option but the aim was to prevent people from accidentally creating 2 different yumps account, one for each login. Perhaps it can be refined. Perhaps the text on that link should say something like "WAIT! If you already have an account on YUMPS, don't click submit to create a new account, but click here to login with your other account and connect this bridge to that account."

I should note that it is quite easy and less confusing to add a new bridged account AFTER you are logged in (from the Manage Bridges) page.

Also, on a related matter, when a user creates an account, she must specify an email and a username. While I can see that this is useful for forums and other stuff, in a situation where you just want to differentiate users, giving a username and an email sounds like an overkill.

A very astute comment, and I agree completely. YUMPS is being built to NOT require emails or passwords (despite some of the screens), if the administrator doesnt want to require them to create accounts.

There are some sticky wickets with doing this and it involves some interesting choices, for example:

If you don't get an email for a person, you cannot send them a password reminder. If they log out or connect via another computer, and have forgotten their password, and all they have is a local account with password (not a bridged account), then there is no way to send them a new password and an administrator will have to step in and handle it on a case by case basis.

YUMPS is built so that you can let people create accounts and enter some areas before providing an email or password, but restrict others that prompt the user that they need to provide an email/password first. This addresses your idea about needing an email to post -- but i think it will be useful in other cases too, where you want to make signing up as easy as possible, and let the user modify their profile at leisure, but restrict certain actions to only after they provide a validated email.

The modify profile screen you saw that said the user has to provide their current password to modify certain fields -- that actually is only the case when the site has been configured that way -- it would not be required if the site did not require local passwords.

Currently when you create a bridged account you are prompted to create a unique username, which defaults to a uniquified version of your facebook/twitter username, etc.

I will be adding a feature that is a 0-step bridged account creation, which will be suitable for some sites. This is the kind of thing used in blog comments where you don't want to bother the user by asking them even just for their username -- where the yumps account creation is entirely automatic and behind the scenes, and the user never even has to worry about whether a local account was created for them (a unique username will be created automatically for them). Then on those occasions where the user is a regular site participant, if the user ever wants to they go to their site yumps profile and modify their info.

As you can see, the issues you are raising are EXACTLY the kinds of issues that YUMPS is meant to handle well. While user sccount creation and management is a small side detail for most web services -- it is one of the central focuses for YUMPS -- so I intend to make it better and more robust than anything else out there.

I will be adding a feature that is a 0-step bridged account creation, which will be suitable for some sites. This is the kind of thing used in blog comments where you don't want to bother the user by asking them even just for their username -- where the yumps account creation is entirely automatic and behind the scenes, and the user never even has to worry about whether a local account was created for them (a unique username will be created automatically for them). Then on those occasions where the user is a regular site participant, if the user ever wants to they go to their site yumps profile and modify their info

How about openid? You can add "myopenid API" which is also used on the stackoverflow, if that is what you want.

I think your biggest confusion was when i showed how you could connect the bridge to an existing account that you hadn't yet logged into yet in that session (ie facebook linked to account created with twitter). I could hide that option but the aim was to prevent people from accidentally creating 2 different yumps account, one for each login. Perhaps it can be refined. Perhaps the text on that link should say something like "WAIT! If you already have an account on YUMPS, don't click submit to create a new account, but click here to login with your other account and connect this bridge to that account."

Yep, that's what I mean. Notice that I did understand the whole process, but I'm pretty sure that a naive user would never be able to finish it. I agree, the problem may only be in the text of that option

I should note that it is quite easy and less confusing to add a new bridged account AFTER you are logged in (from the Manage Bridges) page.

Yep, I imagined so, that's why it seemed a bit overkill to have that "bridge this account with existing account" option, I'm not sure if that would happen much. Also, related to this, if someone did create another yumps account, is there a way to "merge" it (or bridge it?) with another existing one?

As you can see, the issues you are raising are EXACTLY the kinds of issues that YUMPS is meant to handle well. While user sccount creation and management is a small side detail for most web services -- it is one of the central focuses for YUMPS -- so I intend to make it better and more robust than anything else out there.

Also, related to this, if someone did create another yumps account, is there a way to "merge" it (or bridge it?) with another existing one?

There is no "merge" function implemented, or on my near term horizon for now.

HOWEVER, this is exactly the kind of scenario that prompted me to write the full fledged "Bridge Management" area. From that page you can see that users can temporarily disable/enable their bridged logins, or remove them from an account.

So let's say created two YUMPS accounts, one bridged with facebook, and one with twitter. And you decided you only wanted one of those accounts and to have both twitter and facebook log you into that one account. You would log into the other, delete the bridge to your twitter account. Then you could log into the account you want to keep and add the twitter account to that one.

I'll have to give some more thought about whether it makes sense to have an explicit merge function..

I also need to implement some functionality to let users delete accounts -- I haven't done that yet. Deleting accounts is one of those things that is a lot trickier than you might imagine -- because if you have content on the site authored by someone whose account is deleted -- how is that handled? Most of the time it makes sense to "virtually" delete account: mark them as deleted but leave their record in the database for content that is linked to them. But then with some accounts that have not created any content that is overkill. And then there is the issue of whether the user should be able to delete their own account or if/when a moderator has to approve the process.

I also need to implement some functionality to let users delete accounts -- I haven't done that yet. Deleting accounts is one of those things that is a lot trickier than you might imagine -- because if you have content on the site authored by someone whose account is deleted -- how is that handled? Most of the time it makes sense to "virtually" delete account: mark them as deleted but leave their record in the database for content that is linked to them. But then with some accounts that have not created any content that is overkill. And then there is the issue of whether the user should be able to delete their own account or if/when a moderator has to approve the process.

I guess this depends on the "EULA" of the site. If the site owns the contents that the user posts (which for me is the option that makes sense), the user is only entitled to disable his account, preventing any contact from the site, removing her personal details and making her profile inaccessible. If, on the other hand, the user retains ownership of the content they post, then they should be able to remove it. However, for me this does not make much sense: once you've said something, you can't take it back, posting online should be similar.

Here's another related question: can users change their ID? I know it's very infrequent, but I've seen it happen here at DC a couple of times, hence the question.

This is again one of these things that is technically trivial -- the only issue is whether it is confusing for members of the site to see a user name/id change. So this is something a site builder would have to decide if they want to allow or not.

And here's another question/suggestion: It seems to me that the login screen sort of ignores the possibility that you are logging in to get back to some other page. I find it very annoying when I click a link on a site, it asks me to login, and then takes me to my profile in that site. Also, sort of related to this, I love the way sites such as deviantart handle the login: you can login via a javascript/whatever window, and carry on the same page you were before.

And here's another question/suggestion: It seems to me that the login screen sort of ignores the possibility that you are logging in to get back to some other page. I find it very annoying when I click a link on a site, it asks me to login, and then takes me to my profile in that site. Also, sort of related to this, I love the way sites such as deviantart handle the login: you can login via a javascript/whatever window, and carry on the same page you were before.

In fact YUMPS is very good at remembering where you wanted to go -- so if it redirects you to a login page it will automatically bring you back to the page you requested after you log in. Things like this -- and it's good you are mentioning them (keep them coming)! -- are exactly what YUMPS needs to be great at.

[yes, a nice popup window to login might be even better, i'm just not worrying about visuals and gui niceties at this point].