Jump to content

FamilySearch Wiki talk:The Un-Portal Page: Difference between revisions

Comment
No edit summary
(Comment)
Line 13: Line 13:
== Discussion  ==
== Discussion  ==


=== Lerman ===
=== Lerman ===


Having dealt with search engines and looking at the source for a portal page, I do not think I agree with the statement that says that search engines do not index portal pages or has problems indexing portal pages.  
Having dealt with search engines and looking at the source for a portal page, I do not think I agree with the statement that says that search engines do not index portal pages or has problems indexing portal pages.  
Line 38: Line 38:
Well, that is all for now. I cannot think of anything else at this moment, maybe because I have to run to another appointment. [[User:Thomas Lerman|Thomas Lerman]] 16:02, 17 June 2009 (UTC)  
Well, that is all for now. I cannot think of anything else at this moment, maybe because I have to run to another appointment. [[User:Thomas Lerman|Thomas Lerman]] 16:02, 17 June 2009 (UTC)  


<br>
<br>  
 
=== Adkins  ===


=== Adkins ===
Portal or no, the format of it is very important.  
Portal or no, the format of it is very important.  


Line 51: Line 52:
3) Topics  
3) Topics  


News, if long, should be a teaser at the most, then a link. It should never be regarded as more important to display than&nbsp;research items, as&nbsp;above.
News, if long, should be a teaser at the most, then a link. It should never be regarded as more important to display than&nbsp;research items, as&nbsp;above.  


<br>


=== G Fröberg Morris ===
=== G Fröberg Morris ===


I appreciate Lermans insight and thoughts into this and agree with his comments. I'm not convinced the UnPortal really does help with search engine indexing. Given the sheer size of 2 million plus articles in the English Wikipedia and their heavy use of the Portal, they don't seem to be worried about Portal or UnPortal. As far as my experience, generally the Denmark and Sweden content comes up pretty quick using key words in a search engine. Maybe the general standardization of titles and formatting has helped. I do like the UnPortal in relation to ease of use. I'd like to suggest leaving the Portals as a Gate, and using UnPortals for SubPortal, or even individual article pages. <br>
I appreciate Lermans insight and thoughts into this and agree with his comments. I'm not convinced the UnPortal really does help with search engine indexing. Given the sheer size of 2 million plus articles in the English Wikipedia and their heavy use of the Portal, they don't seem to be worried about Portal or UnPortal. As far as my experience, generally the Denmark and Sweden content comes up pretty quick using key words in a search engine. Maybe the general standardization of titles and formatting has helped. I do like the UnPortal in relation to ease of use. I'd like to suggest leaving the Portals as a Gate, and using UnPortals for SubPortal, or even individual article pages. <br>  


<br>


=== Maness  ===


=== Maness ===
If going un-portal drops links, please don't do it!&nbsp; It doesn't sound like there has been enough study or playing around with both ways to truly decide?&nbsp; Moriss' idea of leaving the Portals as a Gate and having things behind the gate go UnPortal or SubPortal, <u>'''''if it truly will insure they are picked up by search engines ,'''''</u>sounds like an excellent combination of the ideas presented thus far.&nbsp;&nbsp;


If going un-portal drops links, please don't do it!&nbsp; It doesn't sound like there has been enough study or playing around with both ways to truly decide?&nbsp; Moriss' idea of leaving the Portals as a Gate and having things behind the gate go UnPortal or SubPortal, <u>'''''if it truly will insure they are picked up by search engines ,'''''</u>sounds like an excellent combination of the ideas presented thus far.&nbsp;&nbsp;
=== Lerman (links) ===
 
You are correct, as long as I understand what you were saying . . . links should not be broken no matter which direction we go. Obviously, all links generally cannot be fixed at the exact same time as an article name or namespace is changed. Also, it is reasonably likely that something will be missed. A major difficulty will especially be the current pseudo "breadcrumb trail" style of navigation that many pages use at this time. It has links on MANY, MANY pages. I believe someone was going to check into an automated way of handling these, but could be mistaken.
 
By the way, I am not sure how I link the way the discussion is broken up here. It seems like it should be more by thread rather than by person. Maybe that was not the intent, but how it seems to have gone and I am propagating the wrong method. I know my initial comments covered several topics.
2,175

edits