Properties and States

24 Aug 2006 - 7:46am
7 years ago
5 replies
401 reads
Janna Cameron
2004

I have been trying to figure out why the radio buttons for published/draft
status in some blog applications seem wrong to me. (maybe they aren't)

I am thinking that this has to do with the difference between properties and
states of an object. I am thinking that states and properties should be
applied in different ways.

I have been looking for a good differentiating definition of states and
properties. What I think is that:

Properties - deal with a single aspect of an object. They should be set in
a property sheet or form.
States - affect the object as a whole - and should be applied to the object
as a whole - either in a view or as a submit action for a property sheet or
form.

I am not satisfied with this definition however - and am hoping that someone
out there has a much better one.

This would be tremendously helpful for creating clear guidelines about what
are "states" and how to set states of objects.

Janna

Comments

24 Aug 2006 - 10:46am
Michael Micheletti
2006

Hi Janna,

Properties need not be explicitly set in the interface. For instance, a blog
publishing application may have an Update Timestamp property that is set
behind the scenes whenever content is saved.

Application States are one of the more confusing design areas. There are at
least three different application states in effect at any one time in any
given piece of software:
- The state of the inner program code (when you say "state" to developers,
this is what they think of)
- The state of the software interface in the specification (what designers
think of as state)
- The state of the software interface in the user's brain (what your user
thinks the application state is)

State mismatch errors between these domains are the cause of much confusion.
As a designer, you try to create a design that helps your user's perception
of your program's state match what the interface actually looks like. When
you write a user interface spec for your developers, you try to help them
understand the interface states well enough that they can create matching
program states underneath. When you test the developed application, you keep
a careful eye out for state mismatch errors at any level.

Properties are, as you said, atomic values that may be explicitly set in a
form. Any of the state domains may have properties; to a user, the "On"
light being lit is a property. To a developer, a property may be a bit value
set when a low-level network message is received.

On 8/24/06, Janna Cameron <janna at alumni.uwaterloo.ca> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> I have been trying to figure out why the radio buttons for published/draft
> status in some blog applications seem wrong to me. (maybe they aren't)
>
> I have been looking for a good differentiating definition of states and
> properties. What I think is that:
>
> Properties - deal with a single aspect of an object. They should be set
> in
> a property sheet or form.
> States - affect the object as a whole - and should be applied to the
> object
> as a whole - either in a view or as a submit action for a property sheet
> or
> form.
>
> Janna
>
>

24 Aug 2006 - 11:08am
Juan Lanus
2005

State is the set of all "values" at a given point in time. As such,
state includes internal values, properties, and transient values as
for example is it's displayed and how.

Properties are a set of values that "persist", i.e. survive between
software runs.

This is object oriented parlance. Almost all programs or other
software pieces are created, or can be regarded as, objects.

When a program onject is not running it has "properties" and
"methods", the properties are values and the methods are the actions
the program can execute.
When the program is up and running then the state gets more complex
because it includes many transient values like, for example, a
variable holding the date and time. There are also transient values
related with the execution of running methods which I think are
irrelevant here.

Janna's view is right; properties are single values and state is "it all".
Radio buttons are an interface for the user to set the value of property.

Janna, if those radios confuse you on't blame yourself, by sure it'a a
design glitch. No mater if they are properties or what.
--
Juan Lanus
TECNOSOL
Argentina

24 Aug 2006 - 12:52pm
Janna Cameron
2004

Thank you for your help!

In my case I am particularly concerned about a checkbox on a properties
form that essentially says "make available". (This is applied to a blog
entry)

I was trying to figure out if "being available" is a state or a
property. I believe that this should effect whether it is applied
through an action or through the existing checkbox in a form.

It looks like the answer isn't as black and white as I would have hoped.

Janna

24 Aug 2006 - 11:46pm
Oleh Kovalchuke
2006

Jana wrote:
>I have been trying to figure out why the radio buttons for published/draft
>status in some blog applications seem wrong to me.
....
>In my case I am particularly concerned about a checkbox on a properties
>form that essentially says "make available". (This is applied to a blog
>entry)
>
>I was trying to figure out if "being available" is a state or a
>property. I believe that this should effect whether it is applied
>through an action or through the existing checkbox in a form.

I think you describe another case of mode button related to the recent
discussion of Play/Pause toggle.

In the case you have described, blog entry status ("state", "mode",
"property") and action to change the status are combined in one checkbox,
hence are confusing (the alternative to "make available" is not obvious).

Raskin describes similar example in The Humane Interface and recommends
using a pair of radiobuttons instead of one check box. That would work, but,
personally, I would prefer to separate status indicator ("Draft" label, for
instance) and action button ("Publish").

--
Oleh Kovalchuke
Interaction Design is Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On 8/24/06, Janna Cameron <janna.cameron at desire2learn.com> wrote:
>
> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
>
> Thank you for your help!
>
> In my case I am particularly concerned about a checkbox on a properties
> form that essentially says "make available". (This is applied to a blog
> entry)
>
> I was trying to figure out if "being available" is a state or a
> property. I believe that this should effect whether it is applied
> through an action or through the existing checkbox in a form.
>
> It looks like the answer isn't as black and white as I would have hoped.
>
>
> Janna
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://listguide.ixda.org/
> List Help .................. http://listhelp.ixda.org/
> (Un)Subscription Options ... http://subscription-options.ixda.org/
> Announcements List ......... http://subscribe-announce.ixda.org/
> Questions .................. lists at ixda.org
> Home ....................... http://ixda.org/
> Resource Library ........... http://resources.ixda.org
>

25 Aug 2006 - 10:12am
Oleh Kovalchuke
2006

Related thought.

"Publish" is probably the single most important and frequently used action
in a blog ("Unpublish" could be more important, occasionally). It should be
accessible via visible button, not hidden in an obscure checkbox in
properties form.

--

Oleh Kovalchuke

Interaction Design is Design of Time

http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

On 8/24/06, Oleh Kovalchuke <tangospring at gmail.com> wrote:
>
> Jana wrote:
> >I have been trying to figure out why the radio buttons for
> published/draft
> >status in some blog applications seem wrong to me.
> ....
> >In my case I am particularly concerned about a checkbox on a properties
> >form that essentially says "make available". (This is applied to a blog
> >entry)
> >
> >I was trying to figure out if "being available" is a state or a
> >property. I believe that this should effect whether it is applied
> >through an action or through the existing checkbox in a form.
>
> I think you describe another case of mode button related to the recent
> discussion of Play/Pause toggle.
>
> In the case you have described, blog entry status ("state", "mode",
> "property") and action to change the status are combined in one checkbox,
> hence are confusing (the alternative to "make available" is not obvious).
>
> Raskin describes similar example in The Humane Interface and recommends
> using a pair of radiobuttons instead of one check box. That would work, but,
> personally, I would prefer to separate status indicator ("Draft" label, for
> instance) and action button ("Publish").
>
> --
>
> Oleh Kovalchuke
> Interaction Design is Design of Time
> http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm
>
> On 8/24/06, Janna Cameron <janna.cameron at desire2learn.com > wrote:
> >
> > [Please voluntarily trim replies to include only relevant quoted
> > material.]
> >
> >
> > Thank you for your help!
> >
> > In my case I am particularly concerned about a checkbox on a properties
> > form that essentially says "make available". (This is applied to a blog
> > entry)
> >
> > I was trying to figure out if "being available" is a state or a
> > property. I believe that this should effect whether it is applied
> > through an action or through the existing checkbox in a form.
> >
> > It looks like the answer isn't as black and white as I would have hoped.
> >
> >
> > Janna
> > ________________________________________________________________
> > Welcome to the Interaction Design Association (IxDA)!
> > To post to this list ....... discuss at ixda.org
> > List Guidelines ............ http://listguide.ixda.org/
> > List Help .................. http://listhelp.ixda.org/
> > (Un)Subscription Options ... http://subscription-options.ixda.org/
> > Announcements List ......... http://subscribe-announce.ixda.org/
> > Questions .................. lists at ixda.org
> > Home ....................... http://ixda.org/
> > Resource Library ........... http://resources.ixda.org
> >
>
>
>
>

--
Oleh Kovalchuke
Interaction Design is Design of Time
http://www.tangospring.com/IxDtopicWhatIsInteractionDesign.htm

Syndicate content Get the feed