In developing a membership registration form for our website, I am looking to include a "Date of Birth" field. However, the "Date" field type appears to only allow one method of entering a date. In our organization, there are many members who are older, and for whom the date entry requires navigation to their respective year of birth, which presents difficulty due to the method of data entry, and the propensity of our older members to be uncomfortable using computers.

(Admittedly, the calendar default of starting on today's date does lend itself to certain types of fields, like booking hotels or flights.)

It would be more intuitive and easier to use a method of entering data into the date field using three drop-down menus, like "Month", "Day", and "Year." I suppose I could do that myself by creating those 3 fields, but that opens up entry errors, like somebody entering "February 30" as a date, for example.

I recommend that the Wild Apricot team considers implementing an option such as the one I have suggested; it seems to be the more common method of entering dates into electronic forms, and would ease the burden on less-experienced users to navigate an unfamiliar date selection format.

I would love to hear what other users have experienced when utilizing the "Date" field in forms, if they have had difficulty, and what they have done to address user feedback in using it.

Would like to request accessibility features to be added to the site's templates including:

FORMS:

Add label tags around the form's labels, and associate the labels with their form fields using IDs (explanation: http://webaim.org/techniques/forms/screen_reader.php#labels)

Group form controls using fieldsets and legends, where appropriate (explanation: http://webaim.org/techniques/forms/screen_reader.php#group).

NAVIGATION:

Add a "skip navigation feature" to allow keyboard users to skip over the navigation menus, when they are tabbing thru links on a page. (explanation: http://webaim.org/techniques/skipnav/#focus).

These features would make the sites more accessible to disabled users (people who cannot use mouse, blind people using screenreader software, etc) and help make them more compliant with the US government's Section 508 guidelines.

I would tell anyone with big websites that the conversion is the most difficult part of going to Wild Apricot, especially when there is need to convert many pages. The conversion process was quite painful. We had php pages with very simple and clean html code. Our subcontractor apparently copied and pasted from the displayed webpage instead. This resulted in poor conversion of links and images. Where we had had had a central repository folder for all the images on the old website, we ended up after the conversion having images attached separately to each page and in many cases links going back to the soon-to-be-defunct website. After the contractor was done, our volunteers had to recreate the central repository of images and revise every page manually and redirect links to that common images folder or to pages on the new website and away from the old website. There must be things WA could do or recommend to make this conversion process easier.

I would like to be able to pull individual data fields from the contact database and insert them dynamically within my content. This would, I feel, make pages more dynamic, reduce my workload, allow a high level of personaliation of member content and, I feel, enable member websites to become a little more sticky, creative and innovative. What do you think?

For example, I'd like to personalise content for each chapter/member but the content would be the same for each chapter/member. With the current system every time I create a new piece of content I then have to dupliate that piece of content for each additional chapter/member. Hence, the ability to pull a field (e.g. Chapter Name | Member Name) from the database would, I feel, allow me to create better websites that could be potentially more sticky to members.

It wouldn't stop at chapter/member names, I could use this for a myriad of stuff including personalising member content, creating dynamic content by getting clever with the contact database; I feel it would open up lots of new opportunities.

In the past I've used some sort of ODBC call on asp pages to access the database. Would the development of an API to achieve the above be useful to anybody else?

I'd really like to hear everybody's thoughts and ideas.

Kind regards
Steve

I thought it would be good to have a "Member-focused SEO" category here, because there are several SEO-related features (not 301 redirects) that my client's members have requested.

Since switching to WA 4 months ago, there has been some attrition of members because more and more, people are seeking better SEO placement through membership organization websites. Their biggest motivation in joining is for the public to be able to find them.

Specifically requested features:

--Customized URL's for publicly viewable member profile pages (so we can include member or practice names in the URL)

--SEO index (.xml) *including member pages* and member directory, in addition to site pages and public blogs.

--Integrated web stats with access to usage on member profiles. I.e. - how many views/visits on a member's profile page, search terms used to find member, etc. This is to be competitive with other high profile membership directories, e.g. Psychology Today.

Can such category be created, and should I post for each of these separately there?

Many thanks.