The next step for browsers! (yes Safari, I'm looking at you)
Hidden Hypertext Transfer Protocol.
The browser adds the http:// in the background, so it's only actually necessary to type from the www and onwards when entering a URL. And when a domain is typed in with the Hypertext Transfer Protocol the browser automatically hides it when loading the site. The user soon realizes they no longer need to waste time typing it in.
And yes I am aware you can get to Apple.com for example by typing only apple in the address bar, but the point here is to deliberately hide Hypertext Transfer Protocol from the users view. You enter apple, you see www(dot)apple(dot)com and not http(colon)(double-slash)www(dot)apple(dot)com
Discuss.
The browser adds the http:// in the background, so it's only actually necessary to type from the www and onwards when entering a URL. And when a domain is typed in with the Hypertext Transfer Protocol the browser automatically hides it when loading the site. The user soon realizes they no longer need to waste time typing it in.
And yes I am aware you can get to Apple.com for example by typing only apple in the address bar, but the point here is to deliberately hide Hypertext Transfer Protocol from the users view. You enter apple, you see www(dot)apple(dot)com and not http(colon)(double-slash)www(dot)apple(dot)com
Discuss.
Comments
If you really need to have it, you should be able to do it already using Apache's URL rewriting. Nothing new required.
It hides the fact that are there are different protocols from the user, which can lead to more confusion when they arise. How do they know that a connection is secure? - https:// How do they know that an image might be about to be mounted on their filesystem? - ftp:// How do they know they are reading some RSS news thingy - feed://
If you really need to have it, you should be able to do it already using Apache's URL rewriting. Nothing new required.
Exactly! I always check for the 'https:' when I think I am connected to a secure site. I would not like to lose that.
It hides the fact that are there are different protocols from the user, which can lead to more confusion when they arise. How do they know that a connection is secure? - https:// How do they know that an image might be about to be mounted on their filesystem? - ftp:// How do they know they are reading some RSS news thingy - feed://
If you really need to have it, you should be able to do it already using Apache's URL rewriting. Nothing new required.
Yes, I get you. I am aware there would be issues like this, but there are ways around all issues. It's about thinking outside the box. Apple is good at that.
As for "if you really have to have it", that's missing the point I'm making. It's about all users having it, a new system becoming a standard in order to make things simpler for all users, particularly non-technical people.
It's about getting users to the www(.)apple(.)com stage of simplification. Tim Burners Lee has on numerous occasions publicly stated how he regrets the Hypertext Transfer Protocol being a bad design idea from a easy to use stand point. It didn't need to be this complex. In 20 years it won't be done this way, it will evolve and change. I'm just proposing ways to evolve the way things are done.
It easy to say that wouldn't be a good idea because of this, but I kind of look at it in a different way. I think differently about it. I think these are hurdles, and we can get over them to get to a place that makes sense for all users, while making the whole process less complex. Thinking outside of the box would be the start of that process.
In the mean time for cases like https: ftp:// & feed:// they could show when they are present. That would be one way, but I'm sure there are many other solutions.
Also, as you've already mentioned yourself, user input of "http://"; is not necessary. Those that are lazy or not technically savvy can ignore the "http://".
And finally, the display of the protocol IS important technically because browsers do not just call one protocol.
There is a padlock that displays in the upper right corner of the Safari window when you are on a secure webpage. So even the https:// is unnecessary.
That's browser specific though. Even if it wasn't, how are website developers supposed to link to a secure site? They can't use a single domain name because it wouldn't know what you want to use.
For example, go to http://www.google.com in Safari. Then go to https://www.google.com and you see how Safari behaves differently. Linking to just www.google.com wouldn't work. Hiding it as a standard relies on developers complying with that in links too, which means changing every website developer package.
Unlike ftp and http, https isn't actually a different protocol, it's just an encrypted http connection to the same site.
URLs aren't all that complicated for people to grasp. If anything, I'd say more people are confused about the www prefix or suffixes that aren't .co.uk or .com. As soon as you say a site that doesn't have www at the start, they get confused as some sites work with www in front and some don't. There can be two different sites with the same general name but different ending
www.PenIsland.com could be a pen shop
www.PenisLand.co.uk could be a porn site
and this confuses people.
Domain names could easily have been just single words like apple but then how do people know in marketing when someone is talking about a website?
I think overall the current URL scheme works pretty well. There are far more important things to be concerned about than URLs like how to ensure that browsers are forced to adhere to a single web standard while not holding back functionality.
That's browser specific though. Even if it wasn't, how are website developers supposed to link to a secure site? They can't use a single domain name because it wouldn't know what you want to use.
For example, go to http://www.google.com in Safari. Then go to https://www.google.com and you see how Safari behaves differently. Linking to just www.google.com wouldn't work. Hiding it as a standard relies on developers complying with that in links too, which means changing every website developer package.
Unlike ftp and http, https isn't actually a different protocol, it's just an encrypted http connection to the same site.
URLs aren't all that complicated for people to grasp. If anything, I'd say more people are confused about the www prefix or suffixes that aren't .co.uk or .com. As soon as you say a site that doesn't have www at the start, they get confused as some sites work with www in front and some don't. There can be two different sites with the same general name but different ending
www.PenIsland.com could be a pen shop
www.PenisLand.co.uk could be a porn site
and this confuses people.
Domain names could easily have been just single words like apple but then how do people know in marketing when someone is talking about a website?
I think overall the current URL scheme works pretty well. There are far more important things to be concerned about than URLs like how to ensure that browsers are forced to adhere to a single web standard while not holding back functionality.
Exactly. Couldn't have said it better.
Domain names could easily have been just single words like apple but then how do people know in marketing when someone is talking about a website?
I never said they should be just apple. As people say www(dot)apple(dot)com or apple(dot)com.
I think overall the current URL scheme works pretty well.
Tim Burners Lee disagrees with you then, and I so do I. There are always better solutions. Things will evolve. Thinking outside the box can help to get that ball rolling. Things always change, this won't be any different. There's always a better way, particularly when the existing solution is not so simple that it can't be made better. Try to have a more open mind, you could be surprised.
....Discuss.
Sounds like an assignment for a term paper!!
...Tim Burners Lee disagrees with you then, and I so do I. There are always better solutions. Things will evolve. Thinking outside the box can help to get that ball rolling. Things always change, this won't be any different. There's always a better way, particularly when the existing solution is not so simple that it can't be made better. Try to have a more open mind, you could be surprised.
I agree current URLology (heh) has many disadvantages. The worst is the HTTP GET where the hash like ab2938c29038d102938laksdjwlkjd is in plain sight. Also caching and hypertext concepts have not really been adjusted well to dynamic websites.
My idea would be how would URLs and other Internet Protocology (not proctology... heh I'm on a roll here)... Seriously, the new ideas in these areas would involve how people interact with websites as web apps or closer to desktop apps.
Of course, Adobe AIR, etc. are pushing in this direction. I never use twitter dot com nowadays, just Spaz. It is AWESOME. http://funkatron.com/spaz
Wow... URLology and Protocology LOL
I never said they should be just apple. As people say www(dot)apple(dot)com or apple(dot)com.
But it's equivalent. The protocol isn't there as eye-candy, it's a functional part of a URL. People tend to miss out the http:// in speech but that's why a browser lets you type a URL without it so there's no problem.
Tim Burners Lee disagrees with you then, and I so do I.
It's not really a matter of opinion that current URL schemes work. They drive billions of websites daily without major problems and have done for years.
There are always better solutions. Things will evolve. Thinking outside the box can help to get that ball rolling.
Things always change, this won't be any different. There's always a better way, particularly when the existing solution is not so simple that it can't be made better. Try to have a more open mind, you could be surprised.
But you haven't thought outside the box. You just don't like the protocol declaration and you haven't given an alternative. Hiding it from people cannot work from a functional point of view.
I agree current URLology (heh) has many disadvantages. The worst is the HTTP GET where the hash like ab2938c29038d102938laksdjwlkjd is in plain sight. Also caching and hypertext concepts have not really been adjusted well to dynamic websites.
This I would agree with to an extent but not entirely. Putting hashes in the PHP GET request isn't the only ways to do things and it's not particularly insecure as it's usually just your session id, which likely has a timeout and these can be stored in cookies anyway. Developers put them in your URL when you have cookies turned off in order to verify who you are. It would be nice to overcome the stateless nature of the http protocol reliably but session ids are what we have and as websites prove, they work so they are reliable enough.
I agree about URL schemes not working with say flash content. Apache just needs to be adjusted to handle flash objects better. I'm not sure the open source community behind it would really support a closed source plugin though.
This is why a more important consideration is developing a single standard that people have to stick to even if it's an implementation rather than a specification. For example, the KHTML code is an implementation of a standard that can be ported. OpenGL sort of but drivers will differ. Nonetheless, OpenGL works pretty much the same cross-platform.
I think they should just have some sort of byte-code OpenGL interface for websites. They would be hardware accelerated when possible so less CPU usage than intense Flash sites and they will work cross-platform. They might crash your OS when your drivers are buggy though but they'd even support 3D content. It wouldn't work for advanced gaming as you couldn't cache the data quickly enough but it would be good for architectural demos and just really fluid, unique interfaces that don't get bogged down.
It wouldn't hold back development because you can pretty much do anything with OpenGL graphics-wise that can be done on a computer. The interaction currently is with C-based languages but you get PyOpenGL which allows Python to interact with OpenGL. If they made a web-based library module for Python that simplified the language for website developers, javascript-style then it might work.
Or they could use Perl OpenGL:
http://graphcomp.com/opengl/
I personally like Python but Perl syntax is closer to PHP so it might be easier to adopt.
I can haz crystal ball