How many of your clients are getting to their gallery by typing in the full, lengthy address? Our clients visit their gallery via a direct link we send them. Random site visitors shopping for a photographer get to our pages through Google or some other method and then navigate using the site navigation. I don't see the upper/lower case thing being a big deal.
I agree with you that in a functional website noone ever needs to type the web address directly in the browser. A menu/navigation system should be capable of bringing the visitor to the album he/she is searching for. On your web site it is very easy to navigate to your client's images AND to the list of your clients. May I ask why you even need to send a client direct link if they can simply land on your homepage and navigate to their album?
Forcing case awareness on end users should have been a show stopper for this change in the first place. It's just stupid.
I agree.
Hopefully smugmug has the right kind of server logs internally that show how many hits the 404 Not Found page gets. If so, I'm sure they'll be seeing a huge increase compared to old smugmug.
Actually this is not the case I was referring to. A user had weddings, events, etc that all had custom links. They created a 404 page that said "Please navigate to your gallery"
They then had a folders content block for weddings and events. Then in those Folders they had folders for year. Then in the year folders, they had galleries. Do I understand your frustrations regarding this? Sure, but I simply gave a viable solution to people who currently have this issue. It is only 3 extra clicks for the user. They don't have to type anything in. I am just trying to help here JFriend
You will perhaps find these links to be of interest. I have partially quoted them to save you time given that you are very busy these days:
Bearing in mind that Web site design conventions dictate that consistency should be followed, the best practice is generally to make all letters of a URL lowercase. But, of course, not everyone follows the best practices.
They (somewhat humorously in my opinion) offer this as a work around for navigating poorly designed websites that employ case sensitivity:
And here's a further trick for when you're having trouble connecting to a very long URL that you manually typed (or that someone else programmed as a link on a Web page, for that matter). One by one, starting at the right end of the URL, delete each part of the URL after the successive /'s and see if your browser can find the site. Hit Enter after deleting each successive part of the URL to search for that page. You will often be able to connect to the site on a page that is one or more levels above your page. You can then dig deeper for the specific page to which you were trying to connect.
People will visit a Web site less often if it is slower than a close competitor by more than 250 milliseconds (a millisecond is a thousandth of a second).
“Two hundred fifty milliseconds, either slower or faster, is close to the magic number now for competitive advantage on the Web,” said Harry Shum, a computer scientist and speed specialist at Microsoft.
And lastly this info graphic published by kissmetrics.com
I agree with you that in a functional website noone ever needs to type the web address directly in the browser. A menu/navigation system should be capable of bringing the visitor to the album he/she is searching for. On your web site it is very easy to navigate to your client's images AND to the list of your clients. May I ask why you even need to send a client direct link if they can simply land on your homepage and navigate to their album?
This isn't always the case. I have a lot of private galleries that don't show up on my home page or anywhere in my navigation structure. The only way to get to these is by direct link. I send the link in an email, but as I and others have said, there are plenty of cases where someone would want to type in the URL directly.
I agree with you that in a functional website noone ever needs to type the web address directly in the browser. A menu/navigation system should be capable of bringing the visitor to the album he/she is searching for. On your web site it is very easy to navigate to your client's images AND to the list of your clients. May I ask why you even need to send a client direct link if they can simply land on your homepage and navigate to their album?
I use the Event features of SmugMug and send them a link that way so they can select favorites.
Maybe something built into the underlying code that fixes the lower case to upper case UNLESS it is a smugmug specific url... like /browse... would be an easy thing for SM to add? I don't know...
(Also, redirecting /galleries to /browse would be nice... browse is the new version of what galleries used to be...)
I use the Event features of SmugMug and send them a link that way so they can select favorites.
Well... I hope we are not getting off topic, Events, again, require a link, correct? I prefer pure, logical, and secure navigation. Go to my website, click on Private Zone in the lower right corner. Type Client777 as your access code, click Enter, and then type the word open as your password. Secure, no link required, all you have to say to your cleints: here is the access code (aka 'user name') and here is the password. This simple implementation, unfortunately, requires javascript, which we all know by now is nowhere to be found in the new SM. So, at this moment, the only (almost) way to provide visitors with a secure access while NOT exposing the entire list of your cleints is with sending them links... which is cAsE sensitive, which is an idiotic business decision.
Well... I hope we are not getting off topic, Events, again, require a link, correct? I prefer pure, logical, and secure navigation. Go to my website, click on Private Zone in the lower right corner. Type Client777 as your access code, click Enter, and then type the word open as your password. Secure, no link required, all you have to say to your cleints: here is the access code (aka 'user name') and here is the password. This simple implementation, unfortunately, requires javascript, which we all know by now is nowhere to be found in the new SM. So, at this moment, the only (almost) way to provide visitors with a secure access while NOT exposing the entire list of your cleints is with sending them links... which is cAsE sensitive, which is an idiotic business decision.
Point is, I send them the link and they click on it. No typing
Agreed. It's ridiculous. SmugMug should reserve /admin/ or /smugmug/ or something else and put everything SmugMug needs under that namespace.. but don't force me to have ugly URLs with pointless capital letters that no one - NO ONE - will ever type in correctly.
SmugMug, you're making a big mistake here -- but you have time to fix it now before it's engrained. Please fix it.
Yeah, I wasn't aware of this issue before we went live and it has taken me awhile to mostly understand it. A wedding pro wrote into the heroes saying she had printed 800 handouts that had an URL with /wedding in it and we produced a 404 page unless it was /Wedding. Ouch.
I think we have a 99.9% use case solution in the works, which is to redirect when no conflict with one of our system pages is detected, which is what we do on SmugMug Legacy today. That will fix the case, for example, of the wedding pro's handouts.
What's less obvious to me is what to do on system pages SmugMug uses today, such as /signup and /pro. I am aware of a use case where a pro printed collateral with /signup on it and was surprised to find out it went to our signup form. I think with the solution we're working on, we can avoid 99.9% of the use cases we're seeing, but for system pages like /signup I'm not aware that we have figured out a solution (this is the part of the problem that's not new; it has existed on legacy for years too).
We're really sorry for the problems this has been causing in the meantime.
Yeah, I wasn't aware of this issue before we went live and it has taken me awhile to mostly understand it. A wedding pro wrote into the heroes saying she had printed 800 handouts that had an URL with /wedding in it and we produced a 404 page unless it was /Wedding. Ouch.
I think we have a 99.9% use case solution in the works, which is to redirect when no conflict with one of our system pages is detected, which is what we do on SmugMug Legacy today. That will fix the case, for example, of the wedding pro's handouts.
What's less obvious to me is what to do on system pages SmugMug uses today, such as /signup and /pro. I am aware of a use case where a pro printed collateral with /signup on it and was surprised to find out it went to our signup form. I think with the solution we're working on, we can avoid 99.9% of the use cases we're seeing, but for system pages like /signup I'm not aware that we have figured out a solution (this is the part of the problem that's not new; it has existed on legacy for years too).
We're really sorry for the problems this has been causing in the meantime.
It's great to see that you're looking into this and already have a plan in place. Thank you.
As several of have suggested - is it possible to rename system pages with a prefix of sm_? So you'd have /sm_signup and /sm_pro.
It's great to see that you're looking into this and already have a plan in place. Thank you.
As several of have suggested - is it possible to rename system pages with a prefix of sm_? So you'd have /sm_signup and /sm_pro.
Or simply make them a level deeper...
/sm/signup and /sm/pro and reserve the entire /sm directory structure for SmugMug use.
Or even (going back to the horrible use of case sensitivity) make it
/SmugMug/signup
FWIW - It appears that the lowercase "bug" has impacted vanity URLs (implemented in javascript) on my legacy site. And since it's a not a "real" URL the redirect doesn't work correctly (although it does partially work).
Blog integration is a feature request we are well aware of, but nope, it is not there yet. But you could easily customize the 2 platforms to match looks.
You can change the background image per page, you would just need to have a unique Theme on each page, since the background image is set in the "Theme" tab on Customization.
I made this video to show you how it's done per page.
I can not find any discussion for changing a whole category looks, like a different banner etc. Only
page by page. We ought to be able to change a folder's looks and have it flow down. Also the "entire
site" banner, how to override it for flow down from a folder.
Yeah, I wasn't aware of this issue before we went live and it has taken me awhile to mostly understand it. A wedding pro wrote into the heroes saying she had printed 800 handouts that had an URL with /wedding in it and we produced a 404 page unless it was /Wedding. Ouch.
I think we have a 99.9% use case solution in the works, which is to redirect when no conflict with one of our system pages is detected, which is what we do on SmugMug Legacy today. That will fix the case, for example, of the wedding pro's handouts.
What's less obvious to me is what to do on system pages SmugMug uses today, such as /signup and /pro. I am aware of a use case where a pro printed collateral with /signup on it and was surprised to find out it went to our signup form. I think with the solution we're working on, we can avoid 99.9% of the use cases we're seeing, but for system pages like /signup I'm not aware that we have figured out a solution (this is the part of the problem that's not new; it has existed on legacy for years too).
We're really sorry for the problems this has been causing in the meantime.
Why not just put Smug URLs like /signup and /pro and /login in their own namespace /sm/signup /sm/pro /sm/customize /sm/login and then there's only one possible conflict forever as you have an infinite namespace available for SM use?
FWIW - It appears that the lowercase "bug" has impacted vanity URLs (implemented in javascript) on my legacy site. And since it's a not a "real" URL the redirect doesn't work correctly (although it does partially work).
The jfriend vanity URL customization is still working fine on my legacy site.
Why not just put Smug URLs like /signup and /pro and /login in their own namespace /sm/signup /sm/pro /sm/customize /sm/login and then there's only one possible conflict forever as you have an infinite namespace available for SM use?
Or you can just not have /signup and /pro be things for user domains. www.smugmug.com/pro makes sense, renstar.smugmug.com/pro makes no sense.
Or you can just not have /signup and /pro be things for user domains. www.smugmug.com/pro makes sense, renstar.smugmug.com/pro makes no sense.
Agree with this, however
paulbrock.smugmug.com/customize and /organize do make sense. But those that aren't needed on user domains shouldn't be restricted, esp when they may be used for other purposes. /signup sounds a handy one to have.
Go to my website, click on Private Zone in the lower right corner. Type Client777 as your access code, click Enter, and then type the word open as your password. Secure, no link required, all you have to say to your cleints: here is the access code (aka 'user name') and here is the password. This simple implementation, unfortunately, requires javascript
You can do this without requiring JavaScript on SmugMug:
What Nicholas doing for others is a very good thing and is appreciated by many, I am sure. But I'll pass on involving a third party service when it comes to my website. This is a workaround , not a promised functionality of a "100% Customizable" site.
If not with JavaScript, I hope that Smugmug can at least make an addition to their available tools and provide a customizable block that will accept gallery/folde/page name (or password) and riderect visitor to the appropriate page.
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
Why not just put Smug URLs like /signup and /pro and /login in their own namespace /sm/signup /sm/pro /sm/customize /sm/login and then there's only one possible conflict forever as you have an infinite namespace available for SM use?
We have 10 years worth of links on the web that go to /login /signup, etc., embedded in sites like The New York Times.
10 years ago when we were two guys in an apartment should we have done /sm/signup, /sm/pro, etc.? Possibly, but that was back in the day when people did type in URLs more than they do now, our partners and affiliates prefer the shortest, cleanest links we can give out, and then there are the SEO consequences.
So I think the solution we're working on that covers the 99.9% use case is probably the best compromise.
We have 10 years worth of links on the web that go to /login /signup, etc., embedded in sites like The New York Times.
10 years ago when we were two guys in an apartment should we have done /sm/signup, /sm/pro, etc.? Possibly, but that was back in the day when people did type in URLs more than they do now, our partners and affiliates prefer the shortest, cleanest links we can give out, and then there are the SEO consequences.
So I think the solution we're working on that covers the 99.9% use case is probably the best compromise.
You could at least create this new /sm namespace for all newly created smugmug.com links and at least stop making the potential problem worse over time.
With the redirect work-around, what happens to customers SEO to /weddings and such? Will Google find the redirect and still be happy or will customers lose their SEO on lowercase links.
I'm unclear why there has to be such codependence between www.smugmug.com and customername.SmugMug.com wrt reserved URLs. Is this an insurmountable problem?
We have 10 years worth of links on the web that go to /login /signup, etc., embedded in sites like The New York Times.
10 years ago when we were two guys in an apartment should we have done /sm/signup, /sm/pro, etc.? Possibly, but that was back in the day when people did type in URLs more than they do now, our partners and affiliates prefer the shortest, cleanest links we can give out, and then there are the SEO consequences.
So I think the solution we're working on that covers the 99.9% use case is probably the best compromise.
Oh, so you do worry about SEO consequences to your website? But you don't see how "Wedding" vs. "wedding" might affect your customer's websites?
As paulbrock asked, I am to not following why so much codependence btw www.smugmug.com and customername.SmugMug.com? Especially why mydomainname.com should be crippled by your case-sensitive "solution"? Look, I know that probably by now I am only perceived as a complainer and critic But seriously, I know a few things about software. A high level overview of your problem is- you have a bunch of pages that you use internally for smugmug functionality. Understood. "signup" is a good example. Perfect, I understand that I my website cannot have www.michaelshapirophotography.com/signup/. I am ok with that. Or http://www.michaelshapirophotography.com/admin, or something similar. It's all yours! Please, put it in you TOS so we all know:) But do you need "wedding" or "cars" or "pets", etc ? Nope, you do not. There are other solutions to distinguish and translate your reserved list of names than rely on the letter case how it arrive to your server. How about a bet: you fly me to your place, you put me under NDA, you show me details of the issue and let me think for three weeks. If I do not come up with a solution - I'll give you the keys from my bmw. If I come up with a solution - you pay me 1 million dollars.
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
You could at least create this new /sm namespace for all newly created smugmug.com links and at least stop making the potential problem worse over time.
With the redirect work-around, what happens to customers SEO to /weddings and such? Will Google find the redirect and still be happy or will customers lose their SEO on lowercase links.
John, unfortunately, there are a few URLs that people still type on the web and best practices always suggest you keep them simple and what customers expect: /help and /search are among the top ones. By changing those to /sm/help and /sm/search, we will confuse a lot of people who type those URLs in today and we break an Internet convention embraced by Google, Facebook, Amazon, Wordpress, Pinterest and the rest.
Part of this release was a big phantom renderer project because Google doesn't index JavaScript. Redirects of URLs is part of what we have to do for good SEO.
Part of this release was a big phantom renderer project because Google doesn't index JavaScript. Redirects of URLs is part of what we have to do for good SEO.
I hadn't heard much (actually anything) about this. It's interesting to hear. With this change I started paying more attention to indexing, and that's one of the things making me think to move -- I can't find my own sites on Google, so I know no one else can.
Here's an example. I put up a gallery on 7/27/13 for the "Cape Coral Hurricanes".
In the gallery meta keywords I have "Hurricanes".
In the title I have it, in the filename of every single image I have it.
In the gallery description I have it.
But a very specific search of "site:www.captivephotons.com hurricanes" doesn't find it at all.
How is that possible?
I guarantee if I posted that on a little known site such as my personal site, as plain old HTML and images, it would find it.
So I'm glad you recognize the issue -- but the fix doesn't seem to work.
Hey Ferguson, were you aware that adding the "-" in front of "site" means "exclude results from this site"? If I take out the "-", it does find your website.
Hey Ferguson, were you aware that adding the "-" in front of "site" means "exclude results from this site"? If I take out the "-", it does find your website.
Typo in the posting -- I'll fix. Try it without, you won't find it. Here's the real site.
Comments
I agree with you that in a functional website noone ever needs to type the web address directly in the browser. A menu/navigation system should be capable of bringing the visitor to the album he/she is searching for. On your web site it is very easy to navigate to your client's images AND to the list of your clients. May I ask why you even need to send a client direct link if they can simply land on your homepage and navigate to their album?
I agree.
Hopefully smugmug has the right kind of server logs internally that show how many hits the 404 Not Found page gets. If so, I'm sure they'll be seeing a huge increase compared to old smugmug.
You will perhaps find these links to be of interest. I have partially quoted them to save you time given that you are very busy these days:
http://www.americanbar.org/publications/law_practice_home/law_practice_archive/lpm_magazine_articles_v33_is8_pg26.html
They (somewhat humorously in my opinion) offer this as a work around for navigating poorly designed websites that employ case sensitivity:
http://www.nytimes.com/2012/03/01/technology/impatient-web-users-flee-slow-loading-sites.html?pagewanted=all&_r=0
And lastly this info graphic published by kissmetrics.com
http://blog.kissmetrics.com/leave-a-website/
Sorry, Michael, but this is a copout answer. You don't have to be a developer to see that this was a horrible decision.
This isn't always the case. I have a lot of private galleries that don't show up on my home page or anywhere in my navigation structure. The only way to get to these is by direct link. I send the link in an email, but as I and others have said, there are plenty of cases where someone would want to type in the URL directly.
I use the Event features of SmugMug and send them a link that way so they can select favorites.
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
(Also, redirecting /galleries to /browse would be nice... browse is the new version of what galleries used to be...)
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
Well... I hope we are not getting off topic, Events, again, require a link, correct? I prefer pure, logical, and secure navigation. Go to my website, click on Private Zone in the lower right corner. Type Client777 as your access code, click Enter, and then type the word open as your password. Secure, no link required, all you have to say to your cleints: here is the access code (aka 'user name') and here is the password. This simple implementation, unfortunately, requires javascript, which we all know by now is nowhere to be found in the new SM. So, at this moment, the only (almost) way to provide visitors with a secure access while NOT exposing the entire list of your cleints is with sending them links... which is cAsE sensitive, which is an idiotic business decision.
Point is, I send them the link and they click on it. No typing
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
I think we have a 99.9% use case solution in the works, which is to redirect when no conflict with one of our system pages is detected, which is what we do on SmugMug Legacy today. That will fix the case, for example, of the wedding pro's handouts.
What's less obvious to me is what to do on system pages SmugMug uses today, such as /signup and /pro. I am aware of a use case where a pro printed collateral with /signup on it and was surprised to find out it went to our signup form. I think with the solution we're working on, we can avoid 99.9% of the use cases we're seeing, but for system pages like /signup I'm not aware that we have figured out a solution (this is the part of the problem that's not new; it has existed on legacy for years too).
We're really sorry for the problems this has been causing in the meantime.
It's great to see that you're looking into this and already have a plan in place. Thank you.
As several of have suggested - is it possible to rename system pages with a prefix of sm_? So you'd have /sm_signup and /sm_pro.
Or simply make them a level deeper...
/sm/signup and /sm/pro and reserve the entire /sm directory structure for SmugMug use.
Or even (going back to the horrible use of case sensitivity) make it
/SmugMug/signup
FWIW - It appears that the lowercase "bug" has impacted vanity URLs (implemented in javascript) on my legacy site. And since it's a not a "real" URL the redirect doesn't work correctly (although it does partially work).
page by page. We ought to be able to change a folder's looks and have it flow down. Also the "entire
site" banner, how to override it for flow down from a folder.
My Website index | My Blog
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
The jfriend vanity URL customization is still working fine on my legacy site.
http://janicebrowne.com/woodendplantlife
opens up
http://www.janicebrowne.com/ANS/Woodend-Grounds/Woodend-Plant-Life/20014554_tfQvZq
Or you can just not have /signup and /pro be things for user domains. www.smugmug.com/pro makes sense, renstar.smugmug.com/pro makes no sense.
Agree with this, however
paulbrock.smugmug.com/customize and /organize do make sense. But those that aren't needed on user domains shouldn't be restricted, esp when they may be used for other purposes. /signup sounds a handy one to have.
You can do this without requiring JavaScript on SmugMug:
http://www.sherlockphotography.org/Customisations/Client-login-system
Please check out my gallery of customisations for the New SmugMug, more to come!
What Nicholas doing for others is a very good thing and is appreciated by many, I am sure. But I'll pass on involving a third party service when it comes to my website. This is a workaround , not a promised functionality of a "100% Customizable" site.
If not with JavaScript, I hope that Smugmug can at least make an addition to their available tools and provide a customizable block that will accept gallery/folde/page name (or password) and riderect visitor to the appropriate page.
10 years ago when we were two guys in an apartment should we have done /sm/signup, /sm/pro, etc.? Possibly, but that was back in the day when people did type in URLs more than they do now, our partners and affiliates prefer the shortest, cleanest links we can give out, and then there are the SEO consequences.
So I think the solution we're working on that covers the 99.9% use case is probably the best compromise.
With the redirect work-around, what happens to customers SEO to /weddings and such? Will Google find the redirect and still be happy or will customers lose their SEO on lowercase links.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Posted from Nexus 7 using Tapatalk
Oh, so you do worry about SEO consequences to your website? But you don't see how "Wedding" vs. "wedding" might affect your customer's websites?
As paulbrock asked, I am to not following why so much codependence btw www.smugmug.com and customername.SmugMug.com? Especially why mydomainname.com should be crippled by your case-sensitive "solution"? Look, I know that probably by now I am only perceived as a complainer and critic
Part of this release was a big phantom renderer project because Google doesn't index JavaScript. Redirects of URLs is part of what we have to do for good SEO.
http://www.dgrin.com/showpost.php?p=1893600&postcount=372
But if I didn't I apologize for not understanding your post.
Please, don't apologize. You did answer this in the post above and I must apologize for not reading it.
I hadn't heard much (actually anything) about this. It's interesting to hear. With this change I started paying more attention to indexing, and that's one of the things making me think to move -- I can't find my own sites on Google, so I know no one else can.
Here's an example. I put up a gallery on 7/27/13 for the "Cape Coral Hurricanes".
In the gallery meta keywords I have "Hurricanes".
In the title I have it, in the filename of every single image I have it.
In the gallery description I have it.
But a very specific search of "site:www.captivephotons.com hurricanes" doesn't find it at all.
How is that possible?
I guarantee if I posted that on a little known site such as my personal site, as plain old HTML and images, it would find it.
So I'm glad you recognize the issue -- but the fix doesn't seem to work.
Please check out my gallery of customisations for the New SmugMug, more to come!
http://www.captivephotons.com/Events/Hurricanes/Tampa072713