Bulk Downloads now Immediate??
darryl
Registered Users Posts: 997 Major grins
Did you guys change the bulk download ("Download All") function? Instead of telling me it's going to generate a zip and e-mail me a link, it starts downloading a zip immediately.
Which is cool... except I that now can't send that link to friends who want to download the zip! (And the bulk download function is not exposed to visitors.)
Which is cool... except I that now can't send that link to friends who want to download the zip! (And the bulk download function is not exposed to visitors.)
0
Comments
Portfolio • Workshops • Facebook • Twitter
However, chatting on IRC, Christina and I discovered something weird. I generated the zipfile yesterday around 1PM PDT. We then added about 20 more photos over the course of the afternoon. I did *not* request another zipfile, but for whatever reason, a new one was generated and linked. Christina confirmed the new one has all 40+ photos. But I didn't get a notification about this regeneration, so I didn't have the link for the zipfile.
She's asked the engineers, er sorcerors, to look into it. Thanks!
Steps to reproduce:
- Upload photos to a gallery
- Request a zip file ("Download All")
- Within 2 weeks, upload more photos to gallery
- Request a zip file ("Download All")
Expected results:
- SmugMug notices you've since added more photos, so it generates a new zip file and sends you a notice.
Actual results:
- SmugMug doesn't know you've added more photos, so it starts sending you the old zip file that doesn't contain the new photos.
- Customers or others to whom you've sent the zipfile link will get an incomplete set of photos.
Workaround:
- None really. You have to mail help@smugmug.com to have them nuke the old zip file.
Portfolio • Workshops • Facebook • Twitter
I understand your saying that the feature is not yet built out, and in fact, I'm perfectly ok with that, especially now that we've got it here on Dgrin with the workaround listed. But this is still, technically, a bug.
Developer-focused people will say that it's only a bug if the behavior is not what the developer who wrote the code intended the code to do.
Customer-focused people will say that anything that doesn't work as any reasonable customer might expect it to work is a bug.
I always encouraged my development teams to adopt the "customer-focused" definition because this includes all sorts of things that should get fixed like a flawed design (it works how we designed it, but the design had problems), a flawed implementation (it works how the developer intended it to, but the developer didn't see/understand the entire scope of the issue that the customer sees), we didn't intend for it to work in situation X, but now there are a lot of customers that see that as a serious problem and so on.
Of course, just because it gets labeled as a "bug" doesn't mean it should necessarily get fixed. But, it does mean that is should be evaluated to be fixed vs. everything else the development team has to do. In a well run development organization, all bugs get prioritized according to some criteria which is different in every organization and for every product I've ever been part of, but it often includes: severity of issue to the customer, support cost of not fixing it, developer cost of fixing it (including relevant testing costs), availability of people who know how to fix it, risk of fixing it, timing versus other release schedules, competitive issues, likelihood of bad press because of the issue, number of customers it matters to, impact of this bug on any strategic marketing initiatives, something that matters to a key and influential customer, convenience of fixing it while making other changes in the same area, etc...
In the end, whether it's called a "bug" or not is mostly a semantic thing. What matters is whether it's been "officially" recorded in some system where it will be evaluated for fixing/changing (like happens for bugs) regardless of whether the developer thinks it works "as intended" or not. Since most development organizations have a well used bug system that the whole organization knows how to use, it's often easiest to just use that system for cataloging and evaluating issues like this. But, it can be done other ways too.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Love the feedback. No matter what we call it, we intend to make improvements in a new rev of this feature.
Thanks so much John & Darryl!
Portfolio • Workshops • Facebook • Twitter