Design question abt how to handle an abundance of properties.

  • Thread starter Thread starter Tom P.
  • Start date Start date
T

Tom P.

This is a design question: I have a customized ListView with three
columns Name, Size, and Date.

I am painting each of these with a LinearGradientBrush so each of them
has a Color1, Color2, and Direction.

There is also a different color for Files and Directories and those
colors can change when the mouse passes over and/or when the item is
selected by the user.

This leads to an inordinate amount of Properties:
PlainDirNameColor1, PlainDirNameColor2, PlainDirNameDirection,
MouseOverDirNameColor1, MouseOverDirNameColor2,
MouseOverDirNameDirection,
SelectedDirNameColor1, SelectedDirNameColor2,
SelectedDirNameDirection,
SelectedMouseOverDirNameColor1, SelectedMouseOverDirNameColor2,
SelectedMouseOverDirNameDirection... etc.

And that's just the Directory Name properties!
3*3*2*4 = 72 properties just to pain the darn thing.

I'm looking for design suggestions for how to deal with this abundance
of properties.

What would you suggest?
Thanks for the help,
Tom P.
 
[...]
I'm looking for design suggestions for how to deal with this abundance
of properties.
Click to expand...
What would you suggest?
Click to expand...

Sounds like you need to encapsulate a group of properties as a new class, 
and then set that as an instance of the new class rather than as separate 
properties.

There is, of course, the separate question as to whether this is really a 
reasonable UI to present to the user.  But you didn't ask about that.  :)

Pete
Click to expand...

It honestly doesn't look as bad as you might think (always assuming
the user doesn't pick 72 contrasting colors, blech).

I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Tom P.
 
[...]
I'm looking for design suggestions for how to deal with this abundance
of properties.
Click to expand...
What would you suggest?
Click to expand...

Sounds like you need to encapsulate a group of properties as a new class, 
and then set that as an instance of the new class rather than as separate 
properties.

There is, of course, the separate question as to whether this is really a 
reasonable UI to present to the user.  But you didn't ask about that.  :)

Pete
Click to expand...

It honestly doesn't look as bad as you might think (always assuming
the user doesn't pick 72 contrasting colors, blech).

I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Tom P.
 
This is a design question: I have a customized ListView with three
columns Name, Size, and Date.

I am painting each of these with a LinearGradientBrush so each of them
has a Color1, Color2, and Direction.

There is also a different color for Files and Directories and those
colors can change when the mouse passes over and/or when the item is
selected by the user.

This leads to an inordinate amount of Properties:
PlainDirNameColor1, PlainDirNameColor2, PlainDirNameDirection,
MouseOverDirNameColor1, MouseOverDirNameColor2,
MouseOverDirNameDirection,
SelectedDirNameColor1, SelectedDirNameColor2,
SelectedDirNameDirection,
SelectedMouseOverDirNameColor1, SelectedMouseOverDirNameColor2,
SelectedMouseOverDirNameDirection... etc.

And that's just the Directory Name properties!
3*3*2*4 = 72 properties just to pain the darn thing.

I'm looking for design suggestions for how to deal with this abundance
of properties.

What would you suggest?
Thanks for the help,
Tom P.
Click to expand...

Hi,

You can have one class with three properties, color1, color2,
direction, and then create several instances (selected, mouseover, etc)
 
This is a design question: I have a customized ListView with three
columns Name, Size, and Date.

I am painting each of these with a LinearGradientBrush so each of them
has a Color1, Color2, and Direction.

There is also a different color for Files and Directories and those
colors can change when the mouse passes over and/or when the item is
selected by the user.

This leads to an inordinate amount of Properties:
PlainDirNameColor1, PlainDirNameColor2, PlainDirNameDirection,
MouseOverDirNameColor1, MouseOverDirNameColor2,
MouseOverDirNameDirection,
SelectedDirNameColor1, SelectedDirNameColor2,
SelectedDirNameDirection,
SelectedMouseOverDirNameColor1, SelectedMouseOverDirNameColor2,
SelectedMouseOverDirNameDirection... etc.

And that's just the Directory Name properties!
3*3*2*4 = 72 properties just to pain the darn thing.

I'm looking for design suggestions for how to deal with this abundance
of properties.

What would you suggest?
Thanks for the help,
Tom P.
Click to expand...

Hi,

You can have one class with three properties, color1, color2,
direction, and then create several instances (selected, mouseover, etc)
 
[...]
I'm looking for design suggestions for how to deal with this abundance
of properties.
What would you suggest?
Click to expand...
Click to expand...
Sounds like you need to encapsulate a group of properties as a new class,  
and then set that as an instance of the new class rather than as separate  
properties.
Click to expand...
There is, of course, the separate question as to whether this is reallya  
reasonable UI to present to the user.  But you didn't ask about that. :)
Click to expand...
Pete
Click to expand...

It honestly doesn't look as bad as you might think (always assuming
the user doesn't pick 72 contrasting colors, blech).

I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Tom
Click to expand...

I will place them there.
If otherwise I will inherit from ListView and create the properties
for the control itself; This has the advantage that if you have more
than one of a type of column you have to specify it only once.
 
[...]
I'm looking for design suggestions for how to deal with this abundance
of properties.
What would you suggest?
Click to expand...
Click to expand...
Sounds like you need to encapsulate a group of properties as a new class,  
and then set that as an instance of the new class rather than as separate  
properties.
Click to expand...
There is, of course, the separate question as to whether this is reallya  
reasonable UI to present to the user.  But you didn't ask about that. :)
Click to expand...
Pete
Click to expand...

It honestly doesn't look as bad as you might think (always assuming
the user doesn't pick 72 contrasting colors, blech).

I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.

Where do these belong? It's a purely design decision

Tom
Click to expand...

I will place them there.
If otherwise I will inherit from ListView and create the properties
for the control itself; This has the advantage that if you have more
than one of a type of column you have to specify it only once.
 
I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.
Click to expand...

If there's a lot of customization going on that affect each "ColumnHeader"
(many properties or whatever) then creating a new derivative is the way to
go. It's cleaner and you'll have a much easier time supporting things in the
long run.
 
I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.
Click to expand...

If there's a lot of customization going on that affect each "ColumnHeader"
(many properties or whatever) then creating a new derivative is the way to
go. It's cleaner and you'll have a much easier time supporting things in the
long run.
 
[...]
I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.
Click to expand...
Where do these belong? It's a purely design decision
Click to expand...

Only you can answer that question.  My only insight so far is that you can
put the three values into a single class, since they are related and
always used together.

I have the impression that you are using the settings for the column
itself, not the header, so it's a bit awkward to store them as part of the
header.  On the other hand, ListView doesn't really offer a per-column
data structure other than the header, and so storing the settings in the
ListView itself would require extra overhead/management to deal with the
possibility of rearranging the columns.  At the very least, you'd probably
wind up with a Dictionary<ColumnHeader, ColumnSettingsClass> (where
"ColumnSettingsClass" is this hypothetical data structure to store the
settings).
Click to expand...

You have hit the nail on the head! The settings are not going to be
for the ColumnHeader (well, there are settings for them but there are
settings for the file and directory items too). If I store them in the
ColumnHeader it's just inappropriate.
I find either approach imperfect, and continue to be distracted by the
seeming inappropriateness of the formatting in the first place.

Pete
Click to expand...

No offense but, there are several industries that make quite a good
living off "inappropriateness".

In practice it's not really as bad as you might think. It's just a
gradient filled box which makes fro an easier presentation on the
eyes. There's a set of 3 properties for the Name, Date, and Size
columns (9). Then there's 4 states "Plain", "Selected", "MouseOver",
and "MouseOver Selected" (36) There is the obvious difference between
Files and directories, so that's one set for each (72). It's not like
you see all 72 on screen at one time, overlapping. But, again, it's
really up to the user how it looks.

Thanks guys, I'll take a look at a couple of these and then resign
myself to not have a perfect design. I'll just have to keep trying.

Tom P.
 
[...]
I was wondering if I should extend the ColumnHeader object and store
them in there or just have a property-only class that is a property of
the FileSystemListView.
Click to expand...
Where do these belong? It's a purely design decision
Click to expand...

Only you can answer that question.  My only insight so far is that you can
put the three values into a single class, since they are related and
always used together.

I have the impression that you are using the settings for the column
itself, not the header, so it's a bit awkward to store them as part of the
header.  On the other hand, ListView doesn't really offer a per-column
data structure other than the header, and so storing the settings in the
ListView itself would require extra overhead/management to deal with the
possibility of rearranging the columns.  At the very least, you'd probably
wind up with a Dictionary<ColumnHeader, ColumnSettingsClass> (where
"ColumnSettingsClass" is this hypothetical data structure to store the
settings).
Click to expand...

You have hit the nail on the head! The settings are not going to be
for the ColumnHeader (well, there are settings for them but there are
settings for the file and directory items too). If I store them in the
ColumnHeader it's just inappropriate.
I find either approach imperfect, and continue to be distracted by the
seeming inappropriateness of the formatting in the first place.

Pete
Click to expand...

No offense but, there are several industries that make quite a good
living off "inappropriateness".

In practice it's not really as bad as you might think. It's just a
gradient filled box which makes fro an easier presentation on the
eyes. There's a set of 3 properties for the Name, Date, and Size
columns (9). Then there's 4 states "Plain", "Selected", "MouseOver",
and "MouseOver Selected" (36) There is the obvious difference between
Files and directories, so that's one set for each (72). It's not like
you see all 72 on screen at one time, overlapping. But, again, it's
really up to the user how it looks.

Thanks guys, I'll take a look at a couple of these and then resign
myself to not have a perfect design. I'll just have to keep trying.

Tom P.
 
Back
Top