Why on earth would there be a minimum speed requirement? SmugMug works fine over modems. You can upload over 9600bps if you want to. It'll take some time - but it'll work fine. The majority of our customers are on 128k - 256k connections.
I seriously doubt that people paying for 128k upstream are surprised when SmugMug delivers only 128k. We certainly don't hear that from any of our customers. The overwhelming response we get is that we're crazy fast, and we hear from plenty of customers asking us to *turn down* upload speeds, like jfriend mentioned. (That's a real feature request in our tracker right now - I presume for shared connections - and we're looking into it).
What am I missing? When I look at your data in our logs, I see that you've got high throughput (2Mbps/file) and low error rates (less than 1%). What's the complaint here?
Here are my complaints which I think are felt much more by people without super fast connections who do large uploads:
1) You offer no way to do unattended uploads that span multiple galleries (like uploading 600 photos across 20 galleries overnight). Important feature for people putting up event photos.
2) When there's a connection glitch, you just fail. You don't retry. You don't leave the failed images in the queue to be tried again with a single button press. If I set up an upload and it fails shortly into it (like it did for me on Thursday night), the whole upload is shot. I have to wake up the next morning and discover that NOTHING uploaded and I have to start the whole thing over again. When the uploader glitches in the middle of the night and stops, it can cost me an entire day in getting photos online.
3) Your own uploaders don't handle your own read-only modes gracefully (like Thursday nights). They just fail and leave you to re-specify and start-over the entire upload when you discover that things didn't upload properly. One would think that your uploaders should be able to "know" about read-only mode and temporarily suspend their work until read-only mode ends, resuming when the coast is clear.
4) There's no easy way to pause an upload when shared bandwidth needs to be used for something else. I press the pause button and the currently uploading images just keep going. Pause means pause. BackBlaze has a wonderful model here where you can pause the backup and it will restart automatically in 2 hrs so I don't have to remember to start it again. Of course, if you want it to pause indefinitely, you can do that too.
One model to look at is the BackBlaze uploader (online backup utility). I just tell it what to do and it just gets the bits online with NO further intervention by me, regardless of outages, glitches, service maintenance, anything. It knows what I told it to do and it just keeps working at it until the job is done. Why shouldn't the Smugmug uploader just do that? I told it what to upload. Why should it give me an error and stop and make me start the whole uploader again? That's ridiculous. It's software - it should just do what I told it to do. If there's a problem that doesn't appear to be permanent, it should just retry and keep going until it gets the job done.
I'm quite confident that if you had to do the types of uploads I do on the bandwidth I have and you had a time deadline to get things uploaded by and you shared the internet connection with the rest of the internet users in the house, you'd clearly see the need for significant uploader improvements.
Here are my complaints which I think are felt much more by people without super fast connections who do large uploads:
1) You offer no way to do unattended uploads that span multiple galleries (like uploading 600 photos across 20 galleries overnight). Important feature for people putting up event photos.
Not exactly true. There are numerous 3rd party uploaders that allow this. It's not a common enough request (yet) for us to build something ourselves, but this is why we have an API and a vibrant developer community.
2) When there's a connection glitch, you just fail. You don't retry. You don't leave the failed images in the queue to be tried again with a single button press. If I set up an upload and it fails shortly into it (like it did for me on Thursday night), the whole upload is shot. I have to wake up the next morning and discover that NOTHING uploaded and I have to start the whole thing over again. When the uploader glitches in the middle of the night and stops, it can cost me an entire day in getting photos online.
Wrong. We do retry. But we're not smart enough about it, and your prior post had some good, specific actions we can take. Stay tuned.
3) Your own uploaders don't handle your own read-only modes gracefully (like Thursday nights). They just fail and leave you to re-specify and start-over the entire upload when you discover that things didn't upload properly. One would think that your uploaders should be able to "know" about read-only mode and temporarily suspend their work until read-only mode ends, resuming when the coast is clear.
4) There's no easy way to pause an upload when shared bandwidth needs to be used for something else. I press the pause button and the currently uploading images just keep going. Pause means pause. BackBlaze has a wonderful model here where you can pause the backup and it will restart automatically in 2 hrs so I don't have to remember to start it again. Of course, if you want it to pause indefinitely, you can do that too.
Fair point. There may be some limitations in the File API with HTML5 for why this behaves the way it does - our hands might be tied. I honestly don't know.
One model to look at is the BackBlaze uploader (online backup utility). I just tell it what to do and it just gets the bits online with NO further intervention by me, regardless of outages, glitches, service maintenance, anything. It knows what I told it to do and it just keeps working at it until the job is done. Why shouldn't the Smugmug uploader just do that? I told it what to upload. Why should it give me an error and stop and make me start the whole uploader again? That's ridiculous. It's software - it should just do what I told it to do. If there's a problem that doesn't appear to be permanent, it should just retry and keep going until it gets the job done.
Fair point, especially in the majority use case. There are times where we simply can't do what you ask - but the majority use case should be pretty simple to accomplish where it just 'does the right thing' on hiccups.
I'm quite confident that if you had to do the types of uploads I do on the bandwidth I have and you had a time deadline to get things uploaded by and you shared the internet connection with the rest of the internet users in the house, you'd clearly see the need for significant uploader improvements.
Actually, I'm frequently in this boat. I often upload to SmugMug on shared 3G connections with other people doing file transfers and playing games. I haven't had many issues other than the uploads take forever. Success rate is high, usability of other people on the connection is high, and that's with a lot less bandwidth than you have.
What am I missing? When I look at your data in our logs, I see that you've got high throughput (2Mbps/file) and low error rates (less than 1%). What's the complaint here?
In my particular case, 2mb is less than 50% when the pipe is 5mb. Don't get me wrong, the improvement is great, but there's still room to go. Once I have time to play with Chrome this may change since each uploader instance will hopefully attempt 6mb (2mb x 3). Then finally I'll get the pipe filled without spending a lot of time manually optimizing each upload session. That means valuable sleep time for me after 20hrs+ of shooting on a weekend.
2) When there's a connection glitch, you just fail. You don't retry. You don't leave the failed images in the queue to be tried again with a single button press. If I set up an upload and it fails shortly into it (like it did for me on Thursday night), the whole upload is shot. I have to wake up the next morning and discover that NOTHING uploaded and I have to start the whole thing over again. When the uploader glitches in the middle of the night and stops, it can cost me an entire day in getting photos online.
I have experienced this and it's NOT a great feeling in the morning. Especially when the upload would have taken 6-12hrs to begin with.
And something to add on this is the ability to continue a batch without the issue of duplicates. Even after five years with SM, I still have to check the number of files uploaded vs what was in my original batch. And a good number of times when I've had an upload crash and I've resumed, I end up with duplicates. These are a pain to find and eliminate too. A "fire once and forget it" uploader like John describes below should be able to address this issue as well.
One model to look at is the BackBlaze uploader (online backup utility). I just tell it what to do and it just gets the bits online with NO further intervention by me, regardless of outages, glitches, service maintenance, anything. It knows what I told it to do and it just keeps working at it until the job is done. Why shouldn't the Smugmug uploader just do that? I told it what to upload. Why should it give me an error and stop and make me start the whole uploader again? That's ridiculous. It's software - it should just do what I told it to do. If there's a problem that doesn't appear to be permanent, it should just retry and keep going until it gets the job done.
This would be the idea setup. You tell it what to do and it figures out the fastest possible way to do this accurately. Fighting with the upload process takes our time away from marketing our work, gaining clients and sales, and ultimately from making money, on which SM loses out on too. Improving the upload process is a win-win for both SM and its users.
Not exactly true. There are numerous 3rd party uploaders that allow this. It's not a common enough request (yet) for us to build something ourselves, but this is why we have an API and a vibrant developer community.
I know about the 3rd party uploaders and I use one. It's got it's own faults, but is a better option for some uploading. Saves me 20-30 minutes all by itself just when creating the 20 galleries for an event because it can do multiple gallery create with all the same settings in one operation (I just type one unique gallery name per line in an edit box). Massively faster than what Smugmug offers.
If you're not interested in supporting the needs of event photographers who need to get a lot of images online into multiple galleries quickly, that would surprise me. You may be surprised how many event pros would love this. Maybe they don't know what they're missing and they're just spending a lot more time doing the uploading than they need to. My curse is that I know how well it could be done so I tend to say something when the experience is less than what it could be.
Wrong. We do retry. But we're not smart enough about it, and your prior post had some good, specific actions we can take. Stay tuned.
They do know, they're just dumb. Stay tuned.
Sounds like some improvements might be coming. That's good. The fact that you have so many different browser-based uploaders almost seems like a false economy when a real downloadable app could be so much more capable than a browser-based solution. One for Mac, one for Windows (those two could share a lot of their code) and a max of two browser based uploaders for everything else might get you a better user experience, much better features and a lot fewer pieces of separate code to maintain or continually enhance. The fact that a single browser window mistake can kill an entire upload right in the middle is quite a compromise from a browser-based app - not to mention simple things like an inability to show per-file progress in FF4 or pause an upload mid-file, a missed drop target that wipes out the whole upload configuration you've spent 30 minutes setting up, etc.... None of these would be issues in a thick client. Browser-based apps can do a lot of things, but when it comes to user experience, they still suck compared to a thick client in a lot of areas.
Fair point. There may be some limitations in the File API with HTML5 for why this behaves the way it does - our hands might be tied. I honestly don't know.
Fair point, especially in the majority use case. There are times where we simply can't do what you ask - but the majority use case should be pretty simple to accomplish where it just 'does the right thing' on hiccups.
Actually, I'm frequently in this boat. I often upload to SmugMug on shared 3G connections with other people doing file transfers and playing games. I haven't had many issues other than the uploads take forever. Success rate is high, usability of other people on the connection is high, and that's with a lot less bandwidth than you have.
We'll try to keep it in mind, though.
If you can upload 600 full-res 12MP photos and 20 2 minute HD videos to 20 galleries on a shared 3G connection with a teen playing an MMORPG XBox interactive online game and a wife trying to use the internet and have everyone be happy, I'd love to see that. Nobody in our house is happy in that scenario with more wired bandwidth than a 3G connection has. I have to stop the Smugmug upload until the others are done with the internet That's why I have to upload overnight or while others are gone during the day.
If you can upload 600 full-res 12MP photos to 20 galleries on a shared 3G connection with a teen playing an MMORPG XBox interactive online game and a wife trying to use the internet and have everyone be happy, I'd love to see that. Nobody in our house is happy in that scenario with more wired bandwidth than a 3G connection has. I have to stop the Smugmug upload until the others are done with the internet. That's why I have to upload overnight or while others are gone during the day.
A lot of routers will allow you to give priority to certain data such as online games, VOIP, etc. In my experience it works quite well. I routinely have a smugmug upload going at the same time as someone else in the house is gaming or using VOIP without any complaints. My upload bandwidth is about 1Mbps. My router gives priority to the VOIP/gaming packets so my upload is slower than otherwise, but that keeps my upload from hogging all the bandwidth.
Look for QoS (Quality of Service) in your router configuration.
Look for QoS (Quality of Service) in your router configuration.
While this is the ultimate solution, what if John doesn't have a QoS router? What if he doesn't know how to configure it? Then again uploading becomes a barrier. I feature that allows the user to simply adjust how much of the bandwidth is being used by the uploader would eliminate this configuration step that might thwart users.
While this is the ultimate solution, what if John doesn't have a QoS router? What if he doesn't know how to configure it? Then again uploading becomes a barrier. I feature that allows the user to simply adjust how much of the bandwidth is being used by the uploader would eliminate this configuration step that might thwart users.
I wasn't suggesting that QoS was the answer, simply that it was another option to help manage limited upload bandwidth when multiple users and devices are competing for it. A bandwidth throttle similar to that used in Backblaze, Crashplan, and other backup programs would be an interesting feature.
A lot of routers will allow you to give priority to certain data such as online games, VOIP, etc. In my experience it works quite well. I routinely have a smugmug upload going at the same time as someone else in the house is gaming or using VOIP without any complaints. My upload bandwidth is about 1Mbps. My router gives priority to the VOIP/gaming packets so my upload is slower than otherwise, but that keeps my upload from hogging all the bandwidth.
Look for QoS (Quality of Service) in your router configuration.
Interesting idea.
I looked and my router has some QOS capabilities. None of the things I need to prioritize for are built in as a menu option so I have to now do research on how to configure it for the appropriate games/applications (ports, IP address, type of connection, etc...) and none of this helps other internet browser users in the house. And, I know from experience that even if I figure out how to get it going once, I'll never remember how it worked 6 months from now when it needs to be updated again and I'll have to learn it all over again because I don't do this kind of stuff for a living.
I will probably try to figure this out for my own situation, but this is hardly something that the majority of Smugmug customers can do themselves. I help people on dgrin every day and I know that many of them are not this capable.
In my particular case, 2mb is less than 50% when the pipe is 5mb. Don't get me wrong, the improvement is great, but there's still room to go. Once I have time to play with Chrome this may change since each uploader instance will hopefully attempt 6mb (2mb x 3). Then finally I'll get the pipe filled without spending a lot of time manually optimizing each upload session. That means valuable sleep time for me after 20hrs+ of shooting on a weekend.
Our uploaders upload 3 at a time on purpose for just this reason. Which means we're trying to send at 6Mbps, so we're saturating your line.
If you're not interested in supporting the needs of event photographers who need to get a lot of images online into multiple galleries quickly, that would surprise me. You may be surprised how many event pros would love this. Maybe they don't know what they're missing and they're just spending a lot more time doing the uploading than they need to. My curse is that I know how well it could be done so I tend to say something when the experience is less than what it could be.
John, we talk to event photographers constantly, as you can imagine. They have given us lists of TODOs that are years long. I can't remember multi-gallery uploading coming up once, but that could be because many of them are using Lightroom and already use our built-in support to handle this.
Certainly on the *long* list of things they have us working on, this rates near the bottom. Wish I had a better answer for you.
Sounds like some improvements might be coming. That's good. The fact that you have so many different browser-based uploaders almost seems like a false economy when a real downloadable app could be so much more capable than a browser-based solution. One for Mac, one for Windows (those two could share a lot of their code) and a max of two browser based uploaders for everything else might get you a better user experience, much better features and a lot fewer pieces of separate code to maintain or continually enhance. The fact that a single browser window mistake can kill an entire upload right in the middle is quite a compromise from a browser-based app - not to mention simple things like an inability to show per-file progress in FF4 or pause an upload mid-file, a missed drop target that wipes out the whole upload configuration you've spent 30 minutes setting up, etc.... None of these would be issues in a thick client. Browser-based apps can do a lot of things, but when it comes to user experience, they still suck compared to a thick client in a lot of areas.
We've talked to our customers, done user testing, looked at the industry surveys, etc - and they all point to one inescapable conclusion: As a general rule, people are allergic to downloading desktop software. They've been trained that it's the best way to get infected by scary things like virii. They've found from experience that it's difficult to install, update, maintain, fix, etc.
With the rise of the Mac App Store and the coming Windows App Store, I'm hoping a lot of these concerns go away. But until then, our customers have been emphatic: They won't download and install our desktop app, just like they won't download and install a few of the excellent 3rd party uploaders like SendToSmugMug.
We've talked to our customers, done user testing, looked at the industry surveys, etc - and they all point to one inescapable conclusion: As a general rule, people are allergic to downloading desktop software. They've been trained that it's the best way to get infected by scary things like virii. They've found from experience that it's difficult to install, update, maintain, fix, etc.
With the rise of the Mac App Store and the coming Windows App Store, I'm hoping a lot of these concerns go away. But until then, our customers have been emphatic: They won't download and install our desktop app, just like they won't download and install a few of the excellent 3rd party uploaders like SendToSmugMug.
What desktop app? I'm not even aware you have one.
Desktop software is only difficult to install and maintain when it's implemented poorly. You and I both know that. I, and millions of others (you included probably), have absolutely no issues installing and maintaining Chrome or Firefox, for example. They work great because they have been well engineered for installation and upgrade. Or what about Lightroom or Photoshop that many of your customers already have installed and use? Certainly, they recognize the value of installing software when it does what they want.
I do have zillions of issues with SmugBrowser (add-on for Firefox that is poorly implemented, has no maintainable upgrade strategy and is usually incompatible with my version of Firefox) so much so that I don't use it any more. More trouble than it's worth to try to keep it running all the time. It's a crap piece of software - an excellent example of what can be wrong with desktop software when implemented poorly and it even lives in a browser framework that makes updates trivial (when the software is maintained).
There's junk and there's good software. You and I both know that. If you offered a great thick client upload app that was miles better than what you have now in the browser (which it could be) and was well implemented, well supported and had a solid upgrade strategy, your power users would flock to it in a heartbeat. If you implement only the same functionality in a desktop app or don't do a good job implementing it and making it easy to install and easy to upgrade, nobody will care because there's no advantage, but it could be massively better than what you have now (like BackBlaze's uploader). It could even be a differentiator for you - it could certainly lower support costs. It could certainly speed uploads. It could certainly do a much better job for customers.
I haven't seen that BackBlaze is hurting because they have a thick client uploader. I think it's more that you've just decided you want to stick with browser-based solutions (and are justifying that decision) and you've decided you're going to live with the quirks and limitations of those implementations. So, along the way, you've implemented perhaps half a dozen different pieces of code trying to make that work (and you apparently maintain a bunch of them too). By count you have live on the site right now at least a Java version, a Flash version, an HTML5 version and old faithful. And, they are all handicapped in functionality by their browser-based infrastructure. The fact that one missed drop of a new file you want to upload can wipe out all previous work in configuring the upload is a joke of a user experience. Come, on you can do so much better. Virtually no handling of connectivity issues.
If, what's really going on here is that you're happy with the user experience you have today and don't think it needs to be improved or don't think it's a priority for your business, then you can just say that and I'll move on because then I will know that I just have different expectations for a piece of software I spend hundreds of hours using than you do.
Our uploaders upload 3 at a time on purpose for just this reason. Which means we're trying to send at 6Mbps, so we're saturating your line.
I still don't see the problem?
Not simple uploader in Firefox. And my router has a statistics page that shows the bandwidth percentage being used so I can verify what the uploader says. 2Mbps is all it's using.
I do have zillions of issues with SmugBrowser (add-on for Firefox that is poorly implemented, has no maintainable upgrade strategy and is usually incompatible with my version of Firefox) so much so that I don't use it any more. More trouble than it's worth to try to keep it running all the time. It's a crap piece of software - an excellent example of what can be wrong with desktop software when implemented poorly and it even lives in a browser framework that makes updates trivial (when the software is maintained).
I don't remember SmugBrowser ever being an official SmugMug offering ? As for enlightening you on the plugin's history, I'm not going to bother considering the trollish nature of your post.
Someone who has a background in software development gives his opinion on a piece of software he's used extensively and and he's a troll?
There's one thing I've learned being in customer service over the years--the customer is allowed to have an emotionally charged opinion...as a representative of the business, you aren't.
Someone who has a background in software development gives his opinion on a piece of software he's used extensively and and he's a troll?
There's one thing I've learned being in customer service over the years--the customer is allowed to have an emotionally charged opinion...as a representative of the business, you aren't.
Something to keep in mind.
Lemme get this right....I'm not allowed to make any comments about a piece of code that I wrote prior to working for SmugMug ?
Not simple uploader in Firefox. And my router has a statistics page that shows the bandwidth percentage being used so I can verify what the uploader says. 2Mbps is all it's using.
fwiw, we're now at essentially 100% of uploads going direct to Amazon, which should include third party uploaders.
Scrutinizing the upload errors is pretty fascinating. The error rate is way down, but a small number of users are generating the lion's share of the errors, and most of them do so on both upload endpoints.
Samir, you're one of those. I see that you're a very high volume uploader, and looking at snapshots of your recent uploads they look like this:
From your 3 connections through the new upload endpoint:
From your 3 connections through the old upload endpoint:
You were averaging 1.7 mbps to the old endpoint and 2.1 to the new.
So not much change in error rates for you wrt endpoints.
And that seems to be the story, from what I can tell. Far fewer people are having upload issues now, but a few that were before are still.
I don't remember SmugBrowser ever being an official SmugMug offering ? As for enlightening you on the plugin's history, I'm not going to bother considering the trollish nature of your post.
Wow. It's hard to imagine a more unprofessional response. Jfriend's posts are arguably the biggest assets on this and the customization forum. To call him a troll is completely unfounded. You owe him a public apology.
I actually hate this 3-way concurrent upload. When I'm uploading large videos, any hick-up and the 3 in progress have to be restarted from beginning. And the 3 TCP streams are a lot more intrusive on other activity I may want to do while the upload is going on. But other times I do want multiple simultaneous uploads, and wouldn't even mind going beyond 3. So some sort of a setting somewhere to let the user say how many would be best (hint: like Filezilla does.)
By the way, isn't it funny how enabling Filezilla use would solve all problems raised in this thread, both saturating large pipes and handling small ones?
We've talked to our customers, done user testing, looked at the industry surveys, etc - and they all point to one inescapable conclusion: As a general rule, people are allergic to downloading desktop software. They've been trained that it's the best way to get infected by scary things like virii. They've found from experience that it's difficult to install, update, maintain, fix, etc.
I will not install a separate app whose only purpose is upload to SmugMug, any more than I would install a separate app to view photos on SmugMug, when a generic solution like a browser/ftp client exists/should exist.
Wow. It's hard to imagine a more unprofessional response. Jfriend's posts are arguably the biggest assets on this and the customization forum. To call him a troll is completely unfounded. You owe him a public apology.
Unprofessional? Go read the part of jfriend's post that Devbobo quoted. Then read Devbobo's response. I think it was a remarkably level-headed response to an abusive and ill-informed rant. Devbobo, as a SmugMug customer and enthusiast, built a piece of software that many others have used and loved. He didn't do it for profit or for himself. He did it to help the community. While jfriend may have some issues with it, it's a free piece of software that Devbobo updates in his spare time (and we keep him extremely busy).
We're extremely grateful for all the nice things that jfriend does here on the forum (and there are a lot). His feedback has helped improve numerous SmugMug features as well. He's not a troll, but that particular post was offensive and trollish.
Unprofessional? Go read the part of jfriend's post that Devbobo quoted. Then read Devbobo's response. I think it was a remarkably level-headed response to an abusive and ill-informed rant. Devbobo, as a SmugMug customer and enthusiast, built a piece of software that many others have used and loved. He didn't do it for profit or for himself. He did it to help the community. While jfriend may have some issues with it, it's a free piece of software that Devbobo updates in his spare time (and we keep him extremely busy).
We're extremely grateful for all the nice things that jfriend does here on the forum (and there are a lot). His feedback has helped improve numerous SmugMug features as well. He's not a troll, but that particular post was offensive and trollish.
David and I discussed this in email and I was willing to let it go on the forums, but since you all are continuing to discuss it here, I'll post what I sent David via email after he contacted me directly about my post:
Yeah, I was harsh in my criticism of SmugBrowser. It regularly frustrates me. SmugBrowser was just an example of locally installed software that is a pain to install and maintain on your PC as it pretty much never works when I want to use it because it's out of date for my version of Firefox and it doesn't participate in the add-on update process. I don't think I said anything about it being official Smugmug software. Perhaps you assumed I was blaming Smugmug for that, but I was just using it as an example of locally installed software that is a pain to deal with because it is frequently out-of-date and doesn't participate in the browser auto-update mechanism.
And that seems to be the story, from what I can tell. Far fewer people are having upload issues now, but a few that were before are still.
Facinating. Although the data doesn't account for one thing that will lead to failed uploads--the uploader crashing. On large batches like I've been doing lately, the parsing of all the video files while adding files to another instance can crash the jre. And I'm sure that results in at least some failed uploads.
It's interesting to see the error rate as it reflects a known issue with my connection that only gives me any real issues when downloading a zip.
I actually hate this 3-way concurrent upload. When I'm uploading large videos, any hick-up and the 3 in progress have to be restarted from beginning. And the 3 TCP streams are a lot more intrusive on other activity I may want to do while the upload is going on. But other times I do want multiple simultaneous uploads, and wouldn't even mind going beyond 3. So some sort of a setting somewhere to let the user say how many would be best (hint: like Filezilla does.)
A setting like that would definitely solve my issues. I could set it to 9 and go to sleep earlier.
By the way, isn't it funny how enabling Filezilla use would solve all problems raised in this thread, both saturating large pipes and handling small ones?
Hence why I want FTP uploading capability. If you agree, vote for it!
We're extremely grateful for all the nice things that jfriend does here on the forum (and there are a lot). His feedback has helped improve numerous SmugMug features as well. He's not a troll, but that particular post was offensive and trollish.
As a customer that has to deal with the frustrations of a paid product (SM), I think the customer is allowed to express this frustration with the company that they pay. Now, after repeated attempts to be friendly and cordial about it, at some point you just let the guns fire. I've been there several times myself in the last year. There's just a point when things boil over.
And that's the way I see John's post--as an emotional reaction. Not meaning to be trollish, but no longer sugar coating his true feelings on the matter.
And one of his requests is the most obvious UI blunder I've ever seen with the uploader overlay. It's form over function at it's finest. I have to click three times just to get the normal uploader screen each time, and John has to be careful of where he drags his photos or 100 windows will pop up with all the images he intended to upload. I know if that happened to me on a regular basis, I'd be ready to scream. I think his frustration is well founded and was worded with restraint.
Anybody else still getting 'Album not exist' errors? I've checked my log and I've got errors in there of 'invalid file type' too. I almost wish I could use the old endpoint just to get this work done.
Anybody else still getting 'Album not exist' errors? I've checked my log and I've got errors in there of 'invalid file type' too. I almost wish I could use the old endpoint just to get this work done.
Can you give us the gallery link you're uploading too, and also what browser, and OS, and which uploader are you using? I will help.
Comments
1) You offer no way to do unattended uploads that span multiple galleries (like uploading 600 photos across 20 galleries overnight). Important feature for people putting up event photos.
2) When there's a connection glitch, you just fail. You don't retry. You don't leave the failed images in the queue to be tried again with a single button press. If I set up an upload and it fails shortly into it (like it did for me on Thursday night), the whole upload is shot. I have to wake up the next morning and discover that NOTHING uploaded and I have to start the whole thing over again. When the uploader glitches in the middle of the night and stops, it can cost me an entire day in getting photos online.
3) Your own uploaders don't handle your own read-only modes gracefully (like Thursday nights). They just fail and leave you to re-specify and start-over the entire upload when you discover that things didn't upload properly. One would think that your uploaders should be able to "know" about read-only mode and temporarily suspend their work until read-only mode ends, resuming when the coast is clear.
4) There's no easy way to pause an upload when shared bandwidth needs to be used for something else. I press the pause button and the currently uploading images just keep going. Pause means pause. BackBlaze has a wonderful model here where you can pause the backup and it will restart automatically in 2 hrs so I don't have to remember to start it again. Of course, if you want it to pause indefinitely, you can do that too.
One model to look at is the BackBlaze uploader (online backup utility). I just tell it what to do and it just gets the bits online with NO further intervention by me, regardless of outages, glitches, service maintenance, anything. It knows what I told it to do and it just keeps working at it until the job is done. Why shouldn't the Smugmug uploader just do that? I told it what to upload. Why should it give me an error and stop and make me start the whole uploader again? That's ridiculous. It's software - it should just do what I told it to do. If there's a problem that doesn't appear to be permanent, it should just retry and keep going until it gets the job done.
I'm quite confident that if you had to do the types of uploads I do on the bandwidth I have and you had a time deadline to get things uploaded by and you shared the internet connection with the rest of the internet users in the house, you'd clearly see the need for significant uploader improvements.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Not exactly true. There are numerous 3rd party uploaders that allow this. It's not a common enough request (yet) for us to build something ourselves, but this is why we have an API and a vibrant developer community.
If you'd like us to put a higher priority on it, feel free to ask the community - I don't see anyone else asking for it: http://feedback.smugmug.com/forums/17723-smugmug/category/18459-uploading. If it gets enough votes, we'll build it.
Wrong. We do retry. But we're not smart enough about it, and your prior post had some good, specific actions we can take. Stay tuned.
They do know, they're just dumb. Stay tuned.
Fair point. There may be some limitations in the File API with HTML5 for why this behaves the way it does - our hands might be tied. I honestly don't know.
Fair point, especially in the majority use case. There are times where we simply can't do what you ask - but the majority use case should be pretty simple to accomplish where it just 'does the right thing' on hiccups.
Actually, I'm frequently in this boat. I often upload to SmugMug on shared 3G connections with other people doing file transfers and playing games. I haven't had many issues other than the uploads take forever. Success rate is high, usability of other people on the connection is high, and that's with a lot less bandwidth than you have.
We'll try to keep it in mind, though.
Want faster uploading? Vote for FTP!
And something to add on this is the ability to continue a batch without the issue of duplicates. Even after five years with SM, I still have to check the number of files uploaded vs what was in my original batch. And a good number of times when I've had an upload crash and I've resumed, I end up with duplicates. These are a pain to find and eliminate too. A "fire once and forget it" uploader like John describes below should be able to address this issue as well. This would be the idea setup. You tell it what to do and it figures out the fastest possible way to do this accurately. Fighting with the upload process takes our time away from marketing our work, gaining clients and sales, and ultimately from making money, on which SM loses out on too. Improving the upload process is a win-win for both SM and its users.
Want faster uploading? Vote for FTP!
I know about the 3rd party uploaders and I use one. It's got it's own faults, but is a better option for some uploading. Saves me 20-30 minutes all by itself just when creating the 20 galleries for an event because it can do multiple gallery create with all the same settings in one operation (I just type one unique gallery name per line in an edit box). Massively faster than what Smugmug offers.
If you're not interested in supporting the needs of event photographers who need to get a lot of images online into multiple galleries quickly, that would surprise me. You may be surprised how many event pros would love this. Maybe they don't know what they're missing and they're just spending a lot more time doing the uploading than they need to. My curse is that I know how well it could be done so I tend to say something when the experience is less than what it could be.
Sounds like some improvements might be coming. That's good. The fact that you have so many different browser-based uploaders almost seems like a false economy when a real downloadable app could be so much more capable than a browser-based solution. One for Mac, one for Windows (those two could share a lot of their code) and a max of two browser based uploaders for everything else might get you a better user experience, much better features and a lot fewer pieces of separate code to maintain or continually enhance. The fact that a single browser window mistake can kill an entire upload right in the middle is quite a compromise from a browser-based app - not to mention simple things like an inability to show per-file progress in FF4 or pause an upload mid-file, a missed drop target that wipes out the whole upload configuration you've spent 30 minutes setting up, etc.... None of these would be issues in a thick client. Browser-based apps can do a lot of things, but when it comes to user experience, they still suck compared to a thick client in a lot of areas.
If you can upload 600 full-res 12MP photos and 20 2 minute HD videos to 20 galleries on a shared 3G connection with a teen playing an MMORPG XBox interactive online game and a wife trying to use the internet and have everyone be happy, I'd love to see that. Nobody in our house is happy in that scenario with more wired bandwidth than a 3G connection has. I have to stop the Smugmug upload until the others are done with the internet That's why I have to upload overnight or while others are gone during the day.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
A lot of routers will allow you to give priority to certain data such as online games, VOIP, etc. In my experience it works quite well. I routinely have a smugmug upload going at the same time as someone else in the house is gaming or using VOIP without any complaints. My upload bandwidth is about 1Mbps. My router gives priority to the VOIP/gaming packets so my upload is slower than otherwise, but that keeps my upload from hogging all the bandwidth.
Look for QoS (Quality of Service) in your router configuration.
Want faster uploading? Vote for FTP!
I wasn't suggesting that QoS was the answer, simply that it was another option to help manage limited upload bandwidth when multiple users and devices are competing for it. A bandwidth throttle similar to that used in Backblaze, Crashplan, and other backup programs would be an interesting feature.
I looked and my router has some QOS capabilities. None of the things I need to prioritize for are built in as a menu option so I have to now do research on how to configure it for the appropriate games/applications (ports, IP address, type of connection, etc...) and none of this helps other internet browser users in the house. And, I know from experience that even if I figure out how to get it going once, I'll never remember how it worked 6 months from now when it needs to be updated again and I'll have to learn it all over again because I don't do this kind of stuff for a living.
I will probably try to figure this out for my own situation, but this is hardly something that the majority of Smugmug customers can do themselves. I help people on dgrin every day and I know that many of them are not this capable.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Want faster uploading? Vote for FTP!
Our uploaders upload 3 at a time on purpose for just this reason. Which means we're trying to send at 6Mbps, so we're saturating your line.
I still don't see the problem?
John, we talk to event photographers constantly, as you can imagine. They have given us lists of TODOs that are years long. I can't remember multi-gallery uploading coming up once, but that could be because many of them are using Lightroom and already use our built-in support to handle this.
Certainly on the *long* list of things they have us working on, this rates near the bottom. Wish I had a better answer for you.
We've talked to our customers, done user testing, looked at the industry surveys, etc - and they all point to one inescapable conclusion: As a general rule, people are allergic to downloading desktop software. They've been trained that it's the best way to get infected by scary things like virii. They've found from experience that it's difficult to install, update, maintain, fix, etc.
With the rise of the Mac App Store and the coming Windows App Store, I'm hoping a lot of these concerns go away. But until then, our customers have been emphatic: They won't download and install our desktop app, just like they won't download and install a few of the excellent 3rd party uploaders like SendToSmugMug.
Desktop software is only difficult to install and maintain when it's implemented poorly. You and I both know that. I, and millions of others (you included probably), have absolutely no issues installing and maintaining Chrome or Firefox, for example. They work great because they have been well engineered for installation and upgrade. Or what about Lightroom or Photoshop that many of your customers already have installed and use? Certainly, they recognize the value of installing software when it does what they want.
I do have zillions of issues with SmugBrowser (add-on for Firefox that is poorly implemented, has no maintainable upgrade strategy and is usually incompatible with my version of Firefox) so much so that I don't use it any more. More trouble than it's worth to try to keep it running all the time. It's a crap piece of software - an excellent example of what can be wrong with desktop software when implemented poorly and it even lives in a browser framework that makes updates trivial (when the software is maintained).
There's junk and there's good software. You and I both know that. If you offered a great thick client upload app that was miles better than what you have now in the browser (which it could be) and was well implemented, well supported and had a solid upgrade strategy, your power users would flock to it in a heartbeat. If you implement only the same functionality in a desktop app or don't do a good job implementing it and making it easy to install and easy to upgrade, nobody will care because there's no advantage, but it could be massively better than what you have now (like BackBlaze's uploader). It could even be a differentiator for you - it could certainly lower support costs. It could certainly speed uploads. It could certainly do a much better job for customers.
I haven't seen that BackBlaze is hurting because they have a thick client uploader. I think it's more that you've just decided you want to stick with browser-based solutions (and are justifying that decision) and you've decided you're going to live with the quirks and limitations of those implementations. So, along the way, you've implemented perhaps half a dozen different pieces of code trying to make that work (and you apparently maintain a bunch of them too). By count you have live on the site right now at least a Java version, a Flash version, an HTML5 version and old faithful. And, they are all handicapped in functionality by their browser-based infrastructure. The fact that one missed drop of a new file you want to upload can wipe out all previous work in configuring the upload is a joke of a user experience. Come, on you can do so much better. Virtually no handling of connectivity issues.
If, what's really going on here is that you're happy with the user experience you have today and don't think it needs to be improved or don't think it's a priority for your business, then you can just say that and I'll move on because then I will know that I just have different expectations for a piece of software I spend hundreds of hours using than you do.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Want faster uploading? Vote for FTP!
I don't remember SmugBrowser ever being an official SmugMug offering ? As for enlightening you on the plugin's history, I'm not going to bother considering the trollish nature of your post.
SmugMug API Developer
My Photos
There's one thing I've learned being in customer service over the years--the customer is allowed to have an emotionally charged opinion...as a representative of the business, you aren't.
Something to keep in mind.
Want faster uploading? Vote for FTP!
Lemme get this right....I'm not allowed to make any comments about a piece of code that I wrote prior to working for SmugMug ?
SmugMug API Developer
My Photos
Scrutinizing the upload errors is pretty fascinating. The error rate is way down, but a small number of users are generating the lion's share of the errors, and most of them do so on both upload endpoints.
Samir, you're one of those. I see that you're a very high volume uploader, and looking at snapshots of your recent uploads they look like this:
From your 3 connections through the new upload endpoint:
From your 3 connections through the old upload endpoint:
You were averaging 1.7 mbps to the old endpoint and 2.1 to the new.
So not much change in error rates for you wrt endpoints.
And that seems to be the story, from what I can tell. Far fewer people are having upload issues now, but a few that were before are still.
Wow. It's hard to imagine a more unprofessional response. Jfriend's posts are arguably the biggest assets on this and the customization forum. To call him a troll is completely unfounded. You owe him a public apology.
By the way, isn't it funny how enabling Filezilla use would solve all problems raised in this thread, both saturating large pipes and handling small ones?
And I'm a software developer myself.
Unprofessional? Go read the part of jfriend's post that Devbobo quoted. Then read Devbobo's response. I think it was a remarkably level-headed response to an abusive and ill-informed rant. Devbobo, as a SmugMug customer and enthusiast, built a piece of software that many others have used and loved. He didn't do it for profit or for himself. He did it to help the community. While jfriend may have some issues with it, it's a free piece of software that Devbobo updates in his spare time (and we keep him extremely busy).
We're extremely grateful for all the nice things that jfriend does here on the forum (and there are a lot). His feedback has helped improve numerous SmugMug features as well. He's not a troll, but that particular post was offensive and trollish.
Yeah, I was harsh in my criticism of SmugBrowser. It regularly frustrates me. SmugBrowser was just an example of locally installed software that is a pain to install and maintain on your PC as it pretty much never works when I want to use it because it's out of date for my version of Firefox and it doesn't participate in the add-on update process. I don't think I said anything about it being official Smugmug software. Perhaps you assumed I was blaming Smugmug for that, but I was just using it as an example of locally installed software that is a pain to deal with because it is frequently out-of-date and doesn't participate in the browser auto-update mechanism.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
It's interesting to see the error rate as it reflects a known issue with my connection that only gives me any real issues when downloading a zip.
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
And that's the way I see John's post--as an emotional reaction. Not meaning to be trollish, but no longer sugar coating his true feelings on the matter.
And one of his requests is the most obvious UI blunder I've ever seen with the uploader overlay. It's form over function at it's finest. I have to click three times just to get the normal uploader screen each time, and John has to be careful of where he drags his photos or 100 windows will pop up with all the images he intended to upload. I know if that happened to me on a regular basis, I'd be ready to scream. I think his frustration is well founded and was worded with restraint.
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
Can you give us the gallery link you're uploading too, and also what browser, and OS, and which uploader are you using? I will help.
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!
The cookies don't bother me - I'm quite addicted to those macaroons - just don't mention beer.:D
www.SaraPiazza.com - Edgartown News - Trad Diary - Facebook