Thoughts on Hike Database Functionality and Design

Date: June 21, 2008

To: Web Redesign Committee

From: Ed Goodell

Copy: Dan Chazin

Re: Hike Database Functionality and Design


I spoke with Dan earlier this week about the Hike Database. He was very pleased to see Doug Cleek's design treatment and thought it a major improvement over the current default display on the website. Below I will describe some of Dan's comments and then offer my own thoughts on the search function.


Dan's Comments

  1. Dan has already begun going through all the hikes and giving them each a name. Right now, each is simply given the park name, resulting in multiple hikes having the same name.
  2. Dan is also willing to note any update dates, bus/train transportation options, and any non-Loop (i.e. circuit) hikes (he estimates that 90% are Loop Hikes) and any other features that we want to include. (See below.)
  3. To get the above information into our database, I suggest the following process:
    1. Each of the Hikes should be printed out in Hike Name (i.e. Park Name) order and put into a 3 ring binder.
    2. Dan will go through the hikes and mark them up.
    3. A Web Redesign volunteer will revise our hike database using the mark-up comments.
    4. (We need to identify a volunteer to help with this. Fortunately, it can be done from home.)

** As you know Dan is involved in many projects and coordination of his efforts will need to be actively managed by us ... (Do you want to take this on Georgette?)

  1. Dan had the following thoughts about the Features Items:
    1. Waterfall-OK but probably should add Pond/Lake as another featured item
    2. Cliffs-Dan didn't see how to apply this objectively
    3. Birding-Not something that Dan can comment on (aren't they everywhere). Perhaps a birding volunteer could help us, or we could poll users about its popularity before putting a lot of effort in.
    4. Wildflowers-Could work if someone knowledgeable would annotate them (ditto the Birding comment)
    5. Panoramic View-Change to "Viewpoint"
    6. Handicap accessible-doesn't apply much now but could in the future
    7. Feature Items to add:

i. Lake/Pond

ii. Camping allowed

iii. Mountain biking (only if the entire hike is open to biking)

iv. Cross-country skiing (portions of the hike OK)

v. Fees (Parking, Parking Seasonally, Per Person, Per Person Seasonally)

vi. Mines


Thoughts on the search function

  1. Could the Feature Items above be handled like the Difficulty is currently? (i.e. Being able to choose as many or little of the features and having the search functions, "All of," "None of," and "One of." Actually "Any of" is probably more correct than "One of.")
  2. Recognizing that we don't want to create an overly complicated search scheme, I wonder if the same search approach as on "Difficulty" and suggested above for "Features" could be applied to a selection of other fields, which have multiple values, as below:
    1. Publication Date (Previous 30 days, Previous Year, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000)
    2. Route Type: (Loop, There & Back, Shuttle)
    3. Distance: (>X, <Y) or (<3 miles, 3-6 miles, 6-10 miles, >10 miles)
    4. Time: (search similar to distance)
    5. Region: (List of Regions)
    6. Park: (List of Parks)
    7. State: (NY, NJ, PA, CT, MA)
  3. New Searches that could be created from existing data
    1. State/Region/Park: (Eliminate above 2 categories by creating a heretical list of parks by region with ability to choose individual regions and/or parks.)
    2. County/State: (Combine County and State as in the Region/Park example.
    3. Public Transportation: (Bus, Train) (Currently the database has memo fields for Auto, Train, and Bus that can hold the directions for using either type of transportation. Probably need to link this with a yes/no attribute if we are to search by it.)
  4. Killer features we should consider implementing
    1. Latitude and Longitude for trail head to allow trip planning and route mapping of transportation.
    2. Search based on max distance from existing zip code
    3. Ability for readers to rank and comment on hikes
    4. Searches by average Hike Rankings
    5. Ability to create lists of favorite hikes
    6. Ability to submit new hikes
    7. Ability to submit photos for existing and new hikes
    8. Ability to submit and map GPS tracks for existing and new hikes


Recommendation for Search Functions (at Launch)

I think we should implement 4 Search Functions, which can be individually set up as preferred and then implemented with a single button-FIND HIKES or SEARCH HIKE DATABASE. I think there is enough room over the Table to set up 4 search columns, each one with a search settings and drop down list that are individually selectable.

  1. Search by Difficulty (Need definitions; see Distance below.)
  2. Search by State/Region(Park?)
  3. Search by Distance (Time could be more useful but is so subjective as to be almost meaningless unless a common protocol is strictly enforced, which is impossible with public submissions. I think we should establish and publish a formula that relates the Difficulty measures to miles/hour for an average adult. With that formula, it would be easy to calculate any variable-Time, Distance or Difficulty-with two of the three attributes.)
  4. Search by Features (See added/changed features above.)


Recommendation for Hike Table

I would minimize the number of columns and put them in the following order. The rows would appear based on the following sort order: State/Park/Submission Date (descending order).

  1. Title (Click through to description)
  2. Park
  3. State (replace by distance to zip code ASAP)
  4. Length
  5. Difficulty
  6. Submitter (Click through to table of all hikes by this submitter)
  7. Submission Date
  • *Submitter may not be of interest to many. Submission Date probably even less.


Recommendation for Hike Description View

  1. Header: Hike Title, Park Name, Region
  2. Table of brief information
    1. Short description
    2. Features (can these be concatenated?)
    3. Difficulty
    4. Distance
    5. Time
    6. Dogs
    7. Directions (click through to bottom of page or Google coordinates)
    8. Park (click through to TC web page for Park page)
    9. Region (click through to Region page)
    10. Submitter (click through to table of submitters hikes) and Submission Date
  3. Photo and Map tabs are wonderful and should advertise for submissions. Could a slide show or gallery be clicked through to?
  4. Would like to have Comments and Ranking functions.







Comment: Please be relevant, civil, non-commercial.

Feedback on Doug's pdf and Dan and Ed's comments

Re: Doug's mockups

I prefer the look of the first two pages in the .pdf file.

A few small comments:

On the Hike Database page search bar:

It may be confusing to have "Search by Difficulty" and "Search by Detail" appear twice -- will the users know which is the caption and which the search button? Where can one find out what the difference is between, for example, Easy and Moderate?

For details, I like Views, Public Transportation, Dogs allowed. I might be happy with a simple search term of "Special features" rather than specific items, assuming it mapped to a field that was either empty or filled in. That would allow things like "birding", "hawk migration", "blueberries", "spring peepers", "mountain laurel", "Indian ruins" and such to be noted. If a trail had no special features, it wouldn't be listed.

I like the idea of limiting my search by geography (State, Region, Park plus any other fields we can use). That might require another search box.

In the Hikes Database page table:

Move the Date field to the far right

I'd like to know the elevation gain for the hike ... do we keep that info in the database?

On the Find a Hike page:

I'd rearrange the order of the fields displayed in the summary table. Submitter should go at the end. Should we also include things like Fees, Handicap access and Public transportation in the summary table?


Notes on Dan's comments:

I'd be willing to volunteer to revise the hike database to incorporate Dan's comments -- it'll get me familiar with the process.

Notes on Ed's comments:

We need further discussion on the "killer features" that allow anyone to submit new hike info -- who confirms the accuracy of the info? What's the process involved?

Let's keep things simple where we can for the initial launch. We can alway add bells and whistles later.

Revising Hike Database

I would be happy to introduce Ann to this database, and the site overall, if needed.

hike description view

All of these are doable and currently implemented (more or less). (need to figure out how to get a name anchor on the description tag, #description then the link is just a constant link to #description. A rating module is currently not loaded. There are several - need to pick one. The common one is 5-star where people rate by #stars and the display shows an average. There are also fancy ones which give people points for rating things or having highly rated submissions, etc. Points are spendable. There are several photo gallery options, e.g. a single picture can be a carousel, if you click on it you can next your way though the gallery. We need to pick one and stick with it sitewide. Perhaps I can put up several examples and we can vote on one.

5 star

I have added the 5 star rating system to Hikes and Trails. It is just one checkbox to add it to other node types. See for an example where I rated it. The hike table view should show the rating in one column and maybe searchable. I have used the default image of a star, but we could go with boots or any other image. That is easy to change but someone has to produce the image.

hike table

zipcode distance is currently not implementable - the required module is broken and no one seems to be working on it. We might consider paying someone to make it work (an honored tradition in the Drupal community). I am a little wary of spending the space on a submitter column. It might be good enough (better) for each hike to have a button for displaying other hikes by this person.

Submitter name

O.K., eliminate submitter then. If it seemed like a good idea later on, we can add it.


agree I need to do some experiments with successive narrowing searches. I need to do some experiments with multi-criteria searches, e.g. moderate hike with dog. I don't know the answers - may be easy and if so will do.

Search Function Research

Could the webmaster please give an update on his research into this matter?  The designer cannot go forward with design until the capabilities are known. 

water features

I think we need to be a bit more expansive here. Perhaps: fishalbe, swimable, boatable, default is scenic. There is an apocophal tail about the AT hiker that started at Springer with a foldaboat because he knew he would need it to cross the Kennebec.

cliffs and views

I agree to remove cliffs and change panoramic to just view. We could get fancy on views with subcategories of: seasonal, panoramic, narrow, flawed (by powerlines - good visually - bad for a photo). I think KISS.

birds and flowers

These checkboxes are very useful for certain subsets of hikers (as is the skiing box). Perhaps we need levels of expertise for marking these boxes when submitting hikes, i.e. most people aren't allowed to mark them. Anyone can search them.

multiuse on hikes

This is a hard thing to code accurately. Many hikes have sections that are multiuse. There is also the issue of defacto practice vs legality. The average hiker only cares about what they will encounter, not what is legal. However our database will be used by bikers and they need to know the legal answer. In doing Walkable Westchester we sometime found it useful to distinguish between ones good for snowshoeing vs cross country skiing. Our typically light snow cover precludes skiing on rocky trails that are still ok for snowshoeing. Just one tricky place precludes all but advanced skiers. Other than Breakneck Ridge and a few others, I would snowshoe almost any of the trails in the area. Hence I think we should leave snowshoe off the list. We should restrict marking anything but easy to moderate skiing trails, the best of the best, i.e. we need people who have actually skied them to mark them (or at least ones you have actually seen ski tracks on).

multiuse trails in parks

My concern is with multiuse trails in PARKS.

In the Parks/view window "Trail Types" [note plural] is featured in the second column. But only one choice is allowed out of eight possibilities -- and "hiking only" is rarely the appropriate choice. For mixed use there is no good single selection to make, so a very large percentage of the parks I've completed have nothing entered in this category. I generally note mixed trail use in my narrative. As Walt knows the couple times I selected multiple entries I created multiple parks instead! (see Blackriver WMA).

If several choices cannot be programmed for a single park, then there should only be two choices:

  • Hiking only
  • Multiple use trails

Multiuse designation

In discussion with Dan, he and I were talking about whether or not biking was allowed (i.e. legal).  And we were in agreement that biking would need to be allowed on the entire route for it to be designated "Mtn. Bikes Allowed."

new view to assist printing database

view/hikes-list Puts all the hikes in one long list with the description shown only as a teaser to keep the paper consumption down. I thought I told it to sort but it doesn't seem to have sorted - bug for another day. If I were doing this, I would forgo the paper and just edit each hike. But I understand that Daniel really prefers editing on paper.

Implementation of hike database

I forgot to acknowledge in my memo on the hike database that some of the functionality, which I am suggesting, may not possible due to constraints of the Drupal database or a lack of available data.