I'm sure it's too late now, but could you trigger on all uppercase? So /ORGANIZE and /CUSTOMIZE would be reserved, but all lowercase - the case that most people will naturally use when they type in a URL - would still be available.
<snip/>
Another option would have been to tag all of your keywords with a prefix - sm_organize, sm_date, etc. Then have a rule saying that users can't create any object starting with sm_.
I'm sorry for being critical, but this just doesn't seem to be very well thought out. Using case as a differentiator is seldom a good idea.
+100
People are used to URLs not being case-sensitive in the vast majority of cases. SM needs to take another route in the instance (almost said 'case'). Figure out a better way to keep your own namespace.
You're probably noticing by now crickets whenever someone asks a question like that because the first law of security on the Internet is don't talk about security publicly.
The only thing I feel that's responsible to say is we have to continually pay attention to security, more with each passing year.
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
HI Sir... I am beyond thrilled that you're clearly really talking about putting JS back, albeit with some constraints. The custom domain constraint wouldn't worry me, and I would imagine people that are putting in enough time and work to need JS shoudln't bat an eyelid at the nominal cost and effort of setting up a custom domain. If it makes is possible, please do it with that as a constraint.
I'm so happy, I'm barely going to call you on the "security through obscurity" argument :-)
Thanks for the update. (More than happy to act as an alpha tester!)
You're probably noticing by now crickets whenever someone asks a question like that because the first law of security on the Internet is don't talk about security publicly.
The only thing I feel that's responsible to say is we have to continually pay attention to security, more with each passing year.
We met again this morning on the JavaScript question because we continue to work on it, but it looks very much like if we do implement it, and we're trying, it will only run on custom domains. Is that a deal-killer for anyone?
As long as the much needed items are allowed in some form, I.E. Statcounter, paypal, (not that I use it) I miss the slideshow, was starting to get sales and comments about how nice it looked.
To force us to pay again to have JS doesn't sound good to me, I code because I have to, not because I could afford to hire it out.
I have a custom domain, so it won't affect me if it's like that.
Of course, the only reason I need JS back is to have my Adsense ad back on my page. I don't even need scripting, and it's ludicrous that I'm being stopped, for security reasons, from using the single biggest CPC network known to man... lol. I know a lot of people would abhor the thought of an Adsense ad on their page... but I was making good money from it... far more than my yearly subscription cost. This needs to be allowed again soon, it's really not OK to just take away a major source of income.
Same here. I use JS for Adsense on one of my two SmugMug accounts. How about a separate external home page, in which our logo and breadcrumb 'home' would link to.
It does seem rather severe for Smugmug to reserve all lowercase urls on my domain for their possible future use.
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.
Only problem with that is, I keep seeing my username.smugmug.com address showing up from time to time instead of automatically changing to my custom domain. Used to be if someone typed username.smugmug.com it would automatically change to customdomain.com. Doesn't seem to do that anymore...
PS - I don't want javascript, I just want Statcounter to work
I haven't migrated yet, so I tested how this works in legacy smugmug. If I type bellhanley.smugmug.com, it goes to that URL. If I think click on a category, it changes to photos.bellhanley.com. It seems to be inconsistent about when it switches the URL. But once it switches to photos.bellhanley.com, it sticks and I haven't found a way to get it to revert to my smugmug name, which is as it should be (EXCEPTION BELOW...) However, my memory matches yours, which is that I thought it used to redirect right away. I also don't remember this being a hack; I think is just used to work once I created my custom domain.
I did just found a bug in legacy smugmug I don't remembering seeing before. If I do a search on my site on a word that's not a keyword...for example, I search for the word "fred", it returns a "No Keywords were found; try another keyword search." Keyword search in this case is a link that takes me out to www.smugmug.com (and searches all sites, not just mine).
I haven't migrated yet, so I tested how this works in legacy smugmug......
.....I did just found a bug in legacy smugmug I don't remembering seeing before. If I do a search on my site on a word that's not a keyword...for example, I search for the word "fred", it returns a "No Keywords were found; try another keyword search." Keyword search in this case is a link that takes me out to www.smugmug.com (and searches all sites, not just mine).
Just wanted to say that I've seen that problem in Legacy SmugMug for a long time. I know I mentioned it at least once here if not more, but there were several problems with searches including that one, and I could never make any headway around here with getting SmugMug interested in fixing them. That problem you mentioned was a particular pain to me, because once on smugmug.com , many of your viewers would just be gone, having no idea how to get back. I just don't understand why some of those bugs have gone on for SO long... this is something that gives me no confidence about all these bugs in the new system. Ugh.
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.
It just sounds very crazy. The thing is, people will have no idea what they could've done wrong, which means us site owners will have to put in a bunch of notices... but how or where, I don't know... When people misspell something, they can at least see what they've done wrong. But they'll have no idea what's wrong with the words they're putting in this way...
Just wanted to say that I've seen that problem in Legacy SmugMug for a long time. I know I mentioned it at least once here if not more, but there were several problems with searches including that one, and I could never make any headway around here with getting SmugMug interested in fixing them. That problem you mentioned was a particular pain to me, because once on smugmug.com , many of your viewers would just be gone, having no idea how to get back. I just don't understand why some of those bugs have gone on for SO long... this is something that gives me no confidence about all these bugs in the new system. Ugh.
Hi Anna Lisa,
I think we have shown we have been fixing bugs fast and furious in the New SmugMug. I think most people here can agree to that.
It just sounds very crazy. The thing is, people will have no idea what they could've done wrong, which means us site owners will have to put in a bunch of notices... but how or where, I don't know...
You can make a custom 404 page explaining the changes. That's what some users here on dgrin have been doing.
You can make a custom 404 page explaining the changes. That's what some users here on dgrin have been doing.
We could, but does it not sound like an incredibly inelegant and ugly solution that is only required because of an ergonomic train crash of a decision taken by SM?
Because if it sounds like anything else I'd suggest you aren't listening hard enough.
Except that we don't know what structures we will need in the future. For example, we now use /organize and /customize. We have a few more in planning, but we don't know what we'll need in a few years. The potential collisions in the future can be avoided by restricting the case of the first letter.
Given that, wouldn't sound programming and design knowledge suggest that given these are internal to the backend SM system - i.e. for those of us logged in as owners) prefix any SM specific URL/component etc. with SM_ or something similar, rather than mandating a single uppercase character at the start of what are commonly used URL components?
We could, but does it not sound like an incredibly inelegant and ugly solution that is only required because of an ergonomic train crash of a decision taken by SM?
Because if it sounds like anything else I'd suggest you aren't listening hard enough.
Cheers - N
Just trying to provide a solution to the question that was asked
Except that we don't know what structures we will need in the future. For example, we now use /organize and /customize. We have a few more in planning, but we don't know what we'll need in a few years. The potential collisions in the future can be avoided by restricting the case of the first letter.
Or, you could have just created a SM prefix for all these housekeeping URLs that are used by the logged in user, but not indexed by Google and then not broken any existing SEO, business cards, etc... For example /sm_customize or /sm_organize. These internal housekeeping URLs don't have to be beautiful or perfect words. It seems such a shame that you made customers break all their previous lowercase URLs and now make end-users have to be case saavy when the majority of the web does not use upper case and thus most end-users are not trained on case. This seems like you took the easy way out and caused a lot of customer grief when there were many other solutions that wouldn't have had any negative impact on existing customers. I rather doubt you foresaw this issue when the decision was made, but now that it's understood, doesn't it seem like a poor design decision to force case sensitivity and mixed case on all customers and end-uers? Especially when there are many, many other solutions to have your own SM namespace that wouldn't do this.
You can make a custom 404 page explaining the changes. That's what some users here on dgrin have been doing.
Yeah, it breaks all existing SEO to those lowercase links. It causes people to have to reprint business literature and, if a customer has a lot of previous lowercase links, the 404 page can't possibly explain them all and take the end-user to the page they really want to see. The 404 solution worked for one user because they only had one URL in this situation and they were willing to hack their site to work around it. I thought the new design was supposed to NOT require people to do that. You guys really shouldn't force all URLs to have mixed case and break all previous URLs. That's certainly not in the spirit of making things "just work" in the new SM. This decision to force mix case on all customers and viewers is just wrong and we're hoping you guys re-evaluate now that you understand the consequences of the design decision.
The 404 solution worked for one user because they only had one URL in this situation and they were willing to hack their site to work around it.
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
Or, you could have just created a SM prefix for all these housekeeping URLs that are used by the logged in user, but not indexed by Google and then not broken any existing SEO, business cards, etc... For example /sm_customize or /sm_organize. These internal housekeeping URLs don't have to be beautiful or perfect words. It seems such a shame that you made customers break all their previous lowercase URLs and now make end-users have to be case saavy when the majority of the web does not use upper case and thus most end-users are not trained on case. This seems like you took the easy way out and caused a lot of customer grief when there were many other solutions that wouldn't have had any negative impact on existing customers. I rather doubt you foresaw this issue when the decision was made, but now that it's understood, doesn't it seem like a poor design decision to force case sensitivity and mixed case on all customers and end-uers? Especially when there are many, many other solutions to have your own SM namespace that wouldn't do this.
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
No, you are just trying to cover up and justify a design flow. Help would be a two part process: 1) "Sorry, we screwed up and currently working on a resolution of..." 2) "For a time being, please use the following workaround..."
May I ask a personal question - do you, personally, think this was a correct and smart design decision to handle url in this manner? Honestly...
No, you are just trying to cover up and justify a design flow. Help would be a two part process: 1) "Sorry, we screwed up and currently working on a resolution of..." 2) "For a time being, please use the following workaround..."
May I ask a personal question - do you, personally, think this was a correct and smart design decision to handle url in this manner? Honestly...
Michael, I am not a developer. However, I trust the developers that work here 100%.
Just trying to provide a solution to the question that was asked
Providing an immediate work-around is good and helpful. That's always appreciated, but as the SM rep, we are looking for more.
Acknowledging that you understand there is a problem here and taking it back to development to see if you can get it fixed (hopefully quickly, not in years) is what we are looking for here.
Right now it sounds like you guys aren't even considering it a real problem.
Michael, I am not a developer. However, I trust the developers that work here 100%.
Not the answer you were looking for, I know.
Michael - I trust your developers too!!!! I trust even those guys or girls who made a simple (human) programming mistake by forgetting to remove SM default meta string if and when user's meta string already exists:) Developers are human. Hey, I am human too - I can make mistakes too:) But developers implement what the decision makers tell them to program. You are very close to decision makers in this company. Do you care to ask Mr. MacAskill if he really thinks that any of his friends or relatives EVER typed a web address in their browsers and paid attention to upper/lower case????
It's not a programming mistake or oversight - it is a (sorry for being strategist forward like this) stupid, idiotic business decision. Use cases and studies, if conducted at all, would reveal that most people would never pay attention to letter casing when typing web link into the browser window. Furthermore, many people would simply either select a link from their bookmarks or the link is auto-completed by the browser address bar as people start typing.
As someone mentioned above - you strive to provide an easy and elegant photo sharing website wizard for the customers, and yet put customers in a situation when they should resort to an ugly and not-user friendly work-around solution with 404 page customization.
The harm is done, the code is written and deployed. But if any of your trusted developers tells you it is impossible to change it at this point - this is a lie.
By the way, share with us what MacAskill told you about any of his friends ever typing the ulr with the correct letter casing
do you care to ask mr. Macaskill if he really thinks that any of his friends or relatives ever typed a web address in their browsers and paid attention to upper/lower case????
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.
Jason, you have a valid point however some of us will give business cards or marketing material with specific addresses out. I have a project I'll be launching soon that I want folks to land directly on that page. If they type a wrong letter case wise, how many are going to lose interest immediately? In the age of instant gratification some folks will bail quick if they don't see what they want upon page load.
I think case-sensitive urls kill the ability to share a link in a context outside of a computer. If given one, I myself would even type it in all lowercase, only to see "page not found".
Also, the operating system that most users use is case insensetive, so case-sensetivity will likely never cross the mind of the average user. Software should Do The Right Thing (tm) and this case-sensetivity nonsense is 100% doing the Wrong Thing.
I can't believe the thought never came up to just put smugmug stuff in a proper namespace. Mind boggling.
I think case-sensitive urls kill the ability to share a link in a context outside of a computer. If given one, I myself would even type it in all lowercase, only to see "page not found".
Comments
+100
People are used to URLs not being case-sensitive in the vast majority of cases. SM needs to take another route in the instance (almost said 'case'). Figure out a better way to keep your own namespace.
Jay
HI Sir... I am beyond thrilled that you're clearly really talking about putting JS back, albeit with some constraints. The custom domain constraint wouldn't worry me, and I would imagine people that are putting in enough time and work to need JS shoudln't bat an eyelid at the nominal cost and effort of setting up a custom domain. If it makes is possible, please do it with that as a constraint.
I'm so happy, I'm barely going to call you on the "security through obscurity" argument :-)
Thanks for the update. (More than happy to act as an alpha tester!)
Cheers - N
http://www.nzsnaps.com (talkiet.smugmug.com)
As long as the much needed items are allowed in some form, I.E. Statcounter, paypal, (not that I use it) I miss the slideshow, was starting to get sales and comments about how nice it looked.
To force us to pay again to have JS doesn't sound good to me, I code because I have to, not because I could afford to hire it out.
Spanish Fork, Utah 84660- 360 Virtual Tours - Landscapes
Google + Facebook Website
Same here. I use JS for Adsense on one of my two SmugMug accounts. How about a separate external home page, in which our logo and breadcrumb 'home' would link to.
PicturesOfVancouver.com · EddieFernandesPhotography.com
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.
Eric
(fka: thompson@best.com)
I haven't migrated yet, so I tested how this works in legacy smugmug. If I type bellhanley.smugmug.com, it goes to that URL. If I think click on a category, it changes to photos.bellhanley.com. It seems to be inconsistent about when it switches the URL. But once it switches to photos.bellhanley.com, it sticks and I haven't found a way to get it to revert to my smugmug name, which is as it should be (EXCEPTION BELOW...) However, my memory matches yours, which is that I thought it used to redirect right away. I also don't remember this being a hack; I think is just used to work once I created my custom domain.
I did just found a bug in legacy smugmug I don't remembering seeing before. If I do a search on my site on a word that's not a keyword...for example, I search for the word "fred", it returns a "No Keywords were found; try another keyword search." Keyword search in this case is a link that takes me out to www.smugmug.com (and searches all sites, not just mine).
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
DayBreak, my Folk Music Group (some free mp3s!) http://daybreakfolk.com
Hi Anna Lisa,
I think we have shown we have been fixing bugs fast and furious in the New SmugMug. I think most people here can agree to that.
Facebook
Google+
Twitter
Photo Blog
You can make a custom 404 page explaining the changes. That's what some users here on dgrin have been doing.
Facebook
Google+
Twitter
Photo Blog
We could, but does it not sound like an incredibly inelegant and ugly solution that is only required because of an ergonomic train crash of a decision taken by SM?
Because if it sounds like anything else I'd suggest you aren't listening hard enough.
Cheers - N
http://www.nzsnaps.com (talkiet.smugmug.com)
Given that, wouldn't sound programming and design knowledge suggest that given these are internal to the backend SM system - i.e. for those of us logged in as owners) prefix any SM specific URL/component etc. with SM_ or something similar, rather than mandating a single uppercase character at the start of what are commonly used URL components?
Broken links is gunna kill our SEO.
http://www.despatchesgallery.com
Just trying to provide a solution to the question that was asked
Facebook
Google+
Twitter
Photo 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
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
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
Facebook
Google+
Twitter
Photo Blog
Cheers - N
http://www.nzsnaps.com (talkiet.smugmug.com)
http://www.despatchesgallery.com
No, you are just trying to cover up and justify a design flow. Help would be a two part process: 1) "Sorry, we screwed up and currently working on a resolution of..." 2) "For a time being, please use the following workaround..."
May I ask a personal question - do you, personally, think this was a correct and smart design decision to handle url in this manner? Honestly...
Michael, I am not a developer. However, I trust the developers that work here 100%.
Not the answer you were looking for, I know.
Facebook
Google+
Twitter
Photo Blog
That's the other part of their job, surely!
http://www.despatchesgallery.com
Providing an immediate work-around is good and helpful. That's always appreciated, but as the SM rep, we are looking for more.
Acknowledging that you understand there is a problem here and taking it back to development to see if you can get it fixed (hopefully quickly, not in years) is what we are looking for here.
Right now it sounds like you guys aren't even considering it a real problem.
Jay
Michael - I trust your developers too!!!! I trust even those guys or girls who made a simple (human) programming mistake by forgetting to remove SM default meta string if and when user's meta string already exists:) Developers are human. Hey, I am human too - I can make mistakes too:) But developers implement what the decision makers tell them to program. You are very close to decision makers in this company. Do you care to ask Mr. MacAskill if he really thinks that any of his friends or relatives EVER typed a web address in their browsers and paid attention to upper/lower case????
It's not a programming mistake or oversight - it is a (sorry for being strategist forward like this) stupid, idiotic business decision. Use cases and studies, if conducted at all, would reveal that most people would never pay attention to letter casing when typing web link into the browser window. Furthermore, many people would simply either select a link from their bookmarks or the link is auto-completed by the browser address bar as people start typing.
As someone mentioned above - you strive to provide an easy and elegant photo sharing website wizard for the customers, and yet put customers in a situation when they should resort to an ugly and not-user friendly work-around solution with 404 page customization.
The harm is done, the code is written and deployed. But if any of your trusted developers tells you it is impossible to change it at this point - this is a lie.
By the way, share with us what MacAskill told you about any of his friends ever typing the ulr with the correct letter casing
+1
Website
Jason Scott Photography | Blog | FB | Twitter | Google+ | Tumblr | Instagram | YouTube
I can't believe the thought never came up to just put smugmug stuff in a proper namespace. Mind boggling.