OSS tend to be powerful software suites that can do millions of things. Experts at the vendors / integrators know how to pull the puppet’s strings and make it dance. As a reader of PAOSS, chances are that you are one of those experts. I’ve sat through countless vendor demonstrations, but I’m sure you’ll still be able to wow me with a demo of what your OSS can do.
Unfortunately, most OSS users don’t have that level of expertise, nor experiences or training, to pull all of your OSS’s strings. Most only use the tiniest sub-set of functionality.
If we look at the millions of features of your OSS in a decision tree format, how easy will it be for the regular user to find a single leaf on your million-leaf tree? To increase complexity further, OSS workflows actually require the user group to hop from one leaf, to another, to another. Perhaps it’s not even as conceptually simple as a tree structure, but a complex inter-meshing of leaves. That’s a lot of puppet-strings to know and control.
A question for you – You can make your OSS dance, but can your customers / users?
What can you do to assist users to navigate the decision tree? A few thoughts below:
- Prune the decision tree – chances are that many of the branches of your OSS are never / rarely used, so why are they there?
- Natural language search – a UI that allows users to just ask questions. The tool interprets those questions and navigates the tree by itself (ie it abstracts the decision tree from the user, so they never need to learn how to navigate it)
- Use decision support – machine assistance to guide users in navigating efficiently through the decision tree
- Restrict access to essential branches – design the GUI to ensure a given persona can only see the clusters of options they will use (eg via the use of role-based functionality filtering)
I’d love to hear your additional thoughts how to make it easier for users to make your (their) OSS dance.
4 Responses
Many OSS users are solving problems and/or trying to get better future outcomes for a class of provisioned components …
It would be nice to visit a provisioned component and ask which parts of the OSS “tree” were engaged to guide this component to its present state from its previous state (or from its previous state to a prior state).
Taken a step further, this detailed log would be of great assistance in pruning the tree (what’s not being used, since when?)
Great suggestion Steve….
To paraphrase – once you start down one branch, then decisions narrow for the duration of that workflow..
Are you also thinking that the detailed log will help intelligently prune the “tree” with an AI/ML that was constantly reviewing the log??
Decisions may well narrow, but some “trees” (the more inter-meshing variety that you mention) may even use multiple branches to drive the outcome. Indeed, this tangled behaviour may not always be obvious and/or may be the result of years of pulling the (wrong) strings rather than being an inherent defect of the OSS design. Finding out that this is happening is even more valuable and untangling the tree may yield more benefits than simple pruning.
Yes, I did have in mind an ultimate goal of adaptive and continual cleaning, but based on the 80/20 rule a periodic analyse and manual clean may well be strikingly cost effective.
I like it Steve!! 🙂