I also have to pass on this scalability post from Ted Dziuba (via Stefan Tikov via Jeff Atwood), which I found very funny (and yet so true) in my punch drunk state: I’m Going to Scale My Foot Up Your Ass.

Unless you know what you need to scale to, you can’t even begin to talk about scalability.  How many users do you want your system to handle? A thousand?  Hundred thousand? Ten million?  Here’s a hint: the system you design to handle a quarter million users is going to be different from the system you design to handle ten million users.

Amen, brother. Subscribed.

I’m glad I can finally talk more about the project that has been consuming me for the last fifteen months – the first beta release of Acrobat.com. One of the questions the end users of SHARE ask us a lot is whether SHARE is just a short-lived experiment – they worry that Adobe will just shut it down one day and they’ll lose their files. I think the announcement of Acrobat.com, with what was once known as share acting as the central file hub, should address that question pretty convincingly. It was hard not being able to give people a real answer before.

Beyond that, there is so much to talk about here that I need to split things up into several blog posts. For this first post, I’m going to talk about the project from a more personal and historical perspective. Future posts will discuss the design of the new file organizer and the work that was done to make SHARE scale.

I came into the project myself somewhat serendipitously: just a couple of months before, I’d taken a job as an architect in the Acrobat team, thinking about how we could further extend PDF’s reach – on the web, on mobile devices, etc. One of the things I designed was a better experience for viewing PDFs in Flash, which ended up being one of the key features of Adobe Share. At the time, though, I was really thinking more about mobile devices. (I did some other cool design/prototype work, some of which may show up in Acrobat.com one of these days…). But then there was a reorg, and my boss had me take over an existing group that was responsible for several existing hosted services around PDF, most notably Create PDF, Adobe Document Center (which lets you protect PDF files), and pdf2html (an online PDF to text/HTML converter intended primarily for accessibility). Together, these services generate quite a bit of traffic, a lot more than people might think. But they weren’t generating enough traffic or revenue to make them into a viable business in and of themselves. We joined forces with the Acrobat Connect team who were working on a next generation web conferencing platform that became Brio. Our mission was to take the talented and experienced teams who had built those services and help them build something more successful that focused on collaborative work in its myriad forms.

For my team, the first step was to build SHARE, which was first released in October 2007: something extremely easy to use and that solved a real world problem, something we could build relatively quickly and get feedback on from real users. From that perspective SHARE was a huge success. We’ve gotten a lot of user signups, we’ve shipped a lot of releases, and we’ve learned how to scale our underlying platform. That platform, by the way, is largely based on the Document Center code-base. But you’d never know it by looking at the UIs of the two products (click the image to view full-size):

(I also need to mention that we had a lot of help on the SHARE UI from our talented XD designers – thanks y’all!)

Along the way we also bought Buzzword, which fit in incredibly well with our strategy for acrobat.com. When you look at the product today you can see how well the pieces fit together, and it shouldn’t be hard for people to figure out how we’re going to mesh these projects even more closely in the future. It also shouldn’t be hard to see how the incredible UI design of Buzzword has influenced the design of the rest of Acrobat.com – one of the things we’ve been working very hard on is redoing the user interface of SHARE, using the Buzzword document organizer as a starting point. But Buzzword’s organizer only had to deal with one type of document, it didn’t support thumbnails, and it wasn’t built to help people organize larger numbers of files. Once again, we worked with a lot of talented designers to come up with a new design. I think the new organizer in Acrobat.com has really come up with some innovative ways of solving those problems, which I’ll discuss more in a future blog post. Again, a side by side comparison is in order:

We also had a very fruitful collaboration with the teams who make Acrobat and Reader. These teams are much larger and better organized than ours, and they are working on a much more mature product. I know there were more than a few times when they wanted to throttle us because our product reliability was “chaotic”, and I want to thank them for their forbearance. I think the end result is going to be an incredible boon to our customers – the workflows for Shared Review and Forms are vastly easier to use now that they are integrated with Acrobat.com, and having our AIR application included with Reader should help a lot of those users share their documents with others.

Looking forward, I’m incredibly excited about the future stuff we’re working on as a group. Supporting more and better ways to organize your work, adding new types of collaborative workflows, adding subscription features people will gladly pay for, and even inventing whole new classes of applications. I’ve been very lucky in my career to have been able to work on three completely new categories of commercial software, all of them focused on collaboration: first Pink/Taligent, then PlaceWare (which eventually became Microsoft Live Meeting), and now Acrobat.com. I expect that Acrobat.com will be by far the most successful, whether measured in terms of revenue, number of users, or, most importantly, as measured in the effect it has on the way people work together.

I’m planning Adobe Share support for AgileAgenda (my scheduling app), but the thing that’s been keeping me from doing it is the beta status.

When it goes official, what will be the fee structure? Free? Free for a limited account, pay for more? Pay-only? How committed it Adobe to the technology? If nobody uses it will it be gone in a year?

Also, being able to embed the content in a web page is great, if you’re sharing one of the few supported formats. But what about custom file formats? I want to supply a custom swf that’s used as the embedded viewer.

First, its really cool that you’d like to support SHARE in AgileAgenda. This kind of integration is exactly the reason why we spent so much time building web services APIs.

Second, on the future: although I can’t make any guarantees that mean anything, the future of SHARE is pretty bright. There is some other software coming from Adobe that make use of the same web service APIs that you can get from SHARE today, so we are pretty darn confident that those APIs will still be around for some number of years to come (since we had to sign support commitments in blood).

Third, on custom file format viewers: this is something we’d definitely like to do, although there are some serious security issues around embedding third party SWF objects inside of our Flex UI which we’re still trying to figure out. So no dates for this functionality just yet. Anyone have any tips? Send them my way.

Fourth, and finally, SHARE itself is getting a little stale, in internet time anyhow: its been almost five months since our last major update. That’s way too long, and we’re going to try to make sure we have something cool to show every couple of months from now on. The good news is that some of the key features we talked about at MAX last October are literally just around the corner, driven in large part by the feedback we’ve received on SHARE to date. And I’m even more excited about the new UI functionality coming in the release after that, which I get to play with a little more every day.

Anyhow, I hope this helps people who are working with SHARE feel better about its future. Hopefully we’ll have more to talk about next week.

I’m hiring two great engineers to work on the leading edge of our next generation of web applications:

• A QE engineer with extensive experience proving the scalability of web applications and web service APIs. This position is in San Francisco.
• An application UI engineer who has an evolved design aesthetic and wants to build killer web applications using Flex. Knowledge of Flex not required, but the ideal candidate will be able to show me at least one great user experience they built using Cocoa, WPF, AJAX, or similar. This position is in San Francisco or San Jose.

If you fit this mold, send me email (shebanow AT adobe.com) and tell me why you are the person I should be hiring. Adobe is an awesome company to work for, and the project is very cool and very high visibility within the company. You don’t actually have to work for Yahoo!

Then Robin Good did an in-depth review of SHARE on his “MasterNewMedia” blog today, and he had some very positive things to say. I’m also happy that several things he said he’d like to see improved were things I was able to demonstrate the day before I saw his review. I want to call out one particular quote from the review, though:

By focusing on simplicity and key features, without trying to do everything under one roof, Share succeeds in providing a tool that is ready to be used the next second you are logged in. With a clean and very well though out interface Share feels intuitive and smooth both to the novice as well as to the tech savvy user.

I think this is a super-important point. It is often a lot easier to build an application with tons of features crammed into every corner than it is to build a application that relentlessly focuses on doing a few things really well. In SHARE’s case, the thing it does well is sharing documents with others. Everything else we do is there to support that usage: previewing, embedding in blogs, and so forth. Nice to see that this quality came through. Thanks Robin!

Meanwhile, my cohorts on the Buzzword team continue to rack up nice review after nice review. As good as I think SHARE’s UI is, it feels a little crude sometimes compared to Buzzword’s amazing level of polish. Even dedicated Mac fanatic John Gruber likes it:

Best web app word processor I’ve ever seen. It even does things like let you use Mac-standard shortcuts such as Command-F (Find), Command-S (Save), etc.

John is absolutely right: it really is the best word processor on the web, by far. And it could only have been done using Flash and Flex.

Buzzword, SHARE, and BRIO are the three publicly available projects our team has going right now, and together they make for a pretty exciting set of services. I’m really looking forward to seeing people’s reactions once they see our next generation of stuff in just a few more months…

The SHARE team is pretty excited about this: its really cool to see someone take your fresh off the presses technology and do something with it.

Ray does mention the fact that the API supports folders, and the fact that those folders don’t show up in the SHARE UI. This is intentional – we’re trying to keep SHARE using the same sort of hierarchy model as Lightroom, iTunes, and so forth: a single flat namespace with collections (aka albums, aka playlists, etc.) that are simply links to files within the flat hierarchy.

We use folders as a way of storing things that aren’t actually user files: thumbnail images, Flash previews, etc. We don’t index files in subfolders for search, we exclude them from some metadata searches, and so forth. This means that if you do put files in subfolders, they aren’t fully participating in the SHARE system and the results may not be what you expected/desired in future versions of the software. We’re expecting to add a lot of mechanisms for user defined collections, tagging/keywords, and more in the future, and we may have some other way of specifying hierarchy as well (e.g., collections that contain collections). Bottom line: don’t put user documents in subfolders.

But here we are late Sunday night – I just arrived in Chicago for MAX and our product’s press release has hit the wires. So now I get to talk about what I and a great team of talented folks have been working on for the last half year. Its a web service that makes it easy for you to collaborate on documents, code-named “SHARE” (it was a last minute name change, in case you were wondering). SHARE allows you to store your documents on the service and share them with others, either via email, via a link to a URL, or by embedding a preview in your webpage YouTube-style. Here’s a screenshot of the main interface (click to view fullsize):

But the coolest part of the product, in my opinion, is the previewing technology. When you are logged in you can preview documents just by double clicking them, but we also support previewing for people you share the document with:

Right now the previewer works for PDF and image files, but in the near future we’ll add support for MS Office and OpenDocument formats. We also make it possible for you to embed a previewer in your own web pages. I’d show you one now, but wordpress doesn’t allow flash embedding (rats!). I’m going to have to go talk to them about that…

I’m also very proud of our REST APIs, which we think will let people do all kinds of interesting things with our service. I’ll have more on that in a future post.

We’ve got other cool stuff coming: integration with buzzword, a printer driver that lets you print directly from any application to SHARE as a PDF, an AIR application, and much more.

The release right now is a limited beta, in the true sense of the word: the software is still rough around the edges. But we’re releasing it now because we think that its pretty usable even in its current state, and we want to get feedback on the UI and start talking to people about the integration possibilities. But give it a try: there may still be some slots open:

http://adobe.com/go/share