Version 2.0 of the Auto FE Updater
in [Help]
|
From: David W. Fenton on 6 Feb 2010 17:36 "Tony Toews [MVP]" <ttoews(a)telusplanet.net> wrote in news:pp3qm5tjf4ocv6ckdnm7i8p57gc231beo2(a)4ax.com: > "David W. Fenton" <XXXusenet(a)dfenton.com.invalid> wrote: > >>> Thanks very much for explaining in detail what you were >>> expecting and your situation! >> >>This is why I hate creating user documentation (pace a >>Stackoverflow.com thread on that topic that you've contributed >>to), because I don't know what needs to be explained. > > 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. -- David W. Fenton http://www.dfenton.com/ usenet at dfenton dot com http://www.dfenton.com/DFA/ |