Talk:Meta:US Structure

US State / County Structure
We need to develop a structure for articles on geographic entities in the United States. Please contribute your ideas, and critiques to this page. Feel free to comment inline below, or in a new section. Please sign your articles with ~.

Assertions
We need to restrict this discussion a bit so we don't spend forever working out every detail. Assertions are proposed as follows:


 * All solutions are sub-optimal
 * All solutions to this problem are not going to be able to satisfy all of the requirements and possibilities needed. We will have to have trade-offs in some places.


 * United States only
 * We will restrict this debate to the United States only.
 * This is likely the most commonly understood nation for this group.
 * This will include oddities in the US like previous governments, tribal lands, unincorporated areas, territories, moving borders and others. If you have other uncommon places, please add them here
 * We will NOT include places outside the US, except where those places need to be differentiated from places in the US. For instance, places named 'Washington' outside of the US would need to be differentiated from places in the US.


 * Rarer exceptions will not fit the structure
 * It is likely that any structure we develop will not work for certain exceptions. We accept that some things may be in weird places, or need unusual navigation to get to.
 * Handling of rare exceptions should not be the focus of this structure, but should not be ignored. Points will be awarded to elegant handling of these exceptions.


 * Time is HUGE
 * All of the entities that fit into this structure have changed over time. The structure needs to be able to differentiate between current, and historical information, as well as information that existed before the entitiy.

'''Please refute these, or add to them as needed. We need as much discussion about what to discuss as we do solutions to the problem.'''

Requirements
We need a list of problems that we need to address. We also need a list of features we would like in a solution


 *  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.

'''Please refute these, or add to them as needed. Please also comment on relative priorities, 'Musts' are required, but the others may or may not be important to you. We need as much discussion about what to discuss as we do solutions to the problem.'''

Exceptions
There are a number of issues that do not fit nicely into the 'State, County, City' hirearchy. Please add your exceptions and ideas here.


 * Colonial and pre-incorporation records
 * Where should colonial records appear. Should there be a link called 'New York, 1400-1770'. What would you put in the 'Utah, 1400-1770' article? What do you do for lands that were Dutch, French or Mexican that are now part of the US?
 * Indian lands, tribes and records
 * Should these be under the federal level, or linked from each state? Should these be by tribe? What do you do if a tribe, or land goes away, or moves?
 * Cross-state and cross-county cities
 * Which state or county do you put them in? How would a user find the city, or where to look for the city?
 * Ellis Island
 * Does Ellis Island go at the federal level, or as part of New York State, or New York City, or New Jersey?

'''ADD ADD ADD! We need as much discussion about what to discuss as we do solutions to the problem.'''

Solutions
Propose a solution here.

Previous Discussion
In navigating through the US portal, I have come up with a suggested structure for the US.

I am most interested in building a resource for people looking for vital record repositories in locations in the US. I think this is an important resource, as it is very easy to verify its accuracy, and imminently useful to new and potentially new users. Working in the US gives me a chance to try this in a well understood environment. It is hoped that the lessons I learn here can help those looking to build a similar resource for other areas of the world.

So I propose that we make it simplicity itself to get to a given county in a given state in the US, and post the contact info for local FHCs, vital record offices, and allow locals to post contact info if they are willing to help with the footwork. Links to local research lines, or public prominent families could be available here as well.

Structure as follows:

Main articles:

Additional levels may be needed for large cities, or public prominent family histories, but these would be added as-needed.

Corresponding Template and Portal sections would be needed as well. It is hoped that with a proper template system, very little work would be needed to build out and maintain this area. Additionally, the portals would allow easy navigation and summary of the main articles.

I'm having trouble understanding the proposal.


 * 1) Is the proposal that we should link to all state portals from the United States portal, link to all a state's county and city portals from the state portal, link to all a county's cities and townships from the county portal, etc.? If so, I strongly agree. A bunch of people want to do this; we just haven't had enough bodies to get it done. Ritcheymt 10:34, 12 March 2008 (MDT)


 * Yes, and thanks The Earl 07:41, 10 March 2008 (MDT)
 * Yes, and thanks The Earl 07:41, 10 March 2008 (MDT)


 * 1) Is the proposal that we should separate a country's portal pages from its main article page? We tried something like that when we were still using Plone and it was counterintuitive to the users. Since each place had multiple "main pages," users didn't know where to find the information they needed regarding a place. It felt like the user experience of Wikipedia's Portal:India page vs. their India page. Ritcheymt 10:34, 12 March 2008 (MDT)


 * I would hope that the Portal page would summarize the main article, and link to the main article. Currently, the portals show a few content boxes, while the main article is more free-form. I hope that as long as the portal points to the main page (which is not the case always now) this confusion would be limited The Earl 07:41, 10 March 2008 (MDT)
 * I would hope that the Portal page would summarize the main article, and link to the main article. Currently, the portals show a few content boxes, while the main article is more free-form. I hope that as long as the portal points to the main page (which is not the case always now) this confusion would be limited The Earl 07:41, 10 March 2008 (MDT)


 * Currently some localities have both a portal page and another page taken from the research outline that's mostly text in paragraphs. It is confusing, as you mentioned. Our plan is to consolidate these two pages into one portal page. Ritcheymt 10:34, 12 March 2008 (MDT)


 * This seems backwards to me of the way a portal should work. Please explain where I can get more information on "Our plan". Thanks The Earl 11:59, 12 March 2008 (MDT)


 * 1) Is the proposal that we should create some standards or at least best practices for the naming of a place page? If so, I strongly agree. I think Wikipedia folks have found this useful. For instance, I think I recall some user this past week naming a page about a county "Washington." Well, there are a lot of places named Washington, so this title was  ambiguous and will need clarification.


 * Agreed, this is the crux of why I propose this structure. The Earl 07:41, 10 March 2008 (MDT)
 * Agreed, this is the crux of why I propose this structure. The Earl 07:41, 10 March 2008 (MDT)


 * Clarification of ambiguous page titles in Wikipedia is handled through disambiguation pages. See Wikipedia's Washington page and their Washington (disambiguation) page. It seems to be a good model, and helps prevent naming conventions that would spam the search engine. Ritcheymt 10:46, 12 March 2008 (MDT)


 * I get the disambiguation page, but the articles AFTER the disambiguation page all have other identifying information in them, ie 'Washington,_Arkansas', 'Washington_DC', etc. I think a disambiguation page is needed here as well, I am just proposing a structure for the main articles that the disambiguation would link to. The disambiguation page does not prevent search engine spam at the Wikipedia site, searching on 'Washington' gets you all of those pages, and the disambiguation page. Searching on 'Arkansas' should, IMO return 'Washington,_Arkansas' as well, but in a bit more friendly order, not its current Wikipedia behavior of taking you to the article 'Arkansas'. Currently on Wikipedia, you cannot find 'Washington,_Arkansas' via an 'Arkansas' search, nor through the 'Arkansas' category or article. Thanks The Earl 11:59, 12 March 2008 (MDT)


 * 1) Is the proposal that we should use slashes and underscores in article titles? If so, I disagree. We shouldn't use characters that are unintuitive to users because it will break Exact Match searching. Ritcheymt 10:34, 12 March 2008 (MDT)


 * Spaces are automagically converted to underscores in wiki links already. I think the search knows how to handle them. Do you have a different character / structure that would work in place of the slash? The Earl 07:41, 10 March 2008 (MDT)
 * Spaces are automagically converted to underscores in wiki links already. I think the search knows how to handle them. Do you have a different character / structure that would work in place of the slash? The Earl 07:41, 10 March 2008 (MDT)


 * 1) Is the proposal that we should follow an article naming convention that would result in an article name of, say, "US/Utah"? I'd disagree with that proposal because anybody doing a search on "US" would see this Utah article in search results. It would spam the search engine. If they were looking for Utah, they would use the term "utah" and if they were looking for United States, they'd use "united states." Ritcheymt 10:34, 12 March 2008 (MDT)


 * Is US/Utah not relevant to 'US'? Where would you look for 'New York'? See my comments below on this. The Earl 07:41, 10 March 2008 (MDT)
 * Is US/Utah not relevant to 'US'? Where would you look for 'New York'? See my comments below on this. The Earl 07:41, 10 March 2008 (MDT)


 * 1) Is the proposal that we should use acronyms as country codes in article titles? If so, I disagree because acronyms are intuitive only to the initiated, not the rank and file of users. Even the initiated can find acronyms confusing. For instance, most Americans find several state postal codes confusing even though this system has been in place for decades. Ritcheymt 10:34, 12 March 2008 (MDT)


 * Agreed, but I can not think of a better solution. Hopefully the portal / navigation will help the uninitiated find what they need, while a good structure will help more experienced users navigate without walking the tree. The Earl 07:41, 10 March 2008 (MDT)
 * Agreed, but I can not think of a better solution. Hopefully the portal / navigation will help the uninitiated find what they need, while a good structure will help more experienced users navigate without walking the tree. The Earl 07:41, 10 March 2008 (MDT)


 * 1) If the proposal is that we should mention, cover, or link to pages about prominent families or families of interest from a place portal, this idea, while exciting, can also lead to big problems. Where does one draw the line regarding how many families are listed for a place? A list of "prominent families" can feel like a private club to those whose families are excluded; how does one define prominence and avoid conflict over who is excluded? A list of "families of interest" of a place could be scores of printed pages long, so how would one keep the pages a reasonable size, and how would these lists be kept from spamming the search engine? These concerns have caused us to place information about families and individuals outside the scope of this site. Information about families and individuals doesn't necessarily have to remain outside the site's scope forever, but to be included, the abovementioned issues need to be addressed first. Ritcheymt 10:34, 12 March 2008 (MDT)


 * The word 'public' hides in that statement. The family information included above should be constrained to only the families you would find in an encyclopedia article on the place, ie 'public prominence'. Other families could be linked from the main article, but that would be subject to the policy above. I don't think that families add much to the portal, and would not include any there. The Earl 07:41, 10 March 2008 (MDT)
 * 'Public' shows in the bottom description, but did not used to show at the top. I goofed. Thanks The Earl 08:16, 10 March 2008 (MDT)
 * 'Public' shows in the bottom description, but did not used to show at the top. I goofed. Thanks The Earl 08:16, 10 March 2008 (MDT)

Ritcheymt 15:40, 9 March 2008 (MDT)

The confusion listed above of 'Washington County' is exactly what I hope to address with this structure. We need a way to differentiate places. Currently if you search for 'New York', or look at the New York category you get a list of ~400 articles. Since New York is a city, a state and a county, there is no indication as to which of these the articles above reference. In many cases, the articles mix information about NY County and NY City, since these two places are very close to the same. Some of the articles include information from all three New Yorks. Some of the articles include information on Brooklyn (Kings Co.), but you can only find this information with a keyword search, and the information is spread over a few pages. Already at this early stage, the NY information is getting hard to find, and confused about its identity.

Looking for a place called Washington gives us a whole new set of headaches. We end up with LOTS of Washington Couties, a good handful of cities, and even two 'states'. Things get even more interesting if you look up names that the US repeated from overseas.

So if we are going to differentiate between 'Washington Co. Utah', and Washington DC, and Washington Co. elsewhere, we need to name them differently. If we have to put the differentiating information in the name of the page, then why not US/WashingtonDC, US/Washington, US/Utah/Washington, etc? Can you come up with a system that is more intuitive, and prettier? Please do!

I do not think that my solution is perfect, so feel free to poke holes in it. I posted this proposal because I think we need a structure, and we need to agree on one before someone (like me) goes off spamming the wiki.

My hope is that with a good structure, the templates will write the pages for us, and we will just have to fill in the relevant information. I hope that we can do this early with a few page moves, rather than later when we would have to hack and slash to get things into a framework. The Earl 07:41, 10 March 2008 (MDT)

I thought it might be wise to have a 'drill-down' structure.

Example: United States,Utah, Davis

For large cities, add the city after the county name, e. g. Bountiful would follow Davis in the example above. That would take care of the problem of multiple links and would allow users to simply drill down into the content they were looking for. Does that sound doable? JamesAnderson 14:04, 12 March 2008 (MDT)

The layout did not work like it should have on the listing of the levels I was talking about.

United States, Utah, Davis

Or United States, Utah, Davis, Bountiful if the cities level is used for a county.

JamesAnderson 14:08, 12 March 2008 (MDT)

I don't understand your 'Layout didn't work' comment, but I agree with your ideas. I think a better order would be opposite the way you propose. I think I need to back up a bit and explain some of the driving forces behind why my suggestions are as they are. Keep tuned, I hope to get a tight framework built out here. Thanks The Earl 12:46, 13 March 2008 (MDT)