My Dream App - All

Triage

2007-11-06T18:16:41Z

In the beginning, Portal was born from a simple idea: Keep my two Macs in harmony. From the start, we all knew that Portal was a difficult idea, with a limited market (people with two or more Macs), and a nightmare of a development path. J Allard called it the “hardest problem chosen by the finalists.” Steve Wozniak said “there are tremendous challenges here… it seems that there isn’t an easy way to get multiple machines just to sync the simple stuff…” Jason Harris was the most direct: “Ease of Programming: low, Potential Earnings: moderate… Don’t vote for Portal…”

The need for a simple solution to this problem is well known, but how to get to such a solution is not. To that end, and in the hopes that Portal lives to fight another day, I submit the following Plan of Action.

Facing the totality of the synchronization problem is overly intimidating, so I suggest breaking the task into parts, ordered by necessity to a final, as yet unwritten application. This process can be best visualized as a three stage development: Foundation, Frameworks, and Finishing.

Foundation

As an application, Portal needs to first be installed on both systems, and then be granted permission to use the machine’s network interfaces to sniff out other Portal installations. Once they find each other, the two Portals need to connect in such a way as to facilitate file transfer between the systems, both for simple communication between the applications themselves and for the eventual transfer of the user’s files. Furthermore, each Portal app needs to be able to plug into the FSEvents system to be able to track file changes on their systems. For each file Portal is designated to sync, the app also needs to be able to identify the corresponding file on the other Mac so that it can identify conflicts. During a live connection between systems, file changes are automatically synced between the systems as they occur, so no dedicated “Sync Now” process is necessary. When systems connect after an extended period apart, the sync should launch automatically in the background.

Conflicts are the meat of the syncing problem, so lets pause for a moment on them. The zero-order, brute force solution would be to simply overwrite older files with newer ones. This is the option presented in the Mac OS X Finder whenever you try to add a file into a directory where a file with the same name already exists. For database driven applications, a partial merger is often available, such as when syncing a Contact or Calendar event from a portable device to a main system (like the iPhone to a Mac). These options should be available as appropriate within Portal’s conflict resolution system (see below). For safety purposes, older files should be backed up in either case (overwrite or merge), in case the network connection is lost in the middle of a transfer. My idea would be for all files to be moved to a temporary directory on the destination Mac first, then copied over the existing files later on. The file transfers should be checked for completeness and authenticity before the overwrite, and the older files should be moved to a safe location (either on the local drive, to a Time Machine backup, or elsewhere as designated by the user).

Network communication, file selection, file transfer, and file backup form the Foundation of a good syncing application and are the necessary first steps for Portal’s development.

Frameworks

The best way of handling conflicts is not at all clear cut. For some files, Apple has made the process simple (Sync Services), but for others you are left wanting. Thankfully, there are several independent initiatives working towards better solutions. Unison was the original favorite out of this category thanks to its robust feature set, but we shouldn’t stop there. To improve upon any one of these individual frameworks, Portal needs to take a “Best of Breed” approach to conflict resolution and use them all. The brute force overwrite method will be in place for all files and types at the beginning. Later on, specific improvements for a given file type (such as .HTML, .PLIST, .ICS, or .KEY) will be put in place on a case by case basis. If Unison is really good at DOCX mergers, but not so good at TXT, then Portal should limit Unison’s use to DOCX and find something else for TXT. Necessarily this complicates the mechanics of the conflict resolution and means that Portal will have a long development cycle. From a user point of view, the complications should be entirely hidden. From a developer point of view, one should realize that these improvements will be made incrementally and are not intended to all be ready for the 1.0 product. Version 1.0 is not the finish line!

Portal can move from a basic “smart file pusher” to a real, full featured syncing app by taking advantage of many of these existing frameworks (and improving them when possible).

Finishing

The last step is to hide all the difficult work done so far underneath a clean, simple user interface. John Casasanta said he’d “like it to be as simple as SuperDuper is at backing-up your computer.” J Allard said he’d “like to have seen less intrusive ui and for it to be directly integrated with os x“. I myself have started going in the direction of a “Time Machine”-like app where the core preferences are stored in a Preference Pane inside the System Preferences, and yet the app’s “main” user interface can be launched by a Dock icon. The goal is to make the act of syncing transparent and the process of conflict resolution quick and simple. The keyword here is subtlety. As much of the work as possible should be done in the background in such a way as to minimize visibility to the user (this means keeping processor usage down as well). When the user must be contacted, it must be in such a way as to minimize distraction from the user’s actual work. Popup boxes and dialogs should fade in and out quickly, information should be clearly presented, and the choice to be made should be explained properly. If the user wants to trust Portal to make all the decisions itself and have no user input whatsoever, that should be an option as well. If the file backups are robust, then this level of trust should be well warranted (possibly to the point of making it the default setting). File restore should be handled as efficiently as possible, taking cues from Time Machine (or even using Time Machine itself) when possible. The user shouldn’t have to learn an entirely new set of UI metaphors just for Portal.

If we let Apple dictate the user experience themes, then Portal can sink even further into the background and be that much more transparent. Extravagance and panache will be held in reserve for the occasional sync animations (user activated only, since the default background sync is invisible).

—-

In the end, Portal cannot be the end-all, be-all solution to the syncing dilemma. All Portal needs to do in order to be a success is be a solid 90% solution. (For the sake of the UI, that last 10% would be hidden anyway, so new additions wouldn’t even be visible to the typical user.) The Foundation level alone should get Portal to a 50% solution, with brute force overwrites as the ONLY “file merge” option. More options can come online with version updates. Integration into existing frameworks like Unison will also come later. All the while, the UI will evolve to match the new features, adding or removing controls as necessary.

Leopard: Pause for Thought

2007-10-29T23:29:27Z

When we started this whole My Dream App adventure, there was a stated goal that the ideas should take advantage of as many Leopard technologies as possible. At the time, we knew a little about Leopard, but since I for one was not a developer, there was really very little for me to go on. Jump forward a year, and Leopard is out (and installed on all of my systems), and all the NDA’s are lifted at long last. In that year very little was said about the applications under development for Leopard, thanks to Apple’s own embargo. Again, as I am not a developer, I was never privy to the specifics of those agreements, but nonetheless I was aware of their existence.

All that is water under the bridge now. Leopard is in the wild. The ADC has a full suite of Leopard developer notes. Ars Technica has even posted a magnificent breakdown of the core technologies at work. Reading all this material has given me pause for thought about how Portal will work and integrate into this new ecosystem.

Finder: File and Screen Sharing

The Macs on a local area network see each other much more easily now, and are much more talkative. It took very little time for me to set up file shares between my systems, so little in fact that I’ve stopped using DropCopy entirely. I have a standing link on each desktop to the drives in all my other machines, making file transfer insanely simple. The hardest part is deciding which files to send over, and, of course, dealing with conflicts. Screen sharing is another magnificent feature, and the “Back to My Mac” addition to .Mac is a powerful draw. The $99 price tag Portal was set to rally against has just gotten justifiable. I was even able to set up a screen sharing session with a Windows XP system in my house (the file sharing was one-click simple, the screen sharing was not. It took five-clicks).

The result is that machines on a network are all at your fingertips and the need for a file to be on your local system is diminished. Why sync your laptop with a bunch of files that just hog space on your hard drive, when you can just go “Back to My Mac” via the web from wherever you are? The only flaw in the argument is the issue of off-network access (the same flaw in the iPhone/Web Apps debate). The issue of “keeping two books” is also still present. Why do I want to risk having my iCal calendars on the laptop disagree with the desktop? With Leopard, .Mac becomes that much more powerful, much to the chagrin of Portal.

Time Machine, Spotlight, and FSEvents

I’m not a developer, and I’m not a computer science guy per se, so what I’m about to talk about may not be 100% technically correct. Just bear that in mind. Leopard has two headliner applications that take advantage of a low-level, system-wide event tracker called FSEvents. This API allows applications to track any and all file system activity, and it does so in such a way that the application that is doing the request doesn’t have to run all the time. Log files are created that keep track of all the events, so when an application comes online after being turned off for a while, it can take a quick look at the event history and know what’s changed about the system. Spotlight uses this to keep its search indexes up to date. Time Machine uses it to keep its backup directory up to date. Portal could use it to keep track of files that have gotten out of sync. The beauty of the FSEvents solution is that it is the user-level application doesn’t have to handle the task of looking for changes and tracking events. That sort of activity, which is potentially very time consuming, is handled by the OS itself.

The ideas I had a few days ago about Portal acting a lot like Time Machine were more prescient that I had thought. I had intended that Portal simply act like Time Machine in the sense that it was a tightly integrated System Preference that also had a full-screen “WOW-factor” interface. In truth, Portal would be well served if it could tap into the same system event tracker that Time Machine uses, and now it appears that such a thing is actually possible!

An added benefit of having a system-wide event tracker and backup system is that there is added pressure for high granularity in files. Massive databases are no longer practical in the post-Time Machine era since they take up unnecessarily large amounts of space (each change to a 50MB file means a completely new 50MB backup, even if the change only affected 50KB of real data). As granularity increases, so does the possibility of better and faster syncing. Apple has also taken to the use of XML in many application and file settings. Merging XML files is far from trivial, but it is a potentially simple file to read and to track changes in. This makes it possible to go in even tighter than the “per file” level for the syncs. This means less data needing to be sent between systems and more applications being candidates for syncing. Its a win-win situation for Portal.

Sync Services

Apple defines the “Five Phases of Sync” as:
Create a Sync Session (clients are alerted that a sync is coming),
Negotiate How You Will Sync (set modes for sync engine: fast, slow, etc),
Push Changes (either whole files or just the changes),
Resolve Changes (conflict resolution, either automatic or user-defined),
Pull Changes (all clients pull down the best file, after conflicts have been fixed).

Leopard is better suited than ever to communicate with other machines (both Mac and Windows), so setting up a Sync Session shouldn’t be difficult. Changes can be identified by calling on FSEvents, which will be running in the background on all Leopard machines (even without Time Machine turned on, Spotlight still uses the daemon). Conflicts can be resolved using the Unison framework, as has already been stated. Apple also includes a few handy services in their default Sync package for dealing with contacts, calendars, etc. that might be useful to integrate as well. The act of pushing and pulling the files from system to system could be handled by the OS and its handling of local servers (for standard file sharing, with the same privileges, etc), or it could be handled directly by the Unison layer. That sort of decision is entirely up to Martin, since I have no idea about how to do either one. (Martin, if I’m totally off base here, I apologize!)

The point I’m trying to make here is that all the pieces of the puzzle for a great syncing application are in place. Changes can be easily tracked. Conflicts can be handled by the OS for some cases (contacts, calendars, etc.), and by Unison in others. The Macs can all talk to each other very easily, so local networking won’t be an issue at all. I can even see it being possible to have Portal push itself out to all your machines so you only have to go through the installation process one time.

An Awkward Reentry

2007-10-24T18:10:48Z

Let me make this clear: What I am about to talk about is pure speculation. I don’t have Leopard, I don’t know what the most recent version of Portal looks like, and I don’t know when Martin is going to make any future announcements. Martin is working on his ideas for the UI, and I’m working on mine. There are more pressing issues with the development right now than the interface. You’ll hear about that end of things later on.

Okay then. Today I want to share a few ideas I’ve had about Portal’s user interface. The more I look at Time Machine, the more I like how Apple has managed to make it both accessible and hidden. There is an icon in the Dock and there is a keystroke for quick activation, but for the most part Time Machine just runs quietly in the background. When you do need to make changes to the settings, you interact with Time Machine through the System Preferences, just like for the Dock, Expose, Spaces, etc.

This got me thinking. If Portal is going to work the way it needs to, then it has to be seamlessly integrated into the OS. Logically, that would put its interface into the System Preferences with the rest of OS X’s settings. Also, the user needs to be able to get at Portal quickly and directly, so a Dock icon would be handy. The icon could serve a double purpose as a Drop Icon for adding files to be synced.

I took a few minutes this morning and put together an idea for what I’m talking about:

I intentionally removed the “Sync” button, since I don’t want the user to have to do that sort of thing manually. Syncs will take place periodically in the background whenever possible (again, just like Time Machine). If the user feels the compulsion to force a manual sync, that option can be put in the pop-up over the Dock icon or in the Settings tab . Keeping track of file histories (Time Machine) between two systems may be impossible, but that would be a cool feature to have too.

Leopard is upon us and miraculously I had a brief lull in my workload. If there is anyone left on this site, I’d appreciate your comments!

Cooking The Books

2007-07-12T03:16:49Z

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.

Hello? Is This Thing On?...

2007-06-07T00:49:34Z

creeeeeaaaaaaak…

“Echo-co-co-co!”

Well. It’s certainly been a while. The dust has settled. It’s quiet in here… but the smell, the smell brings back a lot of memories. If anyone’s still out there, I just want to ensure that the health of the “Codename: Hijack” project is still alive and kicking.

In fact, over at Hijackapp.com, I’ve announced that a new name has been chosen for the app, but is yet to be revealed to the public at large. Rest assured, it’s pretty darn good, and I feel almost as good about the new name, as I did for “Hijack”.

Expect some real movement over the summer months, and give Stephen Deken some encouragement… he’s been doing a bang up job so far. But now the time comes for me to start getting my hands dirty again. This ain’t a game no more…

Ground Control Site Has Moved

2007-05-16T12:40:00Z

Just in case you missed Steve’s posting in the Ground Control forum here as well as the on the Ground Control site, I thought I would post the links to it here so that those that are still subscribed to the RSS feed for this forum will hear the news. They’re both the same thing–but I thought I would post both anyways.

MDA Post:
The end of the beginning. Almost.

GC Post:
The end of the beginning. Almost.

In it, Steve lays out the basic milestones and goals of developing Ground Control as well as announcing that the site has been moved to a new home:

groundcontrolapp.com
groundcontrolapp.com/blog
groundcontrolapp.com/forum

Would enjoy hearing from some of the old faithful who might have given Ground Control up for dead.

Get Ready for the Earth to Move

2007-05-09T06:16:00Z

Well, this is just a teaser post to let everyone that has been waiting for the earth to move regarding Ground Control to know that, it is indeed about to move. And, in more ways than one! Not only are we about to see some serious movement, but we will also be seeing the whole Ground Control site move to a new home. We’ll be announcing that soon. The site will redirect when the move is made so you don’t need to worry that everything will be going away if you have it bookmarked.

Steve Streza is currently working on a blog update that will basically get everyone up to speed about where GC is at and where it is going as well as some new information about developers that are on board to develop GC modules for their apps. Some seriously exciting stuff. He is looking to post that in the next few days and we want to keep the MDA crowd informed too, so keep an eye out.

So, finally, get ready for some real movement on Ground Control.

My Dream App Season 2 Developer Competition

2007-05-03T04:07:04Z

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!

09 F9 11 02 9D 74…

On Configuring Atmosphere

2007-04-18T09:32:57Z

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!

Portal links with Unison

2007-04-06T16:55:27Z

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.

The Next Generation

2007-04-04T05:53:23Z

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!

Vrrrooooom!

2007-02-11T04:52:01Z

It’s been a bit quiet here lately…I’ve been finishing up work on iClip 4 and finally released it, Jason’s had a couple of contract work obligations to finish up, and Austin’s been slaving away on the big 1.0 release of Disco which was just released today.

I’m happy to say that we’re now in full-blown My Dream App development of the apps. On Wednesday Jason flew in from Arizona and Austin bussed in from Western Massachusetts to head up to my house in the White Mountains area of New Hampshire. They’ll be up here for a bit so that we can all collaborate in a better and more interactive way than we do via the Internet and phone.

Virtual Reality

Communicating via the net has its plusses…you can work with others based on who they are rather than where they are. My Dream App simply would never have happened if it wasn’t for things like iChat, email, and Martin’s SubEthaEdit.

The big downside to the net, though, is that the interactions simply aren’t as rich as they are in-person. In a single day here, the three of us banged out most of the pending UI details for Atmosphere. If we did this via the net, it would’ve taken days, if not weeks of back-and-forth communication.

There’s something cool, yet somewhat disturbing, when you can argue about a sheet’s default button during a Malaysian feast.

Coming up…

Jason should be posting here soon with an update on some of Atmosphere’s UI refinements. We’re really satisfied with what we’ve come up with…it’s guaranteed to be delicious. ;)

And it looks like we may be finally be nailing down a graphic designer for Cookbook. Austin and I had a Skype chat today with a superb candidate to try to work out the details. I’m glad to say that it went very well.

It’s taken a while to find the perfect “fit” with a designer but we’re now one giant leap closer. Hopefully we’ll be making a big announcement about this shortly.

Fun and Games

One thing that’s vital to My Dream App being a success is that the whole thing must be enjoyable and fun for us. Plain and simple…if it’s not fun, it’s not worth doing.

We’ve setup a My Dream App flickr account to document some of our experiences. To help keep development progressing, we’ve been supplementing the “marathon coding frenzies” with healthy doses of hiking, Wii-ing, fooding, movies, etc. So far, the whole thing’s been a ton of fun. One of my favorite pics in the group is of an attempt to fix a Disco smoke bug from a mountain top.

Stay tuned for much more…

Portal Update

2007-01-27T14:19:16Z

You might wonder how is Portal’s development progressing after Austin and Jason posted their updates a while ago. After posting my article on the research of file synchronizers I am looked through all the publications and articles I mentioned and a lot more. As it often happens with these kinds of inquiries you end up in similar or even completely different research areas. In this case I found out that some file synchronization publications overlap with the research underlying my company’s product SubEthaEdit which features collaborate text editing.

But let’s get back to identify the implications for Portal’s development. Soon after reading the fundamental papers about this topic I felt confident that you probably won’t invent a new file synchronization engine yourself. There are a lot of interesting tools out there which work quite well but either lack a cool user interface as envisioned by Farzad or just don’t quite meet the requirements Portal has. For example, rsync is a very popular tool among administators and power users to keep file trees in sync over a large number of machines. rsync tries to minimize the transfered bytes to keep two copies of a file in sync by doing incremental updates on the file. This is especially great for slow connections where you don’t want to transfer a complete file if only a few bytes have changed. The described approach is employed by the rsync tool and is generally known as the rsync algorithm. You may find the algorithm implemented in other software as well. But what else does rsync offer? It is basically used as mirroring tool. You can mirror a file tree from your machine to several others. It allows you to promote changes you made on your machine to others. If you change your files on the other machines and then want to promote them back then it get’s difficult because rsync doesn’t have great support for back and forth synching. It’s great as a uni-directional mirror utility. Using Portal you want to have bi-directional synching because you want to work with your files on every synched machine without worrying whether they can be promoted back. Therefore rsync is not an option for Portal.

My next candidate was Unison. It caught my eye early on because like rsync it is a tool that is widely used and not yet another research prototype. First of all it support bi-directional synching which we want for Portal. It uses a compression protocal similar to rsync which makes it suitable for slow links. Besides that it is resilient to failures. I think this one of the most important aspects if you don’t want to worry all the time whether my synching software is gonna destroy my data on the next update. There are so many failure scenarios in a synching application. You can experience all sorts of network failures. Your software might crash. Your files are modified while the synching process is still going on. But in all those cases you want your replicas to stay intact and be synchable in the future. Unison has put a lot of effort into making sure that your data is safe. Interestingly enough Unison features specification dealing with all those issues that is also proven.

What does all this mean for Portal? After my research on topic I decided to use Unison as the foundation for Portal. There are two options for accomplishing this. The first approach I pursued would have been a Mac OS X specific implementation of the Unison specification. The result would be an optimized solution for Mac OS X which could make use of all the operating specifics. Implementing your own solution takes a lot of time and you wouln’t see any flashy results because it would involve mostly file I/O and network programming. Comparing to an existing and mature implementation your own solution will surely inlcude many bugs and issues at the beginning. The second approach I’m now focusing on is to use the existing Unison implementation and build Portal on top of it. Unlike the first approach we now get much sooner to the point where we can experiment with application interaction, i.e. user interface. My next step is to build a prototype of Portal using the Unison tool under the hood.

Another Cookbook Update

2007-01-18T04:52:55Z

So, it’s time for a long-overdue update on Cookbook. If you haven’t already, read Austin’s blog entry, where he offers his perspective: http://mydreamapp.com/news/post/377/.

Collaborating with Austin and John over the last two months has been very productive. As you can see, Cookbook has evolved dramatically. And while it may look quite different from the original screenshots, the concept is very much still there. I think we’re still some time away from an actual release, but much progress has been made.

The recipe management and editing portions of Cookbook are close to being completed, so Austin will be tackling other features soon, such as meal planning and all that other jazz. Because the current UI is quite different from the original mock-ups, the interfaces for meal planning and grocery lists will be redone as well, to work more intuitively inside the new wider window layout.

Speaking of which, I think the three-paned layout of the new window works much better. John and Austin pushed the idea, and I’m glad we went with it. Organizing and browsing recipes this way, as opposed to using one source list with disclosure triangles, allows for a more intuitive experience and also is much better suited for the widescreen displays shipping with all Macs these days.

As for the visual themes for different cultures that Austin talked about, I initially had reservations about it. The possible issues I saw with it was that not every recipe could be definitively classified, and the number of themes that needed to be designed to cover the range of world cuisines could be prohibitive. Lastly, I wasn’t sure if the concept could be pulled off well. (I had flashbacks of MS Word clipart from the ’90s.) But reconsidering the idea, instead of the typical tacky cultural elements such as flags and national colors, certain minimal touches could be incorporated, such as stone and unfinished wooden textures for Japanese recipes, and an earthen and sun-roasted appearance for Italian recipes. (Think of the walls of your neighborhood Olive Garden.)

As for the appearance of the application itself, we were toyed around with the idea that instead of a simple Aqua theme, the application could have certain kitchen appliance elements, such as an LED readout, which you can see in the mock-ups below. In this case, some non-Aqua touches could work well for this application without looking out of place on a Mac desktop.

Here are another two conceptual screenshots of Cookbook, of how certain UI elements such as clocks could look like and how the user could interact with them:

Mock-Up 1 / Mock-Up 2

The window borders in these two mock-ups are also somewhat darker than in the ones Austin posted. I think a darker appearance breaks up the different parts of the window better. Borders were something John really pushed, and I agreed with him that they help separate content much better than a simple borderless design.

Update Time!!!

2007-01-17T21:34:57Z

I think it’s due time for a Cookbook progress update. We’ve spent the last few months actively collaborating on the Cookbook application design and working on the UI and, now, the actual programming portion has been underway for a few weeks. I think it’s worth stating out right that it has been a pleasure collaborating with Michael on the UI, as he clearly brought a lot of new ideas to the table. We never really expected the winners to play such a big role in the development — but they are, and that’s a great thing.

So where has Cookbook gone since you last saw it? Well, it has most definitely evolved. One of the most important things we wanted to emphasize was visual browsing of your food. John and I began talking months ago about how text based lists just won’t cut it for something as visually diverse as food. Would you rather see “Key Lime Pie” or an actual key lime pie? To afford the visual space required by pictures, we moved the app into three columns. Michael had created two mockups, one featuring an outline for the source list and one with a drawer and pop up based form of categorization. In our experience, average users have a lot of difficulty dealing with outlines when you almost never need to heavily nest categories. The left to right flow of a column based app works very well and provides a visual and straightforward user experience.

Considering the new visual approach to the app, we’ve decided to include at least 300 beautiful stock photos with some slick Google Image integration. You’ll be able to see a quick iChat buddy icon style pop up for the Google Image results in case you want something a bit different.

Beyond just the pictures of different dishes themselves, there is a very visually diverse nature for food: the culture behind it. Whether you’re dealing with Japanese, Italian, Mexican, or Middle Eastern, the style and beauty behind the culture is what really defines the cuisine. That’s why we’ve decided to offer some simple visual changes to the app depending on what cuisine you are in. If you’re in Mexican, you’ll feel like you’re in a Mexican restaurant. Likewise, we hope to make you crave for some great pasta when you’re in the Italian section. We’re going to do this by offering a themable attributes view whose background and section containers change. I hope you understand that we intend to approach this with a great sense of Mac style. Look at the shelves in Delicious Library, for instance… it is certainly possible to take a physical object or pattern and apply the right style to it for it to fit into a Mac app.

This brings us to the next major change: the recipe editing. The initial mockups included a sort of Address Book style list solution. A lot of users have problems understanding why you have to go into edit mode before being able to edit, and even then why they can’t just start typing free form. We’ve decided to make the direction and ingredient editing as free form as possible while still offering intelligent formatting and gutter utilities. For instance, if you reference an ingredient in a direction you might have an easy “add to shopping list” black and white icon that appears next to it. Likewise, ingredient calculation will be very freeform. We never want people to have to open up a sheet and go through a few tabs to change or find out some info. The entire visualization and management process will be transparent.

Well, there’s your update. And now… take a peak at what an actual (non mockup) build of Cookbook looks like (click for big version and bear in mind that a lot of the graphics are temporary!):

We considered describing all of the different stages of discussion in detail but I think the mockups created in the process speak for themselves. Check out what it took to get to this point:

Mockup 1 � Mockup 2 � Mockup 3 � Mockup 4 � Mockup 5