jfriend
Sep-30-2008, 10:16 AM
Here's a list of ten things Smugmug could do to make customizing better. These are a mix of CSS and JS things. Many are based on how many times I see people here in the forums make mistakes in customizing. The JS ones are things that I've enountered in the JS I've written. Feel free to add your own top ten list. Here's mine in no particular order:
Customization Validation. When submitting customization changes, Smugmug should do some validation for the customer. A common mistake that can ruin your page is mismatched <div></div> tags and this could be easily checked for, but there are also lots of other common mistakes that could be checked for such as javascript in the CSS box, script tags in the javascript box, etc...
Built-in homepage slideshow. The ability to do a home page slideshow and a galleries page without any coding or CSS. This could all be done simply with a simple configuration page in the customization UI and then have Smugmug generate the right page. Smugmug could then enhance the default offering over time without breaking anyone. It could still all be customizable with JS and CSS, just from a common, built-in starting point.
Better customizing page. If you're doing iterations of CSS or JS, the current customizing page is a real pain. I want the ability to have a window open that stays positioned exactly how I have it where I can make changes (or paste in changes - I use an external editor), hit "Update", switch to another window to try out my changes, come back to the first window and have it still in exactly the same scroll position everything so I can make the next iteration. now if I'm doing JS iterations, I hit Update, go to my other window, try out my changes, come back to the customizing window, scroll to the bottom of the customizing window, scroll the miniature JS window to the right location, make my change and hit Update. It could be a lot friendlier. If you're make CSS changes, those are at the top of the window, but the Update button is at the bottom of the window so you even have to scroll the length of the window every time for that. This whole UI could be so much friendlier. At the very least, it could use an Ajax submit so you could keep your current scroll position, but edit windows could be made resizable, the different types of edits could be put into tabs, update buttons could be easier to reach, etc...
Site change notifications. We need a much better way to know (in advance) about site changes that will or can affect customizing. I recognize that Smugmug can't move the site forward without occasionally breaking customizations. But, at the same time, they should just release something new and let us discover that our site is busted. We should be able to choose to be involved in the release process, know what areas are likely to change, know when to look for those changes and be able to be proactive about our changes. Polling dgrin or an RSS feed are not acceptable solutions. We need an opt-in email - that's the only form of communication that we know we can get asynchronously.
notLoggedIn class. It would help to have a "notLoggedIn" class on the body tag. A lot of people like to have a different set of things showing when logged in. While it's possible to do that only with the "loggedIn" class, it means you have to have two sets of CSS. As the recent problem with hiding the share button when not logged in shows, this is fragile. The code that everyone used to use for hiding the share button when not logged in broke with the recent changes. It used to be:
#shareButton {display:none;}
.loggedIn #shareButton {display:block;}
That broke because the shareButton now needs to be:
loggedIn #shareButton {display:-moz-inline-box; display:inline-block;}
That's because they changed how the share button is laid out in the page.
But, if there was a "notLoggedIn" class on the body tag, this all could have just been:
.notLoggedIn #shareButton {display:none;}
and it wouldn't have been fragile and wouldn't have broken.
Page Done Event. We now need a javascript event that Smugmug fires when it is done adding things to the page dynamically. With the new YUI buttons that are added programmatically via Javascript, it can be difficult for us to add things in relation to those or know when everything is in place so we can do our own customizing. The YUI onDOMReady() event does not give us a consistent ordering with respect to Smugmug's own JS code. I think Smumug should create their own YUI event that they fire when they are done modifying the page.
Javascript error catching and dumping. A lot of customizers make javascript errors and then don't see that they've done so. It would be possible for Smugmug to capture these errors (outer try/catch levels perhaps even on common YUI event handlers) and show them to a logged in user in a cross browser way. This would at least give them the knowledge that they have a javascript error and might even give them enough info to fix it. At worst, it would give them the right information to go ask in the forums for help.
Debuggable YUI files. We need debuggable YUI source files so we can step through them line by line in Firebug. The YUI documentation is not very good and many questions can be answered in a few minutes by just stepping through the library. But, today we can't do that. We can get non-compressed files today, but they still have many statements on a single line which makes the debugger not work.
SmugScripts.org. It would be awesome to have something like userscripts.org (a GreaseMonkey scripts repository) for Smugmug customization scripts. Today, the customizing library of both CSS and JS is all over the place. http://www.userscripts.org is a fantastic site for collecting and finding and documenting and versioning greasemonkey scripts. Wouldn't it be wonderful to have such a thing for Smugmug customizing?
Consistent event model across styles. onPhotoShow should work for all styles. Today, if you want to do some JS customizing after the currently displayed photo is loaded, you have to do it differently depending upon the current style. There's no reason for this. If onPhotoShow was just called for every style, this would be trivially easy for a JS developer and their code would immediately work for all styles.I could go on and on with a bunch more javascript requests, but I'll stop here with 10. Feel free to post your own top 10 things to make customizing better/easier list (or just post your top 2 or 5 of whatever).
Customization Validation. When submitting customization changes, Smugmug should do some validation for the customer. A common mistake that can ruin your page is mismatched <div></div> tags and this could be easily checked for, but there are also lots of other common mistakes that could be checked for such as javascript in the CSS box, script tags in the javascript box, etc...
Built-in homepage slideshow. The ability to do a home page slideshow and a galleries page without any coding or CSS. This could all be done simply with a simple configuration page in the customization UI and then have Smugmug generate the right page. Smugmug could then enhance the default offering over time without breaking anyone. It could still all be customizable with JS and CSS, just from a common, built-in starting point.
Better customizing page. If you're doing iterations of CSS or JS, the current customizing page is a real pain. I want the ability to have a window open that stays positioned exactly how I have it where I can make changes (or paste in changes - I use an external editor), hit "Update", switch to another window to try out my changes, come back to the first window and have it still in exactly the same scroll position everything so I can make the next iteration. now if I'm doing JS iterations, I hit Update, go to my other window, try out my changes, come back to the customizing window, scroll to the bottom of the customizing window, scroll the miniature JS window to the right location, make my change and hit Update. It could be a lot friendlier. If you're make CSS changes, those are at the top of the window, but the Update button is at the bottom of the window so you even have to scroll the length of the window every time for that. This whole UI could be so much friendlier. At the very least, it could use an Ajax submit so you could keep your current scroll position, but edit windows could be made resizable, the different types of edits could be put into tabs, update buttons could be easier to reach, etc...
Site change notifications. We need a much better way to know (in advance) about site changes that will or can affect customizing. I recognize that Smugmug can't move the site forward without occasionally breaking customizations. But, at the same time, they should just release something new and let us discover that our site is busted. We should be able to choose to be involved in the release process, know what areas are likely to change, know when to look for those changes and be able to be proactive about our changes. Polling dgrin or an RSS feed are not acceptable solutions. We need an opt-in email - that's the only form of communication that we know we can get asynchronously.
notLoggedIn class. It would help to have a "notLoggedIn" class on the body tag. A lot of people like to have a different set of things showing when logged in. While it's possible to do that only with the "loggedIn" class, it means you have to have two sets of CSS. As the recent problem with hiding the share button when not logged in shows, this is fragile. The code that everyone used to use for hiding the share button when not logged in broke with the recent changes. It used to be:
#shareButton {display:none;}
.loggedIn #shareButton {display:block;}
That broke because the shareButton now needs to be:
loggedIn #shareButton {display:-moz-inline-box; display:inline-block;}
That's because they changed how the share button is laid out in the page.
But, if there was a "notLoggedIn" class on the body tag, this all could have just been:
.notLoggedIn #shareButton {display:none;}
and it wouldn't have been fragile and wouldn't have broken.
Page Done Event. We now need a javascript event that Smugmug fires when it is done adding things to the page dynamically. With the new YUI buttons that are added programmatically via Javascript, it can be difficult for us to add things in relation to those or know when everything is in place so we can do our own customizing. The YUI onDOMReady() event does not give us a consistent ordering with respect to Smugmug's own JS code. I think Smumug should create their own YUI event that they fire when they are done modifying the page.
Javascript error catching and dumping. A lot of customizers make javascript errors and then don't see that they've done so. It would be possible for Smugmug to capture these errors (outer try/catch levels perhaps even on common YUI event handlers) and show them to a logged in user in a cross browser way. This would at least give them the knowledge that they have a javascript error and might even give them enough info to fix it. At worst, it would give them the right information to go ask in the forums for help.
Debuggable YUI files. We need debuggable YUI source files so we can step through them line by line in Firebug. The YUI documentation is not very good and many questions can be answered in a few minutes by just stepping through the library. But, today we can't do that. We can get non-compressed files today, but they still have many statements on a single line which makes the debugger not work.
SmugScripts.org. It would be awesome to have something like userscripts.org (a GreaseMonkey scripts repository) for Smugmug customization scripts. Today, the customizing library of both CSS and JS is all over the place. http://www.userscripts.org is a fantastic site for collecting and finding and documenting and versioning greasemonkey scripts. Wouldn't it be wonderful to have such a thing for Smugmug customizing?
Consistent event model across styles. onPhotoShow should work for all styles. Today, if you want to do some JS customizing after the currently displayed photo is loaded, you have to do it differently depending upon the current style. There's no reason for this. If onPhotoShow was just called for every style, this would be trivially easy for a JS developer and their code would immediately work for all styles.I could go on and on with a bunch more javascript requests, but I'll stop here with 10. Feel free to post your own top 10 things to make customizing better/easier list (or just post your top 2 or 5 of whatever).