New App in the GUI: Optional Settings are not Optional

[air]

A hurdle for the first-time user:

1. Click + New App
2. Enter a task ID. Leave Optional Settings blank.
3. Click + Create
4. Observe error AppDefinition must either contain one of 'cmd' or 'args', and/or a 'container'.

The panel should give an indication of what's needed to create a task.

[mlunoe]

This is, as of now, expected behaviour - but admit, the interaction/communication could be more intuitive.

@aldipower Could you take a stab at making this interaction a little bit more intuitive?

[pierluigi]

With the new design for the modal there will be a better separation between required and optional fields, as well as the new section for the container settings.

What if we added a help message below the command field like so, @air ?

[air]

Does a command field ever make sense if there's a docker image? Or does it
always get overwritten with a docker run?
On Jul 20, 2015 07:47, "Pierluigi Cau" [email protected] wrote:

With the new design for the modal there will be a better separation
between required and optional fields, as well as the new section for the
container settings.

What if we added a help message below the command field like so, @air
https://github.com/air ?

[image: screen shot 2015-07-20 at 16 44 00]
https://cloud.githubusercontent.com/assets/1078545/8778543/d9c4b95c-2efe-11e5-9ef3-5f9e602867ef.png

—
Reply to this email directly or view it on GitHub
#950 (comment)
.

[pierluigi]

You can supply both, yes.

[philipnrmn]

As I understand it, it doesn't get overwritten by the run in the Dockerfile - it runs in addition.

[pierluigi]

@air what do you think of my suggestion?

[air]

I can't argue with the logic. As a small fix it is fine. I think however with some bigger changes we can have a better flow.

The user will be coming in with either 1. A docker image or 2. A shell command they want to run.

• They are roughly of equal importance. It's even possible docker is more widely used these days (subject to validation).
• Having both a docker image AND a shell command is an edge case (subject to validation).

In the screenshot above docker is a third-class citizen. The flow should expect that a user is coming in with either #1 or #2 above and help the user accordingly.

[air]

Maybe this is fixed in the new docker UI, but I don't have an easy way to see that. Is there a 'nightly' Marathon stood up anywhere - e.g. marathon-dev.mesosphere.com that we can use to test things like this?

[pierluigi]

Following today's discussion, here is what we are going to do to improve the current workflow:

• increase font size for collapsible section headers, remove “Show” / “Hide” portions of the strings
• invert optional / docker settings position
• add a new textarea “Docker Command” inside the Docker settings with an info text below that clarifies: "This will override the value in the Command field" ( @philipnrmn suggests that is the case anyway)
• decrease opacity to 50% on the "(–)" icon when editing the last remaining row of a duplicable set of values (disabled state)

[philipnrmn]

mesosphere/marathon-ui#162 only implements three of the four improvements in the comment above - simply adding a Docker command field really confused the modal, so I added the help text suggested above by @pierlo-upitup on the command field instead.

I'll leave this issue closed and suggest we continue discussion of docker-specific commands over on #2052