With Diskovery coming together, I wanted to take a moment and show what a UI sketching process for an app looks like.

In a vast majority of cases native UI controls (widgets) work just fine. There's really no point in re-skinning, say, a button unless, of course, your goal is to make it stick out like a sore thumb.

There are however cases when the app needs to display information in a way that is not natively supported by the OS. In other cases, while it might be possible to render the data with a native control, it won't do it well or the result won't look good.

In these cases you have no option but to go with a custom UI, but, luckily, if you start with a need (rather than a quest for bells and whistles) the process is fairly predictable and logical.

Diskovery deals with displaying the bits and pieces of the computer storage stack - from physical drives, to parititions, to volumes, to logical drives and mount points.

These fall naturally into a hierarchy, with each level comprising a list of key-value(s) pairs.

So taking the first stab at the UI, we would quickly arrive at something like this: Primary list of drives and volumes on the left, with details of a selected item on the right, organized into a tree of "key:value" entries.

This is functional, but the right pane is not exactly easy to follow. So the first change will be to tabulate the key-value pairs:
Next, note that items in bold act like section headers, so they don't really need to be collapsible. So we do away with the buttons and connecting lines between top-level items:
This gets us a bit of extra horizontal space and trims a useless, but still actionable UI element.

Next, a couple of tweaks to how we render selected items.

There's no need for any items on the right to be selectable at all, so we won't render a selection highlight in the right pane.

The left pane can use a less jarring selection style, consistent with how Windows itself does it.
Next, we try and improve readability of the data on the right by helping to guide the eye from a key to its value.

The simplest option is the grid lines:
At this point, we take a sip of our cold coffee, squint an eye and assess if we like how it looks.

It's not bad, but we can try something else:
Now, that's not bad either and it has a nice visual consistency with the selection bar in the left pane.

However a minor nit here is that we now have bold items (section headers) paired randomly with row highlights. See how Storage space is on white and Partition table is on light gray?

Moreover, adding or expanding items will cause this pairing to flip-flop, e.g. we add an extra row about Partition table and it now sits on the white background:
That's not a disaster, but we can do better.

The idea is to recognize section headers as such and style them independently:
With this change in place we can just restart the row highlight sequence at the top of each section and all's good.

Next, we apply the same styling to the left pane as it happens to also comprise of sections:
Another sip of coffee, re-squint the eye and the whole thing now looks a bit cluttered and busy.

Easy enough to rectify by adding a bit of vertical padding:
Next, we remove vertical connecting lines leading from section headers to the top-level items.

However, we remove them on the right, but keep them on the left. This is because on the left we have a hierarchy of devices, so connection lines make sense. It also seems to look better this way.
Next, we move the expand/collapse buttons to the right.

In this particular app expandable items contain secondary details that 99% of users will not ever need. These items will also be collapsed by default (even though they are expanded here, but that's just because we are sketching through the details).

This change also helps decreasing the leading pad of top-level items and providing for a more compact horizontal packing of the data.
Alright, so that's about it as far as functional tweaks go. So now it's where it gets subjective. We are going to spruce it up a bit.

It's all about colors, padding and little nuances. If we were designing for the web, it would also involve texturing, but for a desktop app texturing is a sure way to ruin native look and feel.

In any case, moving on - invert the headers from dark-on-light to light-on-dark:
Add a bit of hue to the row highlights, tint their edges a bit and also flatten the look of expand/collapse buttons:
Splice in a scroll bar and make sure our precious design still looks reasonable:
Re-style the left pane to look more like an actual connected hierarchy of disks and volumes. The rationale here is to make it more obvious that items on the left are clickable.
Almost there. Take a final look and adjust vertical padding and spacing to de-clump items a bit more: And here it is. Compare to the starting point and you'd probably agree that there's at least some improvement.

Needless to say, one man's extra vertical padding is another man's complete waste of space, but any customization is always a combination of rational and subjective choices. The former is what gives an app the ease of use and the latter is what give it the personality. Can't have one without the other.