LayerVault Blog

LayerVault 2 In-depth: The Tools

Mon, 07 May 2012 13:15:47 -0400

The idea for LayerVault 2 really centered around the idea of the Wormhole. Allan deliriously sent me an email late one night describing it. Things clicked immediately and we began sketching it out.

After playing with the idea a bit, it became obvious that it might be worth adding a few more things to the designer’s tool belt. LayerVault stays open on our users’ desktops the whole day, so we needed to make sure we were providing as much value as possible.

To do this though, we had to face a limiting problem: we had to operate within the confines of the browser. This post details some of the more technical trials and tribulations we dealt with while developing our new Tools.

Canvas, canvas, and then more canvas

We wanted to make sure the Tools we built were reflective of our values. We wanted them to be fast, easy to use and fun. We knew we’d have to use the HTML5 canvas element and some finely tuned JavaScript.

Oftentimes when using a tool, we will be manipulating two or three different canvas elements. We found that in certain cases, it was better to work with transparent canvas elements than to manipulate the image data itself. Such a method also makes it easier to save state.

In the end, we pushed the canvas element to its limit and then some. We’ve never seen anything like our Eyedropper or Smart Ruler tool on the web. They’re fast and a pleasure to use.

Cross-origin Resource Sharing, Oh my!

It should be no surprise that LayerVault uses Amazon S3 as our storage mechanism. It allows us to not worry about feverishly feeding machines with new hard drives. (And at just having crossed 30,000 files tracked, we’re talking a lot of hard drives.)

Unfortunately, it can also be a headache when it comes to Cross-origin resource sharing (CORS). Pulling images off of another domain and manipulating them using the HTML5 canvas element is not as straight-forward as one would like. Because security is a top concern among browsers, manipulating data from other domains is difficult and often prohibited. We obviously found a way around it, also using some other HTML5 APIs.

Our basic methodology for this problem is as follows:

Have the File Page inject an iframe onto the page. This iframe’s source shares the same domain as the image.
The iframe is a simple web page that executes some JavaScript, namely a script that…
Pulls down the proper image, loads it into a string, then transmits the image data as a base64-encoded string out to File Page using the postMessage API.
The File Page receives the message and swaps it into the canvas elements appropriately.
The File Page has no knowledge of the origin domain of the data, so it doesn’t complain when we try to do fancy things with it.

It’s quite the workaround, but it provides for a seamless experience when using the LayerVault File Page.

That about wraps up this post. You can see all of the new LayerVault features on our Tour Page. If you have any questions, don’t hesitate to send us an email.

Announcing LayerVault 2

Tue, 24 Apr 2012 13:57:00 -0400

Allan and I are happy to announce the release of LayerVault 2 today. This release represents several months of work. We focused on our core product even better along with new great features.

What you’ll see at layervault.com now is something we’re proud of. We went through dozens of possible designs before landing on the one you’ll see now.

Let’s dig into what’s new.

(Any press requests can be directed to press@layervault.com. Full resolution logos can be found at layervault.com/about.)

New Design

LayerVault 2 features an entirely new design. The high contrast design provides better readability. No pixel was left unquestioned. The new design takes advantage of every inch of screen real estate.

Our new design brings with it a brand new logo and identity. It’s beautiful. We commissioned SoftFacade to create our new logo and they delivered amazing results. We will be going into detail of the design process of the new logo in the coming weeks.

And yes, they used LayerVault while designing it.

Real-time

Everything that happens on LayerVault happens in real-time. See files updating as your teammates work on them. No more page refreshes.

You can also now open your files without ever leaving web application. Just click “Open Locally” on the Directory page or “Edit” on any file page. With Real-time, designers spend less time shuffling applications and more time designing.

Tools

LayerVault 2 comes with a new Toolbox to make designers’ lives even easier. The Toolbox lives on each File page and can be used with any design. The Toolbox is being released with 3 Tools: the Eyedropper, the Smart Ruler, and Wormhole.

Simple tasks that once required opening up Photoshop can now be done in the browser. Each tool is written with the latest HTML5 technology. No Flash required. That means performance is snappy even on large designs.

Eyedropper

The Eyedropper is a staple of any designer’s workflow. Being able to quickly measure colors is a must.

The LayerVault Eyedropper is optimized for the web. Each click pulls out a color. Select multiple colors at once to build a palette on the fly. Once you’re done, copy the values into a CSS file or another program.

Smart Ruler

The new Smart Ruler is the best way to quickly measure different parts of a design.

Once activated, the Smart Ruler will spring out to the edges of its current container. Measuring pixel widths and pixel heights of gutters, buttons and columns has never been easier. We use it all the time for slicing our own designs.

Wormhole

Last but certainly not least, LayerVault 2 brings with it the new Wormhole technology. Wormhole allows you to search through a design’s history, piece by piece. Just highlight an area of your design and Wormhole will tell you how many changes were made and where in the timeline they occured.

It really is a piece of magic. Even in a design with hundreds of versions, isolating a change from several months ago takes less than a second. It’s a great tool and it’s something you won’t see anywhere else.

Faster File Syncing

LayerVault 2 also brings with it better file syncing. Files will now travel shorter distances to the closest LayerVault datacenter. This can increase upload speeds by a factor of 10. It’s a small detail that we sweated.

That about wraps it up. We’ll be going into more depth with the decisions around this release in the coming weeks. In the meantime, you can dive deep on our Tour page or take a look at our Pricing page.

If you would like to give LayerVault a shot, you can get 20% off the first month of LayerVault with the coupon code LV2.

And a very special thanks to Derek Smith for helping us out with a few things with this release.

Big Things in Store

Thu, 12 Apr 2012 09:59:00 -0400

We’ve been quiet for a little while.

On April 24, that changes. We’re finally ready to show you what we’ve been working on for the last few months. Please join us for the announcement at 11am PST.

We’re really proud of what we’ve created. We hope you like it.

Mark your calendars.

Better filtering with jquery.data.filter.js

Sun, 08 Apr 2012 18:34:38 -0400

We’re trying to get better about open-sourcing some of the great code that we write. Our first foray into open-sourcing the cool stuff behind LayerVault is the simple yet effective jquery.data.filter.js.

It’s a simple jQuery plugin that makes it easier to filter DOM elements by data-* attributes.

So now something like:

var versions = $('.Revision')
                   .filter('[data-project-id="' + projectId + '"]');

Can be simplified to:

var versions = $('.Revision').dfilter('project-id', projectId);

Enjoy and let us know what you think!

Get jquery.data.filter.js on GitHub.

No One Said Scaling Was Easy

Thu, 23 Feb 2012 10:53:00 -0500

Over the past week and a half, LayerVault hasn’t gone down, but it’s been noticeably slow for a few users. We have tools in place that allow us to monitor the individual experience of each customer to the service. If anything looks amiss, we recreate the problems and tighten the screws. We’ve been experiencing some great growth over the past few weeks, and with growth comes growing pains.

For now, it seems like we can see the edge of this forest. I wanted to write a blog post to talk about scaling past that initial machine and scaling Rails. As always: if you’re having issues with the service, please send us an email right away at support@layervault.com. Chances are, we’re already working on a solution.

Here we go.

Scaling Your Web Service

At LayerVault, we built our service using the Ruby on Rails framework, version 3.1. Our database is MySQL. Our hosting provider is Slicehost. We use Amazon S3 and CloudFront for serving out static files.

Rails is one of the best—if not the best—framework in existence; it is designed to take you from your initial idea to a sustainable business. In the early days of LayerVault (just a few months ago), the entire service was powered by one box. That box ran Apache, our Rails instances and the database. Scary, right? But that served our initial needs of having a service online quickly without worrying about maintaining servers we didn’t need at prices we couldn’t afford.

As we got more customers, our needs changed. The megabytes of daily data turned into gigabytes. We had to make sure that a heavy request would maybe slow down a box for a short while but not slow down the whole service. To do this, we slowly started peeling apart the logical functions of our web application. Now our service looks like so:

Whew, quite a bit more complicated. That’s what scaling looks like. Let’s break down some of the more important things we did.

Identify the bottlenecks

Scaling for scaling’s sake is a bad idea. You’ll probably introduce complexity that you don’t need. Make sure that you have tools that let you isolate issues. We use New Relic, the oink gem, pingdom, internal monitoring tools and unix’s top. Before you begin, watch all of the New Relic Scaling Rails podcast, even if you don’t use Rails.

Above all, fix one thing at a time and measure the results.

Set up a reverse proxy

A “proxy” in web parlance is an intermediate server. Proxy servers often accomplish different things: they can help you visit otherwise blocked sites or they can act as a traffic-cop. A reverse proxy is usually the traffic cop for a mid-sized web service. It tells the individual different web requests to go to different application servers. It can also perform caching of common requests, but I won’t get into that. Reverse proxy applications have many other names and uses as well; they can be sometimes referred to as HTTP accelerators or load balances. (This is grossly simplified for the sake of this post.)

Technically, LayerVault uses two reverse proxies: Varnish and Pound. (We used a heavily modified version of this setup.) When a client makes an HTTPS request, Pound takes the request and translates it to a vanilla HTTP request inside our firewall and then feeds it to Varnish. Varnish takes all HTTP requests and appropriately doles them out to our application servers. We have an entire 512MB slice dedicated to being our traffic cop.

As many app servers as we need

Thanks to our reverse proxy, we now just add in application servers as we need them. For LayerVault at this point, the bottlenecks come in the form of not enough CPU time and/or memory. We can horizontally scale our app servers as necessary. All it takes it turning on a new app server and adding it to the server rotation in Varnish. Nifty.

We use 2GB slices for our application servers.

Set up memcached

memcached was a service developed by the guys behind live-journal as an in-memory caching system. It’s so fast. Like 1000x faster. LayerVault customers will notice that the heaviest pages now load in less than 400ms with a warm cache, i.e. they have visited the page recently. This makes navigating your account that much more pleasant.

We use the Dalli cache gem and similar caching strategies described in @ddh’s 37signals post: “How Key-based Cache Expiration Works”.

Caching is difficult, mostly due to the question of “When do you expire this?”. There is no silver bullet. In the future, we’ll be tightening the screws on our caching strategies to shave even more milliseconds off each request.

Rails 3.1 static asset compilation, CloudFront CDN

Each HTTP request has a certain amount of overhead. In general, a page should minimize the total number of requests it makes. LayerVault is not a simple site: we have plenty of CSS and JavaScript. We write our JavaScript in such a way that is highly modular that allows us to make great encapsulations of behaviors. Our style and patterns are prettier than your average CoffeeScript (no, seriously). For example, we may have an entire file that controls the behavior of a button on a single page.

We first built LayerVault on Rails 3.0. We recently upgraded to Rails 3.1 to take advantage of its static asset pipeline. The static asset pipeline allows us to work in separate files until we deploy the code. Upon deploy, all of our JavaScript is smartly concatenated and served off our application server through Amazon CloudFront. Amazon CloudFront is a content delivery network (CDN). It allowed us to remove a slow step in our deployment of uploading all of our static assets to Amazon S3.

So, instead of serving up dozens of CSS and JavaScript files, we server up two. Better yet, these files come from a CDN node near you. Boss sauce. We also take advantage of the Rails asset_data_uri method. It’s amazing. We use it to inline small images in our CSS to cut down on the number of requests. All of this in mind brought our front-page load times from 2 seconds (yuck) down to a few hundred milliseconds in most cases (getting there).

Things that made our lives much easier

Drop the protocol declaration in as many externally-linked assets as you can.

You can visit any page on LayerVault using HTTPS. This is not any easy thing to accomplish, especially when serving up assets from several different domains and worrying about things like page caching. An easy trick is to simply drop the protocol declaration from all asset requests. Thus:

<script src="http://s3.amazonaws.com/bucket/my.css"></script>

Becomes:

<script src="//s3.amazonaws.com/bucket/my.css"></script>

This makes statically caching this page much easier. This will cause older versions of IE to make 2 requests for the asset. Seeing as how 90% of the people visiting LayerVault use a WebKit browser, we could care less about IE.

Offload tasks to worker processes and test them

No duh. But the problem with having worker processes is they often become something extra to test and maintain. We use the delayed_jobs gem to background anything that takes long than a few milliseconds. We also have a huge suite of Cucumber tests. This line in our environments/test.rb allows us to essentially follow all actions to their very end:

Delayed::Worker.delay_jobs = false

Now we know that the work the workers perform will pass tests too.

Switch from Rails-provided lookup helpers to SQL

Rails and ActiveRecord is all flowers and butterflies for awhile.

user.projects.files.select{ |f| f.file_name = "Cool.psd" }

Ah, so nice. Or:

user.select{ |u| u.plan.price > 20 && /[Kk]elly/ =~ u.name }

(Not the best examples, I know.) But while ActiveRecord is great for getting things up-and-running quickly, it’s very greedy. While it’s my fault for using select like I have here, each line loads many more records than needed from the DB. Each record loaded gets instantiated into an ActiveRecord object then tinkered with. ActiveRecord is sufficiently complex and doesn’t go easy on the memory. Too many instantiations of ActiveRecord objects and your request eats up all the memory, your box starts to swap, and your users notice a significant degradation in performance.

So now, we’re slowing moving to more SQL-based statements in our application:

VoreFile.all(:conditions => {
  :user_id    => user.id,
  :project_id => user.projects.map{ |p| p.id },
  :file_name  => "Cool.psd"
})

When we are explicit like this, we only load precisely what is needed. In general, the database layer is much better at selecting record with certain sets of criteria than the application. We could even get better about only loading the project IDs in the example above.

Fine-tune Apache and Passenger

If you’re using Apache and Phusion Passenger, fine-tune the settings. Specifically, we found the following apache directives to be helpful:

PassengerMinInstances
PassengerMaxRequests
PassengerMaxPoolSize
PassengerPoolIdleTime

Because we handle a bunch of heavy requests, we recycle Rails processes more frequently than most. Our PassengerMaxRequests is kept pretty low. We maintain a tight window on each application server of the number of Rails instances running. This keeps us in a sweet spot for memory.

Onward and Upward

We’ve had the phrase “good problems to have” bashed into our skulls here at LayerVault. Getting customers is great. Getting lots of customers is even better. Getting lots of customers to your data-intensive application is a Good Problem to Have.

As we move forward, we’re measuring requests coming across the wire and seeing which users have difficulties. We religiously write tests against any bugs and corner cases that are found.

I’ll write another post in the future to check in and see what kind of issues we’re dealing with then.

Discussion on Hacker News.

Feel free to tweet us any specific questions.

—Kelly

While we’re heads down over here working on some great...

Fri, 27 Jan 2012 10:20:24 -0500

While we’re heads down over here working on some great performance improvements and few other things up our sleeves, we still need to get out sometimes.

Last night, our very own Allan won the basketball competition at the Dribbble NYC meetup. Hidden talents. The image here is a basketball signed by the Dribbble founders, Dan Cederholm and Rich Thornett. It was great to come out and meet some fellow NYC designers.

Special thanks to Squarespace for hosting the meetup. See you next time!

Announcing Unlimited Storage and 60-Day Trials

Thu, 05 Jan 2012 13:40:00 -0500

Let’s get right to the point — We’re building some pretty amazing stuff here at LayerVault. We’ve iterated on nearly every aspect of the product, made huge improvements to things like user experience and reliability. Today, we’re releasing the next iteration of the LayerVault pricing.

We’re doing away with account storage limits. As of today, all LayerVault plans will receive unlimited storage. If you’re an existing customer, worry not. Your account has been upgraded.

If you were on the fence about trying us out, now’s a great time. We’re also offering 60-day risk-free trials for all of our plans. Give LayerVault a try for 60 days and if you cancel before your trial’s up, no big deal.

The last few months have been really great. LayerVault has big plans for 2012 and we’re more excited than ever about what’s in store. Stay tuned.

Improved Sharing Settings

Wed, 07 Dec 2011 00:03:29 -0500

Earlier today we rolled out improved sharing settings at the account level. Users were asking for ways to control permalink visibility and file downloads from the account level. Today, we’re happy to announce Public Permalinks and Downloadable Versions at the account level.

Public Permalinks allow the files that you work on to be collaborate on to be visible from a randomly-generated URL, like a YouTube video. It’s a great way to share work with a client or hand work off to a developer. The Latest Permalink will always display the most recent version of the file. Here’s an example of a Permalink page showing off our own Account page.

Downloadable Versions allow anyone visiting a permalink page to securely download the full version of the file, e.g. the Photoshop document.

Existing users can see the new controls on their Settings page. We think our new settings are a step in the right direction and give us the flexibility to give users more control where necessary.

Let us know what you think!

LayerVault Love: Typekit

Sat, 19 Nov 2011 01:06:52 -0500

Typekit: We like you, do you like us? Check one [ ] Yes [ ] No

Our ears were burning and our tweet stream exploding earlier today, when the official Typekit blog featured us alongside the President, the Verge and Bearded. We are more than flattered.

Typekit is an online service that makes it easy to use high-quality fonts on our site. A good font can set you apart from the pack. Here at LayerVault, we use the serif typeface Adelle to give our landing pages some extra pop. We’ve been big fans of Typekit, even before they highlighted us on their blog.

If you haven’t already, check out some of the other sites we were featured alongside of. They are great. Thanks, Typekit!

LayerVault’s file page is its most heavily used page, and...

Tue, 08 Nov 2011 10:01:00 -0500

LayerVault’s file page is its most heavily used page, and as such it deserves the greatest amount of scrutiny. We’ve actually released at least 3 versions of the timeline since our first early beta — and even more updates to the file page. Here’s what we’ve learned and what we’ve changed.

In the timeline’s first version, points were equidistant from one another, and we used a scrollbar metaphor. That made it rather difficult to figure out where to click. We thought we could do better.

So, in the second version, we went to the other extreme — versions were positioned on the timeline as clickable points. It turned out that we were focusing too much on precision, and it was leading to a bad experience. Watch the video above and you’ll see what we mean. For users like myself, who save every few seconds, it wasn’t a great experience.

In the latest iteration, precision isn’t as important as presenting a general idea of how far things are from each other. Long time spans have been truncated with a “…”. There’s a zoomed-out view (that clock icon) that you can use to jump to any point in the timeline.

We’re not quite done yet on this page, but I think we’ve definitely come a long way. It really helps that we use LayerVault daily, religiously. We have a keen sense of what works and doesn’t, and it’s pretty quickly apparent. More to come soon.

— Allan, Co-founder

Staying Fast

Thu, 27 Oct 2011 10:05:05 -0400

While we build out LayerVault and continue to make it better, there are a few things we do to keep ourselves moving quickly. Most users shouldn’t notice, but we are pushing to our production servers and updating our client application several times per day. This helps us address problems quickly and—more importantly—not push broken code.

Let’s chat about how we work.

Test automatically, but only as much as we need to

Half of the world loves automated testing. The other 50% hates it. Automated, high-level tests help us sleep at night. We use Cucumber to give us a good enough idea that any new code doesn’t have side effects. These tests likely won’t help us prevent problems in the future, but they will help us catch regressions.

Automated tests are like tying your shoes and showing up to the race. They don’t guarantee you will perform well, but they will let you at least compete. Cucumber tests will never tell us how our application feels, but it can communicate that oh crap, that code change breaks file uploads.

Cucumber tests help us spec out future features and isolate corner cases, but we never let it slow us down and we never rely on them completely.

Keep your branches simple

Many of us like to have complicated branching schemes. We tell ourselves it makes sense to have release represent what’s in production, release-hotfix-3a for any work that’s urgent and master for a general Rome that all roads lead back to.

But that is wrong.

Zach Holman and Scott Chacon are big proponents of fixing this anti-pattern. They explain how Github keeps branches simple in talks they give. You have one branch, master, that can be deployed to production. Each feature gets its own branch. Done.

This chips away at a very powerful idea: if at all possible, the only thing representing your code should be the code itself not some arbitrary branching scheme or a bug-tracking system. Complicated branch naming and testing become useless because they often require too much upkeep without much reward.

This leads into…

No deadlines

Deadlines are toxic. Deadlines make companies push out pathetic, sometimes non-functioning code.

If you need to get something done on time, targets might be a better nomenclature. Shoot for a date for a feature release, but don’t push things out at all costs on Tuesday at 03:13 Greenwich Mean Time. It stresses everyone out and leads to half-baked executions.

At LayerVault, we release small iterations of different components as we improve upon them. Each developer or designer will focus on one idea for a small time, say improve the File Page Timeline. We get it to a point where it’s measureably better then we

$ git merge master # magic
$ rake test
$ cucumber 
$ git checkout master 
$ git merge feature
$ git push origin master
$ cap deploy

Scott, Zach and Github hit on this a bunch although I’m not sure if they have spelled out it out explicitly: Switching from a time-based release schedule to a feature-based release schedule does wonders for product quality.

Reduce the friction from development to customer

All of this couldn’t be done if we didn’t have an easy process that encourages healthy development patterns. All LayerVault developers interact directly with customers. All LayerVault developers have the ability to fix bugs. All LayerVault developers have the ability to deploy to production.

Cal Henderson had a great slide in his deck a few years back which likened frequency of deploys to the size of teeth. The longer the deploys are spread out; the bigger the teeth are. Bigger teeth leave bigger marks. Sometimes, they puncture the skin. Deploy early, deploy often, and deploy single features. It’s much easier to identify single features that are not working as expected in production than a suite of half-functioning ones.

On our plate is adding Update Engine to our OS X client. That way we can work just as fast on the client as we do our web application. No more pesky things like “installing” “new” “versions.”

Hope this helps

I hope this post helps illuminate how LayerVault is able to quickly work, respond to customer requests and continue to make our service better. Thanks for reading!

— Kelly, Founder

Two Weeks Down

Tue, 18 Oct 2011 10:05:06 -0400

After launching two weeks ago at FOWA in London and presenting at NYTM, we’re happy to report some great initial numbers and to say thank you. Here’s a few numbers:

Over 1,500 users.
Over 10,000 versions tracked across thousands of files.
Average support response time is less than 10 minutes.
Some of the best companies out there are using us. We’ll be profiling them in the coming weeks.

This is all more than we could have asked for in the first two weeks of LayerVault being open to the public.

In the coming weeks we’ll be tightening the screws and improving the experience. Things will remain simple and continue to just work, oftentimes even better. There’s a few features we’ll be implementing in the coming months that are giving us goosebumps.

It’s up and away from here!

Allan and Kelly presented LayerVault at the New York Tech Meetup...

Thu, 13 Oct 2011 09:46:39 -0400

Allan and Kelly presented LayerVault at the New York Tech Meetup last Tuesday. New York City Mayor Mike Bloomberg warmed the stage for them. They go on around 01:14:00. Vimeo doesn’t allow pseudo-seeking, so you’ll have to wait for it to buffer to that point first.

Fire. Works.

Fri, 07 Oct 2011 15:57:00 -0400

Due to popular demand, we have just rolled out Adobe Fireworks support. We found that there are many folks out there that know and love Fireworks for all sorts of design work.

Download the latest version of the LayerVault OS X client and start dropping your Fireworks PNG files into your LayerVault directory.

LayerVault’s Kelly Sutton did a quick little interview...

Wed, 05 Oct 2011 12:16:00 -0400

LayerVault’s Kelly Sutton did a quick little interview with TechCrunch TV earlier today.

LayerVault: All Systems Go

Wed, 05 Oct 2011 06:08:00 -0400

We are elated to announce that LayerVault has officially launched this morning from the FOWA London. We’ve also got a few new features we would like to highlight.

Collaboration and Projects

LayerVault now has the ability to help you work together in teams. Each version of a file in a Project is now saved, whether it’s yours or your teammate’s. Inviting teammates is as easy as clicking the plus button over a folder. Now working together creatively has never been easier.

New Timeline

With our launch, we are also announcing a totally redesigned timeline. You spoke and we listened. “More contrast” and “easier navigation” were two things we heard loud an clear. We will still be iterating on the timeline on the file page until it’s perfect, but the New Timeline should be a welcome change for those with many-versioned files.

New Pricing Structure

To celebrate the launch, we have published new pricing plans that focus more on getting work done rather than how much space you have. Such structuring helps keep us laser-focused on the most useful features. And don’t worry, phone support isn’t going anywhere.

Now with Increased Security

Wed, 28 Sep 2011 18:54:00 -0400

Earlier today, we rolled out some exciting new features that are aimed to keep your files and their versions safe. From here on out,

All sign-in, account and upgrade pages will only be served through HTTPS.
We’ve tightened up security on our file storage as well. All file requests are signed with temporary certificates that expire quickly. Evil doers, be gone!
We’ve moved to a new method of generating permalink URLs, which ensures greater security.

Although we don’t expect it, these security changes may lead to some quirky behavior. If you see anything out of the ordinary, please write to support@layervault.com. But we’re not stopping here. We’ll be doing everything possible in the coming weeks to continue to ratchet up security.

What's New: File Drop-down Menus

Thu, 22 Sep 2011 18:57:00 -0400

We just rolled out a new feature for the directory view page: file drop-down menus. When in the thumbnail view, each file now has a drop-down menu with a few options. You can now:

Download the full version of the file
Copy the file’s permalink to share with a client or developer
Delete the file without moving it first to your archive.

This is one small convenience that is paving the way to a few, much larger features that we will be rolling out in the coming weeks!

We're LayerVault

Thu, 15 Sep 2011 17:24:00 -0400

LayerVault is version control for designers. Each time a designer creates or modifies a file, we store a copy. Each file and version is securely backed up and accessible from our web interface.

So, if you’re working on a Photoshop or Illustrator file. Every time you save, we save. Log in to LayerVault.com, and flip through versions of your PSD. If you need to revert, just download that version of the PSD.

Lots to come.