Man, to say I’m excited about this would be a major understatement. We’re huge Apple fanboys over here, so when we got accepted to the first wave of SDK developers at Apple, we were stoked. Shizam went to town almost immediately and after a few months of hard work, SmugShot was born. (And as I’m writing this, we’re #1 in “What’s Hot” on both iTunes and the iPhone interface!)
So what is it? Well, we knew early on we wanted something very simple and elegant that did only one thing – but did it extremely well. We didn’t want a kitchen-sink photo-sharing / -browsing / -taking application. We already have a fantastic iPhone application on Safari, so the obvious thing to tackle first was actually taking the photos on your iPhone and getting them up to SmugMug.
SmugShot makes it incredibly simple to simply whip your phone out at a moment’s notice and take as many snapshots as you’d like. The photos will be automagically geotagged with your location, should you wish it, and you can quickly and easily enter a caption and some keywords – or not. Your call. We’ll queue them up and send them along to the SmugMug gallery of your choice – over EDGE, WiFi, or 3G.
And that’s basically it. Simple, elegant, clean – just the way we like it. If you’re new to SmugMug, you can create a free trial account right from SmugShot. You can set up a default Caption and some default Keywords to make entering them a breeze. And you can even upload photos that are already in your Photo Library, rather than from your camera (and you iPod Touch users can do this, too). One big Apple bug with that, though – the SDK only give us access to 640×480 versions of photos in your Library. I’m hoping they’ll fix that soon.
The really wild thing is how much I actually use the app. I’m a bit of a snob when it comes to things like cameras and lenses, and lets face it – the iPhone’s lens can’t compare to some fabulous Canon glass. But as the app has spread throughout the office, everyone’s learned the same lesson I have: There’s an awful lot of value in convenience.
SmugShot is so shockingly convenient and easy to use, it trumps the limited image quality for almost all of my normal everyday shots.
Read over on O’Reilly Radar about David Recordon’s post at Six Apart entitled We Are Opening the Social Graph. He talks about the emerging tools and technology to allow shared social graphs, like OpenID, XFN, FOAF, and others.
Given that Thursday night is ‘Release Night’ at SmugMug and I had a few minutes to kill, I felt inspired and whipped up XFN and FOAF support to compliment the partial OpenID support SmugMug already has. (I apologize for not finishing our OpenID implementation yet, but I’m finding OpenID 2.0 to be a complete disaster and find myself at a loss as to what to do. Anyway, I digress…).
I’m absolutely positive we’re barely scratching the surface, and people like David will set me straight, but at least we’re making forward progress – 150K SmugMug accounts now have auto-discoverable FOAF, embedded XFN, and are OpenID endpoints.
What does this mean for you? It means, hopefully, that SmugMug can play nicely with other social applications on the web. Your network of friends & family is now published in machine-readable formats so that other networks can do intelligent things with that data. How exactly this will happen remains to be seen, but there are lots of bright people thinking about it, so hopefully it’ll happen.
At the very least, when the Semantic Web actually works in the year 2022, SmugMug will be ready. :)
When I’m not busy screaming at my iPhone because it’s hard to sync with my LOST episodes, I’m busy rolling out new SmugMug features specifically for iPhone with the help of GreenJimmy and BigWebGuy. Here ya go:
- Global SmugMug interface now. You can search & browse through the entire SmugMug site using iPhone, not just individual homepages.
- Added search to both the global and user interfaces.
- Added Friends & Family links so you can easily browse through your social network and that of your friends and their friends and….
- Added a Keywords browsing interface. I’m not really happy with it, so I think we’ll keep playing, but traditional keyword clouds don’t work well with finger tips on this small of a screen, so we’ll have to get creative. Ideas in the comments, please?
- Spiffy UI improvements to make things look nicer and feel faster.
- Fixed a rotation bug where the images wouldn’t properly re-render.
Enjoy. I know I am. :)
Last week we released some great updates to our iPhone interface, and today I’m sitting at Apple in the iPhone Tech Talk workshop. So if you’ve got any feature requests, now’s a great time to leave a comment – there’s a good chance I’ll ship it today. :)
Here’s what we released on Thursday:
- A link from your homepage to iPhone if you’re browsing on your phone.
- A link on your iPhone back to ‘Full Homepage’ so you can go back to regular SmugMug
- A cookie so if you’ve visited your iPhone interface, it remembers that you’d like to browse that way. Don’t want it anymore? It clears itself if you hit ‘Full Homepage’ on your phone.
- Browsing your most popular photos.
- Browsing through your photos by date. Full timeline supported.
- A green & black interface to get more similar to SmugMug’s traditional color scheme.
Anyway, leave a comment if you want me to build something for you :)
After camping out in line for iPhones for all of our employees, you knew we were gonna do something fun with it. And we have! After testing a new SmugMug release last night, we saw that Joe Hewitt had posted iUI and I thought it’d be fun to play around. About 30 minutes later, we had SmugMug on our iPhones! Turns out browsing SmugMug on your iPhone is a ton of fun – I can’t put it down.
Currently, you can access and browse your public albums on your iPhone. Simply go to http://YOURNAME.smugmug.com/iphone/ . Here’s an example: http://concours.smugmug.com/iphone/ We have lots more ideas already in the works, so I’m sure you’ll see lots more fun stuff soon. :)
There are some fairly neat things about what we’re doing, much of it made far easier by Joe’s excellent iUI:
- The photos are resized on-the-fly by our servers to perfectly fit the iPhone. They’re gorgeous.
- Yes, we detect the phone’s orientation (portrait / landscape) and show you the perfect resolution. You can rotate your phone at any time and we’ll seamlessly change to the right sizes.
- Speed matters. So we only grab 10 of your albums at first, and allow you to bring more in at any time by clicking “more albums…”. Same deal with photos, only we grab 30 of them first, then let you pull more in if you’d like. Even on EDGE, it’s quite fast. And on WiFi, it screams.
- The UI closely matches other iPhone apps, so it’s fairly familiar to iPhone users.
Now, I love my iPhone, but I’ve gotta get on my soapbox a little bit here. Apple really really blew it with developers. I shouldn’t have to hack my way around their browser to build an app which will always be slower and clunkier than a native app. We need a real SDK to build native apps so they can be gorgeous and fast. We would have already built a photo sharing application that would blow your socks off – only we can’t.
Our customers are already telling us how sucky syncing with iPhoto is (I concur), and the fact that we can’t import photos from the web into the photo storage on the phone really sucks. Going the other way is even worse – we have a great camera and an internet-capable phone here, so why can’t I just take a photo and have it magically end up at SmugMug or Flickr or wherever? Braindead.
I apologize the app isn’t as fast or as slick as we would have liked – Apple has us shackled. If you’d like a faster, easier, slicker UI contact Apple and politely ask them to pay attention to their developers.
Thank goodness for Joe Hewitt and iUI. I’m hoping we can start helping out with iUI as we find ways we want to extend it. Here are some of our first thoughts:
- There is no public variable or method for checking Orientation. It sucks to have to rewrite orientation checking code that already exists in the framework because it’s buried in an anonymous function. A custom event framework where we could just listen for orientation changes would be even better yet.
- Using window.innerwidth to determine screenwidth for orientation detection was giving us heartburn in some cases where objects were wider than 320px. Instead we had to look at the toolbar which does remain a fixed width (at least in our testing) and proved to be more reliable. Oh, and we call it ‘portrait’ not ‘profile’ :)
Anyway, those of you with iPhones, feel free to play with it and let us know what you think.
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.
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.
This is a pretty fundamental shift for us, and while I don’t want to give us too much credit, I really think it’s the beginning of a sea change on the web. There have been plenty of apps which launched with 100% AJAX, like GMail, but I can’t think of any that have yet made the plunge to change an existing, entrenched product with lots of users. I’m sure there have been a few, so forgive me if I overlooked you, but certainly not many – most of the big apps are still HTML driven. But I believe that’s going to change because the customer experience just gets so much better.
Everyone is going to do this. The only question is when? (Ok, two questions: And who will be left behind?)
The benefits of this release are obvious: the interface is faster, prettier, and smarter. But the pitfalls are less obvious. Here are a few of the biggies:
- Backwards compatiblity. We built our URLs from day one to be “permalinks” so they wouldn’t change if you used them in your blog and forum posts. We had to make sure that things still worked going forward.
- AJAX Permalinks. Now we needed new permalinks that describe various pieces of data for browsing SmugMug, but we also needed to keep them short so people could copy & paste easily, so they wouldn’t wrap in emails, etc.
- Browser interfaces. People expect the Back & Forward buttons to work properly, along with History and Bookmarks. Doing so in all three major browsers was thought to be impossible, and we failed many times. We solved this one, and this was the last biggie. I believe it’s an internet first. Jimmy will be updating his blog about exactly how we do it so anyone else can follow suit. It’s good for the web as a whole for this stuff to move forward.
It was an amazing team effort over here to get this thing done, including tons of our customers. GreenJimmy, our resident Web Superhero, especially drove this project long and hard. Hopefully we can talk more about what we did, technically, so others can avoid making the same mistakes we did.
Enjoy the release, and just wait to see what we’ve got coming next…. :)