RFC UI annoyances - "quick fixes" and "require design work"

Matt Wagner matt.wagner at redhat.com
Mon Jul 23 15:20:49 UTC 2012


On Wed, Jul 18, 2012 at 02:20:00PM +0200, Jirka Tomasek wrote:
> On 07/17/2012 05:41 PM, Jaromír Coufal wrote:
> >On 17.7.2012 17:09, Jirka Tomasek wrote:
> >>* "Launch with errors" makes it sound like it will cause errors
> >>on purpose
> >> - maybe rewording to something like: "Ignore errors during
> >>launch" would do be enough?
> >I would like to ask: If error happens, will be user somehow
> >informed what happened?
> >    "Ignore errors during launch."... as Jirka wrote or
> >    "Keep launching even if errors occur (inform me)."
> By default the launch of instance is terminated if error occurs and
> appropriate error message is displayed. If the checkbox is checked,
> the deployment will go through ignoring errors during instances
> launch and finish lauching the deployment even with some Instances
> failing. The user can review the instances state in deployment detail
> as usual. So "Ignore Instance errors during launch" is apropriate I
> think. I will take note to discuss this with Jan next week when he
> comes back.

I do think that the word "Ignore" makes it sound like the errors are
sent to /dev/null and not even displayed to the user. To add to the
brainstorming of terms, maybe something like, "Continue launch if some
instances fail"?

> >>* /pool_families uses both "Environments" and "Pool Families"
> >>terminology (DISCUSS)
> >> - I would prefer the Pool Families here to be keep it the same
> >>as model name but I am not really sure on this one. Any
> >>recommendations?
> >Honestly I have more notes to the dictionary. Some of them will
> >also be connected with workflows. So my question is if we can
> >postpone this discussion later on till I get through the whole UI
> >and start working on workflows? I don't think it needs a fix right
> >away so I just wanted to save our times not to do this twice (if it
> >will be necessary). Of course if everybody agrees.
> 
> Based on our talk today, I will change the Environments to Pool
> Families as it seems not to be consuming task to do.
> I think the Environments/Pool Families confusion came from the
> administer menu item "Environments" that first included just Pool
> Families tab but originally should include also other sections (like
> Images that it includes now also). So If no objections, I will leave
> the Environments menu item the same but change it at places where it
> references Pool Family.

It sounds like in subsequent discussions like this is more complicated
than we thought at the time. I'm fine with leaving it for now, but I
also don't know that we should let PM's requirements shape what we call
things upstream, since we're already doing something different. My
objection isn't necessarily that one is better than the other (though I
do prefer "Environment"), but more that we're using two different terms
interchangeably.

> The same confusion is propably coming up with Content/Catalogs
> relationship that Brian points at in previous email.
> >>
> >>* "Xml Deployable XML file doesn't resolve valid XML" is the
> >>worst error ever
> >>** it is {confusingly, awkwardly, poorly} worded and uses the
> >>word "XML" three times in one sentence
> >>** it doesn't actually indicate what's wrong with the XML -- we
> >>might as well just say "Your XML is no good! Try again!"
> >> - change the validation message to more reasonable one and
> >>include the link to edit deployable xml?
> >When does this message appear? During creation of new deployable?
> >If yes, user is supposed to edit the XML file anyway, because
> >without it he is not able to create new deployable, right?
> >Then make it easier for him and display him edit form for XML right
> >away (of course with some reasonable error message). This will
> >prevent him from one more click which he will have to do anyway.
> I checked the code and the only time this message pops up is when
> editing the deployable xml, so the user is already in place he wants
> to be. So rewording the message should be enough here. Also this
> message alone pops up just in a few special occasions, mostly the
> message is displayed together with description of the exact XML
> syntax error.

I've actually never seen this message next to a helpful description of
the syntax error. I'm going from memory, so I may be wrong, but I seem
to recall seeing it in isolation. At best, it was displayed next to a
totally unhelpful message about syntax. That is probably more a
limitation of the parser we're using.

> >>I would like to start implementing the quick fixes by tomorrow.

Having just come back from vacation, I'm excited to see some of these
already marked as fixed! I think shoring up these little "papercuts"
will make using Aeolus a much more pleasant experience!

-- Matt



More information about the aeolus-devel mailing list