Re: Open source alternative for MsAccess?
From: David W. Fenton (dXXXfenton_at_bway.net.invalid)
Date: 06/13/04
- Next message: Otto Wyss: "Tutorial and guidelines: Basic frame layout"
- Previous message: Jan Panteltje: "Re: Open source alternative for MsAccess?"
- In reply to: Bernd Bollman: "Re: Open source alternative for MsAccess?"
- Next in thread: Bernd Bollman: "Re: Open source alternative for MsAccess?"
- Reply: Bernd Bollman: "Re: Open source alternative for MsAccess?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 13 Jun 2004 20:12:12 GMT
Bernd Bollman <bernd@hotmail.com> wrote in
news:cahg6k$nj$00$3@news.t-online.com:
> David W. Fenton wrote:
>> Bernd Bollman <bernd@hotmail.com> wrote:
>> >> > [Microsoft Access]. . . It's not a programmers tool . . .
>> >>
>> >> Er, yes, it *is* a programmer's tool. I program in it for a
>> >> living.
>> >
>> > Damn! I'm feeling *really* sorry for you :(
>>
>> Why?
>>
>> Because I can do anything I need to do with a tool that allows me
>> to do it in 1/3 or less the time it would take with any other
>> tool?
>
> I know Access is very mature and feature-rich and all of you who
> program in it daily and create applications that are useful to
> some have my deepest respect! I couldnt do this.
>
> The reason is the total lack of a design. It is a lumped up
> collection of components without clean interfaces and lots of
> features taped all over it. . . .
???
Care to explain that? I see it as as very clearly organized
development tool.
Of course, I was programming desktop databases back in 1989 or so,
so part of my perspective is having lived through the evolution of
desktop database development tools.
> . . . Its based on Basic! . . .
Visual Basic and classic BASIC have very little to do with each
other. I learned BASIC in college and what I learned there that was
specific to BASIC (as opposed to concepts like control structures,
data vs. logic, and so forth) was of absolutely no use when I
started programming in Access.
> . . . The documentation
> totally sucks. . . .
!!!!
I think the documentation is excellent. I learned to program
advanced applications in Access entirely without any training, using
the documentation that came with it (Access 2). I doubt that this is
because I'm substantially more brilliant than you.
I'd like to know what about the documentation you see as
problematic.
> . . . The user has to have Access installed. . . .
Or the runtime. The latter costs the user nothing.
> . . . Its just
> damn ugly. . . .
It is? I don't think it's ugly, but then, I have a number of
techniques I use to make sure my apps don't come out looking ugly.
Some examples here:
http://www.bway.net/~dfassoc/examples/
http://www.bway.net/~dfassoc/examples/NKF
http://www.bway.net/~dfassoc/examples/SA
http://www.bway.net/~dfassoc/Splash/
I wouldn't say those are all perfect examples, but they do show that
with a little work you can get something very attractive that
doesn't look like most Access applications.
For that matter, I've noted that most custom-designed software is
butt-ugly, no matter who designs it. Very few small developers
understand how to put together an attractive UI.
Some of my principles:
1. fonts are never colored except when used for headings.
2. fonts should use standard Windows fonts most of the time. This
means MS Sans Serif or Tahoma or Arial for all labels and textboxes.
3. standard command buttons are just fine in most cases, but you can
use labels with invisible command bottons over them to get colored
buttons. This is a lot of work, though, and not necessarily worth
it, unless the colors get you more than just appearance. In the
example where I use colored buttons, they have the advantage of
corresponding to the colors of the forms they take you to.
4. use color in form headers to help identify context.
5. have a nice, professional-looking splash screen.
6. appearance should fade into the background for the user after the
app has been in use for a short time -- it should never draw
attention to itself. It should be regular and non-obtrusive. If it
looks like a Microsoft application, users will be comfortable with
it. If it looks like Windows 2000, users will be comfortable with
it.
I'm sure there are other principles I use, but those are the ones I
can think of.
I do agree that default Access forms are pretty ugly. I also agree
that a lot of apps I've seen where developers use all sorts of
colors and mixed fonts are uglier still.
That doesn't mean Access can't be used to produce attractive apps.
> . . . The only thing I would hate more than having to use
> Access is having to maintain the source of it.
This doesn't seem to me to be a problem. Can you explain why you see
it as a problem?
> "Feature-rich" in this case would better be described as opaque
> monolithic Monster-Bloatware.
Well, I don't see it as opaque at all. PHP, now *that's* opaque. But
if you're accustomed to it, it's not.
I don't think the learning curve in Access is any steeper than in
any other development platform. But I would say that people who
don't understand database design generally don't do well with it.
Understanding how to design a proper schema goes a long way to
getting a decent user interface.
Nonetheless, I'll take my "opaque monolithic Monster-Bloatware" over
any of the alternatives any day.
And I'll probably be able to finish the same project in 1/2 or less
the time it would take anyone working on any competing platform.
-- David W. Fenton http://www.bway.net/~dfenton dfenton at bway dot net http://www.bway.net/~dfassoc
- Next message: Otto Wyss: "Tutorial and guidelines: Basic frame layout"
- Previous message: Jan Panteltje: "Re: Open source alternative for MsAccess?"
- In reply to: Bernd Bollman: "Re: Open source alternative for MsAccess?"
- Next in thread: Bernd Bollman: "Re: Open source alternative for MsAccess?"
- Reply: Bernd Bollman: "Re: Open source alternative for MsAccess?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
