One thing I've found about the Auto FE Updater is I get next to no
feedback about what works and doesn't work. So I'm exceedingly
grateful for postings like yours where we can discuss the issues
and so I can understand what you are doing.
And I agree with you about creating user docs. I hate that too.
Every time I get an email I try to update the website and create
an FAQ.
Most of my response to user problems goes into the application
itself.
Yesterday I rolled out the first update on a new project. It
consistuted a HUGE amount of work (importing 3 years of data from an
outside source that had been languishing unimported, then testing
the import to see what data it produced, refining it to process all
the data into existing records and properly creating new records
only where necessary, in the process, building re-usable queries and
code for building a UI for it (which remains incomplete), massaging
the data so that missing RI could be put in place, renaming all
tables and fields, combining the data in two separate tables into
one (they both belonged in tblPerson), revising all the objects that
used those two tables to now use the new one, putting in place code
that sets fonts and colors for all forms in the OnOpen events,
re-working two of the three forms to have non-haphazard formatting
of field sizes, alignment, fonts, colors, etc., and adding a new
search form to find people without having to know what type they are
before you initiate the search), but not much of it showed to the
users. I had one of the users try the one thing that was new (the
people search form), and immediately saw that my approach to it
wasn't going to work. For finding people, I like using a single
textbox where you type in "Fenton, David" or "Fenton" or "Fenton, D"
or ", David" or "F, David" or "*s?n, D" and get useful results. So,
I also add a label with on-screen instructions on how to use it. I
also tend to use the control's AfterUpdate to initiate the search.
The form has only one command button, a DONE button that closes it.
What I saw when I demonstrated it to the first user:
1. she didn't read anything onscreen. She opened it and immediately
started typing. And then hit the DONE button.
2. once she went back to it, she didn't know how to start the search
(because she didn't read the text onscreen).
3. even once she had grasped hitting ENTER, there was still the
problem that you have to force the AfterUpdate event (so my
implementation was flawed, because when I usually do this, I clear
the search textbox after the search, but in this case, I'm making
the search results and search terms "sticky" so that your last
search is still there the next time you come back to it -- simply by
hidding the form insted of closing it).
So, the next slipstream update will have these features:
1. data import UI.
2. revised search form that uses the LostFocus event and has a fake
GO command button (I've done that one before -- the button has no
event, as it's only purpose is to get the LostFocus event to fire),
and that drops all the complexities (no longer requires "Lastname,
Firstname" format, but instead works just like a Google search,
which means less accurate results ("John Smith" will now get you
"Smith Brittingham"), but be less fussy.
The point is that a UI that is completely sensible and powerful for
me is too complicated for the end users without training. So, I'm
going to make it match user expectations.
One of things I'm puzzling over is how to replicate the way HTML
forms work without running the search multiple times (as is the case
with HTML forms). That is, when you hit ENTER on a field in an HTML
form, it executes, no matter what. I want the search to execute when
LostFocus occurs (i.e., when the users hits ENTER or clicks the GO
command button), but not repeat if the results are already
displayed. I think I may use the AfterUpdate event to set a flag on
this (AfterUpdate won't fire if the data in the criteria textbox
hasn't changed).
There are other issues I'm thinking about, but the point is all of
this is motivated by watching how users react to what I've built and
then redesigning it to make it work the way THEY EXPECT IT TO. If I
do that, NO DOCUMENTATION IS NECESSARY.
I could have written great documentation for my original
implementation, from my point of view, but it would not have
overcome the fact that I built something that did not meet the
users' expectations about how it should work.
In the case of my experience with the Updater last Monday, it didn't
meet my expectations, and now you've done exactly what I am
planning, i.e., change the behavior to address user expectations.
Having the documentation is great, but had it worked the way your
redesign will, I never would have needed to read any docs.
And to me, that's the real goal.
.