Rework the general UX

[almet]

We should not show the save and reset buttons when no fields have been added yet, as they are un-effective. I'm not sure what the best way to deal with them: should they be greyed or now be shown at all? cc @Natouille @QuentinRoy

[QuentinRoy]

I would recommend greying rather than hiding.
(1) Even if the action is currently not available, users can still discover that it is here and may become available depending on the system state (the grey feedback is widespread). It is even better if a feedback is provided to tell why the action is currently not possible (e.g. with a tooltip).
(2) Hiding and showing elements like this on an application may be confusing. It is likely that a user won't "scan" the page a second time to see if it has changed once she created a question. I feel like it may even be more important for buttons like "save" as more and more applications / websites do not require one anymore. It is not impossible that some users fully miss it and make mistakes.
My subjective opinion on removing elements is that in general, it is OK if the user will never be exposed to them, but the goal is to strip the interface down rather than forbidding access to functionalities.

[almet]

Makes sense, thanks!

[Natouille]

Do you mean the first "page" below ?

If so, I don't see hiding the buttons as confusing. The page changes completely when you add a new element (short text, long text, etc.)

Most of the time I try to avoid these unclickable buttons, because it can be seen as a false promise ("it's there but I cannot do anything on it : why ?"). So I hide and then show them when the access is granted.

[QuentinRoy]

I agree, that in this case, it is almost as if one ends up in a fully new page so it probably does not matter much and you may want to make your first page cleaner.
I don't think the "it's there but I cannot do anything on it : why ?" is a big issue though. This is what Tesler would call a mode problem. But, hiding it does not help a user finding how to make an action. I agree it may avoid some frustration, but IMHO, that's only because the user does not know the action can be performed in the first place which, I think, is a discoverability issue way worse than this frustration. But then hey, that's HCI, no hard rules here.

[almet]

Please note that the currently deployed version on fourmilieres is not what the UI currently looks like. I've yet to deploy the new version there, but you can see it at http://kinto.github.io/formbuilder

I think it solves a few problems but I feel the previous version was easier to grasp (we've added a click more to add a field!). I would love to have some feedback.

[QuentinRoy]

Are you sure you do not want to try a bit of paper prototyping guys? You can just roughly draw how the interface could look like on paper, try out different stuffs and even play the interaction on the sketches before jumping into any code.

[QuentinRoy]

I personally tend to prefer the interface as it was before. But then and I already told you, I do think you guys could use a bit more prototyping, iteration, user testing (even quick or informal) on this :). No "UX expert" can replace that. Design is mainly a matter of methods, very little about rules.

[almet]

I think we'll conduct user testing research in the future, but we first need to get to a point where we have something to show them :-)

[DirtyF]

@almet you can show them paper prototype, these can be added in apps to test user scenarios, there are a lot of ways to engage users before writing any code.

@QuentinRoy I'd be interested in conducting some user-testing based on lo-fi prototypes, maybe it's something we could do without interfering with the current development? What do you think?

cc/ @Natouille

[almet]

We'll try to organise something here in rennes with @rlecellier, and share our results. I'm interested in anything you find on your side, that would be great!

The biggest challenge for us here is that we never did this, so we're scared ;)

[QuentinRoy]

That is very easy. If you want, let's Skype this WE I can tell you how to get started. In the meantime, and for those who are not convinced yet or think that won't fit well in your timing, you can have a look at this. Funnily, it looks quite appropriate.

[DirtyF]

@almet great to hear, we could run a session here in Toulouse too with @Natouille. but I'd like to have @QuentinRoy input on prototypes.

[Natouille]

@almet don't be scared :) It should be quite easy to draw some prototypes in order to test them with users.

[rlecellier]

What about something like this ?

a other one with:

• end user field preview
• "insert field" button between fields. It's use to move the "add field" panel.
• widget / shortcut tabs to switch between simple widget and custom one like email and currency

[Natouille]

@rlecellier I think it's a great idea to use the standard web text fields. I am absolutely not a fan of the new Material Design look of these fields. If I check on this page below, I don't what's editable and what's not

For you other options, I have to check, there are some good ideas here.
To all : it would be better if we could agree on a global reflection rather than just some tiny adjustments here and there. At the end, it will be a bit messy.

[rlecellier]

Here my last proposal with the two current version. You can either :

• propose new stuff then i'll add a build the layout with pencil.
• propose modifications on one of the three layouts then i'll modify it.

Currently on https://www.fourmilieres.net/#/

Currently on http://kinto.github.io/formbuilder/#/builder

Proposal