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.

We allow our members to upload photos into a photo album shown with their Profile. Our level allows each image to be up to 25MB and that is way too big for viewing satisfactorily and will also use up our maximum allowed MB in no time. We also have no way to limit the number of images in an album. The automatic features of limiting how many albums there are is nice as is the automatic thumbnail feature with a click to show the full image. However, we really need to be able to control the number and size of each image uploaded. Please consider adding this.

Site admin for http://www.papnm.org

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.