Gallery titles suddenly huge!

LPC · June 2, 2016

My Gallery Titles are suddenly 5 times the size they used to be -

'Alexander Park' should be only slightly bigger than '2008-Present'

What has happened??

Please tell me this is reversible!!!

denisegoldberg · June 2, 2016

CSS to change the size of the title can be found in this post.

Additional adjustments are in the thread Coming Soon: Updated Gallery Header / Cover Image, mainly posted by leftquark in response to questions.

--- Denise

LPC · June 2, 2016

Thanks Denise, I haven't been to these forums for a long time so didn't know about the changes until they just happened. Kind of annoying. No matter what I do I can't get the size right and the font is unsuitable. I resent 'improvements' like this which result in me then having to find ways to work around them. Can we not just simply opt out??

Ferguson · June 2, 2016

Yeah, and now duplicated also. I need to look and see what they've done to me.

Don't have time to look at the code now, but something changed to double up on the heading.

I know it's hard to change things without breaking people's pages, but... come on. There's got to be a better answer. Staged releases with a way to test them first on your site maybe?

Edited post: OK, fixed, but in case anyone was interested, here's what it was changed to. Really, how about a "preview your site with this tool" before changes, and roll them out on a planned schedule, like Microsoft's update Tuesday (ok, not every tuesday!). Then we know to look ahead of each upcoming change, test our site, know what to adjust, etc.

Richard · June 2, 2016

Ferguson wrote: »

Yeah, and now duplicated also. I need to look and see what they've done to me.

Anyone curious here's a link. Don't have time to look at the code now, but something changed to double up on the heading.

http://www.captivephotons.com/Events/Rodeo/Barrels053016/

I know it's hard to change things without breaking people's pages, but... come on. There's got to be a better answer. Staged releases with a way to test them first on your site maybe?

Same happened to me, but it was easy to fix. It looks like they are including the gallery title as a part of the standard gallery header. I had the title as a separate content block in All Galleries. I just removed the title block from All Galleries and that eliminated the duplication. There are some slight differences in appearance still remaining, but I think it's possible to fine tune the title in the header using CSS. Not urgent for me, but check out the thread in SM Product News for more info: http://dgrin.com/showthread.php?t=258143

leftquark · June 2, 2016

Ferguson wrote: »

Really, how about a "preview your site with this tool" before changes, and roll them out on a planned schedule, like Microsoft's update Tuesday (ok, not every tuesday!). Then we know to look ahead of each upcoming change, test our site, know what to adjust, etc.

We've spent some time thinking about how to best push releases like this that change the look of peoples sites and have a number of ideas on what we can do to improve them. We used to only push updates on Thursdays during our regularly scheduled maintenance window, but we felt like we were doing a disservice to all of you by holding exciting releases for up to 6 days. I do prefer to ship items as they're ready but we need to do a better job of announcing that changes are coming and are out. We have been experimenting with some tools that will do a better job of communicating that we've made changes and we hope that it will solve this problem. Stay tuned.

(You can always monitor the Product News forum, and I've been trying to do a better job of announcing things ahead of time but I realize it's unrealistic to expect every SM customer to follow that forum).

Ferguson · June 4, 2016

leftquark wrote: »

... we felt like we were doing a disservice to all of you by holding exciting releases for up to 6 days. ...

I suspect if you took a poll, most people would like a controlled, announced, and testable technique even if it took 60 days longer for these exciting releases.

I do not mean to minimize the benefit of releases, but I'd wager that for any given release most people are unaffected, period. I'd also wager that most people who are affected do not notice.

But... for those who are affected, and do notice (that small percentage)... I'd wager most notice because it had a negative effect they had to remedy. I do not mean that to imply poor programming, nor do I want you to do less stuff... it's the nature of the beast with a lot of customized web sites.

But I really do think your priorities might be adjusted to more methodology, and less rush to market.

No good deed goes unpunished. Sorry.

Lille Ulven · June 5, 2016

@leftquark this release would not have been any less exiting if you had to delay it by a week or a month or what ever necessary to fix what wasn't in place on the day you wanted to do the initial release of it. (Well of course unless you think of the later bug fixes as being exiting

)
Of course initial you might hear someone complaining that something is not in production even though it should have been, but even those people usually are happier if they later on get something that works 100% (OK, nothing in software development ever does work 100% so let's aim for 99%) rather than getting the first version which worked say in 95% of the cases. I have seen this countless times, and even though I am just a "small developer" myself I have put my foot down against releases that weren't properly tested. And there is a simple reason for it: when ever you put something out that you weren't able to test through there will be something that fails and your users will notice. Their scream will be louder than everything you have expected. When you though decide to delay the release of something fancy because it hasn't been tested, and/or there have been problems, you can tell your customers "hey we didn't release it, because we found a couple of things that need fixing, we'll release in 6 days when the problems are fixed". OK, some customers will morn about it -- but only for a little while. Most will nod understanding that not releasing has prevented them from getting in trouble with the application / pages... But when the release then happens both parts will be happy ... and even happier because they avoided the trouble of a not 100% tested system.

So what are the potential outcomes of a release:
1) Everything was tested properly and the release was great (everything working in production) => super happy customers
2) Everything was tested properly, but after the release a few minor errors occurred that were fixed fast => OK, some not so super happy customers but they'll still be happy
3) Not everything was tested properly, the release revealed a couple major things so it was rolled back => happy customers, because they don't have to deal with the errors from a not so happy release
4) Not everything was tested properly, the release was delayed for a couple of days until the next release slot to test and improve things => happy customers
5) Not everything was tested properly, the initial release was delayed for a short time, still not everything was tested but released anyway => some major stuff turns up after the release and your customers get not very happy about it (basically you are committing suicide by doing it this way - at least if you do this too often)
6) Not everything tested properly, release was pushed through as planned => unhappy customers due to occurring errors (suicide as in 5)

And yes, you wrote somewhere that you are planning on a beta-test system. I think this will be extremely helpful for all of us.

And one more question: when I save my changes that include code that I have commented out for some reason (most of the time I have good reasons to comment something out rather than deleting it) and I later go back to the same code area it is deleted anyway. Why? This has happened lately to basically all my gallery descriptions which in the "old days" (prior to June 1st) included a

<h2 class="wsc_gallery_header">My gallery header</h2><br>

which now was commented out...and vanished completely.

Lille Ulven

leftquark · June 5, 2016

Lots of good discussion here. At SmugMug we only release products that have been thoroughly tested. Our developers test their code and we have a strong QA team that pounds away on everything. Some small things can always sneak through but we never release anything that isn't properly tested.

Richard · June 5, 2016

Ferguson wrote: »

No good deed goes unpunished. Sorry.

Ain't that the truth?

Look, let's try to keep all of this in proportion. When a major change occurs, like the "new" SM, a lot of effort was put into communication, warning, test scaffolding and the like. Some people still were taken by surprise, but I think most of us would agree that was their own fault, not SmugMug's. As could be expected in any major release, there were bugs and gotchas, some fixed quickly, some less so.

Since then, there have been quite a few bug fixes and new features introduced. While these certainly are of value, they are still incremental changes, not world-changing events (like the introduction of a new iPhone screen size

). I agree with those who prefer advance warning and stability to earlier or more frequent releases. I am especially looking forward to having a beta environment which allows me to see the effects of new releases on my own customizations before they go live. That would be a huge step forward.

Ferguson · June 5, 2016

leftquark wrote: »

Lots of good discussion here. At SmugMug we only release products that have been thoroughly tested. Our developers test their code and we have a strong QA team that pounds away on everything. Some small things can always sneak through but we never release anything that isn't properly tested.

And maybe I worded my comment badly, as I do not mean to imply otherwise. Unlike, say, Adobe who has a fixed set of features to regression test, but appears at times to not know what the word means, Smugmug is saddled with thousands or tens of thousands (I really have no idea) of people who have modified their sites in rather substantial ways with CSS and their own HTML. While not as bad as Javascript, these often make the result really a whole different system.

There's no way to expect Smugmug to do more than follow some general guidelines (like how you treat existing IDs and classes), I can hardly expect you to test each site by a human to see if the appearance still looks good.

What I am suggesting is do what all vendors (sadly) do now - make us your extended QA department. Just rather than doing it with released code, give us access to a beta copy in some fashion. You did it for years with the "New Smugmug", you must have learned a lot in doing it that could let you do it even better on a monthly basis for each release.

Then those who value time to market can hit the "ready" quickly, those with more substantive testing can take 30 days, and those who do not care could have a button that says "deploy changes when done, I'm excited and want everything instantly, I do not want to test", or they just get it auto-magically at the end of the test period.

Lille Ulven · June 5, 2016

I wonder one about one thing that could add an immense value to these new features. I generally like the new gallery cover and as a matter of fact if the collection galleries in general would work slightly differently I would have switched to them from the smug mug galleries that I am using now, just because I like the new cover so much. But well they don't so I won't

But hey it works great on my Portfolio-Galleries (which have a hidden collection gallery and visible hand coded galleries

).
But for these new covers -- and I suspect the same could count for many more features -- it would be great if they came with some additional settings that one could make in the gallery-style section rather than with CSS coding. Things like
- Size of header font (selectable from small to XLarge)
- Header position (left, center, right)
- All buttons on / off for the cover (well of course depending on the gallery settings what all is)
- Cover height (selectable from small, medium (which might be what it is now) to large -- small could be 75% of medium and large 125%)
- Cover photo built of one landscape photo or 3 portrait photos (good for galleries that only contain portrait photos)
- Cover on / off per gallery (this way we all would have time to test this gallery per gallery and would not be forced to deal with it right away for every gallery -- if these changes are published when you are out in the wild with little to no internet (time) for some weeks and then you come back home and find that your galleries have two headers now...not a good experience)

Most of us who are here are pretty good in CSS (or can be helped to do these things in CSS), but for others these changes might be a huge challenge if they are not included in selectable buttons...so including them in selection lists would make customers happier, I think.

@leftquark: And I wasn't suggesting (lacking a better word here...) that your QA doesn't test or didn't do its job properly. But well they can only do so much - especially with all the highly customized websites that there are. And I am looking forward to that beta-testing system to come up, so I can sign up for it

- I suspect you will get at least as much feedback for changes like this as you got when you initially presented it as an upcoming change.

To be honest: I have so many customizations on my website, I really should start documenting them on my blog as well - sure enough some are the ones leftquark, sherlock, Alan or Denise suggested somewhere, some are completely my own...But I guess my winter-project this year should be to document them all on my blog

Lille Ulven

BigRed · June 5, 2016

leftquark wrote: »

[SNIP]
(You can always monitor the Product News forum, and I've been trying to do a better job of announcing things ahead of time but I realize it's unrealistic to expect every SM customer to follow that forum).

For those of us who have the time and interest to frequent the forums, I believe that Leftquark has been doing an amazing job with how & when he communicates upcoming changes. If I may offer a little suggestion for next time, I think it would help to list any new and/or changed Class/ID names. In this case, that would have helped me better understand the impact on my site design and even get ahead of the curve on maintaining my CSS rules.

In addition to broader push communications, it seems to me that the Help pages are still woefully underutilized. I don't expect to find CSS guidance there, but I do expect to find complete and current content about settings. I'd love to see a homepage that highlights recent changes. (And I'd really love a decent Search function. Just try finding how to turn on the new breadcrumb trail.) Shouldn't updates there be part of the release QA?

leftquark · June 6, 2016

Ferguson wrote: »

Unlike, say, Adobe who has a fixed set of features to regression test, but appears at times to not know what the word means, Smugmug is saddled with thousands or tens of thousands (I really have no idea) of people who have modified their sites in rather substantial ways with CSS and their own HTML. While not as bad as Javascript, these often make the result really a whole different system.

Can I hire you as a Product Manager, Ferguson?!

Your insight and vision is always quite spot on. The custom code (in this case CSS / HTML) makes things difficult. It was part of the reason why Old SmugMug stalled; we were so afraid to release anything that might break peoples sites that we just never released anything. We cannot afford to stall and lag behind due to this fear.

I started working at SmugMug because of my customization, CSS, and HTML knowledge. My site has hundreds of lines of custom code in it. I say this so you all know that I really do understand your frustrations and where your thoughts are coming from. But I also want to be clear: I have no intention of holding back SmugMug because of fear of breaking peoples custom CSS/HTML. We're going to push forward, grow, innovate, and make SmugMug better. Along the way we're going to release things that are going to clash with your custom code and the Heroes, our Sorcerers, and I will be here to help you update your sites. We'll do our best to give you ample warning, which is something we have to get better at, but we're not going to delay or hold releases or not even try because of this fear.

Ferguson, I know you get everything I'm saying and I love the ideas you're tossing out. I'm speaking more towards everyone else here and not directly at you.

Ferguson wrote: »

What I am suggesting is do what all vendors (sadly) do now - make us your extended QA department. Just rather than doing it with released code, give us access to a beta copy in some fashion. You did it for years with the "New Smugmug", you must have learned a lot in doing it that could let you do it even better on a monthly basis for each release.

Then those who value time to market can hit the "ready" quickly, those with more substantive testing can take 30 days, and those who do not care could have a button that says "deploy changes when done, I'm excited and want everything instantly, I do not want to test", or they just get it auto-magically at the end of the test period.

I wish this was easy -- the sandbox system that was built for the transition from Old to New SmugMug won't work for "beta releases". What we'll do for beta releases is just push the update to certain customers before we push it to everyone else. You'll be our extended QA, but those changes will be visible on your site immediately.

BigRed wrote: »

In addition to broader push communications, it seems to me that the Help pages are still woefully underutilized. I don't expect to find CSS guidance there, but I do expect to find complete and current content about settings. I'd love to see a homepage that highlights recent changes. (And I'd really love a decent Search function. Just try finding how to turn on the new breadcrumb trail.) Shouldn't updates there be part of the release QA?

We have a project underway to revamp the Help Pages. In some cases we'll be simplifying them -- there's too many right now. We do try to update all the Help pages prior to a release. In this case, we actually held the release a week in an attempt to get the Help pages updated but our help writer was out on vacation and we decided to push it live knowing she'd be back this week. Everything that you were looking for should be updated on the pages this week.

Richard · June 6, 2016

leftquark wrote: »

I wish this was easy -- the sandbox system that was built for the transition from Old to New SmugMug won't work for "beta releases". What we'll do for beta releases is just push the update to certain customers before we push it to everyone else. You'll be our extended QA, but those changes will be visible on your site immediately.

Not what I was hoping for. There's no incentive for anyone to participate other than goodwill. It doesn't provide any new protection against disruption if it's live. I suppose it could reduce the number of surprises for the non-participants, who could follow the discussions here. That's a plus, but it's a far cry from having a personal, safe test environment.

leftquark · June 6, 2016

Richard wrote: »

Not what I was hoping for. There's no incentive for anyone to participate other than goodwill. It doesn't provide any new protection against disruption if it's live. I suppose it could reduce the number of surprises for the non-participants, who could follow the discussions here. That's a plus, but it's a far cry from having a personal, safe test environment.

Having a safe test environment still wouldn't solve things for the non-participants.

It's very easy to spend time here on dgrin and assume that most SmugMug customers are like us. Dgrin represents a very small set of customers, most of whom tend to be power users. Most of the SmugMug community isn't like us. The beauty of being a power user is that we also have the ability to fix these kinds of things fairly easily. It's the risk we took when we added all the custom code. Rather than build a complex test environment that would only temporarily help this small set of customers, we're going to focus on building great products and then providing all the help, warning and support we can.

Richard · June 6, 2016

leftquark wrote: »

Rather than build a complex test environment that would only temporarily help this small set of customers, we're going to focus on building great products and then providing all the help, warning and support we can.

Fair enough. But perhaps you could help your power users with a simple tweak to the beta scheme: give us the ability to switch back and forth between the old and new code, with read-only access to our sites. That would give us the ability to view the impact at some low-activity time of our choosing, get a sense of what's going to break and start preparing a response.

Ferguson · June 6, 2016

Richard wrote: »

Not what I was hoping for. There's no incentive for anyone to participate other than goodwill. It doesn't provide any new protection against disruption if it's live. I suppose it could reduce the number of surprises for the non-participants, who could follow the discussions here. That's a plus, but it's a far cry from having a personal, safe test environment.

I think it suffers from another subtle issue as well, if you cannot see a before/after, it is hard to notice change. On your own web site, you might think you know exactly how it should look, but after a while you become blind to it, you notice only what you are looking for. Of particular note it is hard to visually notice the absence of something that was there, say a "contact me" link that you purposely made subtle.

Honestly, you have a bunch of very creative software guys there, clearly, but I think in this case they are being a tad lazy. I bet someone asked "can we do this?".

The proper question was "We need to do this, how are you going to make it happen".

I tend to agree with the above. In a simultaneous beta system I think you would get a lot of participation; in a "you get to go first but cannot go back" you will get some (lots of people love going first regardless), but the incentives are all backwards for most "production" users who want to minimize disruption.

leftquark wrote: »

Can I hire you as a Product Manager, Ferguson?!

Sure. I spent most of my life whipping programmers into shape. But I'm not cheap.

Gallery titles suddenly huge!

Comments