• it lets you “Tap the Cloud” – you can search for recipes other SousChef users have shared. Like flickr, sharing is enabled by default.
• it lets you search your recipes based on ingredients you have on hand
• it has a “10 foot mode” that shows you your recipes fullscreen so that you can keep the computer a good distance from your cooking area and still read the recipe. Furthermore, the 10 foot mode supports reading the recipes out loud and speech recognition.
• it makes it easy to export formatted HTML to your favorite blog
• an import facility to make it easy to convert recipes from unstructured text into structured recipes (title, ingredient list, cooking steps, etc.)

SousChef costs $30, but there is a free download that you can use to try things out before you buy. The tryout version is limited to 25 recipes, shows limited search results, and doesn’t allow blog export. I downloaded the tryout version because I do have a library of recipes in text/word/pdf format on my computer that I wouldn’t mind getting into a nice format. One bug or additional limitation is that the import feature doesn’t seem to work in tryout mode: you can drag the little boxes around, but when you click the Import button the imported recipe doesn’t include any of the text you just imported. Because of this bug, I did most of my testing with the supplied sample database instead of using my own recipes. I hope they fix this bug soon.

I really wanted to like this application: it fits a real need, it had a nicely designed UI (albeit not as sophisticated as Delicious Library which was a clear inspiration), its from an indie developer, and it takes advantage of Mac features like speech recognition. But the program is hamstrung by its business model: cloud-based features depend on large numbers of customers to work effectively, and there will never be sufficient volume of Mac users willing to pay $30 to make these features effective. Furthermore, the developers chose to cripple the cloud-based feature in the free version, in the hopes that it would make more people cough up the $30.

Furthermore, there are large numbers of websites around today that will let you do similar things for free (the best of which seems to be bakespace, though none seem really great). I’ve heard of several people who are trying to build the ‘corkd’ of the recipe world. Guess I’ll wait.

But the more interesting part of the discussion is going on in the comments on the article. Scott Stevenson makes an excellent point:

In my experience, if you try to determine a specific set of rules for every UI convention, you’ll find yourself lost down the rabbit hole. I think this is one of the biggest stumbling blocks for UI in the classic engineering approach: there isn’t always a series of logical decisions to arrive at the destination.

Your example of interior design is a great way to illustrate this. The idea of “mood lighting” doesn’t always lead you to the most practical results in terms of visibility, but it does succeed in creating an experience. In a lot of cases, that’s what the developer is looking to do and that’s what the user reacts to.

Chris W’s comment above mentions that that Weather and Stocks are “unnecessarily” different (and you address these as immersive), but I think it’s a mistake to assume consumers want everything to be as uniform and structured as possible. In fact, that can lead to a very monotonous experience. It’s a delicate balancing act between chaos and stagnation.

I agree with you that developers often use UI conventions in contexts that don’t fit well, but that’s nothing new and will continue to be the case whenever they don’t have the the funds for or availability of a dedicated designer.

I don’t know if it was Scott’s intent or not, but he is clearly arguing against the position of having a rigid set of guidelines (e.g. the HIG) and for a more tailored experience. Interestingly, the next commenter, “JB”, says that Apple is making this much more explicit:

At WWDC, I was in many 1:1s with designers, and every single one pushed me to get more daring with the designs. They told my friend the HIG is for people that don’t know how to design.

This was all strange to hear from Apple, and a little hard to swallow. But there you go — Apple is actively pushing to reduce consistency, and to increase, as they told me “cinematic software experiences”.

I don’t know that Apple’s intent is to actually push to “reduce consistency”, but I agree that the trend at Apple is towards more tailored experiences, and I think that follows along very nicely with the stuff I’ve written about earlier: I have seen the future, and it looks a lot like Flash… and The Death of UI Consistency. I’m curious to see where the conversation goes from here, and whether or not this is the beginning of the end for the HIG-zealots…

The product is the first from a new company, Balsamiq, started by a good friend who worked on Acrobat.com. Check it out!

It’s also cool how the Mozilla/Firefox effort was fueled in part by the donation of Tamarin and Tamarin Tracing to Mozilla. I hope this collaboration can continue to be productive.

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 think the message of Blend has some nice takes, but in the end the whole concept of [the] Designer <> Developer processes to me is always couched in developer controlled languages which is Blend’s ultimate failing. It really is a tool to allow developers to be better designers, instead of a tool that really let’s designers do their job better.

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.