Improving the experience for new users
Tony G
also has over 1200 pages of documentation, which is excellent
reference material, but not appropriate for new users.
To help with the initial exploration process, I'm writing a
series of articles which progressively introduces new users to
functionality. People just need to keep focused on the material
that's being presented, and try to avoid getting confused by the
environment until they've had a chance to go through the series.
However, I also think mvToolbox would benefit with the ability
for specific features to be unavailable until a user is ready for
them. If you can't see a feature, you can't be confused by it.
Here is how that might work. Each feature is assigned a level of
difficulty in a table. Users then assign themselves a level when
they entire the environment, the default being level 1 or
whatever was set on last login. Now when requesting features, if
they are at or above the level of the feature, it is exposed to
them. If not, it's not visible in menus, Help, or at the command
line.
So here we see two approaches to improving the user experience.
First, document only what someone needs to start. Second, only
expose specific features until the user wants more. Of course
these approaches can be combined, with a series of articles to
prepare users for each new level.
What if I'm ready for a feature described or exposed later?
What if I need something right now that's not exposed?
No solution is going to be perfect. New documentation may not
introduce features to a given individual that they can use right
now, and users are always going to be looking for features that
they know are in there, but they just don't know where to find
them.
But right now (IMO) the problem is that there is too much in
front of the user in both the screen and the documentation, and,
well, we are where we are. So my solution is to limit one or
both, just making a best guess as to which features are
introduced sooner than others.
I'm relying on Bro and Eugene to feed me a limited set of
features for my own education, and as I learn, I will try to
organize the features into an order which seems appropriate for
others. Frankly, the order in which I'm being fed features is
close to being just right, and some of this dove-tails with the
Getting Started info in the docs. But I'd like to refine the
experience for others so that they can do this on their own.
My questions would be:
Does anyone disagree with these fundamental concepts?
Is there something else that this software needs to get more
traction with developers, outside of just a better introduction
experience?
Should we start assembling a list of features and tagging them
for level 1, 2, 3, etc? I can use this for my articles, and Bro
might get some interesting insight into the experiences of
others.
Are there any features that you absolutely need as a "level 1"
user but you don't know where to find it? (Or didn't know until
Bro told you?)
I'm curious about what others think about the idea of having the
software expose features progressively. Is that too much to ask?
Are you one of the people who has been overwhelmed or confused by
the "too many features" in this software? (I know I am.)
Any other suggestions for how to improve the initial experience?
With the articles we may not need videos, as I do include
screenshots. If you can explain why video (podcast, etc) might
be a requirement even with such articles, please post your
thoughts.
Thanks for your time.
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
Nebula R&D sells mv.NET and other Pick/MultiValue products
worldwide, and provides related development services
remove.pleaseNebula-RnD.com/blog
Visit PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno