Long time no see. It’s been a while, but you’ll be glad to know we’ve made some substantial progress since our last Cookbook update. Creating and tweaking the UI that Wolfgang has designed was no easy task, and it’s something we’ll be doing until launch. I’m proud to announce that every screenshot you see on this page is an actual build of Cookbook — not a mockup. By the way, we’re still planning to put the spotlights in, so don’t panic ;).
Since the last update, I’ve been focusing on actually implementing the interface and integrating it with the backend. After that, we have been working on the theme rendering and have come up with a theme format that allows you to dynamically render beautiful, subtle themes for your recipes. Moving forward, we will be focusing on the recipe editing experience and other features like the timeline and shopping lists. Overall, we are all very happy with how Cookbook is going. This project is a blast to work on. John, Wolfgang, and I have spent hours tweaking and adjusting to make things “just right.”
It has also been decided that Cookbook will almost definitely be Leopard only. As a developer focused release, Leopard will allow us to realize our ideas faster and with better execution. Little animation touches will be used tastifully throughout the app to create continuity in the user experience, and full screen mode will certainly take advantage of many of the advancements in the new OS.
Recipe editing is something we have already spent some time on and plan to continue refining. We are trying to create a superb user experience as well as a stunning interface. Rest assured that we’re investing as much time in making the app “feel” good and usable as we are on making it pretty.
We’ve also been coming up with some new and cool ideas for exploring the ethnic and cultural aspects of food. Here’s a little tease.
Thanks for stopping by. Keep in mind that everything you see is a work in progress and that we probably already know about all of the little imperfections. As always, we’re very interested in your feedback so please visit the forums and let us know if you have any ideas. Or you could just complain.
I’ve recently alluded to some announcement for My Dream App Season 2 so here we go…
While the three winners from My Dream App 1 are in development we’ve been making plans for My Dream App 2. We don’t plan to launch it until some of the MDA 1 apps are released but it’s never too early to prepare for the future. The MDA 1 apps are coming along nicely and the whole event has been a resounding success from our point of view so MDA 2 will definitely be happening.
So, we’re planning to add another dimension to MDA 2 and that’s going to be a developer competition to go along with the app competition. Since Apple’s WWDC is right around the corner, we felt it’d be the best time to prep for this as some of the MDA team will be out there.
What we’re going to do is have video interviews for interested developers. StuFF mc from Pomcast.com will be helping us with these while we’re there. And when MDA 2 rolls around, we’ll have a competition where you get to vote in the devs to make the winning apps.
So if you’re a Mac developer looking to be part of something big and delicious, the doors are now open. Drop us an email us at devcomp@mydreamapp.com with a brief bio and why you feel you should be a “dream app” developer. We’re accepting entries of either solo devs or teams. The winners will work on the applications and then receive 30% of net sales.
We’re really looking forward to everything upcoming here!
Howdy, Atmoheads!
We went through some pretty serious mental gymnastics coming up with a good way to handle Atmosphere’s configuration. In case you’ve forgotten, in the picture on the left the bottom half is what was mocked up during the competition.
But this isn’t nearly flexible enough. We want users to be able to configure Atmo individually for each attached monitor. But we don’t want multi-monitor functionality to get in the way for people with only a single monitor, the vast majority of our users. And we want users to be able to browse and download new themes from the Intartubewebs seamlessly. And we assume that users will reconfigure Atmosphere fairly regularly, either to change themes, or to change locations, or to change the way that Atmosphere behaves, which means that getting to the config screen, discovering its functionality, and navigating it must all be super simple.
A Really Bad Idea
So what do we do about multi-monitor configuration? Weeeeelll, we could stick a popup at the top of the window that lets you pick which monitor the rest of the window’s settings apply to. Yeah, and we could become Windows programmers and write non-Y2K-ready banking software using Cobol. A popup is ugly, non-intuitive, and increases the click count. Ickage. Not drop-dead simple. We could do something where you set your configuration up and then drag some sort of a configuration proxy to a graphical representation of the monitor you wish to apply those settings to. Vile. And horrible for single-monitor users, the most common use case. Blech. Or, depending on how the user initiates the configuration, we could just open the per-monitor configuration window on the appropriate monitor, or even one for each monitor simultaneously! Low click count, drop-dead intuitive, and degrades seamlessly for the single-monitor case. Daddy likes!
One thing that I learned over and over and over again from my ShapeShifter life is that being constrained to a System Preference pane is like a living life as a vacuum cleaner - it sucks. A lot. The location isn’t easily discoverable for novice users, you’re constrained to a fixed window width, and flexibility just generally (yup!) sucks. So no preference pane for Atmosphere. Thank God… :)
And, as you change settings, we want the changes to show up realtime in the theme previews. This means that the previews need to be large enough to be meaningful. Of course, they’d need to be large enough anyway, just to be a meaningful preview, but live configuration really emphasizes the need for them to be fairly big. Our config window can’t be teensy tiny - it’s got to be spacious! Luxurious! With the quiet dignity of a circus clown in a thunderstorm, oh wait…
We want to make the UI as discoverable as possible, which means minimizing the number of clicks needed to get to any particular portion of it. We talked about sheets, we talked about drawers, we talked about tabs, we talked about flipping portions of the UI off and replacing them with other bits of UI. Instead, we decided that the entire configuration area would be a single pane, with all content visible - positioning and relative size determine the importance and the flow, but you can get to anything you need just by eyeballing it.
The final result is pretty damned sophisticated behind the scenes, while appearing dead simple to the user. We’ve come up with a couple of new UI metaphors that both guide the eye and act as a guide for the functionality, while, of course, including plenty of extravagant visual goodness to keep things snazzy. But it ain’t polished enough yet for your eyeballs, so for now, the rationale behind it will have to suffice. But look out for a sneak preview in May!
The development of Portal reached its next step. Portal now links with Unison. But at first lets recap what has happened so far. Last time I wrote about the decision process how to get the best file synchronization engine for Portal. After I decided we go for Unison it was time to get it to work on Mac OS X. It’s a cross-platform product written in OCaml, a language which is not very common among Mac OS X developers. I wrestled some time with its build process but now it builds just fine and is ready for use in Portal.
After I wrote about the decision to use Unison the question regarding Portals license quickly arose. Unison is GPL-licensed which basically means for Portal that its source must be made available if it links against Unison. While the current development version of Portal does exactly that I have different plans for the final version. It will consist of two pieces, an agent running in the background and a standard desktop application. The agent will implement the core file synching functions and relies heavily on Unison. The desktop application will provide the actual user interface and talks to the agent in the background to accomplish its tasks. Only the agent depends on Unison. The desktop application knows only the agent and uses some kind of inter-process communication to interact with it. You’ll find a similar architecture in iChat which also relies on an agent running in the background. In summary, only the source of the agent would then need to be made availabe.
Now that Portal links with Unison I will wrap its functionality in a way so that it can be used from the actual user interface. The first iteration of the user interface will emphasize functionality to test the user interaction and simply provide a interface during development. After that we will focus on developing the user interface envisioned by Farzad. That’s it so far.
Hey everyone! Cookbook has been progressing from behind closed doors for the last few months and we have some absolutely delicious material for you to check out. Before we get to that, though, we’d like to officially announce that Wolfgang Bartelme, the creator of the TextMate and iSnip icons, has been working closely with us on the application’s design and user experience. In case you’re wondering (and you’re probably not) iSnip was actually a project that I was involved in before AppZapper and it was a freeware semi-competitor to John’s iClip.
It’s worth noting that we have made same pretty drastic strides since the initial mockups by Michael. As you know from the last post, we’re going with a 3 column interface that will promote visual browsing. Likewise, the theme of the recipe view will actually change based on the kind of recipe you’re viewing. We’ve expanded this thinking to include a unique style for the app itself… which we feel encompasses a kitchen atmosphere very nicely while still proving to be neutral enough for the themed recipe view to not look out of place.
The interface and all graphics included are still under heavy development. This doesn’t represent the final version, and things will change down the road. We hope that the more conservative interface advocates among you look at this with an open mind. While we are creating a visually diverse and distinct app, the user experience is incredibly consistent and obvious for our audience.
Without further ado, here is where we are right now with Cookbook’s interface (click for larger):
There have obviously been a lot of visual evolution since the last post, so I won’t even try to go through all the details here. We’d love your feedback on how things are going and we ask that you please comments with your thoughts, suggestions, and death threats. Keep in mind that it’s all in progress so we’re not looking for small details, just general comments.
Here is a little chronological evolution of this stage of Cookbook starting from the last post to where we are now. You can see that we’ve made a lot of changes with everything since then. The Flickr page has a nice repository of even more mockups, so make sure you check it out (clicky):
Now we’re going to be working on some finishing touches of the UI, implementing it and make it feel great, and then moving onto the other parts of the app (shopping lists, full screen, timers, etc.) and giving each the same attention to detail that we did to the main browsing portion. I hope you like it (or at least respect what we’ve done) and that you look forward to our next update!
If you absolutely hate it and think things went potato overboard, well, here’s the next best thing.
Delish? digg it!
