form design for end users - best practices 2

[misscrf]

I have a main form. Then I have 3 pages on a tab control ( 4 if the type of entry validates that is is to be shown) Each page has a subform. The subforms can be either single or continuous, I think I am still deciding what I want to lock down this entry form to make entry easy.

The form is for entering applicants for jobs to our company. The main form is just for name and email and candidate type. If the candidate type is one of a few types a page becomes visible for specific info, otherwise, there are just 3 pages. 1 is for addresses. An applicant can have multiple addresses (home, work, school etc), another is for phone numbers. An applicant can have multiple phone numbers.

The last page is for the applications for that candidate. A candidate could apply more than once, so they could have more than one application. This will get tricky because the application form has a subform, for the activities relevant to that application. This is like a logical history. Activity - interview scheduled, interview held, offer extended, rejection letter sent, etc.

Anyway, I am looking for advice on many issues. How to best control the subforms, how to make it so that when the user is tabbing it goes from the last field on one subform to the first field on the next subform, and more. My hestitation is that I think I need to make sure that there aren't more address, phone numbers, applications or activities needed to be added at that time. My next hesitation is that I don't want to be stopping the user with messages every 5 seconds.

I have screenshots available to send out, but there is no way to post them here. I can also email the db if need be.

Thanks.

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[misscrf]

Here is an idea that I came up with. See here is the best I can explain. For all of these types, I have a maintenance form for each of them. In the entry form, where ever a type has a combo, that combo has code in the notinlist event. The code pops a message if the user types something not in the list. That code is above, and explained.

Now, I have made it so that if a user wants to directly maintain a type they do it not from the candidate entry, with buttons by the combo boxes. Instead they only get that message if there is a problem on the entry form. Other than that, from the main menu, they can click a button to take them to a maintenance menu. This has a button to open each type's mainenance form.

My issue has been this:

The user might trigger opening the maintentance form 2 different ways. 1 would be during not in list while on the entry form. In this instance, on the click to close the type maintenance form, the candidate entry form is still open in the background.

I want it that way.

If the user opens the type maintenance form from the maintenance menu, I have the maintenance menu closed, because it would look messy to keep it open at this time. This is where my delema is. There is a close form button on each type's maintenance form, but if it closes from the entry method, it should just close. If it closes from the maintenance form method, I need the maintenace form to open up again.

does that make any sense?

I thought of making the button have an if then else statement that would evaluate if the candidate entry form was open. This is the code that I have, but it is not working. can someone please help? (this is for one specific type, address type. It deals with it's maintenance form and maintenance form's command button)
----

Private Sub cmdCloseAddressType_Click()
On Error GoTo Err_CloseAddressType_Click

Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "frmMaintenance"

If Forms!frmCandidateEntry.IsLoaded Then
DoCmd.Close acForm, "frmAddressType", acSaveYes

Else:
DoCmd.OpenForm stDocName, , , stLinkCriteria
DoCmd.Close acForm, "frmAddressType", acSaveYes

End If
Exit_CloseAddressType_Click:
Exit Sub

Err_CloseAddressType_Click:
MsgBox Err.Description
Resume Exit_CloseAddressType_Click

End Sub
-----

Thank you very much.

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[TheAceMan1]

misscrf . . . . .

Your way ahead of yourself here. If I remember there were some form operations you asked about which havn't been covered yet. Have you forgotton?

At any rate is gonna get harder & harder to post back this evening as I''m cooking for 37 people. Put all your brain storming on paper and go over it first . . . . you'd be surprised.

Any by th way. From experience, I'll allow uers to add, never to delete. I have a message the informs them to contact administration for that. In the past I have been in court twice for loss of data. If your allowing them to delete, then your very brave!

See Ya! . . . . . .

 

[misscrf]

true true. Some of this will have to be tested. For now I wanted to take all of those "maintain" buttons off the entry form. I found what I needed to fix the code, so I will get back to orginal navigation issues next year, along with not allowing them to delete types, unless they contact an administrator.

That is an excellent point.

Here is the code that works, incase anyone out there stumbles on this and finds it useful:

On Error GoTo Err_CloseAddressType_Click

Dim stDocName As String
Dim stLinkCriteria As String
stDocName = "frmMaintenance"

If CurrentProject.AllForms("frmCandidateEntry").IsLoaded Then
DoCmd.Close acForm, "frmAddressType", acSaveYes

Else:
DoCmd.OpenForm stDocName, , , stLinkCriteria
DoCmd.Close acForm, "frmAddressType", acSaveYes

End If
Exit_CloseAddressType_Click:
Exit Sub

Err_CloseAddressType_Click:
MsgBox Err.Description
Resume Exit_CloseAddressType_Click
---

(that goes inside a click module obviously)

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[willir]

misscrf -- Good project

TheAceMan1 -- Good work

Okay, here is a fresh perspective...

A long time ago, I found the use of small LookUp tables to be a real pain. A lot of overhead. And yet, I hate to use a ValueList within combo and list boxes because of the maintenance later on.

My solution is to use one lookup table for the simple lookups. In your case, for PhoneType, CandaditeType, AddressType and ActvityType. But not for things such as GroupID / Group which seems to have a more important need.

I call this look uptable tblGetVar, short for Get Variable. The design is fairly simple...

tblGetVar
gvType - text, 15
gvCode - text, 15
gvValue - long interger
Comment - memo field

The gvType is used to group the record by type. For example, PhoneType, ActivityType.

The gvCode is the actual text value.

The gvValue and Comment / memo fields were added later in development when I found I occasionally needed to track numeric or other types of entries.

The primary key is gvType + gvCode

Some sample data could look like
[tt]
tblGetVar
gvType gvCode
PhoneType cell
PhoneType work
PhoneType home
AddrType work
AddrType home
[/tt]

Yea, this design breaks the rules for Normalization. The one "maintainence" item is that combo boxes have to be tweaked.

Instead of...
SELECT PhoneType FROM tblPhoneType Where PhoneType = ...

I need to use...
SELECT gvCode FROM tblGetVar Where gvType = "PhoneType"

I have to specify / hardcode the gvType data in the query.

Regardless, this approach saves me a tonne of time since I copy the form, and end up re-using the data (for example, Phonetype).

I use one form for ALL lookup type maintenance entries (edit/add to the lookup values, not retrieve data). The GetVar form uses a bit of code to check which form is calling it, and filters the appropriate records.

From the calling side, for example, perhaps the Candidate data entry form. (I will stick to PhoneType)

Private Sub cmdPhoneType_Click()

    Dim stDocName As String, strGvType As String

    stDocName = "frmGetVar"
    strGvType = "phonetype"
    
    OpenGetVar stDocName, strGvType
    Me.PhoneType.Requery

End Sub

And on the frmGetVar side...

Private Sub Form_Load()

Dim strOpenArgs As String, strQ As String, strSQL As String
Dim booLock As Boolean

Me.LockForm = False
booLock = False
strOpenArgs = ""
strQ = Chr$(34)

If Len(Nz(Me.OpenArgs, "")) > 0 Then
    strOpenArgs = Me.OpenArgs
    If DCount("gvType", "tblGetVar", "gvtype = " & strQ & strOpenArgs & strQ) Then
        booLock = True
    End If
End If

If booLock Then
    Me.LockForm = True
    Me.gvType.DefaultValue = strOpenArgs
    Me.gvType.Visible = False
    Me.CategoryQry.Visible = False
    
    Me.Filter = "gvType = " & strQ & strOpenArgs & strQ
    Me.FilterOn = True
    
Else
    
    Me.LockForm = False
    Me.gvType.Visible = True
    Me.CategoryQry.Visible = True

End If

End Sub

Basically, the Form_Load event procedure checks for an openning argument. If one is found, it sets the form up to find the required data, and hides gvType. gvType is set to the appropriate value whenever a new record is added.

I notice that you have large command buttons for CandidateType, PhoneType, etc. What I do is use a small graphic icon image for the command button, and size it as 0.2" x 0.2" -- the same icon button, such as the binocculars, is used every where I need / allow the end user to maintain the type. The icon is placed next to the appropriate control field. The end user associates the common icon to openning the GetVar maintenance form.

Sorry for the complicated example, but I found that this approach saved me the trouble of creating dozens and dozens of LookUp tables for a complex IT support / inventory database. One table and modularized code.

...Moving on
Your form may be improved upon. Having a tab for Phone Number, and a tab for Address does not make sense unless you want to invoke some security to prevent users from accessing the data in one tab and not in another tab.

Unlike AceMan, I do like using tab forms -- it saves real estate space on the monitor screen. But you want to design to simplify data entry, and queries. For example, if you are entering data for phone numbers, you may also be entering address data. So it makes sense to keep the two together. BUT, when you query the Candidate data, you probably will need their phone number. So it also makes sense to move the primary phone number to the form header.

You may find you need to create an unbound combo box to find your candidates. This should be on the form header too. You may also want to find all candidates of a specific type, or a specific degree.

But you do not need to know the person's middle name, salutation, and maybe not even their first name. All this info can be moved to a tab for the address and other contact info.


...Most of your work
Most of your work will for entering and reviewing activities for candidates. This is where you really need to focus on your form design for simplifying data entry and review. Perhaps you can add a command button that opens a simple single form that filters all activities for the selected candidate. This may make it easier to read the entries.


...Want something cool?
If you scanned their resumés or receive resumés via email, you can store the documents on a computer or server, and then use a hyperlink in your database to link to the resumé. You would have to add the hyperlink to your database design.

Richard

 

[misscrf]

Willir, thanks for the post. I will have to read it over and get back to you. I have already made some changes. And some of that has to do with maintenance. I have to say that although I like your idea, unless I hear complaints from the future users, I don't know if I want to go back and change all of that now.

This form is strictly for entry. If they want to see/filter candidates, they will do this on the report side. I understand about splitting up the phone and address. I only did that because I thought that I needed different tabs for the different subforms.

I will look at that.
I have to say, though, that I do not want to put the phone number at the top of the screen. This is not for the users to view the data, just enter it in. If they want to see a candidate's phone number, they will open a simple report.

I will get back to you both with screen shots of what I have changed, later today.
Thanks for all of the suggestions. Brainstorming makes the process so much more.

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[misscrf]

Hi again. I have some more screen shots, and now I want to get back to my original issue.

http://www.geocities.com/misscrf/images/newmenu.jpg

http://www.geocities.com/misscrf/images/maintenancemenu.jpg

http://www.geocities.com/misscrf/images/contactinfo.jpg

Those screen shots should explain the changes that I have made so far. The main menu shows a button for maintaining types and listings. The maintenance menu shows the new place to go to for maintaining types and listings. I did this this way, because I think the users are used to working like this. If I find out that they would prefer to see it differently, I will work to implement your suggestions, Richard.

Now, my original issue looks at the contact info image. You'll see that the maintenance buttons are gone from the entry form now.

Here is the issue. If you look at the address and phone subforms, you see that there shows fields for 1 record, and an add button.

I am trying to figure out how to format and set up my subforms, so that the tabbing can go straight through from the first field (salutation) to the last field on this form, which is Followup/followup notes, on the activity subform.

The thing is that I need to account for the possibility that a user would need to enter in multiple addresses, phone numbers, applications, or activities.

I do not know how to make this appear on the form in a way that will make sense to the end user.

The old phone tab (

http://www.geocities.com/misscrf/images/phonetab.jpg

)
showed a way of using a continuous form so that when a first phone is added a second record opens up. I think I kind of liked that.

The old address tab (

http://www.geocities.com/misscrf/images/mainentryformaddtabshows.jpg

)
shows the form with navigation tab. I didn't like this because when a user tabs from the zip field, the record they are on disappears. It looks that way to the end user. The navigation buttons show that the form has moved to a second record, but the end user might get confused by that setup.

Here is my challenge for applications and activities.

The tab right now (

http://www.geocities.com/misscrf/images/applicationandactivitytab.jpg

) does not account for a second application. I put the previous and next buttons there, but stopped because I was unsure. I could put a new record button there too, since it is single form cycle current record.

The activities has the navigation buttons and cycles all records ( based on application id, which ties to candidate id) but again this has the same problem as address.

Any help or suggestions would be wonderful.

Any screenshots of great end user forms would be wonderful too.

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[willir]

My comment would be to create your subforms that support one-to-many or many-to-many as a contineous form. For example, you account for different PhoneTypes, but only display one phone number per record. If you change the form from a "Single" form format to contineous, you can see all phone numbers for the candidate.

How? Open the subform in design mode, and make sure the Properties window is open (from the menu, "View" -> "Properties"). This allows you to see the properties of the form or control fields on the form. To see the properties of a control field; to see the properties of the form click on the square box on the top left of the form where the vertical ruler meets the horizontal ruler. When the form is selected a small black square will appear inside the grey square. Now select the "Format" tab on the Properties window and change the DefaultView from "Single Form" to "Continous Forms". You will most likely now have to move your column descriptions to the header part of the form -- no biggie.

Then, for Bob smith, you can see somehting like...
[tt]
Header part of the form
Phone
Type Phone / eMail
Detail part of the form
Home 902-555-1112
Cell 987-555-1113
Work 902-555-1114 ext 123
eMailW BobSmith@NotMyWork.Com
eMailH BobSmith@NotYahoo.Com
[/tt]

Hey, since phone numbers should be text strings, did I mention that you can also use the same table to capture eMail addresses? Works for me.

Richard

 

[misscrf]

sounds good. I had that in the old phone screen shot. I am still thinking about that. I do have the email in the main data, only because we will only capture one email per person. We don't plan on getting more, since it isn't our primary method for contacting people. One big reason to keep an email may only be if it is a work email that tells us somewhere they work for ie @courts.us.gov something like that.

Right now I am working on a way to have it all single, and then something more... If you look at my new screenshot of contactinfo, I am trying it with single form and then this is my thought. I put an add button for phone and for address. Then if they do add, I put a static read only version below, that shows the more than 1 records. It would be kind of greyed out. I am working on other code at the moment, and I am sure that that will take a bit of code too, but I think it might look good for the end user. If you want me to make a mock view of it, I will try.

My code problem right now is trying to get the tabbing to go from the salutataion, through candidate notes, and then if the attorney tab is open then through that. Then I want the tabbing to go straight to address, then to phone, then to application, and finally to activities. If anyone can help with tabbing between subforms, I would love the help.

Thanks Willir. I want to try this method for now, but when it gets too complicated, which I am sure it will, I will probably come back to your suggestion.

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[mph1]

I have been reading this thread from the beginning. You really appear to be rather conscientious about this project and are trying to learn. You are extremely fortunate to have two most capable individuals aiding (TheAceMan & willir). As you can see, making this as user friendly as possible is extremely important.

Suggestion ……. you may want to write a help (explanation) section and have a button on the form to bring this up. The idea is NOT to write a help section (similar to what this or other programs have), but instead a section that explains the concept of what you have done. If appropriate, use Popup ‘s or Controltip text as a reminder. Also, since space can become a problem, maybe create a report to show only the current record (

http://www.mvps.org/access/reports/rpt0002.htm).

An investment in knowledge always pays the best dividends.
by Benjamin Franklin
Autonumber Description - FAQ702-5106

 

[misscrf]

Thanks MPH. I have been thinking about those things a lot. I have comments in every field which should give the user something in the status. I will probably work on the control tip text as well. I am not sure about a lot of popups because I don't want to interupt their work.

I have been thinking that I will probably want to make a quick 1 person candidate report button right on the entry form too. That is a great idea. I will look into a help or info button as well. I might just put it on the main menu, and maybe even in a report format, so they can print it out for easy reference.

Thanks for the suggestions. If you can help with the tabbing issue I would love the help!

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[misscrf]

Hi, I'm back.

I got an answer to my tabbing question.

On Error GoTo Err_txtZip_Exit

Forms![frmCandidateEntry]![frmPhoneEntry].SetFocus
Forms![frmCandidateEntry]![frmPhoneEntry].Form![cmbPhoneTypeID].SetFocus

Exit_txtZip_Exit:
Exit Sub

Err_txtZip_Exit:
MsgBox Err.Description
Resume Exit_txtZip_Exit

for those who want it.

Anyway. I am at a new point in my subform testing.

I have a new form view:

http://www.geocities.com/misscrf/images/newsubformview.jpg

It shows 2 forms side by side. They only show 1 record each and only cycle one record.

Here is what I am looking for help on. I want to somehow put a duplicate read-only form under them that shows the addresses and phone numbers if there is more than one phone or address for a particular candidate. Does that make sense? If not, let me know. I can probably make a fake screen shot to show what I want to see....

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[willir]

misscrf

Here is what I am looking for help on. I want to somehow put a duplicate read-only form under them that shows the addresses and phone numbers if there is more than one phone or address for a particular candidate.

This is why a contineous form is useful. It would display all appropriate addresses. As you mentioned above, you will have more than one phone number where the end user has to click the next / previous buttons to see each record. Ditto for addresses.

Your call, but to have one form display the first address, and another forms display the second address is do-able but much more complicated than displaying an abbreviated address in the contineous form, and then the single form address is displayed either in a new form (popup), or in a single subform on the same page as the contineous form that is synchronized to the selected record in the contineous form.

As a side comment, you may wish to add to your table design a method of tracking which is the "primary" phone number and "primary" address. This is useful, because it gives you control on which phone number to display first, and which address to use for printing with a mail merge. The design change could as simple as adding a boolena yes/no field to the table deisgn - PrimaryAddress yes/no and PirmaryPhone yes/no. Coding gets a little difficult here since you have to ensure that only one record is selected as the primary.

and yes, you have done a lot of work, and I suspect you may be just about ready for "production". When your system is "in production", you will get feed back on what is liked and what areas could be improved upon. I value the end-user perspective since it will be more in tune to more effecient data entry. (And the mangers want better reports) My epxerience in the past has been that with a good, solid design, almost any requested / requried changes are mostly cosmetic. (And I consider a change to a form as mostly minor as long as there is no horrifc coding involved.) Where changes become difficult is with a badly designed database -- then changes often require database changes (which are always bad since forms, reports and queries have to be changed to accommodate the change), or queries become incredibly complex.

You seem to have a very good design.

 

[misscrf]

Thank you, Willir. I think that you are right. I think that I should go with the continous form design. I think that I know that I am over thinking the process and making it harder than I need to. I also think that I have said think many times. Too much db!! must get away!
lol

Anyway, I will look at putting those primary yes/no fields into the phone and address tables. I wonder if I can code it that if the candidate has a yes, the yes/no field goes to no automatically for the others. Then if the user clicks yes or no on any of then a message pops up telling them that there is already a primary, and do they want to change it? if they say yes, they all go to null, so that the user can choose one to make a yes. Does that sound right?

i will work on those changes today.

I am not sure about the application tab. If you look back at that screen shot, the subform with the activity subform in it, takes up the whole page tab. To make it continuous might not be enough to tell the user that there are more records, since they would only see the scroll bar, and might not realize that there are multiple applications. I will work with that as well.

I am excited to finish forms so that I can get to reports!
Thanks for the "continuous" input. lmao

misscrf

It is never too late to become what you could have been ~ George Eliot

 

[misscrf]

I figure that I have gone on to other specifics. So while I do have another post, I will make a new post for it. Thank you again for your wonderful advice, and I encourage you to check for my new post, which will be in forms. I will be discussing the checkbox and how to control it.

Thanks again!


misscrf

It is never too late to become what you could have been ~ George Eliot