Fuel Collective

Developing Swatch 2.0

Thu, 27 May 2010 09:06:00 -0500

When you start developing a 2.0 version of your app, it’s like your kid graduating from high school. Either nothing really changes and the kid just goes to work, or you send him to college and then receive him a few years later, nearly unrecognized by his own mother by how much he changed.

As we love our apps we want the best for them, so we send them to college. For Swatch this meant starting with a completely new Xcode project, using 0 lines from the previous one. No matter how experienced a developer can be, when he comes to his project a year later (or even less), he sees immediately where he’s done some internal-design mistakes, what could be done better, etc. He evolves, learns new techniques, his coding style changes a little.

Since we started this company, over 100,000 lines of code went into our projects, which, of course, tought me a few neat tricks.

First of all, don’t be afraid of the paper. I’ve seen many developers scared of this, nowadays, weirdly looking white sheet, however, use it. Draw it out. Draw bubbles with class names, link them with arrows and write the functionality above the arrows. Write rough method names to the class bubbles.

Then let it sit on your desk and come back to it after a week. You’ll see that there are better ways to do it, forcing you to reorganize it and redraw. That’s fine, actually it’s brilliant. Now wait another week. The changes you make then will be less radical. If not, take another week, otherwise settle with your plan.

Now that you have your plan, get to coding. Here I have some tips, too. Even though you don’t immediately need all the methods, declare them, implement them with a #warning statement that doesn’t just say ‘implement me’, but is more descriptive about what the method’s supposed to do. Believe me, when you get back to the method in a few weeks, you’ll have no idea what it was supposed to do and what special conditions should be taken into account. I have had less success using the #TODO’s and #FIXME’s as for the release builds you (should) almost always make a clean build which makes the compiler compile all sources, and if you’ve forgotten to implement the method, the compiler will give you a warning.

If you decide to use unimplemented methods, add logging to them. Something simple like NSLog(@”-[MyClass myFunction:] argument: %@”, arg0);. This way you’ll be able to do some fixes even before there is a bug. Imagine you’re asumpting some method won’t get called too often, therefore may be complex, but in early alpha testing you might find out it gets called too often, which would mean lags and high CPU usage. Rethinking the way it should work now is less work then later on, which would most likely break a lot of functionality in your app.

Sometimes you need to reinvent the wheel - it’s better than to start making a square out of a circle. This is a really hard part to decide. For example Swatch 1.x had some issues with picking a color from a screen. Generally the issue was with the colorspaces - device RGB and calibrated RGB. In Swatch 2.0 we use our own FCColor instead of NSColor. FCColor has, just like NSColor, the -set method, +whiteColor, etc. Note that FCColor’s superclass is NSObject, not NSColor. However, remember you need a really good reason to do this. Reinventing everything is time-consuming and probably won’t work well.

These are a few tips I can give devs thinking about going 2.0, 3.0, or 4.0, etc. During my early developing I had an app, which I then moved to 2.0 later on and now have moved to 3.0. And even now looking at an app that I was writing from the scratch a year ago, I can see some mistakes I’ve made. Don’t get scared. This how you learn.

Krystof Vasa
Software Engineer

Swatch 2.0 - News

Fri, 14 May 2010 09:27:00 -0500

You may have seen our tweet (http://twitter.com/fuelcollective/status/13809299828) the other day with a little preview of what Swatch 2.0 will look like. We still have a ton of work to do on Swatch 2.0 but we wanted to share some insight with everyone. Swatch 2.0 has been completely rewritten from the ground up and has a few new features that I think everyone will enjoy. Some of which have been asked for some time now.

We realized that swatch is becoming a more feature rich app which really separates itself from other screen color pickers. We’re working really hard on redesigning the collections feature to make it much easier to use and in general the user experience has also greatly improved.

So what about upgrading to 2.0 and pricing? We felt like this is Swatch done right, so for all our users that currently own or purchase swatch 1.X before the upgrade will get a free upgrade to Swatch 2.0! The price for swatch 2.0 will be changing, but we’re not sure how much. We’ll get a better idea when we get closer to launch.

We know you’re going to love Swatch 2.0

Stephen Korecky
CEO & Designer

Making Permute

Thu, 29 Apr 2010 13:30:00 -0500

I’d like to talk a little about making Permute and what the process was like. Why Permute? I think it has been by far our best executed application in terms of both design and functionality. We did a lot of things right and learned quite a lot in the process. What was different about Permute from the others? We had a much more clear vision, we went to the people, and we had experience.

We knew from the beginning that we wanted Permute to be a video converting app, but what would make it different from the others? Why would Permute be worth paying for? It clicked, simplicity! So to get a better idea of what was wrong with the current market of video apps, we setup a survey and asked people a few questions, mainly “What do you hate about current video converting apps”. As you may have guessed, most said “confusing controls”, “hard to use”, etc.

From that alone we learned two really important things. One, people are usually pretty enthused to take a survey and have their opinion listened to. Two, we knew what Permute had to be: Easy to use, naturally good looking, and pleasing to the eye. So we had a clear vision of what Permute would be and I set off in Photoshop to create what would become the interface for Permute.

This was the first time I had ever used Photoshop to create a full mockup of one of our apps. Usually I just put out a few good ideas and we go from there. This time, everything you see in the app was mocked up first in Photoshop to get an idea of A. How should it look and B. How it might function. This was very important if we were going to keep Permute easy to use.

So once we had an app that we fell in love with using, we have learned the hard way in the past that a 1.0 is never as good as you think it’s going to be. So this time we decided to have a private beta of about 50 users. The feedback and ideas that we had gotten from everyone was so amazing and helpful. With that we had a really solid and stable 1.0 release that everyone could enjoy using without any major problems.

So as we learn from successes, we will continue to build on them and keep offering new updates to our apps that will make them even more amazing. I’m excited to see what we can do in 2010 and I hope all our uses will stay with us to enjoy great new things.

Stephen Korecky
CEO & Designer

Adding Features

Tue, 27 Apr 2010 13:53:00 -0500

One of the hardest things to decide when we’re working on our apps is what features get added, which we hold off on, and which we just don’t have room for or don’t fit in our vision of the app. Lately we have been trying to take the approach of 37signals and take in all suggestions and then delete them or resolve the issue with a nice reply.

Now I don’t want to give the wrong impression of “we don’t care” we do, really! But now that our apps are getting more popular, thus many more feature requests, if we added every feature request, our apps would get bloated pretty quickly. Instead of catering a feature to just one or two people, we would like to be useful to the majority of our users.

So when we see the same feature request coming up over and over again, that’s usually a good clue as to what features should be added. Now some requests we get just make sense to us, and we feel the need to add it right away.

What we hope to accomplish with this is more streamlined apps that are easy to use, with features the majority of uses would want in our apps.

Stephen Korecky
CEO & Designer