Decisions

(1) Hike & Flower Keys: Keep the key structure for Hike, User, Flower. Would need a page that shows the next key for Hike, User, Flower.

Why: Allows us to merge old content with the new in a consistent way.

(2) Hike Rating: Drop the Hike Rating.

Why: Few hikers are rating hikes so the average rating value doesn’t mean much.

(3) Publication Status: Arrange for all new content to be marked “Published” as far as WordPress is concerned. Add our own Publication Status with our values (e.g., 1-Inactive, 2-In Process)

Why: We want to be able to work with hikes and schedule entries that haven’t been completed yet. Content is only visible in WordPress if it has been marked “Published”. There are some nice notifications that can be sent when a post has been published.

(4) Which Forms to Use: Use Pods Forms to add hikes, flowers, schedule entries, and groups. Use Pods forms for editing when file uploads are involved (hikes & flowers).

Why: Gravity Forms as of 7/20 doesn’t show in the Edit form which photos or gpx files have been uploaded, but does allow entries to be Published immediately. Pods forms show the photos and gpx files that have been uploaded, and allow the user to change the order that they are shown. Apparently Gravity Forms doesn’t store photos in the Media Library (where I want to be able to see them!).

(5) Hike Place Holders: Drop the Hike Place Holder and Exploratory record types and add a Trip record type. Move over-nights and exploratory hikes to separate locations.

Why: There isn’t much difference between a hike “in process” vs. a hike place holder. Trips, such as visits to pueblos or ghost towns, don’t have hiking as their main emphasis and can have a different set of data (no track or waypoints needed). Exploratory hikes might have a free-form content that might sometimes look like a standard hike and other times maybe just a collection of tracks obtained from another hiking group.

Cautions: There should be some minimal level of information provided to hikers before a hike actually happens (more than just the hike name and region). It shouldn’t be an Exploratory!

(6) Flower Sightings: Report flower sightings by Region and Season of the year (rather than by Hike and Date).

Why: Only a few people have contributed flower sightings, and nearby hikes would probably have the same flowers as the ones that have sightings reported. The data can easily be converted into this form. Additional flower sightings would be added primarily as supported by new flower photos. (One drawback is that in mountainous areas the flower population varies with altitude, so one region might have more variability than another one.)

(7) Estimated Return Time: Add estimated return time to the Schedule.

Why: The estimated return time only shows up in the Trip Release Forms for the Java website. Including it in the Schedule makes it visible. (Need to confirm with Hike Coordinators that the formula being used works for them — especially the 2 hr for breaks & lunch. Also ask about rounding up.)

(8) Hike Notices: Use Posts for Hike Notices.

Why: Need something that can be scheduled, and Posts can do that, either directly in the WordPress or as a newsletter in MailPoet. The post category can tie to a mailing list. Try to duplicate the main features of the Hike Notice (automatically sent, created from Schedule information). Also have a front-end User Submitted Post plugin that can be used to send content to a mailing list.

(9) Notifications: Use a separate Notifications plugin to notify the applicable set of editors when a new Hike or Flower has been “published” and needs to be reviewed (or to notify the Membership Chair that a person has submitted information to become a Hiker?).

Why: More convenient than trying to use MailPoet for that, though it might be possible.

(10) Drive Time One Way: Changed Drive Time One Way to be a choice of a time in 15 min intervals, starting with 15 min, and Average Grade to be a choice of 0 to 15.

Why: Drive time isn’t that accurate and don’t expect avg grade to be more precise.

(11) Permissions for Schedule Entries: Make it possible for both the hike leader and the hike coordinator to modify a Schedule Entry.

Why: Access is needed for hike leaders for Hike Change Notices and Hike Reports.

(12) Schedules for past years.  Save as TablePress tables in an “archives” location? Pros: easy to include old Java website info. Can filter TablePress tables easily. Can keep leader/driver names even when they aren’t active anymore. Cons: what happens to hike reports? Nice to have at least several years worth.

Why: Mostly used by hike coordinators in finding appropriate hike leaders for a hike when there are gaps in the schedule. If delete old schedule entries, will be deleting the info for the hike reports. What to do with Hike Reports? Could export them as pdf documents so wouldn’t be affected by deleting old schedule entries. But then wouldn’t be sortable