I pretty much agree with Peter's assessment, so I'll just make a couple directed comments.
sowmini.varadhan at sun.com wrote: > On (11/06/07 15:53), Raoul Carag wrote: > >>> On the second screen, what happens if you edit something >>> that's connected to another link (such as part of an >>> aggregation)? Do you get an indication that you're >>> manipulating part of a larger object? > > As Raoul mentioned, this GUI is a piece of the larger NWAM gui, > and as you point out, the eventual idea is to allow administration > of both aggr properties as well as the properties of the component > links. Ah, good. A disconnect would be bad. >>> On the 3rd screen, I'm confused. Wouldn't it be better >>> to have the current state displayed separately? And then >>> have the other lines in the table without the State column? >>> What's the difference between capabilities and advertised? > > The capabilities are the hardware capabilities supported by the local > endpoint. The administrator may choose to advertise (or not) any > subset of the capabilities. For example, in the screen, the > endpoint can support 1 Gbps full duplex, 1 Gbps half duplex, > 100 Mbps full duplex, 100 Mbps half duplex etc. but only > 1 Gbps is advertised. Hmm. What exactly is meant by "advertise"? I think I know what you're getting at, but the term and context are a little vague for newcomers. (And if my guess is wrong, it's even too vague/confusing for old hands.) >>> (I think what I'm asking is whether this display is meant to >>> indicate that 100M and 10M have been disabled?) > > yes. Again, this is unclear. >>> I'm not too keen on the Properties settings screens. >>> For example, on the first one autonegotiation should >>> be a checkbox not a radio button. But I think I would >>> prefer the properties as a table with the value column >>> being editable (either a checkbox, or an editable >>> drop-down list). At least then you get to see all the >>> values straight away - it's very frustrating to have >>> to click down a list just to see the values (and worse, >>> you have to remember what the other values were). >>> >> For the Properties Setting tab, we actually started with drop down >> lists, but then switched to radio buttons, thinking that having all the >> options for each property on display would be more helpful for the >> administrator to make the selection. Your comments in this regard are >> valuable because they are coming from real scenarios - so we'll take >> them into account. >> >> The GUI designer and the rest of the team can chime in on this, too. > > I'll let Jenya comment on this one.. I think the deciding factor > here was "speed and duplex", as that determined the interface for > the other properties. I'll wait for Jenya's comments, then. I also think having to select the various properties in turn, and not being able to see the values of the others, would be very tedious. This is perhaps the most awkward piece of the whole GUI as presented here. Rainer -- Mind the gap.
