This is a little hijack sorry, but I take issue with your statement about "If it gets enough votes, we'll build it"
I have been hassling Andy for literally years (and yes, I'm accurately using that word!) about the lack of foreign currency transactions, and others have been asking for European print labs etc.
Currently 3 of the top 5 requests on your feature request site relate to this, and while Andy has hinted (strongly) that some work might be in progress on some or all of these features, they don't even show as planned or started on your site.
When pressed about the obvious mismatch between what he's been hinting and the site, Andy falls back on "we're a private company and we can choose what we're going to tell you guys about what we're developing"
Again, all perfectly true.
But COME ON! Why can't you please please please be up front about what you're developing, at least update the status of the features on the feature request site!
I love Smugmug, your support is second to none, and the customisation is unbeatable. Long ago however I totally lost faith that you'lll ever be anything but a US Centric company, focussing only on features that appeal to your US based users (pros and viewers).
Even if a foreign currency systems gets implemented, in the intervening 3-4 years between asking for it and now, I've built a Paypal system that works well and accounts for well over 95% of my sales - won't go back to using SM as a payment processor / printer.
I know several local users here in NZ that have let their Smugmug subscriptions lapse purely because we feel you don't care about non-US users, at least not enough to either support anything but US currencies and print providers. A couple of these users had spent months on heavily cusomtised sites and they still left.
You're the boss right? If anyone can fix this and give your non-US based users some proper hope, it's you, right?
How about updating the feature request site with accurate statuses? That would go a HUGE way to making us believe you have some concern for your non-US based users.
Cheers - Neil Gardner
New Zealand
ps, You might drop these features on us tomorrow for all I know, but the point stands, we've been fed this frustrating line for years, might be 3, might be 5 - I've lost count. After this, it'll be another feature - like your maintenance... A site your size simply shouldn't need a maintenance window, but you have it, and for understandable reasons it's ALWAYS in my peak hour.
But COME ON! Why can't you please please please be up front about what you're developing, at least update the status of the features on the feature request site!
...
How about updating the feature request site with accurate statuses? That would go a HUGE way to making us believe you have some concern for your non-US based users.
Though everyone here on dgrin knows I give Smugmug plenty of criticism when things are working as they should, I'll have to come to their defense here. They are in a very competitive business. They have to balance the benefit to their business and their customers by telling us what they are working on versus the competitive disadvantage of telling their competitors what they are working on. It seems perfectly normal to me that some things create no significant disadvantage by telling everyone they're working on them (like uploader improvements) while for other things (probably big new things), they don't really want to tip off their competitors to what they're doing until it's ready to launch.
Keeping their competitors in the dark on those issues gives the competitors less time to react to new and valuable things that Smugmug might be doing that could affect the competitive balance. This is how business works. I understand Smugmug's need not to telegraph everything they're working on to their competitors long ahead of when it ships. Hopefully other customers can understand that too.
If you're a regular member of the community here, you can often "read-between-the-lines" of answers they give and get an idea whether they are actually going to do something about a particular issue (like currency stuff) or not, but you will rarely get a very good idea of how soon it will come and if it's a really important issue to you, it will probably be frustrating to wait. Smugmug knows an uninformed customer will be more frustrated than an informed customer (assuming the news is good), but they have to trade that off vs. informing their competition. Some things will be worth announcing ahead of time, some will not.
After this, it'll be another feature - like your maintenance... A site your size simply shouldn't need a maintenance window, but you have it, and for understandable reasons it's ALWAYS in my peak hour.
I've beat them up pretty good on this one too. I think they're to a size and maturity where most maintenance should be invisible to us. It takes more planning and more development to implement some new features that way, but it is doable. You don't see Gmail having a planned worldwide outage every other Thursday night. They engineer around it. It does slow down deployment of some new features (sometimes requiring more development to implement them without downtime) so it is a tradeoff space, but I think what Smugmug is hearing is that we're voting for less planned downtime even if it slows down some features.
Intelligently retries transient errors a reasonable # of times
Intelligently understands fatal errors and aborts rather than retrying
Understands Read-Only and Service Unavailable states
Offers the user the option to manually retry any remaining uploads that failed auto-retry after a batch is complete (say your ISP died in the middle of the night, but it's morning and you want to retry the remaining 27)
Correctly pauses (aborts) the upload immediately and allows you to resume
Provides SmugMug with additional diagnostic information so we can continue to improve in the future
The Java and Flash uploader upgrades to similar functionality are in testing now. We also will shortly enable all of them to periodically heartbeat back to SmugMug during RO/SU situations and auto-resume when they're ended.
Finally, during many RO/SU type situations, including most Thursday night maintenance windows, all uploaders (including 3rd parties) will often continue uploading uninterrupted. I'd guess greater than 90% of the time, uploaders will continue. I have some ideas on how to get that above 99%, but going from 0-90% seems like a good start.
Finally, we'll be publishing what we do as 'Best Practices' in our API docs so that 3rd party uploaders can behave similarly on the same error types.
There are a few more features we're experimenting with, too, but your ideas on this thread have clearly been invaluable.
Intelligently retries transient errors a reasonable # of times
Intelligently understands fatal errors and aborts rather than retrying
Understands Read-Only and Service Unavailable states
Offers the user the option to manually retry any remaining uploads that failed auto-retry after a batch is complete (say your ISP died in the middle of the night, but it's morning and you want to retry the remaining 27)
Correctly pauses (aborts) the upload immediately and allows you to resume
Provides SmugMug with additional diagnostic information so we can continue to improve in the future
The Java and Flash uploader upgrades to similar functionality are in testing now. We also will shortly enable all of them to periodically heartbeat back to SmugMug during RO/SU situations and auto-resume when they're ended.
Finally, during many RO/SU type situations, including most Thursday night maintenance windows, all uploaders (including 3rd parties) will often continue uploading uninterrupted. I'd guess greater than 90% of the time, uploaders will continue. I have some ideas on how to get that above 99%, but going from 0-90% seems like a good start.
Finally, we'll be publishing what we do as 'Best Practices' in our API docs so that 3rd party uploaders can behave similarly on the same error types.
There are a few more features we're experimenting with, too, but your ideas on this thread have clearly been invaluable.
Thanks!
Wow. It sounds like you went right down my list! Nice going.
Has anything been changed on simple uploader? I saw it magically uploading three photos at a time, which I've never seen before. Awesome if this is a new feature. ivar
Has anything been changed on simple uploader? I saw it magically uploading three photos at a time, which I've never seen before. Awesome if this is a new feature. ivar
We've always done 3 at a time but it wouldn't show in FF for some reason.
Yeah, and it was a big pain for me to set up multiple sessions and it still not max out bandwidth. :cry I'm looking forward to trying this better uploader and seeing if it will max everything out for me.
Some feedback on the 3 at a time in FF. It works well, but now I can't run multiple instances of simple without it being so cpu intensive that all the sessions crash. This used to be an issue when I ran 4-5+ sessions of the old Simple. Has the cpu demand increased this much with the new version of simple?
After using the new Simple uploader with 3-4 concurrent upload sessions on my uploading computers, I want to say kudos to the development team on some really great speed improvements.
I have never seen almost 100% of all my 15Mb upload bandwidth until today. I was able to upload 2GB in just 15mins. And my workflow hasn't altered from when Simple uploader was uploading single files.
Now, if SM can only make it where it will auto-sense maximum bandwidth utilization, and add a slider so people can adjust the percentage of bandwidth they want to use, that fills almost every demand except multiple gallery uploading.
I just saw this when trying to figure out a problem I'm having with the 'download all' feature:
"One thing i'm sure about, is that you can significantly increase upload/download speed using multi-threading. Download managers did this for a very long time, they download file using number of simultaneous threads.
Amazon S3 does support Content-Range header which makes it possible to download single file using several concurrent threads. Each thread can download specific part of file.
Similar technique can be applied for uploads. Recently Amazon S3 team announced support for multipart uploads. This is very similar to multi-thread downloading descried above. Each file can be uploaded using number of concurrent working threads." https://forums.aws.amazon.com/thread.jspa?messageID=243214
Has multi-part uploading been implemented for the newest uploader or just the cloud? Are there plans to implement multi-part uploading? That would be unbelievably awesome. FTP wouldn't even be that fast.
Any changes in the uploader code lately? My usual setup is now giving me errors in the simple uploader with a 'cancel' and 'retry' option. I can't remember exactly what the message was as I've only had 4hrs sleep...
Any changes in the uploader code lately? My usual setup is now giving me errors in the simple uploader with a 'cancel' and 'retry' option. I can't remember exactly what the message was as I've only had 4hrs sleep...
No, no recent changes. Write our heroes with the error message next time you get it, thanks.
I've had the same problem on another system too, so I've emailed support. The dialog box says:
"An uploading error occured system error" and has Cancel and Retry buttons.
I hit retry, and the box still came up after the upload indicator moved twice. I suspected the file uploaded, so I hit cancel. And the file must be there now because the total number of files increased.
3) If you miss the drop area when dragging/dropping (something that's easy to do when managing multiple windows on a small screen), the browser window opens and shows one of your images and everything you already had dropped into the uploader is "poof" gone. This is terrible user interaction. Missing the target, but still in the same window should either accept into the target or do nothing. It shouldn't kill your entire upload.
This thread isn't about any changes to any of the uploaders themselves - it's about faster and more reliable uploading from the uploader to us, and faster verification steps once we have it.
John's feedback on the HTML5 uploader has been noted when he gave it to us, but unfortunately we don't have any way around the behavior if you mis-drop.
Andy, that's a pretty naive answer. You control how large you make the drop area. You could just make it full screen - leave part of it transparent if you want it to look the same.
Oh man, I just dragged and dropped 13 videos into YouTube's uploader. They have a Drag and drop area highlighted, but the text says: "Drag and drop videos anywhere on the page"
So I did, and it works *great*. So awesome. You guys should totally steal this.
Also, there is *NO GOOD REASON* why the whole page should not be drag-and-droppable. Why would you ever want to drag an image into an upload window and have it display the image instead of start uploading? I'd love to see your use case for this. ;-}
Any changes in the uploader code for Simple? I'm seeing 5 simultaneous uploads (!) vs only 3 before. I love the change (almost 100% usage of my 15Mb with only 3 upload sessions), but am curious when it occurred.
Comments
This is a little hijack sorry, but I take issue with your statement about "If it gets enough votes, we'll build it"
I have been hassling Andy for literally years (and yes, I'm accurately using that word!) about the lack of foreign currency transactions, and others have been asking for European print labs etc.
Currently 3 of the top 5 requests on your feature request site relate to this, and while Andy has hinted (strongly) that some work might be in progress on some or all of these features, they don't even show as planned or started on your site.
When pressed about the obvious mismatch between what he's been hinting and the site, Andy falls back on "we're a private company and we can choose what we're going to tell you guys about what we're developing"
Again, all perfectly true.
But COME ON! Why can't you please please please be up front about what you're developing, at least update the status of the features on the feature request site!
I love Smugmug, your support is second to none, and the customisation is unbeatable. Long ago however I totally lost faith that you'lll ever be anything but a US Centric company, focussing only on features that appeal to your US based users (pros and viewers).
Even if a foreign currency systems gets implemented, in the intervening 3-4 years between asking for it and now, I've built a Paypal system that works well and accounts for well over 95% of my sales - won't go back to using SM as a payment processor / printer.
I know several local users here in NZ that have let their Smugmug subscriptions lapse purely because we feel you don't care about non-US users, at least not enough to either support anything but US currencies and print providers. A couple of these users had spent months on heavily cusomtised sites and they still left.
You're the boss right? If anyone can fix this and give your non-US based users some proper hope, it's you, right?
How about updating the feature request site with accurate statuses? That would go a HUGE way to making us believe you have some concern for your non-US based users.
Cheers - Neil Gardner
New Zealand
ps, You might drop these features on us tomorrow for all I know, but the point stands, we've been fed this frustrating line for years, might be 3, might be 5 - I've lost count. After this, it'll be another feature - like your maintenance... A site your size simply shouldn't need a maintenance window, but you have it, and for understandable reasons it's ALWAYS in my peak hour.
http://www.nzsnaps.com (talkiet.smugmug.com)
Though everyone here on dgrin knows I give Smugmug plenty of criticism when things are working as they should, I'll have to come to their defense here. They are in a very competitive business. They have to balance the benefit to their business and their customers by telling us what they are working on versus the competitive disadvantage of telling their competitors what they are working on. It seems perfectly normal to me that some things create no significant disadvantage by telling everyone they're working on them (like uploader improvements) while for other things (probably big new things), they don't really want to tip off their competitors to what they're doing until it's ready to launch.
Keeping their competitors in the dark on those issues gives the competitors less time to react to new and valuable things that Smugmug might be doing that could affect the competitive balance. This is how business works. I understand Smugmug's need not to telegraph everything they're working on to their competitors long ahead of when it ships. Hopefully other customers can understand that too.
If you're a regular member of the community here, you can often "read-between-the-lines" of answers they give and get an idea whether they are actually going to do something about a particular issue (like currency stuff) or not, but you will rarely get a very good idea of how soon it will come and if it's a really important issue to you, it will probably be frustrating to wait. Smugmug knows an uninformed customer will be more frustrated than an informed customer (assuming the news is good), but they have to trade that off vs. informing their competition. Some things will be worth announcing ahead of time, some will not.
I've beat them up pretty good on this one too. I think they're to a size and maturity where most maintenance should be invisible to us. It takes more planning and more development to implement some new features that way, but it is doable. You don't see Gmail having a planned worldwide outage every other Thursday night. They engineer around it. It does slow down deployment of some new features (sometimes requiring more development to implement them without downtime) so it is a tradeoff space, but I think what Smugmug is hearing is that we're voting for less planned downtime even if it slows down some features.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
New HTML5 uploader is out which:
The Java and Flash uploader upgrades to similar functionality are in testing now. We also will shortly enable all of them to periodically heartbeat back to SmugMug during RO/SU situations and auto-resume when they're ended.
Finally, during many RO/SU type situations, including most Thursday night maintenance windows, all uploaders (including 3rd parties) will often continue uploading uninterrupted. I'd guess greater than 90% of the time, uploaders will continue. I have some ideas on how to get that above 99%, but going from 0-90% seems like a good start.
Finally, we'll be publishing what we do as 'Best Practices' in our API docs so that 3rd party uploaders can behave similarly on the same error types.
There are a few more features we're experimenting with, too, but your ideas on this thread have clearly been invaluable.
Thanks!
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!
http://www.dgrin.com/showpost.php?p=1602508&postcount=124
We've always done 3 at a time but it wouldn't show in FF for some reason.
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
I have never seen almost 100% of all my 15Mb upload bandwidth until today.
Now, if SM can only make it where it will auto-sense maximum bandwidth utilization, and add a slider so people can adjust the percentage of bandwidth they want to use, that fills almost every demand except multiple gallery uploading.
Want faster uploading? Vote for FTP!
"One thing i'm sure about, is that you can significantly increase upload/download speed using multi-threading. Download managers did this for a very long time, they download file using number of simultaneous threads.
Amazon S3 does support Content-Range header which makes it possible to download single file using several concurrent threads. Each thread can download specific part of file.
Similar technique can be applied for uploads. Recently Amazon S3 team announced support for multipart uploads. This is very similar to multi-thread downloading descried above. Each file can be uploaded using number of concurrent working threads."
https://forums.aws.amazon.com/thread.jspa?messageID=243214
Has multi-part uploading been implemented for the newest uploader or just the cloud? Are there plans to implement multi-part uploading? That would be unbelievably awesome.
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
No, no recent changes. Write our heroes with the error message next time you get it, thanks.
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!
"An uploading error occured system error" and has Cancel and Retry buttons.
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
Want faster uploading? Vote for FTP!
Oh man, I just dragged and dropped 13 videos into YouTube's uploader. They have a Drag and drop area highlighted, but the text says: "Drag and drop videos anywhere on the page"
So I did, and it works *great*. So awesome. You guys should totally steal this.
Also, there is *NO GOOD REASON* why the whole page should not be drag-and-droppable. Why would you ever want to drag an image into an upload window and have it display the image instead of start uploading? I'd love to see your use case for this. ;-}
Want faster uploading? Vote for FTP!
Portfolio • Workshops • Facebook • Twitter
Want faster uploading? Vote for FTP!