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

Jirka Tomasek jtomasek at redhat.com
Wed Jul 18 12:20:00 UTC 2012


On 07/17/2012 05:41 PM, Jaromír Coufal wrote:
> On 17.7.2012 17:09, Jirka Tomasek wrote:
>> Hi all,
> Hi :)
>>
>> so I went through UI Annoyances wikipage and divided the issues 
>> between those that require design work to resolve and those that can 
>> be fixed without design intervention.
>>
>> The list of UI Annoyances is here: 
>> https://www.aeolusproject.org/redmine/projects/aeolus/wiki/List_of_UI_Annoyances
>>
>> Most of the quickfixes are straightforward.The fixes which I think 
>> might require some discussion are listed below. Feel free to comment 
>> on any of the issues from the list or add the new ones you bump into.
>>
>> * "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.
>>
>> * /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.

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 would like to start implementing the quick fixes by tomorrow.
>>
>> Jirka
>>
>
> Jarda
>

Jirka

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/aeolus-devel/attachments/20120718/59bcb094/attachment.html>


More information about the aeolus-devel mailing list