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

Jirka Tomasek jtomasek at redhat.com
Mon Jul 23 16:18:38 UTC 2012


On 07/23/2012 05:20 PM, Matt Wagner wrote:
> 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
I have sent a few related patches to the list. Discussion/reviews are 
welcome:)

Jirka



More information about the aeolus-devel mailing list