Cabane

I’ve been receiving feedback from friends and family in the last days. They’re all different.

For starters, the good part ✅
I worked hard on the interface. Every interaction is custom made. And although it can be polished and the fluidity improved, the simplicity of the interface seems to be universally appreciated, and even unexpected. That is some important validation here.

What to expect from early feedbacks?

Two things. First, be in the lookout for critical usability issues. Second, open yourself to how people envision your product as an answer to their needs and desires. Not features.

Some envision it as a canvas to express themselves outside of corporately owned platforms, others see it as an opportunity to start a business. Everyone has their use cases.

The idea is to find the Job To Be Done™️. There are great examples detailed in this HBR article but the take-away is to find the real reason people hire your product for. For example:

I went in thinking we were in the business of new-home construction, but I realized we were in the business of moving lives.

So, when do I know I have enough feedbacks? I guess I don’t. It will be obvious as a path clears up. In the meantime, I have to create the conditions for ideas to come up.
Here is what I think will drive ideas:

Simplify even further the publishing process

You’re not “deploying a website”, that’s too nerdy. You’re sharing a link to your friends
It means, not waiting for a whole minute to receive the email notification with the live link.
It also means putting that link front and center so it can be shared easily.

We need 10, 100 even 1000 pages!

It’s cool to be able to create a web-page quickly, but what is the point if you can only create one?
Whether you’re writing your thoughts or crafting a form for your company, you will have many ideas, and thus needs many pages to experiment and share.

---

Emails. I used them to address two of my previous pain points.

1. Instead of asking users to set up webhooks, I made it optional. Instead, I sent the form's answers to their email address by default. It allowed them to go on with the flow, not having to set up anything complicated if they didn't want to.
2. I would wait for the site to be built (usually less than a minute) and send an email when it was ready.

I used Postmark for this. I recommend them. They are great and easy to set up.

https://imgur.com/a/jYWXK4h

A few days before my birthday, I had been battling with Interface quirks and database inconsistencies but finally, I had something I could share with my closest friends.
I received many great feedbacks. Of them all, I could see three pain points I HAD to improve before going further.

1. Users could not find the publish button. It was hidden in a menu

2. Users HAD to setup webhooks in order to publish a form. It meant having to signup for a Zapier account, making all the required connections to hook the form to a Google Sheet.

3. Users were given a somewhat broken link after publication because the website had not finished deploying.

I would spend the next two weeks correcting these BIG issues.

After spending some time trying to find the proper prototyping tool, I came to the conclusion that I should skip this part entirely.
Prototyping tools are great when you're not trying to push the boundaries of user interfaces. But when you aim at breaking the rules, you might as well do it by yourself.
After spending a week or so on codesandbox examples, I managed to have a nice working drag and drop interaction.
I know there already are plugins out there. But most of them don't allow for arbitrarily sized items and are not properly animated.
This is a good starting point as I envision the product as a WYSIWIG editor.
Let's see what I can do with it.
https://codesandbox.io/s/drag-and-drop-v35-commit-phase-3ir6j

That's always how I feel when I need to pick a tech stack.
Most of the time, it's not obvious.
I initially used React Native as I wanted my app to be as performant as possible.
However, being a website builder, it meant I had a React Native frame and a Webview interacting together. It would be alright if I could dissociate the two parts, but I wanted the product to feel like a coherent whole. This meant the "builder" part had to integrate pretty closely with the "result" part.
After some research, I found out that such communication between the two would be very hard to pull off if at all.
I decided to go all-in with Javascript, React, and React-Spring (an awesome animation library).

📅 Today marks the beginning of me working on my new project!
It doesn't have a name yet and I don't know where it'll go. 🤷‍♂️
But after a day, I'm already enjoying it! 😃
I started drawing and sketching mockups on my notebook.
What if we could build a website straight from its phone?
I know it sounds weird, but I'm pretty sure people haven't done it only because they don't see how it could be done properly. I have my ideas on the subject.
I love the conception phase, it's pretty exciting!