.However in the real software world engineers don't even have that privilege with production releases.
But webmasters do. If it was a site hosted elsewhere I could add whatever I wanted. It's up to the site owner whether they want to run a gamut of unit testing, integration testing and so forth; particularly for a small company or sole trader, they're quite at libertyto make changes without spending weeks testing against every eventuality should they choose to - in fact it my be not only desirable but essential. We absolutely do have that privilege, and it is not inevitable that we should be subject to a lengthy process to make minor changes to our smugmug sites.
the slideshow with its own thread; virtually everyone wants it, because it's simply gorgeous.
Yes, we agree! A thousand times over. John has done a wonderful thing for thousands of our customers over the years with his slideshow and help pages and constant support.
I hope John doesn't mind me saying that we've been talking for a long time, over a year, about how to distribute his slideshow in new SmugMug. The model that seems simplest on the surface is he submits it to our QA, same as if he were submitting an app to Apple's appstore. We write back with bugs we find, and he re-submits. Or we publish if we don't find any.
The benefit to us and our customers is it reaches 100% of them in a very easy way, not just the small percent who are willing to brave dgrin and do their own install.
If I were John, the concerns I'd have are how quickly will SmugMug respond if there's a bug he has to fix, or what the release process is when he has an upgrade or we do something to break his app. Apple's Appstore can be frustrating to work with in that regard.
The concern I have for SmugMug is we shouldn't enter into something like this unless there's a long-time commitment to bug fixes and upgrades. Imagine if several hundred thousand of our customers install it and he's no longer around to maintain it. As will all software, including Apple's, the host company has to make changes which inevitably breaks many apps, so the developers have to quickly fix their apps or get dropped from the store.
Our situation is different in that we can't just drop his slideshow if it breaks due to some security patch we have to issue, or whatever. It's integral to a photographer's home page.
I am working with another slideshow maker whose slideshow is also gorgeous, to distribute theirs with new SmugMug. But we have hurdles to overcome for things that you would expect of us. One is that we would have to have the rights to their source code to fix it in the event something happens to them (they get acquired, or whatever).
Software developers who post here can understand a constraint we currently have on legacy SmugMug that Apple doesn't. When an app crashes on the iPhone, everyone blames the developer, not Apple. And that gives Apple the freedom to innovate while the developers understand they have to fix their apps as Apple makes changes.
Today, on existing SmugMug, if someone's customization breaks due to some change we make, even if the breakage comes from a third-party JavaScript, our customers perceive that we introduced a bug even if it's really a security patch.
So another very big benefit of distributing a third party slideshow is that it can be branded as one so everyone knows that they are dependent on the third party. But as I mentioned above, the stakes are still higher than if it were an app on your iPhone.
But webmasters do. If it was a site hosted elsewhere I could add whatever I wanted. It's up to the site owner whether they want to run a gamut of unit testing, integration testing and so forth; particularly for a small company or sole trader, they're quite at libertyto make changes without spending weeks testing against every eventuality should they choose to - in fact it my be not only desirable but essential. We absolutely do have that privilege, and it is not inevitable that we should be subject to a lengthy process to make minor changes to our smugmug sites.
Posted from Nexus 7 using Tapatalk
Sure, as long as it doesn't conflict with the companies larger goals and overall architecture which it obviously has over the years.
One of the main problems is that most customers, web designers, etc... think only inside the scope of their own websites and do not realize they are actually apart of and therefore impacting a much larger product. SM, in this case, was allowing customers unlimited access to add any JS they wanted throughout their site. Unfortunately that does not occur in a vacuum but rather effects SM's overall functionality, agility and ability to simply modify their own product over time. Freedom is fine until it impacts someone else's which in this case is the larger product that in turn impacts millions of customers. Hence the huge delay to market of this long awaited release. This was the the # 1 reason updating SM was so difficult and still is today. It's also the primary reason behind these loudest complaint threads. Why can't I just do it my way, no questions asked?
Paul - you have to realize that with the "new" smugmug you stopped being a webmaster of your website and SmugMug stopped being a website hosting solution. You are now a lucky user of a very cool template builder tool. The only hosting part you are still offered - is the hosting of your image files.
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
Baldy mentioned something about 301 redirects on Smugmug, implying they already existed. Can we get some clarification please?
are they:
- already existing but aren't working right now
- hypothetically available about some point in the future
- shortly being rolled out
Thanks.
Yeah, that post caught my attention when you posted it. Thanks. My understanding is we were doing a 301 redirect and if we're not now that's a bug. I plan to dig into this in a few days and will get an answer to you.
Just tried to print some more metal prints after I downgraded my account to basic. No more access to Bay Photo So I gotta pay another $100+ a year just to have access to Bay Photo or am I missing something?
Just tried to print some more metal prints after I downgraded my account to basic. No more access to Bay Photo So I gotta pay another $100+ a year just to have access to Bay Photo or am I missing something?
The photos of Power and Basic subscribers all print through EZ Prints.
SmugMug Portfolio and Business account holders can choose to have their prints handled through either EZ Prints, Bay Photo, Loxley, and WHCC . Portfolio users can choose one lab as the default for their website. All orders will print using that lab. Business users can pick a lab for their default but can also specify certain galleries to be printed through another, if needed.
Just tried to print some more metal prints after I downgraded my account to basic. No more access to Bay Photo So I gotta pay another $100+ a year just to have access to Bay Photo or am I missing something?
Yeah, that post caught my attention when you posted it. Thanks. My understanding is we were doing a 301 redirect and if we're not now that's a bug. I plan to dig into this in a few days and will get an answer to you.
Unfortunately all of this is meaningless to most customers because all they see is the functionalitythey want. They either have it or they don't. So they look at our discussions of security and best SW practices as excuses rather the real world of IT we live in daily. Was it a mistake to open that box way back when? Maybe, I don't know. It seemed cool for us customers at the time... But for SM over the years obviously not so much. IMO, going back there makes no sense and would be a bad decision architecturally speaking for all the reasons mentioned as well as difficult lessons learned. But maybe we can find a middle ground with some SM oversight which works for most customers?
Good post, Derek. Great insight.
On the question of whether it was a mistake to open up Pandora's box way back when, I've been dying to ask Tom Anderson of Myspace that question. It definitely launched us like it did Myspace and then became a yoke around both of our necks.
Even so, we had fully intended to deploy it up to 60 days before launch, when the practical issues caused us to delay. And now, as you peel the onion and see how deep the practical issues are, it makes me ask did sites like WordPress achieve so much success despite their lack of JavaScript support or because of it?
You mentioned the practical issues are lost on many customers. My thoughts have shifted about that. Here on dgrin I see and feel the pain like everyone does of people who used to be able to paste JavaScript and get instant results. But I have the good fortune of interacting with all of our customers and a tremendous sense of calm has come over me.
One thing is making the popular JavaScript apps built in and supported to the 95% instead of to just the 5% has been a major boon. Another, and Denise Goldberg can testify to this one, is how much pain and frustration customers and our heroes felt when they copied and pasted JavaScript, didn't understand it, and got unexpected results they couldn't debug. And a third is we have a set of customers who are even more passionate than the pro-JavaScript camp against deploying it as we did in the past. The heat of this debate made us pay more attention to their concerns and I feel that once more people hear about those issues, they'll understand why we have to proceed with so much caution.
Unfortunately that does not occur in a vacuum but rather effects SM's overall functionality, agility and ability to simply modify their own product over time. Freedom is fine until it impacts someone else's which in this case is the larger product that in turn impacts millions of customers. Hence the huge delay to market of this long awaited release. This was the the # 1 reason updating SM was so difficult and still is today.
I think you're making a lot of assumptions there, particularly about the reasons why this rollout took so long.
Code on my site *shouldn't* affect other smugmug users. I'm not saying it doesn't, but it shouldn't. If it does, there's either a problem with the code, or a problem with smugmug's setup. Likewise smugmug rolling out a change or fix, and it somehow 'breaking' our javascript. If the javascript is sound, and the smugmug fix is sound, and neither have some dirty hacks then one shouldn't affect the other.
Of course, as a former developer myself, 'dirty hacks' are part and parcel of the business. That being said, taking your argument to its conclusion, smugmug code could bring down Amazon's servers, or significantly affect their other customers. I'm pretty sure Amazon doesn't ask to vet smugmug's code though.
we have a set of customers who are even more passionate than the pro-JavaScript camp against deploying it as we did in the past.
What I'm seeing here, on the unrepresentative microcosm of dgrin (and to a certain extent on G+), is a few customers arguing for its inclusion, a whole host of customers not really caring either way, and a few customers saying "this is why it might not be as easy as you like to add Javascript". Not really seeing anyone up in arms with concerns about it possibly being included in future. Of course, I see far fewer customers opinions on it than Smugmug does!
once more people hear about those issues, they'll understand why we have to proceed with so much caution.
I agree. Which is why this dialogue is helpful, if occasionally painful for both sides at times.
I think you're making a lot of assumptions there, particularly about the reasons why this rollout took so long.
Code on my site *shouldn't* affect other smugmug users. I'm not saying it doesn't, but it shouldn't. If it does, there's either a problem with the code, or a problem with smugmug's setup. Likewise smugmug rolling out a change or fix, and it somehow 'breaking' our javascript. If the javascript is sound, and the smugmug fix is sound, and neither have some dirty hacks then one shouldn't affect the other.
Of course, as a former developer myself, 'dirty hacks' are part and parcel of the business. That being said, taking your argument to its conclusion, smugmug code could bring down Amazon's servers, or significantly affect their other customers. I'm pretty sure Amazon doesn't ask to vet smugmug's code though.
Paul, I see where you are coming from. But what I'm saying regarding impacts are very real and not assumptions. Rather they are the facts of the rollout stated by SM themselves. The main point you make though is that one shouldn't necessarily effect the other, at least in a perfect world. Still, they have and continue to, whether that be hacks introduced by customers unknowingly or patches SM makes for security reasons among others which impact old 'custom' code or a major release that changes fundamental behavior of their site. Still I think you are on the right track. One shouldn't effect the other. That is really the challenge for the SM team in introducing JS back in a responsible, decoupled fashion.
The major difference between SM and a site you or anyone else hosts on Amazon is that this is a *shared* application. There is a coupling of customer code with SM and they both have to run together as one product - one web application in the same space. Of course another web app running on Amazon or any other host won't have similar impacts because they are *separate* applications. SM is closer to a shared open sourced product than it is a host where you have freedom as a webmaster to create your own website, not impacting others. Infrastructure is much different than the web application layer which shares that same space.
The concept that one is a webmaster in not correct nor was it in the legacy SM either. While for some there were more freedoms in Legacy SM it was still a templated image host in many regards with many more limitations. Those templates were both extremely outdated and locked in place. So in that regard many of us have more freedoms now to create what we really wanted before but couldn't. SM listened to what we were asking for big time. It is also why they received a huge influx of new users and why the majority of customers are much happier now.
Of course in a support forum such as this you will hear a statistically slanted view from those who have issues and are trying to get resolution. You won't see as many customers saying how much better SM works for them now. Though I'm sure this is happening in other venues.
On the question of whether it was a mistake to open up Pandora's box way back when, I've been dying to ask Tom Anderson of Myspace that question. It definitely launched us like it did Myspace and then became a yoke around both of our necks.
Even so, we had fully intended to deploy it up to 60 days before launch, when the practical issues caused us to delay. And now, as you peel the onion and see how deep the practical issues are, it makes me ask did sites like WordPress achieve so much success despite their lack of JavaScript support or because of it?
You mentioned the practical issues are lost on many customers. My thoughts have shifted about that. Here on dgrin I see and feel the pain like everyone does of people who used to be able to paste JavaScript and get instant results. But I have the good fortune of interacting with all of our customers and a tremendous sense of calm has come over me.
One thing is making the popular JavaScript apps built in and supported to the 95% instead of to just the 5% has been a major boon. Another, and Denise Goldberg can testify to this one, is how much pain and frustration customers and our heroes felt when they copied and pasted JavaScript, didn't understand it, and got unexpected results they couldn't debug. And a third is we have a set of customers who are even more passionate than the pro-JavaScript camp against deploying it as we did in the past. The heat of this debate made us pay more attention to their concerns and I feel that once more people hear about those issues, they'll understand why we have to proceed with so much caution.
Exactly, that is same model which makes other hosts so successful and more agile. If you can shift away from having to work around so many variations of someone else's code to implementing new features faster the majority of customers will benefit. The new SM is already much more intuitive and easier to work with right out of the box. Proving agility here will be the key which I have been seeing already with all of the updates since the major release date. Your team has been working double time. But I would imagine it is also easier now to implement the changes.
Of course certain things will take a bit more time and planning to get right like the complexities of introducing JS back in a more responsible way. Paul does make a good point that one *shouldn't* necessarily effect the other. But its getting there that is the real challenge. I just don't see how that could ever happen without some degree of oversight and QA. I also would think that process could evolve over time. Maybe allow JFriend or other JS customizers to pilot it? To help streamline this process I would recommend putting out a *best practices* to follow for those who want to submit a new feature. These would be in line with SM's current best practices. That would help streamline the time from submittal, approval, QA to deploy I think as well as minimizing potential conflicts.
I also think it's great that you are willing to listen to all the issues on here and consider them when going back to the team. Maybe you're right in that while some of what is stated may not be understood it still helps to have the conversation. At least then you hear what customers really want, even if a bit different than what currently exists in the new SM.
The concept that one is a webmaster in not correct nor was it in the legacy SM either.
That's true, and occasionally we'd run into issues in legacy as well,where we wanted to do 'webmaster' things but were unable with the existing infrastructure. I forget the details but I think it was stuff like adding sitemaps ourselves, probably a couple of other bits too. Its a spectrum, and as it stands right now, we've moved a few notches away from "total control". I'm still trying to figure out whether that's intentional, and/or permanent and/or within my requirements.
The fact is I am struggling to understand the direction Smugmug is going in, making it difficult for me to predict what they will do next (or indeed not do). As one of my most important suppliers, that uncertainty troubles me, probably more so than where exactly on the 'control/customisation' scale we end up sitting.
Hence posting lots of rambling thoughts and obscure questions
Trying to understand what direction they are going as well.
I asked a while back in the following thread but they didn't answer. http://dgrin.com/showthread.php?t=239231
Could it be that SM's direction is evolving somewhat even as we speak, especially with regards to some of these additional features asked for? I would say yes and at least *part* of that evolution is based upon user input Baldy and other SM'ers receive on forums such as this. I think part of the problem and benefit of a more conversational approach like this with customers is that during the evolution of a product things aren't set in stone yet. And most customers are not used to that paradigm. They want a Yes or No answer right away rather than 'we're working on it and you are a part of the potential solution.' The problem with the later is that it makes folks nervous. Either this thing meets my needs or it doesn't. And that is true with most products and services really.
I'll admit also that there was a time I was very frustrated with how loooOONG the new release was taking. There were so many things with the old SM just not working for me anymore. I was also getting very tired of waiting. Then add in the lawsuit gag order type issue when it seemed like all communication was suddenly cut off, geesh. But now in retrospect I can see why it took so long after basically an entire rewrite of the application.There are some here who participated in that initial look at the *New Smugmug* internal release several years ago. We all had major concerns most of which revolved around the inflexible, somewhat quirky interface at the time. So SM went back to the drawing board and answered with this new product, but not before some customers got fed up waiting and left. I'm glad I didn't and their effort was not in vain, not by a long shot. I think the same will happen this time around. Some will leave because they simply don't want to wait any longer to see what the final outcome will be with XYZ feature. Let's call it JS for now since that seems to be the latest hot button issue. IMO, I think its worth waiting to see what SM comes up with.
There is a limit to how long people will wait, particularly for stuff that SmugMug clearly has reservations with. For me I would say that anything released this year can be considered refinement of the initial release, anything not in by Christmas is likely not a priority and could well end up on the pile of "stuff we might eventually get round to"
Trying to understand what direction they are going as well.
I asked a while back in the following thread but they didn't answer. http://dgrin.com/showthread.php?t=239231
It would be enlightening to know what SmugMugs vision/mission statement is...
Evolving is great, I don't want to spend hours cutting and pasting, writing or tweaking code only to find out that it will be as simple as a keystroke in the future or have hours of work flushed down the toilet if a SmugMug 2 or 3 comes out!
I really feel for the JS coders that have worked many hours to bring beautiful slideshows and work arounds.(notice I didn't say hacks). Many were works of pure genius and came about because SmugMug couldn't get the job done.
I was one of the vocal ones about pushing out the upgrade. It was over two years in the making.
The feature request list is still a mile long and now we have to request things we had in the old system that are missing in the new.
Yes, that is why I am holding off on the fine tuning, custom code thing for now. I am happy enough with the out of the box look and feel to not feel compelled to start tweaking all the little things yet. But some have already started in earnest if you visit the customization forum. Those aren't even JS customizations. But still they involve quite a bit of cut and pasting of code. I think its somewhat premature for that so early on after the initial release. Maybe those little tweaks (some not so little) could get added into the SM feature set if a submittal path exists for improvements like this which would benefit all.
I have tweaked lots already. Sometimes to overcome limitations in new smug, sometimes just to make my site a bit nicer. Most tweaks have been through asking the CSS whizzes or just copying the work others had put in. Yeah SmugMug might add that next week, but I bet they won't. And other than wufoo, I've been correct.
Tweaks :
Removed video options from search box. V happy with this, easy fix.
Individual Custom background images on any gallery. Again just cut n paste CSS.
Wufoo forms. First added them using the blogger hack, which was then "fixed" without warning on the day I was set to unveil. Then coded a Google sites page to match my smug site, just to host wufoo. This was a bit of a pain, but enough for me to launch with. Then smug launched their wufoo solution, which I quickly added.
Few other layout bits n pieces.
Otherwise, spent as much time on the supposedly easy to use template creator trying to get things in a fit state. Redid a lot of my feature pages from scratch, and manually added numbered captions some client galleries to make up for the absence of numbers on non-SmugMug style galleries. Moving over has been a PITA which is why I wince when people say "just do it, it will take 15 mins and be great". It didn't. Adding a few css tweaks here and there afterwards has added only marginal effort to the migration process.
That being said, taking your argument to its conclusion, smugmug code could bring down Amazon's servers, or significantly affect their other customers. I'm pretty sure Amazon doesn't ask to vet smugmug's code though.
No, bad code on your server cannot bring down Amazon's servers, or affect other customers. Each customer is pretty much perfectly isolated from each other to ensure that this isn't possible. This is why Amazon don't need to care what you're doing, or how much you end up 'ruining' your independent slice of the machine you're using.
If instead you're using one of those $100/year shared-hosting cheap servers, your code DOES affect other customers on the same server. And as soon as you consume too many system resources, slowing down other customers, they'll delete your website and ban you from the service.
Please come back to your site on August 19th and you will see the migrate button on your site.
Back from my business trip and was sitting down to work on this. I don't see a 'migrate' button anywhere on my site. And the only way I can find ANY obvious link to the place to go to start the migration is by doing an search on 'smugmug migration' with a general internet search engine. The SmugMug help pages give all kinds of help on what to do AFTER you migrate but nothing to help you actually get started.
Back from my business trip and was sitting down to work on this. I don't see a 'migrate' button anywhere on my site. And the only way I can find ANY obvious link to the place to go to start the migration is by doing an search on 'smugmug migration' with a general internet search engine. The SmugMug help pages give all kinds of help on what to do AFTER you migrate but nothing to help you actually get started.
I was able to figure it out from a general web search, but isn't there supposed to be a 'migrate' button and shouldn't the general migration help have that info front and center?
I was able to figure it out from a general web search, but isn't there supposed to be a 'migrate' button and shouldn't the general migration help have that info front and center?
This information and link was also included in an email they sent all customer entitled "The New SmugMug is here." Both of which took me ~ 3-4 seconds to find. So I'm not sure why this would be any real issue?
... because a button to migrate (or upgrade, or change) is a logical and expected visual element to have on the website that announces a migration step. The button was supposed to be ON THE USER'S WEBPAGE the moment the user signs in or in the user's Account Settings. To have the link posted in the forum, or in the help pages area - is a very un-intuitive, user unfriendly, backward approach. Yes, it didn't take me too long to find the link. I actually had to ask this question in this forum:) So, it didn't take too much of my time. But I am still, up until this day puzzled how come the button or the link or any other visual element was not present loud and clear on my website as I signed in after the migration was announced.
Comments
Posted from Nexus 7 using Tapatalk
But webmasters do. If it was a site hosted elsewhere I could add whatever I wanted. It's up to the site owner whether they want to run a gamut of unit testing, integration testing and so forth; particularly for a small company or sole trader, they're quite at libertyto make changes without spending weeks testing against every eventuality should they choose to - in fact it my be not only desirable but essential. We absolutely do have that privilege, and it is not inevitable that we should be subject to a lengthy process to make minor changes to our smugmug sites.
Posted from Nexus 7 using Tapatalk
I hope John doesn't mind me saying that we've been talking for a long time, over a year, about how to distribute his slideshow in new SmugMug. The model that seems simplest on the surface is he submits it to our QA, same as if he were submitting an app to Apple's appstore. We write back with bugs we find, and he re-submits. Or we publish if we don't find any.
The benefit to us and our customers is it reaches 100% of them in a very easy way, not just the small percent who are willing to brave dgrin and do their own install.
If I were John, the concerns I'd have are how quickly will SmugMug respond if there's a bug he has to fix, or what the release process is when he has an upgrade or we do something to break his app. Apple's Appstore can be frustrating to work with in that regard.
The concern I have for SmugMug is we shouldn't enter into something like this unless there's a long-time commitment to bug fixes and upgrades. Imagine if several hundred thousand of our customers install it and he's no longer around to maintain it. As will all software, including Apple's, the host company has to make changes which inevitably breaks many apps, so the developers have to quickly fix their apps or get dropped from the store.
Our situation is different in that we can't just drop his slideshow if it breaks due to some security patch we have to issue, or whatever. It's integral to a photographer's home page.
I am working with another slideshow maker whose slideshow is also gorgeous, to distribute theirs with new SmugMug. But we have hurdles to overcome for things that you would expect of us. One is that we would have to have the rights to their source code to fix it in the event something happens to them (they get acquired, or whatever).
Software developers who post here can understand a constraint we currently have on legacy SmugMug that Apple doesn't. When an app crashes on the iPhone, everyone blames the developer, not Apple. And that gives Apple the freedom to innovate while the developers understand they have to fix their apps as Apple makes changes.
Today, on existing SmugMug, if someone's customization breaks due to some change we make, even if the breakage comes from a third-party JavaScript, our customers perceive that we introduced a bug even if it's really a security patch.
So another very big benefit of distributing a third party slideshow is that it can be branded as one so everyone knows that they are dependent on the third party. But as I mentioned above, the stakes are still higher than if it were an app on your iPhone.
Sure, as long as it doesn't conflict with the companies larger goals and overall architecture which it obviously has over the years.
One of the main problems is that most customers, web designers, etc... think only inside the scope of their own websites and do not realize they are actually apart of and therefore impacting a much larger product. SM, in this case, was allowing customers unlimited access to add any JS they wanted throughout their site. Unfortunately that does not occur in a vacuum but rather effects SM's overall functionality, agility and ability to simply modify their own product over time. Freedom is fine until it impacts someone else's which in this case is the larger product that in turn impacts millions of customers. Hence the huge delay to market of this long awaited release. This was the the # 1 reason updating SM was so difficult and still is today. It's also the primary reason behind these loudest complaint threads. Why can't I just do it my way, no questions asked?
My Smugmug Gallery
Musings & ramblings at https://denisegoldberg.blogspot.com
My Website index | My Blog
Thanks for the clarification. Appreciated
On the question of whether it was a mistake to open up Pandora's box way back when, I've been dying to ask Tom Anderson of Myspace that question. It definitely launched us like it did Myspace and then became a yoke around both of our necks.
Even so, we had fully intended to deploy it up to 60 days before launch, when the practical issues caused us to delay. And now, as you peel the onion and see how deep the practical issues are, it makes me ask did sites like WordPress achieve so much success despite their lack of JavaScript support or because of it?
You mentioned the practical issues are lost on many customers. My thoughts have shifted about that. Here on dgrin I see and feel the pain like everyone does of people who used to be able to paste JavaScript and get instant results. But I have the good fortune of interacting with all of our customers and a tremendous sense of calm has come over me.
One thing is making the popular JavaScript apps built in and supported to the 95% instead of to just the 5% has been a major boon. Another, and Denise Goldberg can testify to this one, is how much pain and frustration customers and our heroes felt when they copied and pasted JavaScript, didn't understand it, and got unexpected results they couldn't debug. And a third is we have a set of customers who are even more passionate than the pro-JavaScript camp against deploying it as we did in the past. The heat of this debate made us pay more attention to their concerns and I feel that once more people hear about those issues, they'll understand why we have to proceed with so much caution.
I think you're making a lot of assumptions there, particularly about the reasons why this rollout took so long.
Code on my site *shouldn't* affect other smugmug users. I'm not saying it doesn't, but it shouldn't. If it does, there's either a problem with the code, or a problem with smugmug's setup. Likewise smugmug rolling out a change or fix, and it somehow 'breaking' our javascript. If the javascript is sound, and the smugmug fix is sound, and neither have some dirty hacks then one shouldn't affect the other.
Of course, as a former developer myself, 'dirty hacks' are part and parcel of the business. That being said, taking your argument to its conclusion, smugmug code could bring down Amazon's servers, or significantly affect their other customers. I'm pretty sure Amazon doesn't ask to vet smugmug's code though.
What I'm seeing here, on the unrepresentative microcosm of dgrin (and to a certain extent on G+), is a few customers arguing for its inclusion, a whole host of customers not really caring either way, and a few customers saying "this is why it might not be as easy as you like to add Javascript". Not really seeing anyone up in arms with concerns about it possibly being included in future. Of course, I see far fewer customers opinions on it than Smugmug does!
I agree. Which is why this dialogue is helpful, if occasionally painful for both sides at times.
Paul, I see where you are coming from. But what I'm saying regarding impacts are very real and not assumptions. Rather they are the facts of the rollout stated by SM themselves. The main point you make though is that one shouldn't necessarily effect the other, at least in a perfect world. Still, they have and continue to, whether that be hacks introduced by customers unknowingly or patches SM makes for security reasons among others which impact old 'custom' code or a major release that changes fundamental behavior of their site. Still I think you are on the right track. One shouldn't effect the other. That is really the challenge for the SM team in introducing JS back in a responsible, decoupled fashion.
The major difference between SM and a site you or anyone else hosts on Amazon is that this is a *shared* application. There is a coupling of customer code with SM and they both have to run together as one product - one web application in the same space. Of course another web app running on Amazon or any other host won't have similar impacts because they are *separate* applications. SM is closer to a shared open sourced product than it is a host where you have freedom as a webmaster to create your own website, not impacting others. Infrastructure is much different than the web application layer which shares that same space.
The concept that one is a webmaster in not correct nor was it in the legacy SM either. While for some there were more freedoms in Legacy SM it was still a templated image host in many regards with many more limitations. Those templates were both extremely outdated and locked in place. So in that regard many of us have more freedoms now to create what we really wanted before but couldn't. SM listened to what we were asking for big time. It is also why they received a huge influx of new users and why the majority of customers are much happier now.
Of course in a support forum such as this you will hear a statistically slanted view from those who have issues and are trying to get resolution. You won't see as many customers saying how much better SM works for them now. Though I'm sure this is happening in other venues.
My Smugmug Gallery
Exactly, that is same model which makes other hosts so successful and more agile. If you can shift away from having to work around so many variations of someone else's code to implementing new features faster the majority of customers will benefit. The new SM is already much more intuitive and easier to work with right out of the box. Proving agility here will be the key which I have been seeing already with all of the updates since the major release date. Your team has been working double time. But I would imagine it is also easier now to implement the changes.
Of course certain things will take a bit more time and planning to get right like the complexities of introducing JS back in a more responsible way. Paul does make a good point that one *shouldn't* necessarily effect the other. But its getting there that is the real challenge. I just don't see how that could ever happen without some degree of oversight and QA. I also would think that process could evolve over time. Maybe allow JFriend or other JS customizers to pilot it? To help streamline this process I would recommend putting out a *best practices* to follow for those who want to submit a new feature. These would be in line with SM's current best practices. That would help streamline the time from submittal, approval, QA to deploy I think as well as minimizing potential conflicts.
I also think it's great that you are willing to listen to all the issues on here and consider them when going back to the team. Maybe you're right in that while some of what is stated may not be understood it still helps to have the conversation. At least then you hear what customers really want, even if a bit different than what currently exists in the new SM.
My Smugmug Gallery
That's true, and occasionally we'd run into issues in legacy as well,where we wanted to do 'webmaster' things but were unable with the existing infrastructure. I forget the details but I think it was stuff like adding sitemaps ourselves, probably a couple of other bits too. Its a spectrum, and as it stands right now, we've moved a few notches away from "total control". I'm still trying to figure out whether that's intentional, and/or permanent and/or within my requirements.
The fact is I am struggling to understand the direction Smugmug is going in, making it difficult for me to predict what they will do next (or indeed not do). As one of my most important suppliers, that uncertainty troubles me, probably more so than where exactly on the 'control/customisation' scale we end up sitting.
Hence posting lots of rambling thoughts and obscure questions
Could it be that SM's direction is evolving somewhat even as we speak, especially with regards to some of these additional features asked for? I would say yes and at least *part* of that evolution is based upon user input Baldy and other SM'ers receive on forums such as this. I think part of the problem and benefit of a more conversational approach like this with customers is that during the evolution of a product things aren't set in stone yet. And most customers are not used to that paradigm. They want a Yes or No answer right away rather than 'we're working on it and you are a part of the potential solution.' The problem with the later is that it makes folks nervous. Either this thing meets my needs or it doesn't. And that is true with most products and services really.
I'll admit also that there was a time I was very frustrated with how loooOONG the new release was taking. There were so many things with the old SM just not working for me anymore. I was also getting very tired of waiting. Then add in the lawsuit gag order type issue when it seemed like all communication was suddenly cut off, geesh. But now in retrospect I can see why it took so long after basically an entire rewrite of the application.There are some here who participated in that initial look at the *New Smugmug* internal release several years ago. We all had major concerns most of which revolved around the inflexible, somewhat quirky interface at the time. So SM went back to the drawing board and answered with this new product, but not before some customers got fed up waiting and left. I'm glad I didn't and their effort was not in vain, not by a long shot. I think the same will happen this time around. Some will leave because they simply don't want to wait any longer to see what the final outcome will be with XYZ feature. Let's call it JS for now since that seems to be the latest hot button issue. IMO, I think its worth waiting to see what SM comes up with.
My Smugmug Gallery
Sent from my PadFone 2 using Tapatalk 4
It would be enlightening to know what SmugMugs vision/mission statement is...
Yes, that is why I am holding off on the fine tuning, custom code thing for now. I am happy enough with the out of the box look and feel to not feel compelled to start tweaking all the little things yet. But some have already started in earnest if you visit the customization forum. Those aren't even JS customizations. But still they involve quite a bit of cut and pasting of code. I think its somewhat premature for that so early on after the initial release. Maybe those little tweaks (some not so little) could get added into the SM feature set if a submittal path exists for improvements like this which would benefit all.
My Smugmug Gallery
Tweaks :
Removed video options from search box. V happy with this, easy fix.
Individual Custom background images on any gallery. Again just cut n paste CSS.
Wufoo forms. First added them using the blogger hack, which was then "fixed" without warning on the day I was set to unveil. Then coded a Google sites page to match my smug site, just to host wufoo. This was a bit of a pain, but enough for me to launch with. Then smug launched their wufoo solution, which I quickly added.
Few other layout bits n pieces.
Otherwise, spent as much time on the supposedly easy to use template creator trying to get things in a fit state. Redid a lot of my feature pages from scratch, and manually added numbered captions some client galleries to make up for the absence of numbers on non-SmugMug style galleries. Moving over has been a PITA which is why I wince when people say "just do it, it will take 15 mins and be great". It didn't. Adding a few css tweaks here and there afterwards has added only marginal effort to the migration process.
No, bad code on your server cannot bring down Amazon's servers, or affect other customers. Each customer is pretty much perfectly isolated from each other to ensure that this isn't possible. This is why Amazon don't need to care what you're doing, or how much you end up 'ruining' your independent slice of the machine you're using.
If instead you're using one of those $100/year shared-hosting cheap servers, your code DOES affect other customers on the same server. And as soon as you consume too many system resources, slowing down other customers, they'll delete your website and ban you from the service.
I've been in both of these situations before
Please check out my gallery of customisations for the New SmugMug, more to come!
Back from my business trip and was sitting down to work on this. I don't see a 'migrate' button anywhere on my site. And the only way I can find ANY obvious link to the place to go to start the migration is by doing an search on 'smugmug migration' with a general internet search engine. The SmugMug help pages give all kinds of help on what to do AFTER you migrate but nothing to help you actually get started.
login
go to yoursite.smugmug.com/migration
Portfolio • Workshops • Facebook • Twitter
I was able to figure it out from a general web search, but isn't there supposed to be a 'migrate' button and shouldn't the general migration help have that info front and center?
Why would there be a button? I don't ever remember anyone saying anything about a button. It's right on their migration page here with instructions: http://help.smugmug.com/customer/portal/articles/1212681-making-the-move-from-legacy-to-new-smugmug
This information and link was also included in an email they sent all customer entitled "The New SmugMug is here." Both of which took me ~ 3-4 seconds to find. So I'm not sure why this would be any real issue?
My Smugmug Gallery
... because a button to migrate (or upgrade, or change) is a logical and expected visual element to have on the website that announces a migration step. The button was supposed to be ON THE USER'S WEBPAGE the moment the user signs in or in the user's Account Settings. To have the link posted in the forum, or in the help pages area - is a very un-intuitive, user unfriendly, backward approach. Yes, it didn't take me too long to find the link. I actually had to ask this question in this forum:) So, it didn't take too much of my time. But I am still, up until this day puzzled how come the button or the link or any other visual element was not present loud and clear on my website as I signed in after the migration was announced.