Re: Whut I dew?


David W. Fenton wrote:
> "davegb" <davegb@xxxxxxxxxxxxxx> wrote in
> news:1137164733.632178.261510@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
>
> > It's not the complexity I object to. That's inherent in the
> > application, whether it's critical path scheduling or database
> > design.
>
> But it's the complexity that leads to the desire on the part of a
> software company to provide help for people without the training or
> experience to be able to cope with that complexity. That's a *good*
> impulse on the part of Microsoft (or any other software company).
>
> > It's the fact that MS, in an supposed attempt to simplify, has
> > built traps right into the software for a novice, me in this case,
> > to fall into.
>
> Well, in certain contexts, the shortcuts for the novices *don't*
> cause problems, so it's hard to fault MS for putting them in, since,
> within the limited scope of their intended use, they function fine.
>
> Access itself is often criticized for not being something it was
> never intended to be, so I can't get too worked up about some of
> these features that are implemented to help within some limited sets
> of circumstances.

I appreciate your comments, Dave, but I disagree here. I think that
putting in "shortcuts" that make it easier if you don't know anything
about the subject, but create serious problems for those that do, is
poor design. This Name Autocorrect "feature" has cost me time and been
a distraction from getting the database done. Features should work all
the time or not be there at all. I believe than inconsistency is a
major flaw in any software.
There is a similar "feature" in Project which, under certain
circumstances, creates "links" between tasks automatically. Most
beginners would hardly notice. But when I finally figured out that it
was happening, it took me an hour and a half to track down how to turn
this feature off. It was sabotaging my efforts. Now I warn my students
to turn this feature off if they want to have any hope of creating
meaningful schedules. I don't think this is good design, no matter how
well-intentioned it is.


>
> It's when the features are implemented in a buggy way that I have a
> problem.

I agree here. Just making matters even worse!

>
> > If the software is smart enough to create those linked tables when
> > I did something wrong, why wasn't it just a tiny bit smarter and
> > give me an error message explaining why it had automatically
> > created them? And why are there these other traps like look-ups.
> > It's like luring you into thinking something is much simpler and
> > easier than it really is to sell you the product, knowing that
> > down the road the end user is going to pay in lost time and effort
> > to make the application really work. I'm just not a fan of this
> > kind of marketing strategy.
>
> Well, I suspect that if your problem was related to AutoCorrect,
> that what actually happened was some kind of catastrophic bug that
> caused a complete failure of the system. It's hard to build anything
> that can recover from a complete breakdown like that.

Actually, it wasn't a catastrophic failure. Everything worked fine
until I deleted the automatically created linked files to correct for
my error (I am know to be a bit impulsive at times. And knew I could
recover if I had to.). I was impressed that it did that, just annoyed
that it didn't give an appropriate error message when it created the
special files. Even more annoyed that this is a known problem that
probably should have been fixed several versions back.

>
> But I saw that I didn't need or want Name AutoCorrect the first time
> I opened and Access 2K database -- *I* want to be in control of when
> object names change, not some behind-the-scenes operator that I
> can't control.
>
> Now, if they'd implemented it with some kind of granular control
> over which things it propagates name changes to, and allowed
> granular control of when you'd get prompted, and incorporated some
> kind of backup so that it could be easily reversed if it caused a
> problem, now *then* it would be a useful feature.
>
> But my guess is that this would be too complicated for most people
> to use. Nonetheless, programmers would be able to use it, and it
> could be set with defaults that would make it universal with no
> prompts, as it actually was implemented, but allowing for those who
> are smart enough to use it with more control.

MS has to recognize that their software has users at all levels of
expertise, and that some users just ain't gonna get it, not matter how
simple they try to make it. I don't like the paradigm of designing in
"ease of use" features for the beginner (and may undermine their
understanding of how the process actually works) that sabotage the
expert.

>
> They didn't implement it that way, so I won't use it.
>
> I believe there's a conflict between MS's product engineers and
> their marketing department sometimes, too. A perfect example
> (similar to your description of the designers of MS Project) of
> where I would guess a software engineer on the Access team probably
> resisted the implementation of a MS Office-wide feature was the
> standard AutoCorrect function (not Name AutoCorrect, but the
> AutoCorrect that replaces i with I when you're typing in Word) that
> is applied by default to *all* controls on an Access form. This
> might make sense as an optional function for text fields, but it is
> completely brain-dead stupid to have it even available at all for
> combo boxes, which are designed for the sole purpose of restricting
> data entry to a set of pre-defined choices. Any control type that
> has that purpose should *never* be subject to data entry changes
> from some outside function that is actually not controllable by the
> database application programmer.
>
> It was just dumb.
>
> And I am as certain as one can be that the Access project managers
> told the Office team that it was bad design since they know
> perfectly well that such a feature has no place in a database
> application. But they were overridden, nonetheless.

Sounds like a case of a company-wide edict, "make all Office programs
compatible in these areas", overriding common sense in one package.
Unfortunately, happens all the time in big business.

>
> The surprising thing when you think about it is that so many Access
> apps created by novices using these less-than-good features still
> function perfectly reliably, and have value for the people who use
> them.
>
> Access is pretty indestructible, seems to me.
>
> And that's one of the reasons it's so dangerous -- it tolerates too
> much suboptimal design.
>
> --
> David W. Fenton http://www.dfenton.com/
> usenet at dfenton dot com http://www.dfenton.com/DFA/

Years ago I worked with a scheduling software package that gave the
user the option of 3 levels of menus, Beginner, Intermediate, Expert. I
liked that feature. I think it has merit in these situations we're
talking about here. But I'm never a fan of automating to the point
where it becomes difficult for knowledgeable users to use the software
following established best practices in the field. MS seems to do this
consistently. In the case of Project, I know it was due to a
combination of arrogant and ignorance (I met the Project Lead face to
face). I don't know why it happened in Access, but I'm mistrustful
based on my experiences on Project and with MS in general.

.

Relevant Pages

  • Re: Conceptual, Logical, and Physical views of data
    ... >> David Cressey wrote: ... >>> the problem itself from a feature of some imaginary soultion to the ... the difference between analysis and design. ... >>> DBMS class independent. ...
    (comp.databases.theory)
  • Re: What do programmers do?
    ... I know the software development cycle looks something like ... no authority to change the design based on feedback from their code, ... My typical week starts by asking the people who use my program what feature ... Then I convert the requirement into a set of goals. ...
    (comp.programming)
  • Re: Conceptual, Logical, and Physical views of data
    ... >> the problem itself from a feature of some imaginary soultion to the ... the difference between analysis and design. ... The logical model should be DBMS independent... ... or the relational data model. ...
    (comp.databases.theory)
  • Re: IC redux
    ... then how is it possible for that feature to ... >As far as evolution goes, ... >"scaffolding" and then take it away. ... For example, if we think a bit about a "complex design", we ...
    (talk.origins)
  • Re: Whut I dew?
    ... these features that are implemented to help within some limited sets ... Well, I suspect that if your problem was related to AutoCorrect, ... if they'd implemented it with some kind of granular control ... told the Office team that it was bad design since they know ...
    (comp.databases.ms-access)