The other day I was playing around with the Operator Toolbar in Firefox (for those who don’t use that, or for that matter Blue Organizer should give them a shot). The preferences allow you to look at information in two ways
This first screenshot shows actions
The second shows the data type
This reminded me of some thoughts I had when I was a young product manager. Do your users care about the data type, or do they care about the actions they can take on the data returned to them? It quickly became clear that they care about the actions, at least the bulk of customers do. So when we build software for scientists, we should think about what they would do with the returned information. That’s where context is really important as well. I’ve seen too many examples where the user is offered options that make no sense for what you want to achieve.
Of course, this is not an easy problem to solve. One approach is the 37Signals approach. Just implement functionality that you believe address the problems of a certain percentage of your user base. Unfortunately, in the scientific realm, where people are always looking to explore, do things just a little bit differently. The challenge becomes recognizing the core set of actions that your target users share, and the scenarios that are the most common. Then you have to make a decision. Do you want to target a set of users who are happy being given tools that fill most of their basic needs and are easy to use, or do you want to add a layer of flexibility that empowers power users at the cost of some of a broader user base. Unfortunately, too many software providers try to make both groups happy with the same piece of software, which rarely works.
That is one place where workflow engines shine. The best part here, is that a small group of power users/developers can implement methods that can then be accessed by a broader group of users who would not have to worry about implementation details but about performing actions that fit their goals and needs. The ability to distribute these workflows as web apps available on an intranet makes them very effective for certain applications.
Software as a service is still not too common in the life science, at least not in the Web 2 sense of the word (companies like NextBio are exceptions). It will be interesting to see how SaaS-based offerings change the thinking around how scientific software is made available. Will there be APIs that allow people to modify or repurpose the services and integrate them into various workflows? What kinds of actions will people take on the information being provided? What kinds of information will people want to take actions on?
Taking action
The other day I was playing around with the Operator Toolbar in Firefox (for those who don’t use that, or for that matter Blue Organizer should give them a shot). The preferences allow you to look at information in two ways
This first screenshot shows actions
The second shows the data type
This reminded me of some thoughts I had when I was a young product manager. Do your users care about the data type, or do they care about the actions they can take on the data returned to them? It quickly became clear that they care about the actions, at least the bulk of customers do. So when we build software for scientists, we should think about what they would do with the returned information. That’s where context is really important as well. I’ve seen too many examples where the user is offered options that make no sense for what you want to achieve.
Of course, this is not an easy problem to solve. One approach is the 37Signals approach. Just implement functionality that you believe address the problems of a certain percentage of your user base. Unfortunately, in the scientific realm, where people are always looking to explore, do things just a little bit differently. The challenge becomes recognizing the core set of actions that your target users share, and the scenarios that are the most common. Then you have to make a decision. Do you want to target a set of users who are happy being given tools that fill most of their basic needs and are easy to use, or do you want to add a layer of flexibility that empowers power users at the cost of some of a broader user base. Unfortunately, too many software providers try to make both groups happy with the same piece of software, which rarely works.
That is one place where workflow engines shine. The best part here, is that a small group of power users/developers can implement methods that can then be accessed by a broader group of users who would not have to worry about implementation details but about performing actions that fit their goals and needs. The ability to distribute these workflows as web apps available on an intranet makes them very effective for certain applications.
Software as a service is still not too common in the life science, at least not in the Web 2 sense of the word (companies like NextBio are exceptions). It will be interesting to see how SaaS-based offerings change the thinking around how scientific software is made available. Will there be APIs that allow people to modify or repurpose the services and integrate them into various workflows? What kinds of actions will people take on the information being provided? What kinds of information will people want to take actions on?
Further reading
Provenance in scientific workflows
Software development is never easy