The question was: If the situation is that an individual webpage is already known to Google search engine, and if we changes the title of this web page, how does Google register any such change of title? And how quickly?
I believe it's critical for webmasters to get the title right in the first instance. There are lots of acticles on writing titles, and I think it takes time, efort and a conscious attempt to improve.
There are lots of bad webpage titles out there - which might be too long, content-free, plain boring, inadequately describing the page's content, repetition, too much adherence to a website style.
Porn sites often do their titles well, and this zone has some masters at describing a site is just a few words. Sad to report, a lot of the page titles on a variety of websites from [Australian] government departments are too wordy or repetitious.
 PayPal - safe and secure |
|
If you value the information
posted here, |
My reasons for my interest in page titles re as follows...
(a)
Problems are so easily fixed;
(b) If the writer understands
titles, then he can understand writing for the web too. It's a
worthwhile effort.
(c) if you bookmark a page, it's the title
that shows up. If the title is just "home page" or "country
music" then it's a hopeless bookmark. The web page designer has
rendered his page a pain for the surfer who actually wanted to
bookmark it. What a shame, and so unnecessary.
(d) Google uses
the titles to name the page. Why waste a golden opportunity for
precise and free advertising by titling, "Home Page"???? No
point in writing a long title or a bad one. Clearly the most
important words must be first. Don't use filler words. Inspect Google
results to see the bad titles, these are the ones that get less
clicks than the good titles, these are the people who put themselves
in the last third.
(e) Google only visits an individual website
every so often. You must get the page title(s) correct on day one. I
wonder how long it takes for bad page titles - and bad pages - to
disappear. As far as I know, we have to know how often Google visits,
assume once every two weeks as a starting point. (Google definitely
updates changed titles, the unit of indexing is the url itself, not
the title.)
Some of my rules for page titles are:
(a) Must describe the
content exactly.
(b) Must not be all caps or all lower case.
(c)
Must not be a url.
(d) Must not exceed 40 characters.
(e) The
title in the top line must match the title as it appears on the page,
or nearly so. Major differences are out and so to are silly
word-inversions or meaning-inversions. Remember, page users like
uniformity.
Re navigating to various pages of a wesite via internal hyperlinks, it's vital to use the correct wording or very close to it. Make the hyperlink its own title. Directing netsurfers to "click here" has gone out of fashion, the hyperlink should be its own title, so the netsurfers know where they are going to go. (There is nothing you can do however if some other website hyperlinks to your pages and uses poor titles - this can happen too often.)
Think about a title for a page or a hyperlink as a mini-review in just six words of what the page is actually about. Think about this one carefully, since it's a key discovery that Google claims to have made, along with counting the number of links into each page and using this as a weighting factor.
Ends
Recently, while learning how to compile a Cascading Style Sheet (CSS), which is not so easy, I (Dan Byrnes) happened to visit a great many websites on music notation, music notation software, and music-related graphics.
The zest and enthusiasm, the creativity, the range of graphic presentations impressed me all over again with how varied (and numerous!) are the tricks of the trade that produce good websites.
So the idea arose to maintain (intermittently) a page on HTML tips 'n' tricks which will help other webmasters. The latest trick learned is right below and comes from Brian Robson of The Bondi Beach Home Page...
Tip One: Brian Robson wrote: If you go to Google, and type
in - allinurl: and then a web site URL, you will get everything on
the site, as found by Google.
Initially it will just give a
couple of pages, so repeat the search, asking to show all.
Example... allinurl:www.danbyrnes.com.au/
However, there
seems to be some sort of upper limit, say 250 or 300 pages maximum.
Tip Two: Check - Quality Tips for
Webmasters
See a now defunct website: http://www.w3.org/2001/06tips/.
Tip Three:
From WR in April 2004
Speaking of
editing reminded me of an article I read in last weekend's Financial
Review. It concerned a website - www.onfolio.com - which has a
piece of software you can download which allows you to quickly store
whole web pages, pictures, snippets of text from the web and other
material in a way which makes it easy to retrieve later. It requires
either Windows XP or 2000 and Internet Explorer 5.5 or later. It
costs $40.00 but you can download a free trial version for 30 days.
Might be worth a look-in for anyone who copies lots of material from
the web?
|
Dan Byrnes
|
|
|
|
Articles old and new... This page updated 28 November 2005 |
||
A webmaster confesses his incapacity in public - responses from anywhere in cyberspace very welcome!
Go to a good search engine:
Search for "CSS + placement +
graphics + webpages"
Search for "PHP + placement +
graphics + webpages"
The reason being... though there is
little satisfaction to be gained...
SINCE I first began on the Net, and because of my background in newspapers and print media, I have been wondering how to conveniently insert advertising material into existing webpages, onto whichever pages I have had on the Net at any one time.
Technically, this seems to remain a very difficult problem to
solve in terms of day-to-day management of text-oriented webpages,
which is what my websites have presented (on a low budget).
Going
back to late 1996, many will recall that at that time, beliefs
existed that scads of advertising revenue could be netted by astute
webmasters... Beliefs which turned out to be hollow promises.
Advertising agencies, newspapers, magazines and lesser folk in the world of people-wanting-to-advertise never fell for it. One of the reasons might have been that a lot of the so-called tricks to be played on the Internet were actually old hat.
A lot of that cute/zippy stuff - zany - intriguing graphics - animations - Flash stuff - creative typography - sound clips - have been used by TV advert workers for nearly 30 years. Why re-invent the wheel? Why indeed?
Of course, as HTML-users know, ordinary HTML formatting of webpage material can be used to insert any graphic into any webpage at will, as long as one is willing to proceed page-by-page. Newspapers with their dedicated systems soon learned this, but with their large-scale systems - and the programming behind such systems, often specially-scripted - they also learned to bury information and clues as to how advertising graphics could be inserted/deleted on schedule. And with the handling of advertising materials, any such schedule also implies questions of estimating present, resulting and future revenue - the factors on which media fortunes have traditionally been built.
This "burying factor" plus other factors have left the small-scale player at a disadvantage regarding technigues of insertion of advert material into websites. We notice, many genealogy websites enable the webmaster to present their genealogical info to the world fairly easily, at the price of also presenting extraneous advert material to anyone who stumbles on their presentation. As to the precise placement of the said advert material, the programming intricacies of this are so arcane, no non-programmer would want to know how it is achieved!
Equally of course, a great many webmasters might wish to use some global solution to be able to place (and/or remove) a particular graphic onto ALL their webpages, independently of any requirement to render or re-render the required commands (individually, on ALL of their webpages), which suggests that CSS (Cascading Style Sheets) might provide an answer, which it doesn't quite do, yet.
Here is the problem. Is it possible, using just one file - eg., a CSS file - to place a chosen graphic on ALL one's webpages - for say three weeks - and at the end of this three-week period, go to just the one file, delete programming re the said graphic file - and see it deleted when certain key files are re-uploaded to the Net?
Usually-offered CSS recommendations (see whatever W3C recommends re CSS) give most of their attention to what happens with a background graphic for a website/for its webpages. Very important, too. But questions of how/why/where to place any other particular graphic - in a foreground - via use of CSS are not discussed, except in some forums or chatrooms or on a few websites which discuss such arcane questions. (Such discussions often come from graphic designers, it seems, a matter which evidently speaks for itself; graphic designers on this question are interested, intrigued, self-interested - and quite frustrated.)
This problem could affect any webmaster. It is important to define the problem. The foregoing is merely by way of trying to invoke the usual response of engineers: if you can properly define a problem, you have gone a long way to solving it.
The problem is: how to use CSS to place a particular graphic on ALL pages of a website, independently of instructions/rules already in a style sheet regarding placement of a background graphic, or any graphics usually going into a header or a footer (as may be with a frames website). We are not talking here about a frames site.
Presumably, this graphic, if it can be so inserted, will go somewhere on the body of the webpages, eg, in the middle, or toward the top? The solution to this problem is sought so that the graphics in question hopefully can be inserted into webpages (or removed) by modification of one file only - the CSS file.
It is known (from mark Newhouse, see below), that the following can be used from CSS to "float" an image in the middle of an individual webpage, if the appropriate HTML is added to the page in question...
address img { float: right; border-style: none }
address {
font-size: smaller }
div.float { float: right; )
div.float p
{text-align: center; }
The above tactic comes from a programmer working for an astronomical observatory in the US, Mark Newhouse, at National Optical Astronomy Observatory in Tuscon, Arizona.
The HTML used with this to add a selected graphic (eg., named -
"advert1.gif" ) to a particular (individual ) page is:
(tilde here is used to designate the mandatory < and the mandatory
>)
~div class="float" /~ ~img src="advert1.gif"
width="190" height="99" Border="0"
alt="advert1.gif" /~ ~br /~ ~p~ ~center~This is
advert1.gif! ~br~Caption 1 ~/center~ ~/p~ ~/div~
This goes some way to help define the problem. The next step is to be able, without using a table format, to designate in CSS the name(s) of the graphics to be so floated into ALL the webpages from CSS, so that the above HTML does not have to be added or re-added to individual pages Not so easy.
Now, consider the below information from Digital Web Magazine... a feature article on: In Defense of Fahrner Image Replacement... by Dave Shea...
The CSS-based background image replacement technique, also known as Fahrner Image Replacement (FIR), is a vital cornerstone of all future Web design.
As the Web moves away from presentational, hacked-up HTML towards a structural future, code is becoming abstract and graphic designers are losing their traditional control. CSS offers wonderful methods of regaining it, and in many ways goes further than HTML ever did. But it doesn’t go far enough yet, and designers still need images.
Whether they’re photographs, individual headlines, or crisply anti-aliased and typographically beautiful pullquotes, images play a large part in a designer’s role on the Web. We can continue to use the ~code~img~/code~ tag and lock ourselves into its quirks (and face its demise in XHTML 2.0, but I digress). FIR, however, offers more flexibility due to its fundamentally configurable nature. We don’t ~em~just ~/em~ drop an image onto a page; instead, we create a structure for the image and then lay it over the structure. Plus, we can modify the image from the style sheet itself—a true separation of content and presentation.
FIR is an absolutely essential tool to both the designer and the coder as HTML becomes less and less about presentation. It is far too important to be cast aside over some of the problems it has encountered, and this article aims to tell you what it is, how to use it, some of the problems in using it, and possible solutions.
~div class="sidebar"~ A note from a graphic designer to coders and accessibility and usability experts who still don’t get it: You may try telling us that image-based text is against what the Web is about, but that’s blindly ignoring our needs, and the last time that happened the Web ended up with ~code~spacer.gif~/code~s and table hacks. Image is what pays us, and it pays well. Work with us, and we can create a better Web for everyone.~/div~
The technique and its syntax are discussed at: http://www.stopdesign.com/articles/css/replace-text/. but here’s a quick summary in case you don’t yet know why you need it.
What FIR does is allow a further layer of structure and information underneath an image. Whereas ~code~img~/code~ tags allow for ~code~alt~/code~ text, ~code~title~/code~s, and the later-added ~code~longdesc~/code~riptions of each image, FIR goes a step further and allows you to replace something like this:
<div id="recipe">
<h3>Marinara Sauce</h3>
<ul>
<li>2 lbs washed, seeded Roma tomatoes</li>
<li>2 cloves garlic</li>
<li>1 Tbsp olive oil</li>
<li>1 Tbsp sugar</li>
<li>1 Tbsp oregano</li>
<li>1 tsp salt</li>
</ul>
</div>With a single image: (Which you need to be able to see to appreciate, it's good, but not given here.)
The code required is trivial. Take a simple header for example:
<h3 id="firHeader"><span>Sample Headline</span></h3>
The CSS required to replace it boils down to:
#firHeader {
width: 300px;
height: 50px;
background: #fff url(firHeader.gif) top left no-repeat;
}
#firHeader span {
display: none;
}
The first declaration places the image in an appropriately-sized
container, the second one hides the text. If we didn’t have the
second, the text would overlap the image — not what we want. In
the prior recipe example, we could safely eliminate the span
and hide the interior elements (h3 & ul)
instead with display: none.
Whether the code comes first and the image added later, or the image is created and meaningful code generated afterwards, doesn’t matter. The point is that a designer is able to create a visually complex but structurally sound site. View the css Zen Garden for examples of FIR at work.
With the recipe example (in a perfect world), the sighted viewer would receive a nice image with the recipe, the blind viewer would hear the text of the recipe read to him, Google and other robots would be able to index the text of the recipe, devices like PDAs which don’t have the capable color depth or resolution to display the image would get the text instead, and it would be fully possible to port the recipe to and from XML-based applications.
There are problems though. As the proprietor of a project that heavily relies on FIR, I receive a consistent volume of email detracting the method. Let me take some time to analyze the major problems and suggest some possible solutions.
The number one problem is that screen readers render display:
none, hiding the content which the image is meant to replace.
We can’t even do so much as provide alt text to compensate. Any
accessibility advocate worth their copy of JAWS would tell you
something’s fishy, and they’d be right.
If you add a media type to your style, however, you may serve the
proper CSS to each user agent. Since FIR assumes image display is
acceptable, if we restrict its use to screen media style
sheets only, then devices like PDAs and screen readers will not hide
our valuable text.
<style type="text/css" media="screen">@import url(style.css);</style>
The kink is that some screen readers don’t respect our media
types. If a style sheet is linked instead of imported,
they will render screen media style, contrary
to what we’d assume. The simple solution is to import
all style which hides content, as above.
Note: Using Tantek’s box model hack in a screen
media style sheet causes validation errors. See the first three
replies in this
thread for more information, and the resulting dialogue between
myself and Michael Cacciottolo (MikeyC) for possible fixes.
Committing to image-based text introduces translation problems.
For example, view the Greek translation of the Zen Garden —
text that’s left as HTML shows up in Greek characters, but the
header images are still English. You face this problem whether you’re
using img tags or FIR, but CSS offers a unique fix.
CSS-2 introduced the :lang(n) selector, which allows
style definitions for variants of n. In a few years
time, when support for this selector is more universal, serving a
French header will be as easy as defining a style for h3:lang(fr).
Unfortunately, we’ll have to wait until browser support is
better to use this.
For now, the best approach is to serve multiple style sheets based on document language. Placing all FIR-substituted text into its own language-specific .css file allows you to selectively call in image-based headers for each translation. For example, you could build a site with three style sheets:
<style type="text/css" media="screen"> @import url(basic.css); @import url(en.css); @import url(de.css); </style>
Basic.css would contain most of your site-wide style rules. En.css
and de.css would contain your English and German FIR translations,
respectively, and you wouldn’t use both at the same time. Based
on the document’s current language, you could script one of the
@imports out of the list and be sure to see only the
language you expected.
It’s possible to prevent your browser from downloading
images, while still allowing it to render CSS. Very few people do
this, but it’s important to consider those who do. Just as
screen readers don’t render display: none, this
combination will not provide any alternate text either.
No solutions have been found for this yet. Accessibility problems have a way out with media types, but this continues to be a problem. Some of the alternative methods discussed below might have an answer for this as well.
Semantics conjures up images of narrow-minded professorial types arguing the definition of words like “this.” It’s a concept that makes the average person cringe. Semantics on the Web can be just as tedious, but in many cases more important.
The simple problem is that FIR relies on extra spans
to add hooks in the code that are later used to hide content. These
spans are completely meaningless to the document, and
act as nothing but empty containers.
So what, you’re asking? Well, the theory goes that a structural document is made up of the necessary elements, all the necessary elements, and nothing but the necessary elements. Adding empty containers is a concession to presentation, and makes the document “impure.” Tedious enough for you?
Unfortunately, for these purists’ arguments though, today’s
technology requires the spans. Purity of a W3C ideal is
nice in theory, but as we all know it’s a whole different ball
game when we try applying it to some of today’s browsers. Read
below for some of the ways the development community is working
around this problem.
So if there are so many problems, how can we, in good conscience, use FIR? Some smart minds are currently working on this very question. Methods to get rid of the spans and solve the accessibility problems are starting to develop.
Dave Hyatt (of Safari fame) proposes using (see website http://weblogs.mozillazine.org/hyatt/archives/2003_05.html#003257) which keeps the code simple (and theoretically
accessible!) but completely obfuscates the style. Radu
Darvas has approached me about the possibility of re-introducing
spacer.gifs and creative use of alt text to
duplicate the text within the hidden element ( View
source), but that adds a further non-structural element; purists
everywhere cringe.
At http://www.moronicbajebus.com/playground/cssplay/image-replacement/, Seamus
Leahy and Stuart
Langridge have each independently discovered that using overflow:
hidden will hide the interior text without the use of spans.
Brilliant thinking as this alleviates the accessibility problem and
drops the unnecessary spans, their technique shows the most promise
of replacing FIR, once the remaining “CSS On, Images Off”
complication is resolved. It’s even possible to use the title
attribute of the containing element to restore the mouse-over
tooltip we all know and love.
These methods all offer strengths and weaknesses to varying degrees, and the final solution hasn’t been found yet. But we’re working on it.
Structure is good, but unformatted structure is arguably as useless as unstructured design. To move forward with a harmonious balance of compelling visuals and well-built code, the remaining issues with FIR need to be resolved. We all need this technique: coders, to keep the structure clear; accessibility advocates, to keep the page viewable to alternative user agents; and designers, to make the Web a more beautiful place.
It is not up to you as a designer to solve this problem. That job rests squarely on the shoulders of software developers whose products take issue with FIR. As long as you are responsible in your usage, make sure your media types are safe, and provide every reasonable means for a person to get at the information you are presenting, then you may start (or continue) to use FIR with a clear conscience.
See http://www.digital-web.com/profiles/dave_shea.shtml re a cultivator of the CSS Zen Garden. A graphic designer by trade, he writes about all things web for his daily weblog, mezzoblue.com. Hailing from Vancouver, B.C., he can most often be found at the local farmer's markets or independent coffee roasters.
Answers are still eluding me. Some views on these topics have been checked by Stuart Langridge, but his answers were not so useful. One available tactic, for using image replacement headers, is not my bag. I initially wanted an image placement trick, plus a replacement trick. I don't want the image placement inside a table. I do want the placed image (probably aligned right) to have text flow easily around it.
What else? At www.virtualmechanics.com/ (who promote DHTML) is a tactic for graphic optimization, using div.style in CSS, which also does not quite hit the spot. I've looked at some tricks for placing well-known maths symbols into webpages, but this also is not quite what I imagine I'm looking for.
At a forum run by webmasterworld.com appears a message with a trick that's well-detailed, from Rosemarie, which looks like it's on the track I want, but so far I can't make it work. I begin to wonder, if W3C can allow us to do things in *background*, why can't W3C let us do things in a *foreground*, in some specially-defined webpage space which can be created on a browser and allocated for the specific kinds of purposes I have in mind? Independently of the usual kind of HTML placed on usual kinds of webpages? It begins to look as though I have to try to redefine the problem!
There is some action on these questions. One idea coming along is "dynamic layering", where x, y and z co-ordinates can be varied in CSS to vary object placements in webpages. I look forward to seeing more about it one day. So far the best trick seems to come from Mark Newhouse and many thanks to him.
- Dan Byrnes
NB: the advertisements on this page appear via application of the system I'm now trying to apply. [Except that by 2019 the advertisements in question have been deleted! -Ed]
Ends for the present - feel free to check the source code for the above on this page if you are curious about these topics - Dan Byrnes
|
|
