FamilySearch Wiki talk:Naming Conventions: Difference between revisions

FamilySearch Wiki talk:Naming Conventions (view source)

Revision as of 09:25, 31 March 2008

2,807 bytes added , 31 March 2008

no edit summary

VisualWikitext

RitcheyMT

4,497

edits

@@ Line 25: / Line 25: @@
 # Including all jurisdictional handles in a title tends to result in many undesired search engine results. Thus, if towns are named like "Rockville, Montgomery County, Maryland, United States," an article on tax records of the town might be titled "Tax Records of Rockville, Montgomery County, Maryland, United States." But under such a system, if a user trying to find United States federal tax records searches "United States tax," the search engine results will list every article on tax records for every town in the U.S. rather than just articles on United States federal tax records.<br>
-<br> <!--{12069763876712} --> <!--{12069763876713} -->
+* '''Musts'''
+** Names must be unique to a place. This is enforced by the wikimedia software.
+** Names must be human readable. Names show in lots of places on the page. People have to know what they are looking at, and make sense of how the page title relates to the place they are looking for.
+* '''Shoulds'''
+** Names should be computer readable. Generally, if names are human readable, they are also computer readable, but this is not always the case.
+** Names should include a hierarchy. Hierarchical names facilitate navigation, and also point to higher and lower level places related to the place. For example, the bare name 'Washington' does not indicate whether it is a part of a larger state, or a county, nor does the name indicate if it is a link to a smaller place like a city, or a larger place like a state.
+** Names should be accessible by the search function. It does no good to name a place a cool name, then prevent users from finding it because the search engine can't.
+** Names should allow for smaller divisions. Currently, we are looking at states and counties, but we may add cities, wards, districts, neighborhoods, families or other smaller organizations.
+** Names should allow for dates. Looking for records in NY in 1770 is very different than looking in 1970. This structure should allow that.
+** Names should be easy to differentiate. A user should not have to look to the 70th character of a name to decide if it is a state, or county.
+** Names should show in the search page approximately ranked such that a users intended result is very near the top. A search for 'Washington DC' should show the district article in the first few articles listed. If it shows further down, or on additional pages, users will have a hard time finding it.
+** Name structure should be easy for people to remember. It should be possible for an experienced editor to manually enter a link to an article without having to search the wiki first.
+* '''Should Nots'''
+** Names should not ignore places outside the US. Eventually we WILL have to build a structure for the whole world.
+** Names should not show in the search box if they are not relevant to the search entered. Getting a bunch of search results named 'Not Washington DC' is not going to help you find 'Washington DC'. Additionally, including the entire hierarchy in the name of the page may result in getting lots of detailed articles (county and city level) when looking at a much higher lever (federal)
+** Names should not contain abbreviations or acronyms. Shorter names means fewer characters to differentiate names, and may confuse users.
+** Names should not contain redundant information. Names like 'Utah County, County, Utah State, State' are hard to read, and difficult to type and search for.
+<br> <!--{12069771115150} --> <!--{12069771115151} -->
+<!--{12069771115152} -->
 == Resources ==