Archive
Why OpenID at SmugMug?
We announced OpenID support last week. I then responded to some comments asking us why we were a provider first, rather than a consumer. Now, I’m answering some more comments basically asking why they should care about OpenID and how it helps SmugMug customers.
Honestly, I had no idea it wouldn’t be obvious how great this is. To me, the picture seems perfectly clear. There are no dastardly designs or secret agendas – to me, it just makes sense. Here’s are a few reasons why:
We are a pay site. Every SmugMug customer pays for the right to share their photos here. They get what they pay for. That comes with both pluses and minuses where identity is concerned, though. On the one hand, we have a much much stronger relationship with our customers than somewhere free like Hotmail, for example. On the other, we have no good mechanism to interact with viewers, who don’t and shouldn’t have to pay (or even sign up) to see their friends’ photos.
Let’s talk about the pluses first. There’s a much higher level of trust and respect between the customer and SmugMug than a free email provider. They feel secure in knowing that we treat their data carefully and with respect. They consider SmugMug to be their home (or at least a major part of their home) online. They strongly identify with the brand and even more strongly identify with the fact that their memories are stored and shared from our servers. They identify with us.
Do you see where I’m going with this? While everyone has multiple identities online, from email to IM, blogs to photo sharing, the ones where there is a volume of priceless content, such as their photo-sharing site or blog, are the ones our customers identify with the most. Email addresses are “less permanent” since they’re free, easy to forward, etc. Ask your typical passionate Flickr or SmugMug customer, though, and they’ll tell you about their passion for their photos and the pain and anguish it would cause them to move or if the service died. Note that not everyone falls into this category – but those passionate about photo sharing *do* fall into this category, and that describes every SmugMug customer.
Further, I believe the customer should get to choose which site they identify with most. I’d hate to limit them to only their email provider if they happen to hate their email provider. Just like everyone resonates with different brands of cars, jeans, computers, music, etc, they also resonate with different sites. Leave the power in the hands of the customer – let them choose their own identity.
Now, let’s talk minuses. Since there are no free accounts at SmugMug, we can’t interact as well with our viewers. They’re allergic to setting up “yet another account,” something I resonate with, or even passing over their email address. I completely get that – it really really sucks when you go to view someone’s photos at KodakGallery or Shutterfly and they demand your email address so you can get spammed till the end of days. It also sucks when you want to leave a comment at Flickr but can’t without signing up for a Yahoo account. What a pain.
OpenID goes a long way towards solving some of these problems. Comments can now be far more spam-free since identity can be verified, yet the commenter doesn’t have to go through the hassle of signing up for yet-another-account. Access controls to photos and galleries can be specified by the owner of the photos in such a way that sensitive data (like email addresses or passwords) no longer has to be exchanged. Even if we wanted to, SmugMug couldn’t spam someone using their OpenID to leave a comment or view a photo. That’s big – I hate giving my email address out to sites because so many of them *do* spam, you’re never sure which ones are the “good guys” like we are.
OpenID isn’t perfect. There’s no trust here – just identification. There’s still no complete single sign-on. There are issues with dangling stale IDs being left around. Consumer education is going to be interesting. But it’s still a huge step in the right direction. Just verifying that someone has an identity somewhere online gives you the ability to make your apps richer, regulate abuse more easily, and generally improve the user experience.
What’s not to love?
More SmugMug & OpenID
I hope you’ve heard we now support OpenID. If not, now you have. 🙂
A commenter asked politely (after deleting his first rant) why on earth we were being a provider, when being a consumer was more important. I completely disagree, and here’s why:
We should be both. And we will be. But I believe in releasing features quickly and incrementally, so I had to choose one or the other. I chose being a provider. Why?
You can’t sell lightbulbs to those without electricity. You can’t sell gasoline cars to those without access to gas stations. You can’t consume OpenID if there’s no-one who has an OpenID.
Up until AOL’s announcement, LiveJournal/SixApart was the best (and only?) source of OpenIDs on a reasonable scale (100,000+ users), as far as I know. That’s really not very many users. I figured throwing our 100,000+ into the mix would help. I certainly hope it has. AOL, though, threw 63,000,000+ into the mix – so now we’re even closer to a critical mass.
This is a chicken-or-the-egg problem, and I believe you need lots of providers with established user bases to jumpstart it. I’m glad there are tons of brand-new OpenID providers who’ll give you an ID for free – but I believe the real make-or-break metric will be existing services enabling huge chunks of people in one fell swoop.
We just swooped. 🙂
On a side note, while I rarely whine about our lack of coverage (generally, I believe the best way to get coverage online is to buckle down and improve your product), I was surprised to see our OpenID news fall on the net in complete silence. More than 30,000 people read my blog on Friday, but not a single blogger or news source I’m aware of picked it up. Digg can announce that they’ll have support “later this year” and get tons of coverage but we enable more than 100,000 people overnight, making us the 3rd largest OpenID provider on the planet, and no-one cares?
We didn’t do this to get coverage, we did it because I’m a geek and I think OpenID rocks. But a little, tiny bit might have been nice. I guess my “improve the product” theory doesn’t work after all. Can someone enlighten me as to what I’m doing wrong?
Oh, and I’m sorry for the whining. I’ll try not to let it happen again. 🙂
SmugMug embraces OpenID
The subject says it all and I’m thrilled. Here’s some details:
- We’re an OpenID 1.1 Provider. Hundreds of thousands of SmugMug customers can now use their SmugMug homepage URL as their ID on sites all over the net.
- We don’t yet support Diffie-Hellman association, so if plaintext isn’t ok, you’ll have to fall back to dumb mode. Sorry about that. I’m hoping we can support DH soon, but I’m really waiting for Wez’s PHP patch to use OpenSSL’s functions. I may end up creating a custom build, we’ll see.
- We’re planning on consuming OpenID for photo comments and other things shortly.
- We probably have bugs. Sorry about that – let me know and we’ll get them fixed.
OpenID is a fantastic idea, I’ve loved it since I first heard about it, and finally found a day to play with it. AOL recently announced support, and so did Microsoft. OpenID will be everywhere.
I’m a little worried with the direction OpenID 2.0 seems to be going – one of the great things about OpenID is how simple and easy-to-implement it is. I haven’t taken a good, close look yet, but the preliminary 2.0 spec seems to be complicating things a great deal. I see that as a Bad Thing(tm) but maybe I’m smoking crack.
The documentation for OpenID leaves a lot to be desired. Specifically, there’s no example messages, including sample values, for you to make sure your code is doing the right things. Luckily, the spec is so simple that some trial-and-error takes care of things, and someone has written a great narrative overview of the implementation. I will put up an OpenID page on our wiki that includes example requests and responses, including secret keys, so anyone else implementing this from scratch has some values to work from.
LiveJournal (and thus, Brad’s CPAN module used by lots of other services) seems to have some bug in it where it doesn’t like OpenID server URLs without a trailing “/”. It returns a useless (to me?) error message: “naive_verify_failed_network” which meant I spent hours and hours of time going over my code with a fine-toothed comb. Finally, out of ideas, I made a 1 character change to my HTML and everything magically worked. I don’t understand why, since the docs don’t state this, and Vox seems to have an openid.server without a trailing /, but oh well. It fixed my problem. 🙂 Hopefully this will help someone else figure out what that message might mean.
There are clearly still issues around OpenID, such as what happens years from now when your OpenID identities are lingering out there long after you’ve closed the account from which the ID was provided? Someone else may even own or use that old URL if it’s been repurposed. But there seem to be smart people thinking about the problem, so hopefully everyone will figure it out without bloating it or making it unusuable.
I think OpenID is huge, and I’m glad we’re able to move the ball up the field a few more inches.
Forget the X-Men, SmugMuggers are on the scene
Man, I love the company we’ve built!
We had a bunch of SmugMuggers in from out-of-town this week and, being a fun-loving photography company, we had to get some shots of our employees. Since our Help Desk is manned by Support Heroes, we thought a Super Hero theme would be appropriate. 🙂
I’m blue-and-gold Wolverine, above, with my co-founder and father Chris MacAskill as J’onn J’onnz aka Martian Manhunter. Last night four of us even showed up at the YUI party at Yahoo’s HQ with our faces still on. It was a blast – congrats to YUI on their first year!
Below, you can see the half of the company that was in Silicon Valley this week. Can you name each hero?
Lots more shots, including close-up portraits, in the gallery.
Neat, this got dugg. Go give it some love. 🙂
Browser History – How we did it (as told by Yahoo)
I’ve been hounding GreenJimmy, our resident Web SuperHero, to write up our approach to solving the Browser History problem when using AJAX apps. I wrote in broad terms about our solution (and how it worked on Safari, the tough one, in addition to Internet Explorer, Firefox, etc), and promised that Jimmy would update his blog with a detailed explanation.
That was exactly a month ago, and Jimmy has written exactly nothing. I guess I need to employ more Lex Luthor management techniques, because clearly I’m sucking in the boss category. 🙂
Luckily, our friends over at Yahoo have a new Browser History Manager in the latest YUI release, and it does the same thing we did in the same way. Best part? They actually wrote up how they did it so the rest of the world can use it. So if you’re curious as to how to get Safari to behave with proper history, including full back/forward button support, go read up.
Many apologies for everyone waiting around (and emailing me) for our solution. Many thanks to Yahoo for stepping up to the plate and sharing.
Yahoo, YUI, & Browser History
Today, the YUI blog mentions they’ve released a great new version. As you probably know, we’re a huge fan of YUI – we couldn’t have done our fantastic new UI without it. We’ll be at the YUI party this week, celebrating with everyone else.
However…
When talking about the new Browser History Manager, they mention that “No one, as far as we know, has resolved the technical issues in a satisfactory way across the A-Grade.” Alas, that’s just not true – SmugMug has solved this technical issue, and we did it first. What’s more, the YUI team knows about it – we had lunch with them and told them exactly how we did it. Their Safari implementation is exactly the same as what we did and explained. We even offered to give our code back to them under a BSD license so they wouldn’t have to duplicate our work.
It looks like they missed one technical detail of our implementation, though. Safari has an issue with “permathrobber” (basically, the Safari throbber never stops throbbing) which we managed to solve.
Note that I’m not upset that they have a great Browser History Manager – far from it. I just wish they’d give us a little credit where credit is due, given that we pimp YUI any chance we get for them.
We built it first, they know it, and sharing the love is the right thing to do.
UPDATE: Just called Yahoo and the love is still flowing. 🙂 Turns out the two guys who wrote the Browser History Manager are new to the team, weren’t at our lunch, and had no idea what we were doing. Great minds think alike. 🙂 And Yahoo can’t accept our code currently, even under a BSD license, but they’re working hard at getting that changed. Sounds like an internal big-company roadblock.
Photowalking in San Francisco on Feb 21st
We have a bunch of SmugMuggers in town so we’re getting together with Thomas Hawk and anyone else who wants to go shooting in San Francisco. Should be a blast, and with Thomas and Andy on board, we should get some great shots.
Details can be found at involver.
If you’d like to come, bring your camera and show up!
Also, as most of you probably already know, we take groups out shooting fairly often, to places like Yosemite. The next upcoming one is Wild Utah, hosted by one of our artists-in-residence, the incredible Marc Muench. I believe there are 5 slots left if you’re interested in shooting with the pros.
My SuperHero Lover
I’ve known the answer to this one my whole life, but at least we know the test is accurate. 🙂
I wonder how she feels about Lex Luthor or Green Lantern?
This is your Mac on drugs
Why the web can look wonky on a Mac by Chris MacAskill, President of SmugMug
The PC is a soldier. When Direktor Gates demands color #e3823c, PC responds “Sir, Yes Sir!!” Color #e3823c looks identical on the PC whether it’s in a JPEG, GIF, PNG, CSS, or HTML.
The only colors Direktor Gates tolerates are found in the box of crayons called sRGB. Internet standards like HTML, CSS and Flash march in step with the same colors.
The Mac Thinks Different. Color #e3823c is different on Macs. Except sometimes*.
If you have a Mac with Safari, check out this wonkiness (if you don’t, here’s a screen shot). Now check the page with Firefox. It looks completely different than it does in Safari, and different from Firefox and Internet Explorer on the PC.
Why this is a big deal:
Most people don’t have light-controlled rooms with color-calibrated monitors. I don’t, and you probably don’t, either. Almost everyone will see your photos slightly differently than the next person. We’re not talking about perfect color precision here, because on the net, that’s an impossibility.
What *is* important, though, is for your photo to match the rest of the page. If you’ve selected a background on a PC to match the blue in your subject’s eyes, you don’t want background and eyes to be mismatched on a Mac. Or your photo to look different in some Mac web browsers than it does in Photoshop.
Yet this is exactly what’s happening. And the fix is simple.
Demystifying the wonk:
#1: Macs ship with a display gamma of 1.8. The word gamma was probably chosen to make it sound like nuclear physics, but it’s fairly simple. It’s a setting, like brightness or contrast, that adjusts your image. Halfway between black & white (midtones) the changes are greatest; they change less as the colors get darker or lighter.
If you’re a mime with white makeup and black clothes, photos of you on the Internet will look similar on Macs and PCs. But if you’re gorgeously mid-toned, you’ll lose some of your tan on a Mac. Except sometimes*.
Internet standards, including HTML, CSS, and Flash, are based on a gamma of 2.2, making colors partway between black & white appear darker and higher contrast than 1.8 gamma makes them appear. Examples.
#2: Some Mac browsers (IE, Safari and Omniweb) go part way in preserving the artist’s intent: if you know what an ICC profile is, you can attach it to your photo and the Mac will render your photo with a gamma of 2.2. Then it will look like it does in Photoshop on your Mac, or on the Internet on PCs.
There are three problems:
- Safari still won’t know to adjust the rest of the page, such as borders drawn in CSS or background colors specified in HTML, leaving you with color mismatches like you saw on the wonkiness page.
- Other Mac browsers like Camino, Opera and Firefox don’t know for ICC profiles. The good news is they don’t get color mismatches. The bad news is nothing on the page matches your intent. (Except sometimes*.)
- Very few photos on the web have ICC profiles because they slow down browsing, especially on thumbnail-sized images. In this case, Safari doesn’t render them with a gamma of 2.2 unless your monitor is set to 2.2.
#3: PNG images have their own issues with Safari, unless they’re specially prepared, as you saw near the bottom of the wonkiness page. Read it and weep.
What’s this ‘except sometimes’?
If your Mac’s gamma is already at 2.2, you’re golden. Unfortunately, this is rare. Macs ship with a default gamma of 1.8, even though Apple recommends you and your friends change your gamma to 2.2. Here’s what they say:
If you calibrate your monitor with a Huey, for example, you’ll be asked what you do with your Mac. If you answer photo editing and web surfing, it will quietly set your gamma to 2.2 to make web pages match the artists intent. The good news: theoretically, now web pages look the same in Firefox & Safari — and on the PC. Photos look the same as they do in Photoshop. And in print. Color mismatches disappear.
In practice, devices like the Huey are not 100% accurate and the calibration they provide is influenced by the room’s lighting. So if you’re using Safari, you’ll probably notice that color mismatches will be reduced but not gone on the wonkiness page.
If you want to see almost no mismatches on the wonkiness page, go to Apple > System Preferences > Displays > Color > and pick sRGB IEC61966-2.1. Then quit Safari and restart it. Now everything should be as it is on a PC except the PNG may not match perfectly. It will match in Firefox.
What would Photoshop do?
If your monitor is set to the factory default, Photoshop is between a rock and hard place. It knows to display your photo with a gamma of 2.2 because it’s smart. But how should it preview your photo when you choose Save for Web? It has no idea. Will you be viewing your photo in Firefox or Safari? Will you be seeing it with an ICC profile or without? On a Mac or PC? It can’t know.
So by default it plays the odds and takes its chances: you’ll probably end up viewing it on a Mac and since few photos on the web have ICC profiles, it shoots the crap and renders the photo the way your monitor is set, with a gamma of 1.8. Tens of thousands of photographers are tormented by the shift in color they see between an open photo in Photoshop and the save for web preview they see of the same photo right beside it, and they wonder why Photoshop is so wonky.
If you set your monitor to sRGB IEC61966-2.1, that color shift goes away.
What should Steve do?
It seems to me…that artists and photographers want their admirers to see the web the way they intended, which they would if Mac browsers used a gamma of 2.2 for everything on the page.
I worked for Steve’s company in the NeXT days so I can understand the dilemma. High-end publishers standardized on 1.8 gamma before consumers seized the web. But publishers understand words like gamma, ICC profiles, and calibration. Try saying gamma to a consumer. They just want the web to look right.
As it is, companies like Pantone are deciding for Steve to set the gamma at 2.2 with their Hueys. Except sometimes*.
And let’s not forget that Apple already recommends changing the gamma to 2.2 after you buy your Mac.
Why not ship OS X with gamma at 2.2 and say farewell, wonkiness?
UPDATE: The story gets worse. 😦 Turns out the right sRGB profile isn’t included by default on the Mac, so you can’t fix things yourself without some outside help. Photoshop installs it for you automatically, as do some other apps. You can download the right profile here and stick it in /Library/ColorSync/Profiles yourself to fix things up.
Google – Please please please support email aliases!
If anyone from Google is reading this, please, hear my plea!
I, like many people, have more than one email address. One for work, one for home. It’s nice to keep them separate. I’m sure you know what I mean.
I also like to use Google’s services, such as Calendar or Docs. Since I use multiple computers, it’s nice to have stuff centralized out on the net. I’ve wanted this for decades.
But my friends & co-workers don’t always know which email address to send meeting invitations or document permissions to. So I get a Calendar invite or a Docs link, and click on it, and I’m greeted with “Sorry, you don’t have permission to use this.” WTF? I clicked on the unique link in my email, and I’m already logged into Google, what do you mean I don’t have access? Oh, duh, they used my personal email address instead of my work email address. Crap.
So I’m left with two choices: Just not interact with Google on this particular event or document (most likely) or email the party back and ask them to resend (least likely).
Please, Google, let me add email aliases (yes, verify that I actually own them first) to my Google Account so all your services will recognize me from my multiple email addresses. Pretty please? With a cherry on top?
Oh, and it’d be nice if our years-old application to Google Apps for Your Domain was accepted too, but that seems to have gone into the void. Doh.
SmugMug's Don MacAskill 
