Arrangement of items in node summary screen could be improved

[Rod Smith]

The MAAS Web UI node summary screen presents useful information about nodes, but that information is scattered about in a somewhat chaotic way. I suggest a rearrangement of the information on that screen to keep related information together:

1. Place "Status," "Owner," and "Physical Zone" entries on the first row.
2. Place the "FQDN", "Network Interfaces," and "IP Addresses" items on the second row.

I'm attaching a screen shot of the node information screen as it exists now for one node, and a mock-up of what it might look like with these changes.

Note that if my recommendation in bug 1315072 to add information to the summary screen is followed, it should be placed logically within this scheme.

In addition, I'm not sure what the point is of the dashed underline under "FQDN;" it's not present on other headings, and doesn't seem to fill the same separating purpose of other dashed lines on this screen. (I haven't removed it from my mock-up, though.)

[Julian Edwards (julian-edwards)]

The page as it stands is rather dynamic as items appear and disappear as necessary. This is what makes it a bit of a dog's breakfast as things have been added over time.

I like your mock up, thank you for providing it. I am going to ask Raphaël to comment as he is more familar with the workings of this page than I.

[Raphaël Badin (rvb)]

> In addition, I'm not sure what the point is of the dashed underline under "FQDN;"

It's the usual way to signal that the underlined term is an acronym. When you hover over it, the "full" version of the acronym is displayed. I think it's quite useful.

[Raphaël Badin (rvb)]

Like Julian said, the problem with this page is that some of the things it displays are displayed only if the information is there (that's what happens for the IP addresses list for instance).

What you've done seems to me like like a step in the right direction but I would even go further and divide all the information into two categories: the blocks we display all the time (i.e. even if there is nothing to display —that information alone can sometimes be useful in itself) and the blocks that are displayed conditionally. Then,same as what you've done, I'd move all the blocks that are always displayed at the top of the page and put the rest at the bottom. This way, at least part of the display will be constant. What this means in practice is that we should remove some of the conditions; for instance the conditions governing the display of the "IP Addresses" block. This block will now be part of the "always displayed" blocks. It's an good example of where having an empty block is meaningful —I think— because when it's empty, it says pretty clearly: "This node doesn't have IP addresses attached to it *yet*."

[Rod Smith (rodsmith)]

Raphaël, I concur that a label associated with an empty field can be meaningful. Even better, instead of being empty, you could put in text like "not yet available" (or "N/A" if the field is very small) to make this meaning even more explicit.

Thanks for pointing out the meaning of the dashed underline under "FQDN." I suppose it's a little unclear because similar dashed lines are used elsewhere to separate sections of the layout, making the "FQDN" underline look like something that landed there by accident -- although as I look at it again, I see that the "FQDN" underline is darker than the others. Perhaps increasing the differentiation would help a bit. This is a minor point, though.

[Raphaël Badin (rvb)]

> Raphaël, I concur that a label associated with an empty field can be meaningful. Even better, instead of being empty,
> you could put in text like "not yet available" (or "N/A" if the field is very small) to make this meaning even more explicit.

Agreed. We can decide what the best "empty" message is on a case by case basis.

[Julian Edwards (julian-edwards)]

On 06/05/14 03:19, Raphaël Badin wrote:
>> Raphaël, I concur that a label associated with an empty field can be meaningful. Even better, instead of being empty,
>> you could put in text like "not yet available" (or "N/A" if the field is very small) to make this meaning even more explicit.
>
> Agreed. We can decide what the best "empty" message is on a case by
> case basis.
>

+1 from me too. UIs that morph around depending on context are often
frustrating to use.

[Blake Rouse (blake-rouse)]

The whole node details has been redesigned in 1.8.