Spend less time perfecting and more time evolving

A case study in how “almost-finished” is better than never finished.

While we were redesigning our web app for Trading Paints last year, we took our time. We told ourselves the update wouldn’t go live until we had reached 100% perfection — after all, this launch would directly set the tone for our long-term future, and we’d only have one shot at introducing our new set of features.

Our well-intentioned mindset of perfectionism turned what should have been a small evolution into an astoundingly lengthy two-year redesign process (in Internet years, that’s practically a decade).

In those two years, we went through three different design and feature concepts, scrapping the first two iterations entirely and landing on a third. We threw away a lot of time and effort getting to Concept Three. Through all this, I thought I was going to scare away our lead programmer, who had to do a lot of re-work over that time.

The lesson we learned was that “good enough”, despite what others had always told us, is OK — that is, as long as you commit to evolving your product once you’ve shipped it.

It’s getting to the “shipped” status that’s the important part.

Our two scrapped redesigns would have been major improvements over our 2009-built Web 2.0 mess we set out to replace. Because of our Perfectionist’s Disease (well, stubbornness, really), our users had to deal with an icky, outdated, inefficient web app for two years longer than they should have.

It’s more important to ship a product in the first place than it is to ship a perfect product. Chances are, most of your audience won’t realize something nearly finished isn’t actually completely finished in your mind.

In our case at Trading Paints, our audience would have been delighted by any of the “imperfect” designs or features we built but didn’t release.

Eventually, at a certain point in our magical third concept, we shifted our focus to getting the damn thing out the door, promising ourselves we’d improve once we were live. This shift in our thinking led to a quicker launch, an end to two-years of wheel-spinning, and 25,000 happier users.

Self-proclaimed perfectionist Sean McCabe suggests curing perfectionism by aiming for 90%. This is solid advice for someone dealing with Perfectionist’s Disease.

Using McCabe’s 90% model, you shouldn’t spend so much time trying to perfect the last 10% when you can instead ship at 90% and evolve once you’ve reached that point. In our case, we had the opportunity to evolve and improve after we launched our redesign. In the case of a designer or developer doing project-based client work, evolving means aiming for the 90% mark and improving in your next attempt. If you’re a perfectionist, it’s awfully likely that 90% in your mind is 100% in other people’s minds.

We eventually launched the new Trading Paints earlier this year, still perfecting things and evolving features as days go on. Even after releasing an “almost-finished” product, our users have been delighted by the updates and pleasantly surprised when we drop in new features that we once swore we couldn’t launch without.

Our only wish is that we’d have stopped trying to be perfect two years sooner.

Note: This advice does not apply to brain surgeons.

Few weeks ago, I went to @lxjs conference which was great. Soledad Penadés explained me the vision of Firefox OS, and I found it exciting.

After ten days, I started to work on creating an app for this system on my free time. I needed a simple but useful idea for me: a Buffer client for Firefox OS.

Before I started to develop with a library or system, I like to read their documentation. On that point, Firefox OS has the advantage of the documenting spirit of Mozilla: detailed in different languages and examples https://developer.mozilla.org/en-US/Firefox_OS.

Preparation

Now time to develop this app! I setup a front-end project like I’m used to doing it: NPM, Bower, Gulp.

I chose AngularJS, but promise, I will try Polymer or React in the next one. I could use Ionic Framework for the UI, but I wanted to try the Gaia interface. Have a look there: http://buildingfirefoxos.com/index.html

What is truly good with Firefox OS, it’s the fact they’re using the same libraries as third-party developers to make the system: UI elements, transitions, etc. The code of the default apps is open source too. So you can get inspiration by looking at it: https://github.com/mozilla-b2g/gaia

The only difference with a website is the app manifest: https://developer.mozilla.org/en-US/Apps/Build/Manifest. It’s not that different from a Google Chrome App’s manifest. You have to set the permissions, icon files. Good point, you need to describe the need of each permission. It will help the user to understand what he allows. No more bullshit permissions for games, yeah!

You have three types of app:

• Hosted: The app is hosted online. Limited access to the APIs
• Privileged: The common one in mobile. Mix between the others.
• Certified: Access to sensible APIs like manage the WIFI, monitor the networks. The system apps have this status.

You can check the list of permissions here: https://developer.mozilla.org/en-US/Apps/Build/App_permissions

Good point, the user can change the permissions of the app even after the installation. The spirit of Firefox OS is focused on the transparency of the system, letting the power to the user. I’m fond of the concept! So you need always to check if the permission is granted before making a call to the API.
If you root your Android phone, I think you can do it too but it’s a hack, some apps may be buggy, and I don’t even talk about the closed-mind spirit of iOS…

The Dev tools of Firefox OS 1.3 can’t debug network requests while Firefox OS 2.0 yes. So I decided to work only on my browser until I need a device-specific API.

Simple Python HTTP server

I didn’t use file:/// because you can set the origin property in the manifest. It will look like app://my-app.com. Useful for origin problems.

Redirector extension

It simulates the redirect property of app manifest. This property allows you to have an automatic redirection from a page to another inside your app. It’s much simpler to use that instead of having an in-app browser for OAuth authentication.

CORS proxy

Firefox doesn’t have a security flag like Canary, so you need to bypass the checking of CORS by doing that if the API used doesn’t provide it. Remember it’s only on desktop. In Firefox OS, you have this permission: systemXHR (https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#mozSystem)

Notification

Local notifications are the same as the one defined in the specs of HTML5. For the APIs which aren’t specific to the device, you can test them directly on your desktop. Sometimes, you’ll need to the nightly version. It wasn’t the case for me on this app.

Web Activity

This API allows you to delegate an activity to another. It’s the Intents of Android. I played a little bit with the simulator, and it’s easy to use. It’s well described here: https://developer.mozilla.org/en-US/docs/Web/API/Web_Activities

User Interface

As written earlier, all the UI elements of the system are open-sourced. You can custom them with CSS. Follow the guidelines to have an app well integrated: https://www.mozilla.org/en-US/styleguide/products/firefox-os/

I had some frustrations due to the lack of examples and uniformization of design elements (the icons of the header aren’t the same as the edit ones) but it will be improved.

I didn’t play enough with transitions due to the lack of time that I had but so far I tested; it’s easy to add them in your app. They look smoothed in the simulator. I will try on my soon-coming Firefox Flame.

Open System, Open services

The team of Mozilla is known by always open source their code. All the Firefox OS system is available online. But it is interesting to know they open sourced the code of the marketplace and the push server.

You can put your app in the default marketplace or another one, you’re free. You can set a whitelist of marketplaces in the manifest of your app. Android allows that too, but you need to enable the unknown sources. It’s not safe and hard for not advanced users to do it.

The push system is intelligent too. You wake up your app by sending a simple request. No title, description or sound. It’s like the silent notifications in iOS. The main advantage is to avoid sending sensitive data to Mozilla servers. We can trust them but to they can be compromised by a cracker (or the NSA). You can set a version property which is a number that keeps increasing. Your backend tells the Mozilla servers about a new version whenever it wants an App to be notified.

You can read more about it here:

• https://wiki.mozilla.org/WebAPI/SimplePush
• https://hacks.mozilla.org/2013/07/dont-miss-out-on-the-real-time-fun-use-firefox-os-push-notifications/

My App

I didn’t describe in details the development of my app because the process was the same as a Single Page Application. The code is available here: https://github.com/yrezgui/buffer-firefoxos

If you have any questions, feel free to contact me: http://www.yrezgui.com

Conclusion

I just loved to create an app for Firefox OS. I rediscovered the excitement that I got when I developed Firefox and Chrome extensions. The simulator debugger still need to be improved (a right-click on an element doesn’t display the options of the desktop one), the UI library is nearly done but the system is ready. I developed for Firefox 1.3, but version 2.0 is already available in beta.

Bonus point, the simulator, doesn’t take ten minutes to open as the Android one, and you don’t need to wait your app to be loaded to open the inspector like iOS. You can catch easier the errors at the loading.

The philosophy of having a complete open source system, default open source apps, manageable permissions for each app is the right way to do mobile OS. But it doesn’t mean the system needs to look ugly, or it’s hard to use it (I’m looking at you MeeGo!). Creating apps is starting to be cool again, so rush for it ☺

I recently made a project named Furaito (フライト, flight in Japanese). It’s a simple app that checks your emails to find your last flights. It uses Polymer, Import.io and Gmail API. You can check the demo here and the source code here.

Before I write a blog post about how I built this app, let me explains you web components, the root of Polymer.

As you know, the Web has been continuously evolving, even more these last years because of the need of apps working on every platform, the mobile, the realtime.

So far, CSS evolved with a lot of new styling features in its third version. We created preprocessors to make it easier to develop with it.

JavaScript got its preprocessors, and its sixth version is coming soon (modern browsers have already partial support).

But HTML didn’t really evolve. We have now semantic & multimedia tags, but the way we write them didn’t change and preprocessors don’t help that much. We need a change.

Web Components!

When you develop a complex web app, you know that HTML debugging is painful. The depth of your DOM is damn long, and you don’t want to open all elements again and again in your devtools after each refresh of the page.

So what’s this revolution?
Web components bring four new features to help you writing your HTML in a better way:

Templates

Forget the time when you had to wrap your templates into an ugly scrip tag:

<script type=”text/tpl”>

Now you have a dedicated tag for that.
First benefit, you will have your syntax coloration back in your IDE.
Secondly, even if there are scripts or videos inside, none of them will be executed until the template is used.
Thirdly, the elements inside your template aren’t considered as part of your DOM until you use them. Clean separation.

• http://www.html5rocks.com/en/tutorials/webcomponents/template/

HTML Import

You hate to add your templates in your views because you have nowhere else to put them? Me too. Now with HTML import, you can import HTML pages where your templates and scripts tags will be written (DRY).

No need to make XHR requests anymore to do lazy-loading. Good point, the browser will request only one time your imported files. So no need of being afraid to duplicate execution of your scripts. You can import from your imported files too. Importception!

• http://www.html5rocks.com/en/tutorials/webcomponents/imports/

Shadow DOM

At first, it was hard for me to understand this feature. Why would I like to have sub DOMs? Well to have a perfect sandbox. As you know, it’s painful to check if your components names don’t collides with externals elements (Facebook Login, Timeline widget, Google Maps, etc.).

With Shadow DOM, you can do whatever you want inside your component, it will not impact the parent DOM.
Good news, the CSS is sandboxed too, there aren’t id collisions. Yeah, no need to write very long unique id or class!

• http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom/
• http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-201/
• http://www.html5rocks.com/en/tutorials/webcomponents/shadowdom-301/

Custom Elements

The last but not least feature of web components. In AngularJS, you will use directives to create your own elements. So what’s the difference with Custom Elements? Instead having a library dealing with personalized elements, you can have them recognized directly by the browser engine!

They have their own prototype, methods, properties, lifecycle callbacks (element created, attached, detached, attributes changed). Isn’t that cool ☺ ?

• http://www.html5rocks.com/en/tutorials/webcomponents/customelements/

In conclusion, Web Components are a much cleaner way to create HTML UI elements. They are sandboxed, importables, clonables in your templates and have their own logic. No need to have an external script to manage them. Their support isn’t still complete, but there are already polyfills (scripts which provide facilities that aren’t built into old browsers).

I’m going to talk more about Polymer in my next article but if you can’t wait, you have to know that it is made on top of web components with a lot of sugar: two-way data binding, bunch of logic & UI components (which can be reused in your components, that’s the point), template syntax a la AngularJS, etc.

Have a look to the talk of Addy Osmani at LXJS, which resumes well these technologies : http://addyosmani.com/blog/video-componentize-the-web-talk-from-lxjs/

Poor desktop. Because of the smartphones, tablets and now the watches, all the studies predict its approaching death. But I think they’re wrong.

Of course, the desktop hasn’t the monopoly anymore, but I still think tablets and smartphones are extra units, of course with a lot of features, but you can’t really work on it. You can write your notes on them, but you’ll always want to finish on your laptop for styling, spelling correction, search easier references, etc.

But I’m not going to talk about desktop usage market share but its new apps. Cross platform apps are the dream of every developer.

Java was the first try, not that successful unfortunately. There are apps but making a UI with Java is honestly not that easy.

Adobe came with AIR, which was a good idea but maybe too early on its time and wrong technologies. The HTML support was good, but only Flash, Flex apps had a deep integration with the system. Plus using an extra plugin was painful for everyone.

But now it’s different

The first one to innovate was Google with its packaged apps (I need to write an entire post about it). They need Google Chrome to be installed but can run separately. Good point, they work on Chromebooks.

• https://developer.chrome.com/apps/about_apps

Mozilla Firefox made a similar solution with a deeper integration of the browser, and nice idea, the APIs (not all of them) and manifest are the same as Firefox OS apps

• https://developer.mozilla.org/en-US/Marketplace/Options/Open_web_apps_for_desktop

I don’t know about Opera and Internet Explorer, and I will not even talk about Safari (honestly Apple is the new Microsoft in terms of evolving the web). They have extensions, but I don’t think they have a similar feature.

But for different reasons, you might prefer to have a standalone app. There are two ways to do that:

Native webview

This solution is limited to Mac & Windows 8. You can have a deep UI integration. In Mac, you have to write some Objective-C for that while Windows 8 has a native HTML5 interface (well done guys !). Your code doesn’t need to have a lot of changes if you already have a unique interface. Otherwise, you can still share the logic between the platforms, which represents the big part of your code.

• http://blog.frontapp.com/how-we-make-front-work-as-an-hybrid-app/
• http://msdn.microsoft.com/en-US/library/windows/apps/br229565.aspx

Chromium Embedded

This solution is better for a real cross-platform. It uses an embedded Chromium webview, so no need to install Google Chrome. It has a support on Windows, Mac & Linux. There are different implementations, but the most famous one is Node Webkit by Roger Wang.

It’s a special webview, packing NodeJS inside. You can use node modules inside your HTML page! It includes a native UI package too:

 <script>
 var nw = require(‘nw.gui’);
 var win = nw.Window.get();
 var nativeMenuBar = new nw.Menu({ type: ‘menubar’ });

 nativeMenuBar.createMacBuiltin(‘Jōto’);
 win.menu = nativeMenuBar;
 </script>

There are two huge advantages. You can install packages directly from NPM, and you don’t have to write native code to get a UI system integration.

Have a look to Roger’s talk at LXJS conference:

• https://www.youtube.com/watch?v=XmHh4RrlpIk

Examples

Have a look to these beautiful apps made with HTML5.
You don’t have an excuse to don’t code your desktop app using another technology anymore ☺.

If you have other examples with screenshot, feel free to write a comment to help me update the list.

“The world doesn’t need another blogging platform. But I did.”

This morning, Drew Wilson launched his new blogging platform, Buffalo. As someone who sees dozens of new products every day, I immediately drew connections to Medium, Svbtle, Tumblr, and others that no longer exist. Playing devil’s advocate, I asked:

Do we need another blogging platform?

Humbly and thoughtfully, Drew replied with:

Perfect response. ☺

It’s a good reminder that not everything needs to be a business and that it’s OK to simply build for yourself.

I’m sick of armchair entrepreneurs, judging others for simply building. Would you criticize the 16-year-old banging on the drums in his parents’ garage? The music might sound terrible but he’s learning and even more importantly, trying.

Thanks, Drew.