Scrivs 30 Aug 05

I will always take an username/pasword over an url that I cannot remember or have to bookmark just to get to. Although I already have enough usernames to keep track of I would probably simply use one that I have been using for the past couple of years.

Besides, 10-15 chars is much easier to remember than 15-30 chars.

Bryan Fillmer 30 Aug 05

It seems to be a good practice. The biggest problem is that you are going against many years of ingrained behavior, that is, we are all used to creating usernames and passwords. While that is no good reason to continue with a flawed system it is a rather large bump in the road to overcome.

One way that I do see it as being very effective is when used for something business related that you share with others, much like Goovite. When someone recieves the e-mail with the link they always find it easier to click the link than to click the link, then check the email for the username and password.

Essentially I believe there is still a place for both systems, depending on what it is the app is trying to accomplish and by what methods the average user is arriving at the app.

J 30 Aug 05

I think there are two kinds of possible app-less web-apps:

First, there is the app that could remember your personal details for you and thus help your user experience.

Second, there is the app that has no personal details to remember.

The goovite seems like the second kind: the unique url builds the page and when each user arrives, there is no personal info that the app needs to store for them.

But let’s say a certain page had chunks of content that you could individually select to have emailed to you. It would get inconvenient to have to input your email all the time. So if the app saved that info for you through a username and password, that would help. Of course, you can in this case also increase the user’s experience by remembering their email with the help of cookie-based session tracking, so they don’t always have to login.

David 30 Aug 05

I agree that both systems have their advantages. I still find accounts handy, especially ones on sites like evite that aggregate information: my evite account rolls four email addresses into one and gives me a handy summary of everything to which I’ve been invited. If I say, “What’s the evite I got the other day?” I log in and view them all—this is easier than having to dig through my inbox to find the email to click on the link that brings me to the right event.

That doesn’t mean “app-less” doesn’t have its place. Take, for example, the file sending site, like Dropload and YouSendIt: for one-time use, sending a URL and not requiring login info is ideal. For an information disseminator, though, being able to store and recall that information certainly retains merit.

Mike 30 Aug 05

Username and password are fine, I have a default set I use for sites where security is not a big issue. The problem is when the registration form wants to know your address, phone, 2nd cousin thrice removed, and a whole bunch of stuff not at all related to the needs of the app.

So, username and password, no other non-necessary stuff please.

Scott 30 Aug 05

Stop putting the onus on me! It is one of the most irritating aspects of living life online that I have to remember dozens of usernames/passwords, very few of which I can recycle due to the constraints of the systems (e.g., at least 6 characters, no more than 8 characters, must contain at least one non-alphanumeric.) Bookmarks are nice because I don’t have to remember anything. I’m not sure why people wouldn’t prefer them… I thought that’s what they were for.

The only disadvantage I can see is if you are at a different machine that doesn’t have your bookmarks. How about an “Add to your del.icio.us page” or a similar button that I can just press? Or “Match this account to this IP” if I am someone who never switches computers? Just thinking out loud here, but there have to be better ways.

Jason Gilstrap 30 Aug 05

A think the app-less web application has its place only when an instance of the application would be used once or a small number of times. For instance, with an online invitation users would not frequently return to edit the information.

However, for most web applications I think it’s best to use an e-mail address and password to log in to the account. For an application like Writeboard, which of course we don’t know too much about yet, it seems you would want to easily return to edit a document multiple times. If I lose the URL then the document is gone forever. Therefore having a traditional account seems best.

On the other hand, why couldn’t you have both? By default the application uses a URL but users have the option of creating an account and adding the URL to that account.

Jason Santa Maria 30 Aug 05

Username and Password, hands down. More times than not I end up using one of the same few usernames and passwords I use for other things. So, the amount of “work” on my end is negligible. But, when it’s a URL that no one can easily guess or remember, you are introducing an unnecessary middle-man into the equation. My usage of the app-less web-app is then tied to another product, be it my browser (for a bookmark) or my email (for the email confirmation).

tef 30 Aug 05

What stops people from implementing both?

You give people out the horrible long url.

If they want to sign up, they can and then they can find the information without having to remeber the full url.

You can have it both ways :)

tef 30 Aug 05

P.s. You should look at openid as an alternative method of authentication.

So people don’t have to rememeber a new username/password

Platte 30 Aug 05

This app is an extension of email. Its URL-only implementation makes lots of sense to me for this functionality: a fancy “reply to me if you’re coming”. So what if an email transaction requires the email client?

It would be a lot slicker if only the email confirm could be eliminated. Curse spam! To remedy that, I agree with comments above that a both-and approach could work great: adding a cookie and/or login could remember who I am. But by starting with this simple idea, the design and concept are sound.

Thanks for posting this link, I think I’ll enjoy using Goovite.

Richard Spindler 30 Aug 05

I believe the concept is quite nice especially if you want to email people to do some stuff on that web-site, you just mail the link, instead of explaining: “you have to type in the following username and password, ….blablabla”

Stephen 30 Aug 05

I’d say stick with the username and password. If you have an “unguessable” URL then you are negating the biggest feature of the web - it’s accessible from anywhere. Some people download their mail with POP still, so there’s no guarantee they can look up “their url”, which is a de facto password anyway.

Better let them choose their password. My bugbare: if you are using their email in the app, always make that the login username, as everyone can remember their email address, and it’s unique. I have too many usernames.

Jamie Stephens 30 Aug 05

I agree that there is a place for both the URL and the username/password and that the two don’t have to be mutually exclusive. I think this is a good case where you let context be the key.

I think the URL is handy when (as Jason Gilstrap mentions) the application is only going to be used a small number of times or (as Bryan Fillmer mentions) you are directing others to something through an e-mail. If someone is clicking on a link to a site in an e-mail they have received, then why make them log in too? We know who they are since we sent the e-mail to them, so we should save them the trouble of having to click the link in the e-mail AND logging in (sure they can share the e-mail and compromise the security of the model, but this rests on the assumption that e-mail for individual is secure unless shared - the same assumption made about username/password combinations).

However, in the event that they do not have access to the link, there should be an alternative way to log in with other credentials (i.e., username/password). I like it when I receive an e-mail confirmation of a purchase, I can click on a link to view the receipt online, without having to login. However, if I am at a different computer, then I can typically log in to my account and view the same receipt (and other receipts).

In the end I like the idea of using a username/password for long-term management and having a URL as a convenient supplement in places such as e-mails. In the case of small apps like Goovite, I have no problem with just the URL as I don’t plan on managing it long term.

Charbel 30 Aug 05

I like having a URL to send out. It makes it really easy that way, and I can always bookmark it for later retrieval.

These types of applications may give rise to a new set of applications that revolve around bookmarking.

However, there are instances when personal information needs to be secured via username/password, but in this case, there is no need. Thumbs up to Goovite…Catchy name…

Philip King 30 Aug 05

I like the idea of going to a url, for applications that do not hold personal information.

I know personally that I would not remeber the URL; so a simple reminder sent from the website in question would be nice.

Scott Meinzer 30 Aug 05

I think both would make sense.

That way if I am planning on doing something once I get a quicker set up time on that cause I don’t need to create an account.

But if I later decide I might want to edit it; I should be able to add it to an account. And from my account I can login to get a list of all my information. (I am surprised that their isn’t any true open passport type system for stuff like this; well I guess there is typekey, but few have integrated that into their apps).

Speaking of Writeboard. Did it die? I remember reading blog posts like 10 months ago that is was coming soon….

Kris 30 Aug 05

I agree with tef. Use both!

Also in e-mails relating to the app or service use the URL to auto-login instead of the usual ‘Click here and enter your username and password to login’

Security?

Well, most web-apps and services are happy to send your password via e-mail so what’s the difference?

Obviously, this wouldn’t be advisable for high security sites/services (e.g. Online Banking) until the widespread adoption of a secure e-mail system

Dan H 30 Aug 05

You guys already have a great dictionary for random word combinations. If you generate a URL similarly to how you generate the email addresses for backpack, you have [random word][random number][random word]@[my username].backpack.com; Just remember Psych 101’s 9-Things (+/- 2) rule. …that email address is ~6 fairly safe items to remember. The link on the page and auto-complete in my Mail.app helps, just as bookmarks help with links to web pages. But if I want to remember things in my head, for each of my 5+ pages, it could start to suck. If you take the username out of the URL, links sent to other people look less personal, and that has disadvantages. Finally, random words do raise some questions for some people: “Why do I email to monkey28hotpink, again?”

My vote would be something like this: [a word i choose].writeboard.com/[a number you generate].

I choose the sub-domain each time, it could be “dan”, “danh”, “acme”, “widgetproject” or “myparty”… anything that’s meaningful for the writeboard whatever-it-is-it-does thing. As I use the app, I might want all mine to be dan.writeboard.com/[a number], and just remember the number for each thingie I have. Someone else could have things at dan.writeboard.com, as well.

Sigh, back to my real job now.

Aaron Gustafson 30 Aug 05

I think it is important to keep the user in mind and, in this day and age, if a site contains any personal information, people feel more secure knowing it is “protected” by a username and password. Of course, how many of those people check to make sure they are logging in securely (Yahoo still defaults to http for login instead of https for example)?

I think in the realm of apps which store nothing about you, it’s a toss up. Usernames & passwords are good if you use multiple computers. Of course, if you use multiple computers, why not buy a USB stick and install Portable Firefox on it? That way you can bring your cryptic bookmarks (and any stored usernames & passwords) with you wherever you go.

I think a lot of it comes down to convenience too. Maybe when we all have next-gen smartphones or some other convergence device, we will always have a browser (or whatever they develop into at that point) with us. Some people do this now with their Treos or even their iPods, but I wouldn’t call it a movement… yet.

Ryan Kuykendall 30 Aug 05

If the app you are creating follows some kind of invitation model (ie., it allows users to mail out unique urls so that others can use/share them) you could just store a mapping of unique URL identifiers to email address. If a user ever deletes the original email that was sent to them, they can just go to the website, enter their email address, and have every URL ever mailed to them sent in one batch (with perhaps the email address of the person who sent them the original URL.)

Amy 30 Aug 05

I suppose it depends on your audience, but I think ID and password is the safest way to go in many cases.

I’ve run into this with web conferencing. My company was ready to switch to Breeze, which uses a URL for their meeting invitations/security. However, we have found that most people gather with their colleagues and attend the meetings from a conference room, where they don’t have access to their email. It’s much easier for them to go to our simple to remember WebEx URL and join with a 6 character password, than to print out an email and try to enter a long, purposefully complicated, URL into their browser.

Daniel Lakier 30 Aug 05

There is no reason you cannot do both.

From a security perspective,however, the URL approach should include an encrypted version of the userid and password, rather than some random combination of words - that is fairly weak encryption, and can also easily be stolen.

Our systems send a confirmation message to users upon password registration or change which includes a link to their account including their credentials encrypted and munged into the URL.

We never expect users to memorize the munged url, rather, if they are accessing the application without using the email we sent them, they are challenged for their credentials at point of authorization.

Our authorization algorithm examines the querystring, determines if their is (valid) encrypted userid and password. If there is, it attempts to log in using them. If no credentials are supplied, or the authentication agent rejects the credentials, then the login screen is displayed.

-Dan

David Ely 30 Aug 05

I prefer username/password, but please, please let me use the same one for all my 37 Signals accounts, and let me log into one of them and stay logged into all of them.

JF 30 Aug 05

please let me use the same one for all my 37 Signals accounts, and let me log into one of them and stay logged into all of them.

If you have a Backpack account you’ll be able to pull your Writeboards into Backpack so you won’t need to remember the URLs or any additional username/password combos.

Benjy 30 Aug 05

My vote is for login/password. I agree it’s a pain when the registration asked for a bunch of extra info, but I’d rather have a login/password so I can access the info anywhere — even if I don’t remember the url to the event or have access to the email with the link.

dtb 30 Aug 05

I think both should be offered. I would rather have user/pwd, because I am used to that and do not mind using it.

choonkeat 30 Aug 05

Personally I hate frivolous login+passwords… always gives me the creeps its yet another weakest link to have my other accounts compromised (critical or not, a compromise is still major hassle)…

And for the record, I’m experimenting and trying my best to keep a login-less system for www.rssfwd.com - each user still gets unique urls to manage their subscriptions (xslt+opml) all without login. Trying to see how far I can go without compromising.

Travis Schmeisser 30 Aug 05

I agree I would also prefer username/passwords anyday, but with how I’ve seen clients of my company work I know they can barely remember that info (which they usually ask me to set to something specific for them). So they end up reverting to an email I’ve sent them with that info anyway even though they gave me the original info in the first place.

The less-savy woudln’t even notice and would be fine with going to an email to retrieve there url while people like I would imagine everyone reading this is - would find it easier to use something we can remember.

Bob Aman 30 Aug 05

Username and password, definately.

It may be a flawed system, but every other system is flawed too. The bookmark system is a lot more inconvenient. Imagine: What happens if you don’t use GMail? What if you habitually delete your email if it isn’t from friends. Well, poof, there goes one reference to the encrypted URL. What if you have to reformat? Oh, there goes the bookmarks. Possibly the e-mail too if you aren’t using webmail. What if that magic url pointed to something I actually considered important?

What if I’m on another computer and I need access to the site? I mean, heck, isn’t that at least half the point of these web-based apps?

Gotta say, lack of some kind of username and password for any web-based app is a huge deal-breaker for me.

Bob 30 Aug 05

Give me the cryptic URL; Google/Gmail/Desktop search will remember it for me and track it down if I need it again. Most times, for an Evite, I never need to visit the page again.

Brad 30 Aug 05

another problem with URLs that I don’t think has been mentioned yet:

An cryptic URL is likely to be fairly long, which means it will wrap over several lines when sent by e-mail. For email messages formatted in HTML, this is no problem, but some email servers convert all incoming e-mail to text-only. This is true for some of my government clients, for example. In those cases, long URLs that span several lines tend to be un-clickable..you have to copy and paste individual sections of the URL into your browser. That’s a major pain, and may be a roadblock for some users who can’t figure it out. You’d have to use tinyurl or some similar service to get around it.

topfunky 30 Aug 05

Microsoft’s start.com (can I mention that here?) has a cookie-only no-login config. It’s a little weird to click “Login” and then see the same page.

Ruminator 30 Aug 05

Isn’t that what URL123 (TinyURL, etc.) are for? For one off things that don’t need editing, I don’t see a problem with embedding everything in a url.

Peter Boothe 30 Aug 05

URL hands down. Allow people the option of creating an account, but with a URL (and it doesn’t have to be that complicated and long - check out tinyURL for how small you can get away with) you don’t have to give up some privacy to participate and add value to the system. Fewer clicks to use means more users.

James Spahr 30 Aug 05

I would keep the beginning part of the url rememberable/guessable and let my browser’s autocomplete (from history or bookmarks) help me fill it out.

I think for non sensitive info indented for sharing with a select group of people, getting rid of the username/password is might be okay.

Drafting an email that says use this username and this password is always clumsy.

Dan Boland 30 Aug 05

It’s been said numerous times, but I’ll also chime in and say “do both.” The u/p could be a backup if you don’t have your e-mail or bookmarks available.

pwb 30 Aug 05

You can.

No, you can’t.

Re: URLs vs. accounts: I think the organizer may feel more comfortable with an account since it implies more stability. But the invitees shouldn’t need to create accounts.

And amen for putting the event information in the friggin email!!

Jamison 30 Aug 05

I’m in the “why not both?” camp as well.

For something I use once or twice or very infrequently creating a username and password is a bit of a hassle and I’m just as likely to loose my password as the e-mail. I’m actually more likely to lock myself out of a username and password, since my bookmarks are accessible anywhere via .mac and my remembered passwords are specific to the mac I saved them on.

I’m less likely to use an app that requires a username and password seeing as I already get enough spam.

I’m not saying anything about your apps, but the web in general, and often these setups are so long and involved it’s quicker just to do what I need to do in meatspace instead (Fandango is a great example: when it first started there was no password and it was very quick, now the buying movie tickets to them involves several screen, being offered magazine trial offers, etc…)

Adam DuVander 30 Aug 05

I’m guessing the folks who tell us to “Get Real” would say the same thing to those who suggest both login-based and address-based verification.

For an app like Goovite, I agree that it’s not a pain to go back to the email each time I want to visit a particular invitation. Craigslist uses this method.

For something where I maintain a profile or I otherwise need to visit often without jumping into my mail, usernames and passwords seem the standard. Craigslist also does this. They might be a good example of a simple blend of the two.

And I bet the 37 Signals guys love the CL interface. (I’m being facetious).

JF 30 Aug 05

No, you can�t.

Yes you can. Go to Backpackit.com and click the “Login if you have an account” link in the bright yellow bar under the sign-up box.

Su 30 Aug 05

Mmm, I’ve got to back pwb here, anyway. That’s a single five-letter link in ~3 screens’ worth of marketing, in a smaller font size than even the smaller copy immediately above it. I also don’t think it’s much of a nitpick to point out it’s _inside_ the sign-up box. I wonder how many people are immediately ignoring that entire block due to the giant red SIGN UP above it.
Why is this not in the top nav?

In the same vein I just today found the link for Everything Basecamp. The only reason I knew it before was because you’d linked from SVN.

Brad 30 Aug 05

Have you considered secure certificates? I know these are more for enterprises (are they?), and before I used them I hated them because I didn’t understand them. But now it is quite easy (although not portable unless I have the p12 file saved on an accessible server or webmail).

After I’ve installed the certificate on my browser, all I have to do is click login and the process handles itself.

Did you guys ever consider this? I’d be curious to know your thoughts on the usability of certificates.

Eloy Anzola 30 Aug 05

… I made a mistake earlier…

It is possible to login to backpack from Backpackit.com. I meant basecamp.

Anonymous Coward 30 Aug 05

“Mmm, I�ve got to back pwb here, anyway.”

Back whoever you want, but JF is right, you can log in from the Backpackit.com home page. As for the link being like 5 words, would you prefer it to be 4 paragraphs? It’s also in a bright yellow bar.

neil 30 Aug 05

As someone who has listened to his parents, girlfriend, siblings, and friends not as technically-savvy or computer-centric as we are complain bitterly about “another damn password to remember”, I say URL.

Every single person who commented on this post probably has some system for remembering login passwords. “Regular” people (and I mean people for whom computers / the Internet / etc. isn’t a key part of their lives) hate them, or use unsafe methods to work around having to remember them.

Personally, I’d love to see a company dispense with the archaic username / password system and create something that’s actually user-friendly… like getting users to choose from a set of photos (of faces, maybe?).

For all of the innovation that’s happening out there, authentication is definitely something still mired in the past.

Dan Wick 30 Aug 05

RE: Unique Goovite URLs

What happens when search engines start indexing the “expired” event URLs which include all of the emails of people who have responded and event details? Is there something that prevents these pages from being indexed or do they not really “exist” like other pages do?

I am in the “do both” camp. The clean URLs would act as short-cuts to places inside and auto-log the user in. This is where the Google indexing of URLs problem would come in. Anyone who found a Goovite URL could log into the system.

Maybe I’m missing something…

Jeff 30 Aug 05

As someone who uses a public (lab) computer occasionally (when I don’t want to be bothered to carry my laptop with me, and can easily fit all my working files on my iPod shuffle), I think that obfuscated URLs are a very, very bad thing. I can log into my backpack because I have an easy set of information to remember. Sure, I could put the cryptic URL on my backpack and go from there, but it’s just another layer, instead of allowing me to use the tools I’ve got always at the ready (my brain and my fingers).

Usernames and passwords are well understood, safe, secure, and take advantage of the existing infrastructure (that is, me).

Plus, they give me, the user, a sense of control (since I choose my own) rather than giving all control to the system (who am I? 24601?). When in doubt, make it more human, not less so.

qwerty 30 Aug 05

login vs. url: go with the login but use an user-provided email adress for the login. It’s unique, each user already has one, and it’s the place where you send the forgotten password and everything else. You can use cookies for automatic login.

Pete Prodoehl 30 Aug 05

Just adding to the ‘both’ camp, I built an app that sent out unique/cryptic URLs but also provided a way for people to log in using a username/password. Best of both worlds, as long as it doesn’t cause confusing with the users…

Dan Lakier 30 Aug 05

Just a quick note of warning with regards to URL based systems - you want to make sure that they are as secure as passwords and change when users change their passwords.

It is generally a good policy to change passwords periodically, and by that same token, the URL should change when you change your password, or if you only use URL authentication, then via some other process.

That is one of the reasons we use encrypted credentials as part of the URL instead of an arbitrary cryptic url.

Loser 30 Aug 05

For the app described, I would prefer the URL way. Desktop search, bookmarks, history, autocomplete, whatever it is , the account deets are close at hand and not in my poor addled brain.

Patrick Smith 30 Aug 05

Why not do both and let your users choose the one they prefer?

My preference for one over the other would be so context or application specific that it’s impossible to answer the purely theoretical question.

Be interesting to do this as a series of A-B tests tweaking the implementation.

You should be able to get a pretty good idea of the pros & cons after testing it out both ways in a couple different incarnations.

Radha Mukkai 30 Aug 05

I am for the encrypted URL. Whenever a site asks me to register, I simply move away. Username/password are very tough to remember (and it usually ends up on a text file on your desktop). With the encrypted URL, I can easily add it to my Favorites and am ready to go. My 2 cents.

Ben Askins 30 Aug 05

How about let us sign in using our .NET Passport? Just kidding…

I like the idea of a first use login with username and password after which I can use a unique URL on any machine that I’ve logged in from before. Use a cookie or certificate or some “thing” that is downloaded to the client machine after the first login, and from then on in the unique URL is authenticated against this “thing”.

Nate 30 Aug 05

Definitely go with the user name and password method. I just don’t think that it’s such a big deal. Users who have problems with remembering their passwords are going to have a problem remembering any piece of identifiable information, so we cannot try to work around them.

Evan Wired 31 Aug 05

Sanity check: We’re not really talking about “security” here as much as we’re talking “configuration shortcut” or “unique location of a resource” whose access we don’t mind trivially sharing, right? Because hiding behind a funky URL is security through obscurity and, for any system of non-trivial value, that’s the kind of scheme that gets people fired.

Some things just shouldn’t be bookmarkable, or spiderable by a robot, especially if the URI represents the state of an application. Other things really need to be, since they are idempotent. I’d expect some kind of consideration at the server side to keep Googlebot from visiting the invitation to my secret party if I happened to have the URL in my Gmail account, for example.

If you really want to eliminate all of the repeated hassles of passwords and credentials and obscure URIs, look into personal certificates. I’d imagine that certs, in combination with some kind of federated identity (the old “web of trust” from PGP) and a better portability (thumb drive, for example) could be made into something viable. If you use Verisign’s MPKI service (which you get roped into once you need more than 4 SSL certs at once), you’re issued an ID cert for your browser(s). You then can access the MPKI workbench without needing any manual credentials or any weird URLs. It is nice, though not exactly a “one-click” installation yet. I’ve used personal certs for a couple of web services APIs as well; the service issues me a cert and I connect to the service over SSL using that cert without need of any credentials in the request.

What you’d want to do, I’d think, is offer multiple levels of security depending on what you’re trying to accomplish. If you just want to be able to point someone to an instance of an application or resource with state intact, make your URI scheme sensible and take precautions against user agents you don’t want to see the app. If you need to do basic authorization (affirming that this requestor can see this resource), ask for an easy to remember token that must be presented (like the ticket number in Kayako’s eSupport system). If you require authentication/identification as well as the other items, set up whatever credentials mechanism (username/password, whitelisted email address, OpenID, certificates, SecureID token, whatever). Keep them all decoupled — they serve different purposes.

The amount of security you employ should be appropriate for the value of the information you’re protecting plus the costs (monetary, computational or user-effort) you’re willing to invest. The invite to a party, no big deal. My files in Basecamp pertaining to Client Project MK-Ultra, big deal.

And “app-less web app?” Yuck. Rarely should any team inflict its internal shorthand on the general audience.

dave 31 Aug 05

If you have a Backpack account you�ll be able to pull your Writeboards into Backpack so you won�t need to remember the URLs or any additional username/password combos.

What if you don’t have a Backpack account but want to have several Writeboards? Guess I’ll have to wait and see… :)

Jens Meiert (of UITest.com) 31 Aug 05

It is best to keep it simple, and cryptic IRIs are not simple. From my experience - and from others, too, as I understand other replies here -, both approaches might work perfectly.

Tomas Jogin 31 Aug 05

I’d prefer username/password, I think. However, I prefer emails over usernames. Having to pick _another_ unique username for _every_ account enabled website is a pain in the ass. Please, just let me sign in with my email address, it too is unique and I don’t tend to forget it.

Brad 31 Aug 05

With the certificate you can take it with you or store it on you web mail then install/unistall as needed. One certificate could contain your authentication for all 37 signals accounts (if you wanted).

Portman 31 Aug 05

[+1 vote for username/password] Re: BFillmar’s post— ‘ingrained behavior’ = familiar, which is a good thing. Only change ingrained behavior if the benefits outweight the switching costs (i.e. QWERTY vs Dvorak).

Alipasha 31 Aug 05

My 2 Cents, while pretty much all have been said:

If you want to have the benefit of a one-time-id-number but are used to email/password, or the service you request espects an email address, then give Mailinator.com
a try.

BTW: I vote for an email-address/password feature

Rick 31 Aug 05

Logging into Flickr over and over because it won’t remember my Yahoo(!) id is getting really annoying. Flickr doesn’t even seem to let me browse without the login/pw.

URL favoriting works great and I have 5 computers that I rotate on.

Gmail access from anywhere - I can go back and get that URL from any email on any computer.

Brad 31 Aug 05

But what about browser history? Do you have to manually erase the history if you want to protect the content?

Jay 31 Aug 05

This is an interesting idea. However, i think the idea may be suitable for scenarios where the security is not a big concern. By using only the URL, the user is confused (has to memorize or bookmark the URL), the page is accessible by any dick and harry. It is a neat idea, no doubt, but not suitable for general adoption.

Personally, I have always had issues with usernames and passwords. Different domains have different policies and I have to create a new password everytime. Recently, I was thinking about the possiblity of starting a web username/password directory where users can create a unique username/password and websites can use the repository as a �certification authority� before they are allowed to log in to the respective websites. I admit my idea may need some fine-tuning but it may also be a step in the right direction.

Gerd Riesselmann 09 Sep 05

Sorry for beeing late - and maybe what I’m about to say was already mentioned above and I simply oversaw it.

Anyhow, I wonder why the URL necessarily has to be cryptic? Why not let the user choose one itself?

For example given the Goovite not-so-appy web-app. If I’m about to invite a set of people to my birthday party, the system can offer me to choose an unique path, like “gerds_birthday”, so the URL would be www.goovite.com/gerds_birthday”. This is simple to remember.

Of course the choosen URL must be unique, so this has to be checked.

There however is a drawback: This approach can decrease the user experience, since it simply is annoying if the inivitation is denied over an over again because of URLs beeing already in use (which surely will happen for terms like “mybirthday” ;-) ). For this reason, the application should come up with some reasonable alternatives in the case of a duplicated URL, which can be build by some common patterns like already mentiones above. Like name_date, e.g. Using ajax-magic, this even can be done immediately during typing before even commiting an invitation.

To free up the available URL space, used URLs should also be removed as soon as possible, e.g. two weeks after the event has taken place.

thomas hopkins 12 Sep 05

brill good work

same name 12 Sep 05

ghuygtrysdhwieg8sdgbejg87tfdbsugfsdgbhuywegeibitntgihtkhikpo0emnssygamosjlkeoijknhiuhghgihngkhigkhsifngdhvgujbgjoibbgijfvhoidgbjhjgkfgthuiygff

suntan Technology Limited company 16 Sep 05

offer capacitor