[AccessD] Design Considerations - Was: Table Structure Ideas

If the client insists on a particular UI design that I feel is a poor
solution, I don't take the contract.  No point in subjecting myself to
abuse I can avoid. That's one of the advantages of free lancing.

Charlotte


On Thu, Sep 11, 2014 at 11:13 AM, James Button <jamesbutton at blueyonder.co.uk
> wrote:

> My first consideration is the relationship you have with the users of the
> delivered system.
>
> If your contact with them is you provide it as specified by the
> 'management'
> than that is what you should do.
> Yes, you may discuss your concept of what is needed from the facility.
> And following that - maybe discuss what else the system may be required to
> do,
> and techniques that you, as an experienced developer believe are worth the
> extra
> effort - and consequent up-front cost with the targeted offset of future
> costs.
>
> That is basically a COST concept.
>
> Maybe you can suggest that some techniques be adopted as being minimal
> cost to
> avoid major constraints later
> - Y2K being a prime example - save 2 digits in a date - so the users don't
> have
> to enter the leading 19 all the time.
> AND - note the windows environment actually includes that concept - with a
> user
> specifiable range of years to be associated with the current century and
> the
> prior century.
>
> If you are working with the users then you have a good opening to
> prototype the
> facility and introduce what to you seem to be good design and input data
> handling and processing, while addressing the background maintenance and
> reporting needs.
>
> For instance - entering an animal - include their parents - with a search
> facility as a subsidiary option from the entry screen so they can search
> for the
> entries.
> But - what if the parent entries need to be entered - do that as a
> subsidiary
> process, or require them current entry to be abandoned in order to enter
> the
> parent entries.
>
> Then - Species - allow that to be selected from a list - with addition of
> new
> ones - or require a separate panel to 'add'
> Well you are going to need a panel for add, change, delete maintenance, and
> should you allow delete with cascade, or do it without cascade and leave
> orphan
> entries
> If a 'supervisor' has to do the delete, do they use a different panel, or
> the
> same panel with actions greyed out
>
> Strict normalisation - or just as needed for what they will be doing
> Stored procs - VBA on forms - DBMS with GUI included, built-in, or built-on
> audit and rebuild facilities
>
> It all comes down to money, and your relationship with the client as in is
> that
> interface at end- user, IT, or corporate management level, or maybe follow
> the
> documented & contracted requirements.
>
> I feel that those clients who willingly discuss matters of design with me
> at
> contract time get a far better result than those who tell me what they
> want and
> how it is to be done.
> And overall, I probably made more profit from the latter group than from
> those
> who were guided to systems that were  logical and easy for them to
> understand
> and use.
>
> So - Horses for courses, providing the best ( to the clients view)
> facility you
> can for the money, and within their constraints
>
> JimB
>
>