stevencl's WebLog : API Usability

API usability evaluation

stevencl — Fri, 06 May 2005 00:53:00 GMT

Christopher Oezbek is keeping notes about an API usability evaluation he is doing using the cognitive dimensions.

HOWTO: Run an API usability study

stevencl — Thu, 05 May 2005 20:31:00 GMT

With the task list in place and participants recruited, it's time to run the study. My experience has been that running an API usability study is really no different from running any other type of study. Here's a description of what I do.

The day before the study I make sure that the machines I'll be using in the usability lab are set up. I install the necessary builds of Visual Studio and associated SDKs etc to be able to run the study. I always do this first thing in the morning just in case anything goes wrong as setting the machines up properly can be quite time consuming. Once that is done, I then go about setting up the screen capture software so that I have video recordings of each participant's session in the lab.

While our usability labs are well equipped with audio and video recording equipment, I prefer to use HyperCam for screen recording since the quality is decent and the format (AVI) makes it easy for me to create video clips to show highlights from each session. Running HyperCam and VisualStudio on the same machine can sometimes cause the machine to slow down pretty significantly though, so I run HyperCam on one machine and then use remote desktop from that machine to connect to the machine running Visual Studio. Setting up HyperCam, including setting up the PC microphone so that the recording level is just right usually takes no more than 10 or 15 minutes.

Our usability labs are split between the participant side and the observer side. After setting up the participant side of the room, I set the machine up on the observer side. We have in-house tools that we use to record our observations during each session. The tools allow us to create a simple tagging scheme that we use to tag our observations as we take them so that afterwards we can easily refer to all events that involved use of the ServiceContract attribute for example, or events that were particular highlights for whatever reason. I take some time to think about how I might want to analyze the observations after all the sessions and set the tools up to use the particular tagging 'schema' that I come up with. Sometimes the schema is as simple as three tags labeled 'Highlight', 'Success' and 'Failure' but other times it will be more complex. It all depends on the nature of the study.

Lastly, I print out the task list and a copy of the tutorial materials that were sent to participants, just in case participants forget to bring their own copy in. I always leave printing the task list to last as invariably I'll make small changes to the task list right up the last minute.

After all this setup, all that is left is to run each participant's session.

The first time each participant comes into the lab I spend some time getting them familiar with the lab. It can be quite disconcerting to be sitting in a lab knowing that people are watching you behind a one way mirror so I reassure participants that the purpose of the study is to learn how usable the API is, not to test each participant that comes into the lab. I also give some participants time to practice talking out loud while they work. We always ask participants to provide us with a running commentary of what they are doing as they are working as that is the best way to get at the intent behind the actions that they take. However it can feel a little odd to talk so much while working since it's not something that most people are used to doing. So for participants who have not been in the lab before, I will sometimes ask them to do some task (such as using Paint to draw a picture of a mouse) and ask them to talk out loud while they are working. Many participants find that after just a few minutes of practice that it's actually not that difficult to keep talking while working.

Then participants start working on the tasks. While they work on each task, I try to take as many notes about what they are doing as I can. I typically try to record a transcript of everything they say as they are working. When something interesting happens, I'll make sure to annotate my notes accordingly so that I can easily refer back to that event (our note taking software timestamps each note that I take so that I can associate a note with a point in time on the video recording of the session). Paying attention to what is going on and taking good notes can be very tiring but it's critical, especially if you don't want to be spending hours reviewing video tapes and other logs afterwards. Time and effort spent here pays off in the long run.

Probably the most important thing to be aware of when running a usability session is the impact that anything you say to the participant has on their behavior. The most obvious way in which you influence the behavior of the participant is in how you describe the task you ask them to perform. If you mention the specific classes, namespaces, methods etc that you want them to use, then you've led them down a path that they might not necessarily have taken had you not mentioned it. But during the study there are other less obvious ways that you can inadvertently influence participants. Very often, participants will get stuck with a task and might get a little frustrated. They'll ask for your help and the natural inclination is to offer some help, particularly if they are very frustrated. You can simply tell them how to get unstuck, but that doesn't really provide you with useful data about why they got stuck and how they expected to be able to fix the problem themselves. All you know is that when told to do the right thing, they were able to do it. Instead, you should see this as an opportunity to understand what it is about the design of the API that leads participants to get stuck.

These sort of situations are where the benefits of running a usability study really become apparent. As soon as a participant gets stuck on some task, they are in the best position to describe how and why they are stuck because they are literally going through the experience right there and then in front of you. They don't have to rely on their memory to tell you what happened, as they would if you simply interviewed somebody about their use of an API after they were done using it. They are motivated to explain things to you because that will help them recover the situation, unlike if you were asking them to describe the situation after the event.

Whenever participants ask me questions when they are stuck, I'll very often not tell them anything and will instead ask them to describe what they think is happening and how they expect the API to work. With that information I'm able to start forming hypotheses about the conceptual model that participants are forming while working with the API and how that leads to breakdowns in using the API. I can then start testing these hypotheses by asking participants to provide feedback about the way that these conceptual models are formed. I don't ask them to comment explicitly on their conceptual model but instead I'll ask them about salient aspects of the API that I think might lead to a particular model being formed. These are the points in a usability study during which I learn the most from participants.

Outside of these situations I try to say very little during the session. For example, to begin with, lots of participants ask me when they should move on to the next task. I try never to answer these questions, telling participants that they should move on to the next task when they think they are done with a task. I don't want participants to get used to my confirmation that they have done the right thing. If I keep telling participants that they are doing the right thing, participants tend to do something then wait to hear my confirmation before moving on. Instead of using their own intuition to figure out if they have done the right thing, they simply wait for an acknowledgement from me. At that point the data I'm getting is questionable.

The key criteria for success in running a usability study are: good observation and note taking skills, and the ability to understand observed behavior from the participant's perspective, instead of your own. You'll notice that running a successful study does not depend on having expensive usability labs. They're definitely nice to have, but not necessary.

HOWTO: Design and run an API usability study

stevencl — Tue, 29 Mar 2005 19:26:00 GMT

A few people have asked me about how I design and run API usability studies. I'm running an Indigo study this week so I thought I would describe the steps that went into setting this study up.

The study is a follow up to the Indigo study we ran in October and which identified a number of usability issues, the biggest of which was the extensive use of attributes. Since then, the team redesigned parts of the API and were keen to get fresh usability data on the new design to see if the problems were resolved. To get the new study kicked off, I met with Steve Swartz (one of the Indigo architects) and David Palmann (a program manager on the Indigo team responsible for usability) in December 2004 so that they could describe the design changes to me.

We discussed the earliest date that we could run the follow up study. The implementation of the new API design wouldn't be complete until some time in February and then with the necessary testing that needs to take place, it looked likely that the earliest a stable build would be available wouldn't be until some time in March. We tentatively scheduled early March to run the study.

One of the first trade-offs to make in setting up a study is deciding when to do it. You need to make sure that you run the study with a version of the API that looks pretty much the way that the team have designed it but you don't want to wait until the API is completely implemented and tested since there probably won't be much time to respond to any changes suggested by the usability study. We thought that we would be able to secure a reasonable build of the new Indigo API by early March which would still give the team enough time to respond to any usability issues.

With a rough timeframe in mind, I drafted out a plan for the work that I would need to do to prepare and run the study. Typically the very first thing that I like to do is to get hold of a build of the API such that I can spend some time coding against the API to get a feel for the API and to identify any potential usability problems in the API. This build needn't be the exact same build that I will use in the study itself, just something that I can get up and running and playing with. At this point in time (late December), a build wasn't yet available so I had to put off being able to play with the API until some time later in January.

This would leave me with at most four weeks to play with the API and prepare the study if we were to run the study in early March. Normally this would concern me since one risk is that once I start playing with the API, I discover that it is pretty complex and that preparing the study materials is likely to take a significant amount of time. Since I am typically running/designing more than one study at a time it can be quite difficult to find the time to prepare the materials for a complex API when there are other studies going on.

In this case though I wasn't worried since I already had materials ready from the October study. I just needed to update those materials based on the new changes. The study materials that need to be prepared are basically an API introduction document that each participant gets before they come into the lab and the task list that participants work on when they are in the lab. The API introduction is a very important document - it gives participants enough of an intro to the API so that when they come in to the lab they have some idea of what to expect and what they will be working on. However, the intro needs to be tuned to the needs of the study. It's important that the intro gives participants enough information that they feel comfortable working on a task in the usability lab, but not so much that we just tell them what to do. Very often I end up writing this document myself from scratch based on my experiences using the API for a few weeks. I try to look back on my experiences using the API and try to document answers to questions that I had while getting to grips with the API. Quite often these will be things that I needed help from the API team to figure out.

We try to send the intro document to participants at least a week before they come into the lab so if I wanted to run the study in early March., I really needed to have a draft of the document complete by mid February so that it could be reviewed before being delivered to participants. I was able to reuse the document that was sent to participants for the October study and edit this to reflect the new API. In late January I spent an hour with Steve Swartz making changes to the original document.

At this point I still hadn't used the new API myself. I found that when I was working on the changes to the tutorial document that Steve had suggested there were still some niggling questions that remained which would have been easily answered had I been able to use the API and explore for myself. So I waited until a reasonably stable build was available for me to play with. In mid-February David was able to provide me with a Virtual PC image containing a build of the API that I could use. This helped me complete the edits to the intro doc so that it reflected the new API.

Around the same time, other projects I was working on required some attention. There were UI reviews for Visual Studio Team System and Joey Lawrance had just started his internship with us. He and I were working on a pretty big study that was to take place throughout February and this took higher priority. This meant that our original plan of running the study in early March wasn't feasible so we had to postpone the study for a couple of weeks. But I had a build of the API now so I could get at least think about getting started on the task list.

In my next posting I'll talk about how I go about designing tasks for an API usability study.

API usability talk available on MSDN from tomorrow

stevencl — Fri, 18 Feb 2005 00:30:00 GMT

The API usability portion of the Designing .NET Class Libraries class will be available from tomorrow. Apologies in advance if my Scottish accent makes it difficult to understand me! Let me know if there is anything that I need to translate...

Feedback on Avalon CTP?

stevencl — Fri, 28 Jan 2005 17:20:00 GMT

If you've downloaded and played around with the Avalon CTP release would you be willing to share some of your feedback? I'd love to hear what you think of the usability of the Avalon APIs.

Attributes and API usability (again!)

stevencl — Fri, 08 Oct 2004 15:52:00 GMT

I've been running another usability study on an API that makes heavy use of attributes and have made similar observations to a previous study (see http://weblogs.asp.net/stevencl/archive/2004/05/12/130826.aspx#FeedBack)

This time we've been looking at the Indigo APIs. Indigo makes heavy use of attributes throughout. For example, attributes are used to identify an interface as representing a service contract or a method inside that interface as a service operation.

In this study, we've observed similar issues to those observed before. One of the issues that has resurfaced is the apparent reluctance of participants to consider the attributes sprinkled throughout their code as potential causes of unexpected application behavior. As in the previous study, we've seen developers consistently neglecting to consider modifying any of the attributes that they have applied to their code when attempting to modify the behavior of their code. In many cases, the desired effect (changing the lifetime of a service for example) is done by simply changing a property of a particular attribute. But instead, many participants spend time investigating their own code and even changing their own code to try to achieve the change in behavior they are looking for. It seems too that this behavior isn't necessarily isolated to the usability labs. One of the Indigo team members told me of a recent example where some folks from the product team were attempting to debug some customer code. They spent a lot of time checking the IIS configuration, the customer code etc and overlooked the attributes in the code. It turned out that the wrong attribute had been used.

I think one factor in this is the low visibility of attributes. For example, one participant in the study this week was stepping through his code in the debugger when he noticed some unexpected behavior at some point during the excecution of his code. He was focused on a particular block of code and concentrated his efforts on understanding how that block of code might have caused the behavior he had just observed. The cause for that behavior was due to an attribute that had been applied to the class that defined the method the participant was stepping through. Thus when he was reading his code, the attribute was well out of his focus of attention.

However, such issues are typically an issue for the first few times only - once you learn the effect of an attribute, it's more likely that you'll remember that attribute and will revisit it if the same issue occurs again. And indeed, this is what we observed during the study.

Another factor involved is when there are relationships between two or more attributes. The problem gets worse when the change in application behavior necessitates modifying more than one attribute at a time. The problem is that the relationship between multiple attributes is often unclear. One of the tasks in the study I am running this week requires that participants apply an attribute to a method inside an interface declaration and another attribute to the class that implements that interface. Participants who have worked on this task have been unaware of this requirement and have not been able to complete the task without significant help. There is nothing about the design of the attributes that makes this relationship clear.

Once participants have been told about the multiple attributes and the requirement to modify them all in conjunction their reaction is always the same - "that's kludgy!". Having seen this in multiple studies on different APIs, I'm pretty much at the point where I would strongly recommend API teams avoid designing APIs that require developers to modify multiple attributes to achieve specific functionality. Instead, I'd recommend examining ways that the same functionality could be achieved through the use of one attribute or at the very least, consider naming the multiple attributes in such a way that the relationship between the attributes is much clearer.

It would be interesting to hear anyone's feedback on this issue. Is this something you have experienced yourself when using an attribute heavy API? How big of an issue do you think it is? What would be your preferred solution?

Parameter naming and the Google test

stevencl — Tue, 24 Aug 2004 15:39:00 GMT

Brad has a post on choosing parameter names for overloaded methods which brings to mind a recent question on an internal mailing list about using acronyms for parameter names.

In general, when determining whether or not it's reasonable to use an acronym to name a parameter, we ask whether or not the acronym will be well known to most people using the API. This is often difficult to answer though, so we will search for the acronym on Google - if one of the top five hits is a page that explains or describes the acronym then we consider that the acronym will be reasonably well known. Otherwise we tend to suggest that the parameter name be renamed or the acronym be fully spelled out.

A recent example was for a parameter named Upn of type string. When searching for Upn on Google, the top ten hits are comprised mostly of pages linking to the TV network UPN. When you search for the fully spelled out name, "universal principal name", the first result is a link to a glossary page on MSDN that provides a link to a definition of 'Universal Principal Name'.

When thinking about naming parameters, types etc, we try to think of how developers will use these names. Very often the names are the first thing that people search for in Google or other search engines. We want to make sure that our names are as expressive as possible and will quickly lead people to understanding the correct usage, whether that be through intuition or through being led quickly to the correct documentation.

System.Net usability study

stevencl — Mon, 16 Aug 2004 19:26:00 GMT

I'm running a study this week on the Beta 1 version of the System.Net namespace.

In addition to the feedback I'll be collecting from participants, I thought it would be useful to capture any comments that anybody else might have on the usability of this namespace. If you've used the types in this namespace and think that there are some usability improvements that could be made, I'd love to hear them.

Virtual properties anyone?

stevencl — Fri, 30 Jul 2004 21:23:00 GMT

As part of the WinFX review team, I regularly review APIs for usability issues. One thing that we as a team have been highlighting as a potential issue is the use of virtual properties. Consider the following code snippet:

public class Class1
{
private string theString;

    public virtual string MyString
    {
        get{return theString;}
        set{theString = value;}
    }
}

public class Class2 : Class1
{
    public override string MyString
    {
        get{return "Ha ha!";}
        set{base.MyString = value;}
    }
}

Code that accesses the MyString property of an instance of Class1 might either return the actual string or “Ha ha!” depending on the actual runtime type.

The design guidelines suggest that properties should not be used if they perform some expensive operation (see Brad's post on a similar issue). Calling a virtual property or method is more expensive than calling non-virtual methods or properties so that is one reason for not creating virtual properties. Another reason is that we believe the code to access a property doesn't really suggest that the value of MyString depends on the runtime type of the object. Consider the following:

public void DoSomething(Class1 c1){Console.WriteLine(c1.MyString);}

In this case, a developer might be surprised if calling DoSomething resulted in “Ha ha!“ being output to the console. We believe that to provide a consistent user experience, properties should mimic simple field access as much as possible. Thus virtual properties run the risk of breaking this consistency since in some cases, some properties work just like accessing a field while in other cases they work more like a virtual method call.

We're not suggesting that there is never a good reason for declaring virtual properties. We're just discouraging the use of virtual properties and encouraging the use of virtual methods instead.

However, I'd be interested in your feedback on this issue. Are we being too cautious?

VS automation samples

stevencl — Wed, 14 Jul 2004 18:08:00 GMT

I've been asked for suggestions for a list of VS automation samples that would help solve tricky tasks that I've observed users working on during usability studies. Just wanted to check if anybody has such a list of samples that they would like us to provide.

One example from a recent study that I can think of would be a sample to show how to automate migrating or copying a bunch of project settings from one project to a collection of other projects.

Any other suggestions?

This scares me!

stevencl — Tue, 06 Jul 2004 17:00:00 GMT

Aleksei Guzev was scared by my last post on readability vs writability.

I think what might have scared Aleksei (feel free to correct me if I am wrong Aleksei) is the thought that the results of this study would be used to make a case for adding a Count property to the DataReader class and removing the ability to iterate through the contents of the class with IEnumerator. Far from it - no such case was made as a result of this study and none will be. What the study shows though is that for some developers, using IEnumerator will not be as intuitive as it will be for others. Therefore, it is worth considering how to make this more obvious to those developers. For example, Intellisense in Visual Studio could highlight particular programming patterns or tasks that a class supports (it might show a list of tasks in addition to a list of methods such as 'Iterate through the contents of myDataReader') such that when the user selects one of these tasks, the code to accomplish this is generated and inserted into the editor. In this case, Intellisense might generate code that creates an instance of an enumerator, sets it to the first element, creates the loop to MoveNext through the enumerator and calls Current to get each element. The user would then just have to add code to do whatever they wanted with each element.

You can think of other examples - for instance, classes that implement IDisposable might have a task called 'Use this resource' (or some better wording...) that would automatically insert a using statement if the language supported it, or would just insert the appropriate Dispose call.

Other alternatives to addressing the usability feedback would be to make supporting these tasks much clearer in the documentation. The key point that I am trying to make though, is just because participants find some tasks in an API usability study difficult, doesn't always mean that the only solution available to you is to change the API. In many cases it is, but there are times when changing the API to address usability feedback won't always be the best thing to do.

Readability vs Writability

stevencl — Fri, 02 Jul 2004 22:52:00 GMT

Jay has a great post on readability vs writability.

It's really important to take this into account when performing a usability review on an API. Don't just review the code that a developer has to write in order to accomplish a given task with an API. You should also review the steps that they need to take in order to write that code. In so doing, you might find that even though a particular line of code makes perfect sense when reading code, it might not make so much sense when writing that code.

In one usability study I ran on ADO .Net, participants were asked to write code that queries a table and outputs the results to the console. The results were stored in a DataReader. Many participants expected to find some Count property on the DataReader that they could use to loop through the contents of the datareader, indexing each element in each iteration of the loop. However, no such property existed. Participants spent a significant amount of time looking for other similar properties such as Length, NumberOfRows etc. but did not find anything that would help.

At this point, most participants went to the help docs to find a code sample to help them. As soon as participants found a code sample that showed them that they needed to use an IEnumerator to enumerate through the contents of the DataReader, they understood exactly what they needed to do. Even though the solution was slightly different to the one that participants had orginally attempted, they had no difficulties understanding this new approach.

In other words, the code that participants needed to write to accomplish this task was readable, but not writable. It just wasn't obvious to participants when they originally attempted the task that calling GetEnumerator and using the returned IEnumerator to enumerate the contents of the DataReader was what they needed to do.

In the cognitive dimensions framework, this is covered by the role expressiveness dimension.

Using the cognitive dimensions

stevencl — Mon, 24 May 2004 19:31:00 GMT

Now that I've finished posting the series of articles on using the cognitive dimensions to evaluate API usability, I've finally gotten around to adding links to each of these articles (see the left hand nav bar at http://weblogs.asp.net/stevencl).

And, now that you've seen the full list of the cognitive dimensions and a detailed description of each, I'd like to ask if you think there are any dimensions missing. Is there some aspect of the usability of an API that you feel is not best described by the current set of dimensions? If so, please go ahead and propose a new dimension. Add a comment with a name for the dimension, a description of the dimensions, values for the end points and the mid point, and a description of how it might be evaluated.

Using the cognitive dimensions - domain correspondence

stevencl — Mon, 17 May 2004 18:59:00 GMT

This is the last in the series I've been posting about how to use the cognitive dimensions framework to evaluate your own APIs.

For each user goal that your API supports, describe how closely related the classes and methods exposed by the API are to the conceptual objects that users think about manipulating when using the API.

In the System.IO namespace, a user goal might be to append text to a text file. In order to accomplish this task, users need to use the StreamWriter class to manipulate the contents of a file on disk. For some users, this might not be obvious. Some users might expect to find a type that more closely represents a file on disk such as a File or FileObject class. The concept of streams used by the StreamWriter class might be unfamiliar to these users. They may be put off from using the StreamWriter class since it does not map well to the corresponding domain.

Domain correspondence can be defined in the following terms.

If the types exposed by the API map directly on to the types and concepts expected by users, the API is said to have a direct domain correspondence.
If the types exposed by the API only map on to the types and concepts expected by users after describing the mapping, the API is said to have a plausible domain correspondence.
If the types exposed by the API do not map directly on to the types and concepts expected by users even after describing the mapping, the API is said to have an arbitrary domain correspondence.

Given the above definition of domain correspondence, the System.IO namespace class has a plausible domain correspondence. For some users, the mapping from a stream based type to a physical file on disk will need to be explained. Once explained however, the user will then be able to work with the type as it exposes familiar methods such as Write and WriteLine which map well on to the methods that users would expect in this domain.

I just need to find a way now to link to each of the postings for easy access...

Attributes and API usability revisited

stevencl — Thu, 13 May 2004 00:26:00 GMT

I posted a query last week requesting feedback on the use of attributes in an API and their effect on the usability of that API (thanks for all the responses!). My query was driven by a study that I was running and that is now complete. I promised that I would describe the results that we obtained from the study with respect to attributes.

The API that we studied makes extensive use of attributes (I don't want to go into the details of the specific API so I'll just use finctional examples here to demonstrate the different points). To achieve any of the functionality of the API, developers must decorate their code with specific attributes. Nothing useful can be achieved in the API without doing so. For example, the API is used to create instances of Foo which can then be plugged in to some executable framework which calls methods on Foo. The API exposes a Foo base class that must be derived from, but also a Foo attribute that must be used to decorate the derived class with, like so:

[Foo(“Some property“,“Some other property“)]
class MyFoo : Foo

Many of the participants thought that the Foo attribute was overkill and was not required - they felt that deriving from Foo should be enough.

Deriving a class from Foo and decorating it with the Foo attribute is still not enough to achieve any useful functionality. You need to create some public members (properties or fields) and then decorate them with the Bar attribute. Only then will the execution context know which members of your class it should access. On top of this, you need to override one of three methods that the Foo class defines. In the example below, we've overridden Method1:

[Foo(“Some property“,“Some other property“)]
class MyFoo : Foo
{
    [Bar(optionalparam1=false, optionalparam2=0)]
    public string Message;

    public void override Method1()
    {...}
...
}

Note those optional parameters in the Bar attribute. These were pretty critical to the success of participants in the study. In order to implement some particular behavior, participants needed to alter the values of those optional parameters, and to set some other parameters. In many cases though, participants would not consider the attributes when they were thinking about what they needed to do in order to accomplish a given task. Instead, they would concentrate on their implementation of Method1 and think about what they needed to change there. They would end up spending a lot of time writing code that wouldn't help them accomplish their goal. In many cases, participants needed to be prompted to consider the attributes as a means to accomplish the goal.

The problem was made worse by more advanced tasks that required participants to decorate members with two attributes, and to set some optional parameters to specific values:

    [Blah(“some string“)]
    [Bar(optionalparam1=true, optionalparam2=0)]
    public string Message;

Note how optionalparam1 is now true. Without being set to true, the attribute Blah has no effect. Blah on it's own also has no effect (if the user just used Blah and did not also decorate Message with the Bar attribute, nothing would happen). This caused some significant issues for participants in the study. In particular, the requirement to change the value of the optional parameter was difficult to see. The interaction between the two attributes just wasn't clear, since they both look as if they operate in isolation from one another.

These problems were not insurmountable. After a couple of hours, most participants started to grow accustomed to the way that the API worked. But it was clear that they struggled for a while to get to that level, making their initial experience with the API an unpleasant one. Furthermore, even after growing accustomed to the API, many participants commented that they felt that the attributes took a lot of control away from them and hid a lot of the details of how the API works. This made it much more difficult for them to form a conceptual model of how the API works. Thus resolving problems and bugs in their code was much more difficult for them than if they had been able to form an accurate conceptual model of the API.

The key take aways from the study with respect to the use of attributes are:

Many developers will not expect core functionality of an API to be exposed through attributes only.
Many developers will be uncomfortable with an API that exposes most, if not all, of it's functionality through attributes due to the perceived lack of control afforded by attributes.
Combinatorial effects between different attributes should be avoided. If they cannot be avoided, the interaction between different attributes should be expressed through good naming.
Many developers will be unlikely to consider modifying attributes in code to achieve particular functionality and will instead concentrate on their own (imperative) code.