In this video from FOWA London 2009, Francisco Tolmasky will demo Atlas, a new visual tool for building web apps and desktop apps. It will blow your mind and change what you thought was possible with web apps. This is new footage that has not been shown to the public ever before.

Editor’s Note: Only eight hours till we launch FOWA Miami 2010! There’s only 20 Super Early Bird tickets at 47% off, so be quick (only 440 seats total, so the show will definitely sell out early). Speakers include: Twitter, Reddit, Mint.com, jQuery, Palm Pre, FreshBooks, Opera and PayPal. Keep an eye on events.carsonified.com for the launch at 9am EST.

At 280 North we’ve been working on a framework called Cappuccino for creating what we like to call desktop class applications. These are not your average web sites, but instead a new breed of web application that aims to replace many of the programs that currently run on your desktop. When we launched 280 Slides, the first application built on this framework, many people were surprised to see just what was possible in the browser. Since then, Cappuccino has been steadily progressing with over 40,000 downloads and code contributions from twenty-one individuals.

The goal of Cappuccino has always been to make it as simple as possible to build high quality applications in the browser, and up until now we’ve worked on providing built-in behavior for enabling such tasks as autosaving, undo/redo, and copy/paste. But recently we’ve been focusing on an entirely new product: Atlas. Atlas is a new IDE and visual layout editor that leverages the power of Cappuccino, but drastically reduces the amount of work required for creating a truly rich application experience on the web.

WYSIWYG

With Atlas you can build and style your entire interface using drag and drop. By default we provide you with a large library of built in widgets along with the new Aristo open source theme, meaning your application will look fantastic with no additional work. However, you can also skin these applications entirely from the editor and extend the library of widgets with Atlas’ plugin architecture. And unlike a lot of existing layout editor availabe today, Atlas is not a code generator. On the contrary, Atlas lets you edit the live JavaScript objects in memory and then takes a “snapshot” of them in place. When your application runs, it ‘thaws’ these objects out, making sure that you see exactly how your application will look before you run it.

Layout that Makes Sense

Atlas provides a new take on web layout that make it easy to define precisely the behavior you want, while simultaneously doing away with existing browser inconsistencies. Instead of having to learn the variety of different ways to position and resize elements in the browser, Atlas introduces the simple concept of ‘anchors and springs’. Anchoring an interface element to one of the edges around it ensures that it will stay “stuck” there when it’s container resizes. Activating the internal ’springs’ causes it to resize with its container.

While simple to learn, these two tools enable you to create incredibly complex and fluid layouts. More importantly, they’re guaranteed to behave the same way regardless of the browser you’re running your web app in. Atlas also provides a large selection of collection views to handle common layout tasks such as split views, table views, and scroll views.

Connections Reduce Glue Code

A common problem that has plagued layout editors in the past is the need for additional glue code to “talk” to the generated interface. In Atlas, much of this work can be done with a technology called ‘connections’. Connections allow you to visually define the interactions between interface elements and other objects. For example, you can define what action a slider should take when it is dragged:

Similarly, you can ‘bind’ the contents of an array to a table, so that when it changes the table automatically updates as well, all without having to ever touch the keyboard:

Model View Controller Built-In

Cappuccino is a Model-View-Controller framework, and Atlas takes this idea to the next level by allowing you to not only create visual elements, but abstract models and controllers as well. By allowing you to interact directly with the objects in your program visually, you can focus on building unique interactions instead of learning a myriad of APIs.

Atlas has gone a step further and provided a number of pre-built controllers to existing web services that you can simply drop in to their applications. You can then simply use connections to grab information from services like RSS and Twitter. Once again, Atlas’ plugin architecture allows you to create controllers for your own web services as well, which you can then share with others.

Multi-Platform Support

Cappuccino was built from the ground up in preparation for a world of multiple platforms. It is becoming increasingly important for applications to run in several different environments: browsers, social networks, handheld devices, and much more. In general, very little application logic or backend code has to change from platform to platform, but the interface usually needs to be recreated from scratch.

With Atlas, it is drop dead simple to create a unique and custom interface for different platforms like the web browser and the iPhone. Cappuccino will then intelligently load the correct interface for your application depending on the environment it is being run on, allowing you to reduce the amount of code you need to rewrite and as well as using just one language and API for all the platforms you deploy on. We call this idea ‘Write once, layout everywhere’, and we feel it is the right way to gaurantee a high quality experience everywhere you ship your application.

View full size

View full size

Atlas will be shipping this summer and you can sign up for email updates at 280atlas.com.

[Photo credit: flickr.com/photos/atelier_tee]

Undo and redo are two of the most essential features in any real rich application experience. In many cases, your user has already turned these commands into reflexes, automatically hitting the proper keys and expecting the right thing to happen. Unfortunately, this is often left unimplemented by developers when making the transition from the desktop to the web, serving as a rude awakening to your users when they make a mistake that can’t be undone. It makes sense that this doesn’t receive the attention it deserves since the actual functionality of your application should obviously come first, and it doesn’t help that implementing these features from scratch can be quite difficult. However, they add a necessary amount of polish that you should seriously consider adding to your web application.

Luckily for us, Cappuccino has built-in support that can allow you to plug undo and redo right in by just by adding a few lines of code. In this tutorial, we will be exploring how to add sophisticated undo and redo support to a graphical application in the browser. We won’t be creating the entire application from scratch however, but instead building off of an existing example. We’re doing this for two reasons. For starters, we don’t want to get distracted from our main task by having to wade through unrelated code. Instead we’ll simply review whatever code we need to as we get to it. More importantly, the sample provided is complex enough to serve as a true real-world example, as opposed to the contrived code we’d be forced to put together in the limited scope of space and time of this tutorial. This also has the benefit of displaying the modular nature of undo support in Cappuccino, and how we can add it to an application without knowing every detail of its implementation.

That being said, you can, of course, feel free to review the entire source of the application as well. The application itself is written entirely using Cappuccino, but you don’t really need any prior knowledge of Cappuccino to follow along with this tutorial. Feel free to review Cappuccino and Objective-J at cappuccino.org before you dig in, but it’s not a requirement to follow along.

Let’s start by taking a look at the application we’ll be modifying. You can see it and play with it live here. You’ll need to download the source in order to follow along with the changes in this tutorial. As you’ve probably noticed, it’s a simple floor planning app that lets you drag and drop and arrange furniture into the layout of a small apartment:

Have a play with the app. As you can see, it supports three actions that we’ll want the user to be able to undo:

• drag-and-drop to add furniture: should remove the furniture when hitting undo, and add back in when hitting redo
• drag-and-drop to a new location: should revert to previous location when hitting undo
• rotate: should revert to previous rotation when hitting undo

Now, the main thing you should know before we dig into the code is we’ll be dealing with two classes, FloorPlanView, which represents the background and layout of the apartment:

The other is FurnitureView, which displays each individual piece of furniture in the apartment:

The first action we’re going to tackle is undoing the movement of furniture pieces. All the code to handle moving furniture views is currently contained in two methods in FurnitureView.j: mouseDown: and mouseDragged:. Let’s review their current implementations:

- (void)mouseDown:(CPEvent)anEvent
{ dragLocation = [anEvent locationInWindow]; [[EditorView sharedEditorView] 
setFurnitureView:self];

} - (void)mouseDragged:(CPEvent)anEvent
{ var location = [anEvent locationInWindow], origin = [self frame].origin;
[self setFrameOrigin:CGPointMake(origin.x + location.x - dragLocation.x,
origin.y + location.y - dragLocation.y)]; dragLocation = location;
}

mouseDown: simply stores the mouse down position, and additionally sets the furniture view as selected through the EditorView, which we won’t need to concern ourselves with. mouseDragged: then proceeds to update the origin of the view on every drag event. Despite being where the actual changes take place, we don’t want to register our undo action in mouseDragged: because if we do we’ll be registering an undo action for every pixel the user drags! So instead, we’ll want to add a new method right below it called mouseUp:. The mouseUp: method gets called when the user lifts the mouse and is thus done dragging:

- (void)mouseUp:(CPEvent)anEvent
{
// Register undo here.
}

Now, before we continue we’ll want to create one additional new method, setEditedOrigin:. The reason for this is that we want a way to change the furniture locations that notifies the undo architecture, and a way that doesn’t. Currently we’ve fullfilled one of these requirements: setFrameOrigin: can be used to change the position of a FurnitureView without registering any undos, so let’s now create an analog that will:

- (void)setEditedOrigin:(CGPoint)aPoint
{ if (CGPointEqualToPoint(editedOrigin, aPoint)) return; [[[self window]
undoManager] registerUndoWithTarget:self selector:@selector(setEditedOrigin:)
object:editedOrigin]; editedOrigin = aPoint; [self setFrameOrigin:aPoint];
}

This method is relatively straightforward and shows us how to talk to Cappuccino’s undo support. We create a new instance variable called editedOrigin which keeps track of the last “undoable” position. This way we can ignore all the origin changes that take place during while a drag is mid-flight. When the user passes in a new position, we compare it to editedOrigin to make sure they’re not the same. We do this in order to prevent undos being placed in the stack that have no percievable difference to our user (making it appear that the undo “didn’t register”). After this we do the most important step, which is tell our undo manager that it should register an undo. Every view has a window, and every window has its own undo manager (that way, different windows can have different undo stacks). So we grab our undo manager from our window. We then call registerUndoWithTarget:selector:object:. This method tells the undo manager what to do when the user hits undo. In this case, we want to just call this very same method, but with the old origin, editedOrigin. We then set editedOrigin to the current position, and of course update our actual origin, and we’re done. We do need a bit of book-keeping however; namely we need to declare this new instance variable in the class definition:

@implementation FurnitureView : CPView
{ CPString name; CPImage image; float rotationRadians; CGPoint dragLocation;
CGPoint editedOrigin;
}

as well as set its initial value in mouseDown::

- (void)mouseDown:(CPEvent)anEvent
{ editedOrigin = [self frame].origin; dragLocation = [anEvent locationInWindow];
[[EditorView sharedEditorView] setFurnitureView:self];
}

You may be wondering why we need this new instance variable at all, since we can just query our frame for our current origin. The reason is because when we only want to “remember” origins that are to be undone. If you hit refresh in your browser, you should be able to undo moving a furniture item by hitting command-z on a Mac and ctrl-z on a PC. You’ll also notice that you are capable of redoing these actions as well. That’s because setEditedOrigin: gets called for the undo action as well, thus registering another undo on the stack, which Cappuccino is smart enough to know should actually be a redo.

We can now move on to undoing the rotations which are slightly more complex. As we saw earlier, the goal is always to register an undo once editing is complete. You’ll notice that there are two empty methods in FurnitureView.j, willBeginLiveRotation and didEndLiveRotation, which the editing system is kind enough to send to us when the user begins and ends rotating, respectively:

- (void)willBeginLiveRotation
{
} - (void)didEndLiveRotation
{
}

Clearly we’ll want to add our actual undo action in didEndLiveRotation, but just as before we’re going to created an “Edited” version of setRotationRadians: for rotation actions that we want to register with the undo system:

- (void)setEditedRotationRadians:(float)radians
{ if (editedRotationRadians == radians) return; [[[self window] undoManager]
registerUndoWithTarget:self selector:@selector(setEditedRotationRadians:)
object:editedRotationRadians]; [self setRotationRadians:radians];
editedRotationRadians = radians;
}

This should look very familiar. It’s almost identical to our previous implementation, except we are dealing with radians instead of positions. Let’s not forget to add our new editedRotationRadians to the other necessary places, namely the class declaration:

@implementation FurnitureView : CPView
{ CPString name; CPImage image; float rotationRadians; float editedRotationRadians;
CGPoint dragLocation; CGPoint editedOrigin;
}

and willBeginLiveRotation, which is analogous to our mouseDown: since it’s what kick starts the rotation process:

- (void)willBeginLiveRotation
{ editedRotationRadians = rotationRadians;
}

Now all that’s left to do is to actually call setEditedRotationRadians when the user finishes rotating a furniture piece:

- (void)didEndLiveRotation
{ [self setEditedRotationRadians:rotationRadians];
}

Once again, if you refresh you should be able to undo and redo rotating furniture items, as well as being able to undo their positioning.

We are now done with editing the FurnitureView class, and we can move on to the last action that the user should be able to undo: actually adding furniture to the apartment layout. To do this, we’ll have to move to FloorPlanView.j, where the FloorPlanView class is contained. The two methods we are primarily concerned with are addFurnitureView: and removeFurnitureView:, which do just that:

- (void)addFurnitureView:(FurnitureView)aFurnitureView
{ [self addSubview:aFurnitureView]; [[EditorView sharedEditorView]
setFurnitureView:aFurnitureView];
} - (void)removeFurnitureView:(FurnitureView)aFurnitureView
{ var editorView = [EditorView sharedEditorView]; if ([editorView furnitureView]
== aFurnitureView) [editorView setFurnitureView:nil]; [aFurnitureView removeFromSuperview];
}

As you can see there’s quite a bit going on here, but again most of it is not of our concern. In fact, in this case, none of it is. This comes from one simple realization: these methods are opposites of each other, and thus undo each other. So to undo addFurnitureView:, we need to removeFurnitureView:, and vice versa, so the code is actually quite simple:

- (void)addFurnitureView:(FurnitureView)aFurnitureView
{ [[[self window] undoManager] registerUndoWithTarget:self
selector:@selector(removeFurnitureView:) object:aFurnitureView];
[self addSubview:aFurnitureView]; [[EditorView sharedEditorView]
setFurnitureView:aFurnitureView];
}
- (void)removeFurnitureView:(FurnitureView)aFurnitureView
{ [[[self window] undoManager] registerUndoWithTarget:self
selector:@selector(addFurnitureView:) object:aFurnitureView];
var editorView = [EditorView sharedEditorView]; if ([editorView
furnitureView] == aFurnitureView) [editorView setFurnitureView:nil];
[aFurnitureView removeFromSuperview];
}

And there it is, it’s that easy. All we had to do is register the opposite action in each method, and both of them are undable (and redoable) now.

Make undo and redo discoverable

Something interesting that I’ve noticed with undo and redo in our own applications is that many times people don’t realize they have this feature. When we first launched 280 Slides we got a number of “feature requests” asking for undo and redo support. They were thrilled when we told them they could just use the key commands they were used to, but apparently this was not discoverable enough. Because of this, we decided to add actual undo and redo buttons to make these actions more explicit. Let’s go ahead and do the same here by adding the following snippet of code to the end of the applicationDidFinishLaunching: method in AppController.j:

var undoButton = [[CPButton alloc] initWithFrame:CGRectMake(20.0, 400.0, 60.0, 18.0)],
redoButton = [[CPButton alloc] initWithFrame:CGRectMake(90.0, 400.0, 60.0, 18.0)];
[undoButton setTitle:“Undo”];
[undoButton setTarget:[theWindow undoManager]];
[undoButton setAction:@selector(undo)]; [redoButton setTitle:“Redo”];
[redoButton setTarget:[theWindow undoManager]];
[redoButton setAction:@selector(redo)]; [view addSubview:undoButton];
[view addSubview:redoButton];

Now if our users have “unlearned” expecting undo and redo to work, they’ll be able to idenitfy these buttons. With that, we’ve now made all the current actions in this application undoable and provided an easy way for our users to use this feature. As we continue to add new features to this application we can also incrementally add their associated undos. As we’ve seen here, it’s often a matter of just adding one or two lines of code per method, so it’s good to start early and not wait until the very end to begin incorporating this functionality. I hope you’ve enjoyed this tutorial and make sure to leave any questions you may have in the comments! The completed source with all the above additions is available here and you can give it a spin here.

Francisco will be speaking at The Future of Web Apps Miami