It’s OK To Not Know

Or how to stay sane at a new job

I’m a work vagabond. Over the course of six years, I tried six different jobs and now I’m at my seventh halt. This is one thing I've learnt from all these different experiences.

1. Keep calm and do your research

You can’t know everything about the new job. But you can (and probably should) try to get there. No matter what it is, don’t expect someone to hand all the information on the plate and be unbiased about it.

2. Ask for help

People tend to fear coming off as incompetent or even lazy, but asking for help makes you deal with struggles faster. Don’t just limit yourself to the people you work with. Ask advice from everyone you know (and don’t know) who are able to give some worthy piece of mind.

3. Speak your mind

Speaking your mind is good for two reasons: you get to be right; and you get to be wrong. If you’re right, you earn credibility. If you’re wrong, you will be corrected and you will be right the next time. It’s OK to hit and miss, as long as you learn from your actions.

Read the full article on Despreneur and please share your own experiences with me!

It’s 2014 — where is my backendless CMS?

Please stop the madness

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 ☺