LayerVault Blog

Speed

For LayerVault customers, syncing speed is extremely important. In fast-paced environments, every second counts. That’s why we’ve spent many sprints improving the overall speed of the interface and the LayerVault Sync application. The result is a LayerVault that’s faster than ever.

On the web, we’ve continue to refine the speed of the interface. Pages are loaded before you even click on them, resulting in an experience that will make you forget you're using a browser.

We’ve also continuously refined the LayerVault Sync application. There are two main things that are driving some big speed increases in the syncing application: multithreading and something we’re calling Smart Uploads.

Multithreading makes it easy for applications to take full advantage of modern processors. We spent considerable effort perfecting our app to perform the best in a multithreaded environment. The result is a sync application that utilizes your system to the fullest to sync things quickly. By tapping into the latest multithreading libraries provided by Apple, we take advantages of every ounce of performance your Mac can deliver.

By introducing Smart Uploads, we are supercharging upload speeds. Many web services will send your uploads always to a single location. This makes the performance degrade based on your physical location. To solve this, the LayerVault Sync application will choose from one of several dozen data centers to upload and chooses the one fastest for your location. This means whether you’re working from San Francisco or New York, Sydney or London, Johannesburg or Mumbai, getting your work to your team via LayerVault has never been faster.

Given the improvements in the LayerVault Sync application and due to limitations in the Dropbox API, we have deprecated our support for Dropbox Sync. New organizations will no longer be able to opt in for Dropbox Sync.

All of this makes up for a faster experience than ever on LayerVault.

Web Uploads

For just getting started with LayerVault, sometimes you don’t need a full-blown application. As part of the LayerVault 3 release, we’re giving customers something totally new: you can now upload files directly via the web interface. What’s even cooler: you can upload entire folders as well, just by dropping them in.

Our Web Uploads experience is like none other. Drop your files and folders into LayerVault, and immediately begin browsing them while the upload completes. Navigate to different documents, organizations, or whatever you may desire. No warning dialogs that your upload will be interrupted, no lost work. Just an incredibly seamless experience.

Realtime Updates

Every part of LayerVault now updates in realtime. Updates are also beamed directly to the app when changes occur. The web interface updates seamlessly as previews are generated. Feedback appears in realtime, just as you would expect from a chat application. Top-to-bottom, LayerVault has been updated to work in realtime.

This is apparent in two specific places: the file navigation experience and the feedback experience.

File navigation is nothing short of magical. All work done by you and your team is now immediately reflected in the web interface. As you sit on a file page, you will see new Saves and Revisions come in without reloading the page. As files are created, deleted, and moved, you’ll see the results immediately. This makes the LayerVault web interface even faster, and saves precious seconds many times throughout your day.

The new feedback experience also updates in realtime. Realtime conversations are now possible, without the need to reload the page to see new discussions. See your teammates critique your work directly on the source files. Respond to and resolve the feedback just as fast as it comes in.

The ability for the LayerVault interface to update in realtime makes LayerVault that much easier to work with each day.

Full List of Improvements

Although the big release of LayerVault 3 centers around the previously mentioned big features, we’ve made many small improvements to the experience.

Time Spent on Projects

LayerVault will now automatically compute the total amount of time your team spends on each project. This is great for freelancers looking for a quick way to track their billable hours, or for an organization looking to keep a closer eye on where their time is spent. Our beta testers for this feature describe it as "scarily accurate."

Code Previews and highlighting

More and more of design today is happening in the browser. Not all mockups happen in Photoshop or Sketch. To recognize this, we now track code files and display colorized previews of each file on a file page. This is great for small snippets of HTML and JavaScript, or for requirements documents written in lightweight Markdown.

The Sketch Bundle

All LayerVault customers on our annual Pro plan can now get licenses of Bohemian Coding’s Sketch for free. Visit our Sketch Bundle page for more information.

The Starter Plan

To give smaller teams a more accessible price for LayerVault, we introduced the Starter Plan. It's now possible to get your team on LayerVault for just $19/month.

Edit/Delete Feedback

Customers can now edit and delete feedback threads on any file page. Finally.

Updated Activity Feeds

Activity Feeds have been given more information about the goings on inside of each project. See who is making Revisions, starting discussions, and more.

Improved login flow for the app

To give a more pleasant experience, especially when things go wrong, we’ve created a more descriptive login flow for the LayerVault Sync application.

Advanced Notification Settings

You can now decide when you receive notifications for activity within your LayerVault projects. Got some noisy teammates? Receive breakdowns of discussions every hour, or every day.

Directory Sorting

Customers love LayerVault. Customers that love LayerVault put thousands and thousands of their design assets in LayerVault. As a result, customers need a better way to navigate their assets. We now expose several methods of sorting folders, all without reloading the page.

Improved PSD rendering support

As part of our ongoing efforts into PSD Native, we’ve increased the fidelity at which we render PSDs.

PSD layer comp support

LayerVault will now render layer comps for each PSD, directly onto each page. No more exporting PNGs of each layer comp.

Sketch 3.2 support

We’ve worked with Bohemian Coding to make sure that LayerVault’s support of Sketch files is the best in the industry. As a result, LayerVault will render every page and artboard of every Sketch file.

Totally overhauled preview generation

LayerVault deals with trillions and trillions of pixels per month, and we don’t lose a single one. Doing this for more and more customers quickly is challenging. As a result, we’ve overhauled how we generate previews for all customers. The result is a much faster experience all-around.

Project-level discussions

It’s important to keep an eye on all discussions within a project from 40,000 feet. This is now easier than ever with project-level discussions. See which conversations are being had at any time on each project discussions page.

Multiple email addresses

LayerVault users can now have multiple email addresses tied to their account. This makes it easier than ever to minimize sign-in headaches, without giving up the much needed separation between personal and work accounts.

The LayerVault referral program

Hello Meng, thank you for joining us today. Could you tell us a little about yourself?

My name is Meng, I’m a self-taught designer. I skipped college to follow my passion, which was making Websites. I built my first community at the age of 20 and tried to create a company out of it, but ultimately I failed. So I worked for startups in Montreal for a number of years, which all failed to gain traction.

Shortly after, I moved to San Francisco and failed to renew my visa. When that happened I decided, what the hell, I'm going to travel the world and spend all my money. That sounds terrible, but I can’t think of a better way to live. Without those failures, I would never have made those hard decisions so quickly. I hated business, travels and books. I did all 3 anyway. And today, I travel to a new city every week and I sold almost half a million dollars’ worth of books.

How did you get the idea for Design+Code?

It wasn’t so much an idea, very few designers had the guts to learn Xcode much less teach it. I was one of them. Yet no one can deny that mobile is eating the world. For much of the people we design for a mobile device is their first computer.

In Hong Kong, I learned to make apps with the help of an iOS engineer who loved design. Isn’t it great that developers love design now? I started writing about that. When my 6 months stay limit was over, I was faced with the decision of either becoming a freelancer or write like I never wrote before. I needed a way to pay for those crazy travels. I opted to write a book instead of doing anything else. I didn’t want to treat writing like a side project. You know, spend a weekend, realize that there’s a shit ton more to do, and skip the polish. It would be the worst mistake you can make.

My initial plan was to cover 2 months of travels which would have been the sale of 200 copies. I was in Japan and in 2 weeks, I had the site up. I always liked to hack things in the shortest amount of time. It had one long page detailing all the content and a pre-order button. That day in Tokyo, I exceeded my goal while not even having a product yet.

What has been the most remarkable part of producing Design+Code?

I think the craziest thing about the book is that I’m still doing it, after 8 months. The surprises came in stages. First, the pre-order. Who would have thought that people wanted my book? I was no writer, and I certainly wasn’t a fluent iOS developer. I had just started coding for iOS seriously in the past few months. I just wanted to improve the way designers work, for the mobile era that we’re in. To me, they were using the wrong tools. They’re not part of the implementation process like they are with CSS and Javascript. That’s why I’ve been such a proponent of Sketch and Swift.

Every time that I think that people don’t want my product, I’m wrong.

The second part was when I divided the book into 3 chapters. I’m a big Steve Jobs fan and I first heard about this principle in an interview with Dave Morin. It just made a lot of sense, people won’t remember your work if you present too many things at once. It turned out that at every 2-week chapter release, the sales would boost and stabilize at a higher average. It never went down because I kept adding new stuff. Plus, between each chapter, it gave me enough time to digest the feedback. And every time, I would try to come with better content than the last chapter.

The third part was Swift. When the new language was out, people just assumed that my book would be dead. For most books, they wouldn’t be wrong. Books are typically physical and the author rarely goes back to re-write the content. Design+Code isn’t a typical book. I built the site from scratch using Angular and Parse. I update it regularly. So with that same approach, I decided to just learn Swift and write a fourth chapter about it. Same thing happened with iOS 8 and the iPhone 6. I’m in the process of re-writing Chapter 3 in Swift. I’m going to keep updating the book. I treat Design+Code like a product. And every product needs a steady stream of iterations. Otherwise, it’ll die like the naysayers prophesied.

Tell us about the Sketch & Swift workshops. How did those come about?

I started receiving hundreds of emails asking for workshops. In fact, that’s one of the things people don’t tell you about building products. You have to get really good at email. You have to be able to read feedback, distill what’s important and objective from the bullshit. (I hate long emails). You have to reply to everyone. I mean everyone.

People don’t take negatives very well. They panic when questions are unanswered, and that leads to destructive behavior. You don’t want that, because you worked really hard to get to where you are. You can’t let one opinion destroy your life’s work. So be patient, reply to every piece of feedback whether it's good or bad.

Anyway, back to the topic, people started requesting in-person lessons. I started saying yes, excitedly. I always wanted to be a better speaker. I couldn’t deny the fact that people can learn better in person, especially for things as scary as Xcode. The way modern apps are built (even for the Web) is so foreign to designers. It’s a big jump.

I had zero experience organizing workshops. I was in SF for the WWDC and started asking around. That didn’t go well. You need at least 20 emails to get close to the booking. Really frustrating. After a couple of talks in SF, a workshop in Canada, I gained a lot of insights on the format. How much should I charge? How do I know which cities people want to have workshops? How do I avoid hundreds of dead-end emails?

That’s when I created the Google doc. But even after that, I still needed to make sure that people would get to the booking process. As we all know, the initial interest is a mile away from the actual booking. It’s like the difference between landing on a page and finishing the payment. Stripe was a big help to make the process less scary.

I couldn’t just create one EventBrite or Meetup for every city. What if there’s not enough people? Can’t afford that. Each trip costs in the thousands. That’s when I knew I had to create one giant page with a list of cities and a “Buy Ticket” button for each city. If people didn’t see their city listed, they can always leave their email.

Since, there have been over 400 bookings and 1000 requests. My next 3 months are fully booked and I get to travel from Paris to London to Taipei. Most importantly, I get to meet people and help them grow in a way that I can’t behind the screen.

You lived in San Francisco for a little while, and now you’re traveling the world. What do you consider your home base, if any? If you could give one piece of advice to a developer or designer looking to pursue a nomadic lifestyle, what would it be?

I have no home that truly feels like home. Not Montreal, not even San Francisco. When you travel this much, you start to realize that every city has their strengths and imperfections. And that’s alright. I don’t feel ready to settle because my desire to learn and help people is stronger.

I think in the future, there won’t be one city, or even one planet. People will learn to be more nomadic because traveling gets easier by the day. Especially for designers and developers who literally can work anywhere in the world with their laptop. A home near the beach with decent WiFi in Thailand costs a fraction of an apartment in busy San Francisco. There isn't a reason that prevents you from going there when your unlocked iPhone can get you 4G with a local SIM card. Additionally, you can rent a short-term apartment with the touch of a button using Airbnb.

My best piece of advice is to try it! I said the same thing about Sketch two years ago and Xcode last year. Then you’ll know what it really feels like.

What is the hardest part of teaching people how to design and code?

It’s really hard to get people at different skill level to be on the same page. That’s when I try to simplify things resolutely. Because simple is so damn hard, people appreciate the subtleties beyond their own preferences. I like to say that everyone understands the language of simplicity. That’s why I really focus on Sketch and Swift. People instantly get the values behind these tools.

I get developers coming to the Sketch workshop and designers going to Swift workshop. They don’t go because they expect to become experts overnight, but because they want to learn how to speak the same language as their co-workers. They want to be part of the conversation. I couldn’t have asked for a better reason.

What do you believe are some of your biggest failures?

My biggest failure was during my first company. I was clueless about the money aspect and I paid dearly. When the company went under, it took me quite a bit of time to get back up. I wasted a lot of time playing games at my parents’ house, working at terrible jobs that I didn’t love and being stuck in a city that didn’t want me.

I promised myself to never undervalue myself like that again. That’s why today, the first thing I try to create is a valuable product. Something so valuable that people would pay for. Without that, I cannot help anyone. And I want to help people.

Real failure is not in failing, but in not trying again. A successful person is someone who gets punched a thousand times and gets back up every time. Hopefully without wasting too many years like I did.

What do you think the biggest challenges of being a designer are today?

We have to learn so damn much, don’t we? As people of the 21st century, we’re faced with so many choices. That’s why it is our duty as designers to make things obvious. We learn so much so that people don’t have to.

Personally, I try all of these tools so that other designers don’t have to. And that’s a good thing, because I would be out of job if there wasn’t this incessant need to curate, simplify and make people’s life easier.

Speaking of tools, what are some of the tools you use to get your projects done?

I like simple and deep tools. Sketch is the perfect example because it’s really focused on UI design, but once you start designing, you realize how much more you can do with it. There are new ways that I design with it, like Artboards for multiple screens, vector assets (SVG for Web, PDF for iOS), Mirror for previewing multiple Artboards, etc. I use Screenflow a lot for creating screencasts, Ulysses for writing and exporting to ePub, Mailbox for doing quick email and of course, Xcode for prototyping and making apps.

What has your favorite Designer News story been of all time?

Designer News’s strength lies in the community and the quality of the comments. I love when the community comes together and genuinely tries to help each other. Stories like Who's on a visa?, The unspoken D word and beccapurple come to mind.

If you would like to learn more about Design+Code, you can do so easily on Meng’s site.

If you liked this interview, you will also like the other interviews we’ve done with creators of design-centric software.

What is Macaw and what does it do?

Macaw is a new breed of web design tool, which allows you to work on a canvas much like Photoshop. However, that canvas is actually a web browser.

As you design, Macaw is automatically generating the HTML and CSS necessary for your design. It’s not your typical WYSIWYG, though. Macaw has a custom coding engine – called Alchemy – which follows the same logic a developer would use to write semantic HTML and succinct CSS.

What was the moment you decided to start working on Macaw? Who was there, where were you physically at? When was that?

It all started when my daughter was born and I was home on paternity leave. Between swaddles, I found time to tinker with a few ideas. One of them was Macaw. It was just meant to be a small side project, but I realized how many problems a tool like this could solve and I quickly became obsessed with it.

How long did it take you to build your first prototype? What was the length of time between idea to getting something in customers' hands?

I spent about four months working nights and weekends before I showed it to anyone. My partner, Adam Christ, was the first to see it and he decided to help out. We thought we’d finish it with another three to five months of work, which was pretty naïve on our part. It took well over a year to finish and launch.

My wife was ready to kill me.

What's your favorite tool you use to build Macaw?

My first instinct is to say Sublime Text. It's far and away the best text editor I've ever used. However, Macaw wouldn't exist if it weren't for Chromium.

We played around with numerous platforms before finding our groove with Chromium Embedded Framework (CEF). It's crazy to think how powerful browsers are becoming. I think we're going to see more and more of our favorite apps rebuilt on an HTML-based stack.

What is the most challenging thing about developing tools for the design community? How have you overcome those challenges?

Designing a tool for designers to design with is equally awesome and difficult. Our community is very tech savvy and most of them have built apps themselves, so they're always happy to point out things we could be doing better.

It's incredibly helpful that our audience is preprogrammed to help make our product better. We're building something really complex and we need their help to get everything right. That being said, we’re also building an app that many people have thought about building themselves. So, they're quite opinionated about how it should work. Many voices can make it difficult to identify features that are crucial for the overall vision.

What do you think are the biggest challenges designers face today?

Dealing with a medium that is constantly evolving, which is why we're building Macaw.

Designing for the web has never been more complex. For the first two decades of web design, things stayed pretty much the same. We did mostly fixed-width layouts, which could be easily mocked in Photoshop. Then, it came down to mastering layout properties and learning the ins-and-outs of each browser.

The past few years have brought us tremendous growth in browser capabilities and even more in design thinking. Responsive design brought an enlightenment of our medium. People are finally treating the web in a different way than the way we treated print, and browser manufacturers are constantly improving the underlying technology so we can do more and more.

As a designer, keeping up with these changes can be overwhelming.

What do you believe are some of your biggest failures?

I don’t know if I’d call it a failure, but jumping in head first with Macaw was a tough thing to do. It felt like a failure for a long time. The product took a long time to develop and we didn’t take investment. Watching our family’s savings wither away month after month was really discouraging and there were many times that I wanted to quit.

I wouldn’t change a thing about the journey, though. I learned more in that one year than I did in the entirety of my career – not just about design and development, but about business, life, and family.

What advice would you have to anyone looking to develop applications or services for designers?

Do it! The design community is an incredible group of people. I feel honored to be building things for them. It’s a unique situation to find yourself in, because your audience is also inherently capable of identifying problem areas with the product and they’re usually willing to help you resolve things.

This is a blessing and a curse, because you’ll be held liable for every design mistake made. That’s a good thing; it’s humbling and you can learn a lot from your audience. The community guides most of the product direction for Macaw. So, I guess my advice is to engage the community because they’ll make the product much better than you can alone.

Has there been a watershed moment in the product? What was it?

There have been many. Kickstarter was the most meaningful moment for the company and for me personally, but the largest moment for the product is taking place right now. We're in the midst of some major product initiatives.

It's still a little early for us to say too much about what we’re developing, but I can say that we've cracked numerous things that we didn't even think would be possible. We can't wait to share them with the community!

Who is your favorite person to follow on Twitter?

I follow the typical list of designers and developers, but one of my favorite people on Twitter is neither: @brainpicker. Brain Pickings is easily one of my top sites as it covers a ton of awesome, nerdy stuff: creativity, life and science.

If you would like to learn more about Macaw, you can do so easily on their site.

If you liked this interview, you will also like the other interviews we've done with creators of design-centric software.

LayerVault customers participating in the Sketch Bundle will not have to pay for upgrades to Sketch. The issue of paid upgrades has been contentious in many communities online, not just the design community. That argument no longer needs to be part of the equation.

Hello Sacha, thank you for joining us today. Could you tell us a little about yourself?

I'm a maker of Internet products. I know that just sounded very pretentious, but it's the best I've come up with to describe what I do. I see myself as a guy who tinkers in his garage on the week-end, except I do this full-time, and online.

You live in Japan, but are originally from France if I’m not mistaken. How did you end up there?

My wife is currently doing a PhD here in Japan, which is why we moved here a little over two years ago. We had travelled around Japan three times previously and we both love Japan and Japanese culture (something we have in common with most of our generation, at least in France), so spending more time here was definitely on our to-do list.

What advice would you give to designers looking to live a nomadic lifestyle?

I don't really view my own lifestyle as nomadic, since I've been living in the same place for the last couple years.

I personally don't think I'd like living a true nomadic lifestyle at all, and I doubt most people would. When you're moving around every couple days or weeks, half your life becomes a quest to find transportation, accommodation, and good internet access.

Instead, I would recommend finding a new “home base” that can act as a hub and venturing out every couple months for shorter trips. For example, since moving to Japan we've been to China, Korea, Hong Kong, and Okinawa.

How do you decide what client work to take on, versus what client work to pass on?

I think when it comes to picking clients, a lot of designers suffer from what mathematicians would call “hill climbing”. In other words, they keep focusing on immediate financial gain and climbing the comparatively small hills of quick and easy projects, instead of taking a longer-term view and finding a mountain to scale.

At least personally, I've always tried to give priority to projects that would let me grow as a designer and open new doors, even if they paid less (or not at all) compared to more mundane work.

Of course, not everybody can afford to do that. Which is why it's so important to take those risks while you still can, before you get three kids and a mortgage.

You have several side projects under your belt including Folyo, Telescope, and others. How do you decide what to work on, and what takes up most of your time these days?

One thing I underestimated in the past is the importance of building up momentum. Working on a project four days in a row is very different from working on it one day a week for a month. So now I try to work on each project in 2-3 week sprints, even if it means neglecting the others, rather than try and juggle everything at the same time.

Right now we're working on updating Discover Meteor for the upcoming 1.0 release of the Meteor JavaScript framework, but apart from that Telescope is the project that takes up most of my time.

Being an open-source project, working on Telescope combines coding, community building, and support. It's a huge amount of work, but it's very rewarding seeing people use the app to build their own communities.

You also run Sidebar, which publishes the 5 best design links each day. How do handle submissions, and what is the most difficult part about running Sidebar?

Although Sidebar links can come from many sources (Twitter, Designer News, the site itself) I act as the final curator that distills all that down to five links.

This is actually not the vision I originally had for Sidebar, as I wanted to build a much more community-oriented site, not one where I would control all the links myself.

But I ended up getting “stuck” with the current model, as I don't know yet how to open up link submission to more people without losing the quality and curation that became the site's trademark. Having a few dumb links and reposts is not a problem on a site the size of Hacker News, but if you only send out five links a day you need to make sure they're all amazing.

Finally, what has been your favorite Designer News story of all time?

My favorite story is that time Jony Ive came on the site and posted his designs for the new iOS icons. He took such a trashing for the poor contrast, bad highlights, and perspective problems that he hasn't been around since.

It's normal if you don't remember it though, it was probably before you joined.

You can always keep up with what Sacha is up to on his personal site.

If you liked this interview, you will also like the other interviews we've done with creators of design-centric software.

What is Stand In and what does it do?

Stand In is a way to help designers iterate quickly through the design of mobile apps. We bring prototyping into the design process so when you iterate on your design, your prototype updates in real time.

What was the moment you decided to start working on Stand In? Who was there, where were you physically at? When was that?

For years, my co-founder and I both worked at agencies and startups, working on mobile apps. During this time we were frustrated with the disconnect between the design phase and prototyping phase. We wanted a solution that integrated into our existing workflow rather than adding more steps to it. After kicking the idea around for a while, we decided to quit our jobs and build it. We started at the beginning of 2013 in Portland, Oregon.

How long did it take you to build your first prototype? What was the length of time between idea to getting something in customers' hands?

The first prototype of our prototyper (so meta) was built in about 3 months but soon after we decided to rewrite it using a new plugin technology that Photoshop was working on. We were just two folks at the time so it took us a little under a year to ship the first version.

What's your favorite tool you use to build Stand In?

We use Node.js really heavily and I love it.

What is the most challenging thing about developing tools for the design community? How have you overcome those challenges?

I'd say it's how quickly the world is changing. The number of new devices coming out and even new forms of interaction (e.g. Force Touch) that makes us really think hard about how we approach building design tools. The old way of building for the web doesn't work today.

Designs aren't siloed the way they used to be. Now we're thinking about designing experiences across devices.

What do you believe are some of your biggest failures?

I wish we had shipped sooner. I'm too much of a perfectionist at times and don't get things out the door soon enough. I've been trying hard to ship early, ship often.

What advice would you have to anyone looking to develop applications or services for designers?

Talk to as many designers as possible about their process, and pain points. It's too easy to build a product for yourself, but you really need to learn how others work and if your product solves problems for them. It's much less painful to learn that before writing a lot of code.

Has there been a watershed moment in the product? What was it?

We're currently going through Techstars and it's been an amazing program.

Who is your favorite person to follow on Twitter?

Marc Edwards (@marcedwards)

What has your favorite Designer News story been of all time?

I thought it was really cool how Simon Jaspers made a tool to generate DN avatars.

If you would like to learn more about Stand In, you can do so easily on their site.

If you liked this interview, chances are you'll like our past interviews we've done with creators of design-centric software.

The idea of version control is not new. The theory now is the same as it has always been: keep track of how a document has changed over time, and who changed it. It is sometimes just as important as what the document itself contains.

Documents and ledgers have been crucial to modern industry. Who owns what and what do we agree to be true. It pays to have a safety net, a place to return when things go south. Thus, version control existed long before programmers gave it a name and a suite of tools.

This blog post will discuss the history of version control in the obvious and less-than-obvious places, and where we think it’s headed.

Before Software

Although there were probably different copies of cuneiform tablets, we’ll keep this post scoped to the 20th and 21st centuries. In the 20th century, keeping a history of a document was usually done through carbon copies or rote copying. After the introduction of the Xerox 914 in 1959, this process became much easier. The storage mechanism was always the same: a filing cabinet.

In the case of publishing, these documents were separated into drafts and the final product. In the case of a republishing, you would create a new edition. If one were to collect all of these, you could be able to see an author’s subtly changing perceptions over time.

Around the same time, some sectors were wont to discard past copies for legal reasons. In public accounting, for example, a paper trail of draft audit workpapers was seen as a potential liability. When an audit was complete, the only documents that existed were the final workpapers. Contrast this with banking and insurance industries, where it was incredibly important to keep a full record of document drafts and who made which edit.

The Beginning of Computer-Aided Version Control

Manually keeping full records of every past document did not seem sensible. As computer software became more and more complex inside places like like Bell Labs, IBM, and Xerox, the need arose for simple way of recording the changes to source code files. Thus, Marc Rochkind developed the Source Code Control System (SCCS) at Bell Labs in 1972.

When just a single character difference can result in a program compiling or not, tracking changes byte-by-byte was incredibly important to the nascent software industry. As with any promising new technology, it becomes the new norm and later “not good enough.”

Years later, Walter Tichy developed the Revision Control System (RCS) while at Purdue University. It provided the technological foundation for CVS, one of the major open-source version control systems.

Although byte-level accuracy of changes was important in early systems, there was another important factor: space. Maintaining many sets of nearly identical files can eat up hard drives quickly. Space was extremely expensive. Now, universities use these old hard drives as doorstops. (They are about the size and weight of 8 bricks.) Thus, maintaining a history of your work only made sense if it could also be done in a space-efficient way.

The Evolution of Computer-Aided Version Control

Since then, version control for code has improved by leaps and bounds. The introductions of Subversion, Perforce, git, Mercurial, and many others improved a programmer’s ability to track changes to source files over time.

Each iteration in version control also made the concept of working with others easier, both through interfaces and new technology. The interface of a “branch” allows a programmer to isolate her work from the “trunk” of the canonical history. A branch is an effective, safe test bed for new work.

So too has the technology improved. Smarter algorithms around merging source files have lessened the inherent friction in collaboration.

Over time, the version control systems became good enough to become central to software development itself. The credit for this goes squarely to GitHub. Started by four friends in 2008, GitHub pioneered the idea of “social coding.” But they have advanced the idea of version control beyond just version tracking and collaboration: they have made version control central to how software is developed, tested, and deployed.

Using a system like GitHub, continuous integration and continues development becomes easier by an order of magnitude. They have made the git tool crucial to starting any software project, no matter how large or small.

Version Control for the Rest of Us

In parallel to the advances of version control for software developers, a few ideas leaked into more consumer settings. Microsoft Word 2007 introduced the idea of tracked changes. Google Docs likewise has a robust revision history on each document.

Finally, version control has also been introduced at the file level through a few consumer-facing products. Apple introduced Time Machine with OS X Leopard in 2007, and now defaults to tracking different versions of files with many applications. Dropbox, Box, and other cloud syncing services also allow limited tracking of history for files as well.

A typical software developer might not consider these applications of version control: they are too simple. It’s true in a purely technical sense. All of these implementations take a highly linear approach to a document’s history. The result, however, is good enough for that industry.

Version control in any context helps the author tell her story. Watching something evolve over time often eliminates confusion. It makes the conversation around the finished product much more productive. Most importantly, it instantly establishes trust among everyone invested.

The Next Evolution in Version Control

The next evolution in version control is to bring the idea to the masses. The tools for versioning software are good enough for a large majority of the users. The real value is building on top of this technology, much like GitHub has. Kryder’s Law (the storage-related sibling to Moore’s Law) has made the financial viability of version control for larger files a reality.

That is what we are trying to do at LayerVault: apply this history of collective learning to designers. The team over at Splice is doing it for musicians. Before we can run, we need to walk. Figuring out what version control looks like for musicians, designers, lawyers, doctors, and more must be the focus. In most applications, the result will be more linear than graphical. That is to say, merely recording the history of files over time will suffice rather than worrying about how to merge different sets of work.

Once each industry has its version of SCCS or RCS, then we can begin to run. What type of value you can introduce once you know the entire history of every file? What are some simple things that become immensely valuable? For LayerVault customers, having discussions around files over time is just that. Leaving comments on files is nothing new, but having discussions tied to the evolution of work is powerful. It eliminates confusion and makes each conversation more productive.

The next evolution in version control won’t look much like it has for software. Different industries have different programs, and the solutions must be built with those in mind. Splice works with Ableton Live, FL Studio, and Logic Pro. LayerVault works with Photoshop, Sketch, Illustrator, and more. The next evolution has a strong network component where the entire history is constantly at your fingertips. The next evolution has an extremely simple interface, where you are building a history without any extra effort.

This is what's most exciting: marrying this technical power with the creative process. Version control is both a safety harness and a supercharger for creators. When a designer no longer needs to fear that any idea could be lost, it becomes much easier to explore all avenues. Both the quantity and the quality of work improves drastically.

Whatever happens, one thing is for sure: the next evolution will be tracked.

—

Thank you for reading. If you are interested in trying out LayerVault, it’s free for the first 30 days. Splice is free as well.

Although we primarily track design files, we also track some text documents. You can see this article evolve over time on this LayerVault page.

What was the moment you decided to start working on Marvel? Who was there, where were you physically at? When was that?

The idea for Marvel came about whilst I was freelancing at a big global agency. Like most of the designers there, a large part of my time was spent on pitch work.

There was one pitch in particular that sparked the idea. It was a iPhone app for a big brand worth 6 figures, so everyone had their heads down all week working hard on putting something impressive together.

All of my time was spent doing the interface and UX for the app, 20-ish screens in total. I sweated details, I did it all in Retina, I displayed interactions and gestures, it was full on.

What happened next is pretty typical in most agencies I’ve worked in. You hand over the finished mockups to the account director, who then crams them into a Powerpoint, throws in the agency logo, paragraphs of text and maybe even some clipart.

In an ideal world I would have handed my designs over to one of the devs and they would have coded it up so that we could have presented a prototype that the client could have played with. The reality is that in most agencies, all the developers are stacked on existing projects and don’t have time to anything else.

For the next pitch I decided to put all my mockups on the photoroll of the device and give it to the client myself.

The result was incredible, even though the only thing you could do was swipe through the screens, the client loved it and actually thought it was a real app. I had to explain that it was static mockups but she was impressed and we won the pitch.

Getting my designs into the client's hands was powerful, not only did it make the agency money by winning the pitch but it also saved development resources. But I knew that making the mockups interactive would have a even bigger impact.

That's when the idea for Marvel started to form, a super simple platform for making my designs interactive without needing to code.

How long did it take you to build your first prototype? What was the length of time between idea to getting something in customers' hands?

I think I first mentioned it to Brendan, a developer and one of my co-founders, late 2012. It wasn't until early last year that we got started on it.

We were both freelancing at the time so we worked on Marvel over evenings and weekends, grabbing a few hours here and there. In total it took around 3 months to get the first prototype of Marvel up and running.

It didn’t help that on two occasions when we were a week away from going into public beta, I decided the UI and UX had to be changed.

If there's one lesson I've learned from that experience hat was that you just have to let go.

It turns out that if people like your product and it solves their problems, they’ll forgive spelling mistakes, misaligned text, bugs, and all the other things I was paranoid about. Obsessing that the website didn’t look like my PSDs was a waste of everyone’s time and energy. ​

What's your favorite tool you use to build Marvel?

I'm really impressed with Mixpanel right now.

I recently set-up several retention emails which get sent to users asking why they haven't returned to Marvel for a couple of months.

The response has been immense. It's sparked hundreds of conversations with users (many face-to-face ones too) and helped us prioritise bugs and features.

We're not even close to utilising Mixpanel's full potential either. You can get some real granular detail on how your users are behaving so we're still figuring out how to utilise that data to make a better product.

What is the most challenging thing about developing tools for the design community?

Probably that most of your users are experts in UX and design so if your product isn't up to scratch in both look and feel, it'll get dumped pretty quick.

Reliability is another big challenge. Marvel is used everyday to pitch and present work to bosses, investors and clients. If the prototype bugs out or the service goes down, we make our users look bad. That could lead to them losing a pitch (and the money that goes with it) or getting a bad reputation. The stakes are high.

We found out the hard way that if you mess up at those points, you don't get a second chance.

How have you overcome those challenges?

​Iteration! We beat ourselves up a lot when things go wrong or aren't up to standard but the reality is that takes time to build a great product.

What do you think the biggest challenges facing designers are today?

Keeping up to date with new design patterns, technologies, platforms, API and tools.

It's harder than ever to stay relevant. Just when you think you've finally got to grips with one device, another hits the market or a new OS gets released.

On one hand it's an incredibly exciting time to be a designer with endless possibilities, on the other it can feel like you're being bombarded with stuff without the time to learn.

For example, recently I read that iOS 8 supports animated PNGs - I didn't even know animated PNGs existed! Now I'm thinking, what is this thing? How can I use it? When should I use it? How can it help me?

Even the tools we use everyday are changing. I've spent my career putting thousands of hours in and mastering Photoshop, but now Sketch is looking so good that I'm making the switch and basically starting from scratch. Everything is in flux.

What do you believe are some of your biggest failures?

​I think I waited too long to do what I loved.

For years I knew that I wanted to design and build my own products, but instead I spent so much time and energy trying to convince my bosses at various agencies to let me create internal initiatives and side-projects​ to try and scratch that itch.​

Looking back now at those 3-4 years, I feel gutted that I didn't channel that energy into my own stuff instead.

W​asting your time doing shit you don't believe in - that's something i see as one of my failures.

What advice would you have to anyone looking to develop applications or services for designers?

I think understanding the problems of your end-user is always a good thing. You should either be a designer already or work closely with one.

One of the advantages with Marvel is that a lot of the product decisions we make come from my past experiences. It makes it easier to step back and ask yourself "Would I actually use or want this thing?"

The great part about making stuff for designers is that you have so many amazing, highly active communities to tap into. Whether that's Designer News, Dribbble or /r/design, you can quickly put your idea out there and get immediate feedback from your target audience. And they aren't afraid of being honest!

Has there been a watershed moment in the product? What was it?

That was when the first person paid to upgrade their Marvel plan. Before that point we had absolutely no idea if Marvel could be an actual business.​

Who is your favorite person to follow on Twitter?​

​I love @millsustwo​, his feed is completely random but always honest views on the industry. Sometimes he tweets really interesting articles, and sometimes he tweets about ponies.

You guys have a pretty impressive story when it comes to promoting your product on Designer News. Can you tell us about that?

​Yeah! You can actually trace our progress through DN posts.

So around this time last year we were still building Marvel in our bedrooms​ and during that summer we threw up a 'coming soon' page with the obligatory form to add your email address to be notified when we launched.

It got posted to Designer News and within a week we had over 1500 email addresses. It allowed me to start reaching out to people and getting them on the alpha and gather feedback.

Then in October we launched Marvel into public beta and I posted it as a Show DN. It reached the top of the front page and suddenly we had enough traction to go to angel investors and get some funding.

A month or two later we were full-time on Marvel!!

What has your favorite Designer News story been of all time?

​Every Designer News AMA! All of them were great fun to read but I especially liked the insights from Maykel Loomans, Frank Chimero and Justin Edmund.

If you would like to learn more about Marvel, you can do so easily on their site.

If you liked this interview, chances are you'll like our past interviews we've done with creators of design-centric software.

How long have you been on the Photoshop team? How did you get there?

I joined Adobe XD in May 2012 and have been working with the Photoshop team since March 2014. Adobe XD is the experience design team within Adobe. The team works on a wide range of experiences and products, from the Acrobat mobile app to Ink & Slide.

I was hired to work on the web portion of Creative Cloud, but was moved onto other projects shortly after joining. My first two years were spent working on small teams in a lean, skunkworks style approach. Earlier this year my director asked me if I’d like to work on Photoshop. I said yes, and here I am.

Photoshop can be simultaneously one of the most-loved and most-despised applications for designers, but it's stood the test of time. How does Photoshop change over the next few years to remain competitive?

A wide range of users have adopted Photoshop for their workflow over the years. Lately we’ve been giving more focus towards designers. Workflows in this area are rapidly changing and we want to provide helpful features. We’ve got a few things coming down the line, like better integration with Creative Cloud and our family of mobile apps, improving team workflows and the reuse and sharing of elements, and extending the power of the CC Libraries.

We also demoed Project Recess at MAX ’14, which strips the Photoshop UI down to the essentials for designers while retaining the power of Photoshop.

I’m very excited for the road ahead.

Photoshop is a mature piece of software with many different types of people relying on it for their livelihood every day. How do you approach segmenting those users, and then developing solutions for problems that each subset has?

That’s an ongoing problem for sure, tackling the wide range and breadth of users. Right now we have an excellent pair of researchers on the team, Heather Dolan and Charles Pearson, to help with this. They are constantly embedding themselves into different groups and reporting their findings. This is very helpful in informing the team on the finer points of specific workflows.

Research is a pretty serious and constant endeavor. Everyone on the team is proactive in conducting their own research and sharing with the group. We love to meet users and chat about how they use Photoshop and what they’d love to see feature wise. It’s all about developing empathy.

What's your favorite tool you use while developing Photoshop?

Photoshop, Illustrator, Trello, and Slack are used on a daily basis. Depending on the point of the development cycle, I’ll make more use of certain tools. I spend the majority of my time creating documentation in the form of writing and wireframes.

In Illustrator, I’ve created a large wireframe style guide and asset sheet. Slack is indispensable for communicating with multiple scrum teams and research groups. Trello helps us organize tasks as we move through cycles.

I hardly render Photoshop UI from scratch. Our icon team in Germany and San Francisco handle all icon assets. It's faster for me to take a screenshot of the interface and manipulate pixels within Photoshop when communicating UI tweaks. CC Libraries helps significantly. I’ve broken the building blocks of the UI into separate assets for quick reuse. Always be Layer Compin’.

What is the most challenging thing about building tools for the design community?

Within Photoshop, it’s a challenge to please a wide variety of users and workflows. A UX designer will have different requirements than a production designer in an ad agency. Workflows are constantly changing and adapting. Twenty years ago, a responsive website was not a deliverable for a client. Assisting evolving workflows while maintaining existing ones is a big challenge.

These tools help designers earn their bread and beans. They’ll be vocal. They’ll be critical. It can be tough to hear when the work is being done but has yet to ship. You have to take it all in stride.

What do you think the biggest challenges facing designers are today?

In regards to digital design, designing beyond one format and input. Multiple screens, devices, audio, touch, etc. It’s maddening. There’ll be a day when 5k screens are seen on the wrist.

What do you believe are some of Photoshop's biggest failures for designers?

In the past few decades, design for digital devices and experiences has changed rapidly. In the recent past, I’d say more attention could have been given to these specific workflows. That’s shifted gears in the past year or two. Several big features for designers were announced at this year’s MAX. The future’s looking good.

What advice would you have to anyone looking to develop applications or services for designers?

Talk with everyone who might use what you’re building. Really get down to the nitty gritty of how what is being built will have a positive impact on someone. Understand their pain points. This is the best part of the job.

Who is your favorite person to follow on Twitter?

@xeni. I always enjoy the stories she shares, both the BoingBoing content and her own experiences. People I love to follow on Twitter tend to have a culture bent. And are ornery.

What has your favorite Designer News story been of all time?

When my colleague @bradee posted her article on Stateful Design and it was shared on DN. We had challenged each other to write an article to share online. Her’s was on the usefulness of layer comp states and smart objects. She is awesome, go read it.

I’d like to think my nagging helped.

That wraps up our interview with Seth. A special thanks for making this happen.

If you like this interview, you will also enjoy the other interviews we've had with the creators of design applications.

As always, you can discuss this post on Designer News.

What is Affinity Designer and what does it do?

Affinity Designer is a professional grade graphic design application for the Mac. It creates graphics – for marketing materials, websites, icons, UI work, or just concept art and illustrations.

What was the moment you decided to start working on Affinity Designer? Who was there, where were you physically at? When was that?

About 4 years ago the head of our development team, Tony Brightman, presented this amazing plan to us with his vision for this new professional suite of graphics applications for Mac. We were sold. We needed about six guys on it initially, so it took about six months to be able to properly clear their desks of other work before they could 100% focus on it.

How long did it take you to build your first prototype? What was the length of time between the idea to getting something in customers’ hands?

We had documents rendering in as little as six months. We could see immediately how fast this new technology was going to be. In terms of getting something into customers’ hands that didn’t happen until the beta which was only 4 months ago. So all in it took just over 3.5 years from original idea to anyone outside of the company using it.

3.5 years! That's a long time. In a world of Minimum Viable Products and shipping ASAP, how did you stay the course and stay motivated?

It was a scary prospect working on something for so long without knowing for sure what the reaction to it would be. We have developed graphics software, admittedly for more hobby applications, for about 25 years so we felt confident what we were producing was special and would be received well. After all, we already had a revenue stream from other products so we could afford the investment. I guess we’ve got a bit of a gambling spirit here as well: trust your gut, it’s more exciting.

Staying motivated was indeed a very big challenge for the developers. Little sprints, followed by the win of the problem being solved—like the performance of the tool exceeding what they thought possible—kept the developers going. That said, you can’t avoid having long periods where there is just a huge amount of grunt work typing. It's boring and tough. And you can’t avoid things going wrong. Looking back there were some very dark days, but they seem such a distant memory now.

What is the most challenging thing about developing tools for the design community? How have you overcome those challenges?

It’s all about workflow and speed for designers. Speed wasn’t a problem – workflow more challenging. Everyone works in different ways and are used to different products. We were lucky in that we already had a team of 10 designers working at Serif and so we used them a lot for early feedback on workflow considerations.

How the Affinity range really sets a new precedent in terms of workflow will not be fully realized until the releases of Affinity Photo and Affinity Publisher. We are going to totally remove the file format boundary between these types of apps.

I guess one other thing which is quite unique about apps for the design community is they will always have an opinion on the look of your UI!

What do you think the biggest challenges facing designers are today?

Same as they’ve always been – mostly all the CEOs who think they know more about design than designers.

What do you believe are some of your biggest failures?

Hard question. We’ve had loads of failures, but that’s the nature of research and development. Someone can spend 6 months trying to solve a particular problem, and the method used just doesn’t work. You just have to throw it away and start again.

What advice would you have to anyone looking to develop applications for designers?

Make sure you have a designer on your team, or who can work closely with the development team and listen to them.

Also, and this really applies to any app, never compromise on your code. Be perfectionists, follow best practices, build in regression. Never throw good code after bad.

Has there been a watershed moment in the product? What was it?

I guess when we decided exactly what products we would make. And yes, believe it or not we were not sure about what they would be when we first started out.

We were originally considering one all-singing, all-dancing design app, but half way through that wasn’t making sense. When we decided on a suite of three in Designer, Photo and Publisher it all came together a lot better in our minds.

What was your biggest challenge?

With all the crazy mathematical and technological problems which have been solved over the last few years, without a doubt the biggest challenge was coming up with a name! What a nightmare. We had white boards all over the place with hundreds of ideas on. Every time we thought we had a good one, there was some trademark or other issue.

We’re very pleased with the Affinity name though—and also that it’s recently been registered.

You can purchase Affinity Designer today in the Mac App Store.

If you liked this interview, you will also like the other interviews we've done with creators of design-centric software.