Talk:Meta:US Structure

US State / County Structure
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.
 * Yes, and thanks The Earl 07:41, 10 March 2008 (MDT)


 * 1) Is the proposal that we should seperate 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.
 * 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)


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


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

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.