|Subdirectories and complexity|
example.com/xyz or example.com/xy/z
| 12:57 am on Feb 9, 2009 (gmt 0)|
I have a website with just 10 or so pages of content at the moment.
I plan on adding another page with a listing of physicians by state who offer a niche treatment. Some of those listings will also have my comments next to them along with physician name and website links.
I could just do one page (e.g., www.example.com/ physicians.html), and that would be a mammoth page. However, navigation on this mammoth page would be easy since at the top of the page a visitor could click on his/her state of interest and the page would move to that state's listing (I would use the # command to do that) instead of the user having to scroll all the way down.
Another option (which might help me with Adsense, although I don't expect to get too many visitors to these pages) would be to have many separate subdomains for each of the 50 plus US states and possibly for a few other English speaking countries in the future.
I would thing that the one page thing is more user and programmer friendly and faster to navigate? I can only put around 5 total Adsense ads on the one page, so I would lose some revenue.
However, are there any other factors I should consider in favor of the multiple page concept before starting this project?
[edited by: encyclo at 2:40 am (utc) on Feb. 11, 2009]
[edit reason] switched to example.com [/edit]
| 12:31 am on Feb 11, 2009 (gmt 0)|
First, let me say that these are not subdomains:
a subdomain would be something such as:
What you had was just a "physicians" directory with a separate page for each state, all on the same domain.
It sounds like you plan to expand your index of physicians, so I would recommend a database-driven site. This will let you add new records with much greater ease than hand-coding hundreds of HTML records.
You could have a "physicians.php" file where the user can select a state, which will return the "physicians.php?state=alaska" with the appropriate data from the database.
Using a database, you can add, delete, and modify reccords easily, and it is generally a much more practical way of storing data.
[edited by: encyclo at 2:39 am (utc) on Feb. 11, 2009]
[edit reason] switched to example.com [/edit]
| 2:31 am on Feb 11, 2009 (gmt 0)|
Using a database driven application does make sense, although if you are still wanting to simply use pages to store information then I suggest not storing all the information on one page. If you spread the content across multiple pages it make the site a lot easier for your user.
For example what I would want to acheive would be a page per state, but dont just limit it to one page. I suggest perhaps limiting the number of listings to 20 per page. So if you have only 15 listings for one state it would be one page. If you have 25 it would be 2 pages and so on.
As Webfoo mentioned a database driven site is certainly a good idea. There are in fact database driven directory applications that would allow you to run this sort of website with little or no modifications. there are even some free scripts that would be able to handle this type of site.
You might want to take a look through hotscripts.com from there you can search for a suitable directory script.
I hope this gives you some ideas.
| 11:33 pm on Mar 15, 2009 (gmt 0)|
Thanks for the replies guys.
I only know basic html and even more basic CSS.
What language would I need to learn (php?) to create a basic database? I want to create something very very basic and fast.
Also, can I put in a World map and people can drag their cursor over the specific country and click on that country to go to that country's record in the database?
| 11:51 pm on Mar 15, 2009 (gmt 0)|
PHP is the best for database-driven websites. In combination, of course, with MySQL. I reccomend W3School's PHP tutorials.
For your map idea. I would make an imagemap in HTML that links to your data reccords for that country.
| 1:06 am on Mar 16, 2009 (gmt 0)|
"Php is the best for data driven websites"
Hey, my website is not data driven. Its only this one section that might require a database. Thats why I want to use the easiest and simplest database type solution, and not spend too much time on learning php as well as mysql if possible. I suppose php (+ msql) is still the best way?
| 9:35 am on Mar 16, 2009 (gmt 0)|
I had the problem once of putting in a set of artist discographies on a site without the luxury of a database. The most maintainable solution at the time turned out to be frames. List of names on one side, page for each artist on the other.
A alternative solution that indexed better in search engines would be nice but the pages aren't critical to the site and it has never been worth the time and effort of reworking them.