Domino Breadcrumbs
Here's some food for thought. Breadcrumbs in Domino databases. Anybody ever used them? Personally I can't see the point of them in the standard Domino database!
Breadcrumbs to me are a great idea; they're simple and effective. Take Macromedia's site for example, as below. It needs no explanation and it's a handy navigation tool (even if the font colour could do with being a tad darker).
But Domino is different. Take the standard model for a Domino website, as below. I've always wondered if there's ever any point to breadcrumbs this short.
database / view / document
The database link is normally taken care of with a "home" link. If the site's well designed then the view link is also catered for by a persistent navigation element. The document? Well you're already in that and there's no need for a link to it!
Breadcrumbs are great for helping a user find their way home but, with Domino, you're never further from home than just round the corner. Sure you can use them, but are they of any use?
Maybe I could use them on codestore. Maybe, and this is stretching it, you could have a case where they push to four links, as below:
codestore / articles / article / response
I remain scepticle. Anybody ever seen a Domino site that uses breadcrumbs effectively?
Skip to the 
You can subscribe to an individual
Hey Jake,
I'm a little surprised at your skepticism. You're the guy who taught me not to think too lowely of Domino's ability to generate a website.
Since you can pretty much get whatever kind of layout you like from careful webcrafting with Domino, I think it's more a question of, do breadcrumbs fit the task at hand? If so, then they do fit in Domino. :-) It comes down to the useability - if it's a complex website, they're going to be an asset. If it's just a few pages, it's a waste of time.
My 2 cents.
Jerry
This isn't a rant at Domino post Jerry. It's just me wondering if there's a point to breadcrumbs when used with the Domino model
>> if it's a complex website
Are they ever? Most sites I make are db / view / page and rarely anything beyond. I just wondered if anybody had gone a step further and make use of breadcrumbs in Domino.
I agree with Jerry. We run our content sites that on Domino (that is, we have a Notes based Content Management System). As an example our Intranet has pages that may be 6-7 levels from the homepage (eg. Home -> Business Units -> Business Unit A -> Area within Business Unit A -> Procedures -> Random Procedure X -> Page 5), no single navigation system is going to capture that depth whilst remaining usable. That's where you can use breadcrumbs.
For an application, or even a fairly flat site like a blog, breadcrumbs are probably not what you want - you want some other more appropriate navigation system.
Oh, I didn't detect a rant.
Havn't used them, but I have one or two corporate monsters where they would have been a good idea. Categorized views, for one... you can have layers upon layers - bread crumbs are a good way to go.
Cheers,
Jerry
Good point Marcin. But how does Domino get that deep in the first place?
As I understand it, each piece of a breadcrumb list should be a clickable link and take you to a distinct part of the site. In your example what would, say, "Area within Business Unit A" be a link to?
At my Domino site every page has a simple user understandable name, and pages can be tree-nested to any depth. We use mappings so the user never see the View/Document stuff. And we generate breadcrumbs to show the logical nesting of pages.
On the RFD site David? I can't see any breadcrumbs...
We have a site that's the site map is not like a tree but more to a 2 dimension matrix. Not only that, the some of category has many level too. User can go to a page from many different way. So it's important to have breadcrumbs for user navigate back to where they came in from (may not be the home).
The site is composed of documents which are all in one view, so at the URL level it all looks "flat" (ie. {Link} or {Link} however the documents themselves have parent-child relationships via their unique names and a field storing the parent's unique name.
So a breadcrumb would be built by working backwards from the current page, putting a link to the parent, then getting the key of the parent's parent and so on until you hit a "null" and that's your homepage. This is why I say it probably doesn't apply to blogs where you don't have such a complex information architecture.
You could probably do it using a forumla with R6, however we use a WQO (R5 server). As an aside, yes WQOs slow down the page opening but we still manage 100-150 concurrent users on a dual-733MHz box (yes we're upgrading soon :) ) - i think people have a preconception about WQOs from the R4 days, like people who say "Java is slow" because they used 1.0 10 years ago.
Breadcrumbs relate to a site/topic structure not the internal database structure!
Most domino based sites I've made have only 1 view to link from, but also a large tree-like site structure.
Within the database all documents are equal (on the same level) but the subject matter is not.
Sure, you can invent your own navigation structure and implement it via response hierarchy or other ways of linking documents. But there's an even more natural case that doesn't rely on inventing your own strucure. Strictly within Domino's builtin navigation structure, you have the capability to go as many levels deep as you could reasonbly want for a web site. Categories and/or folders, nested several levels provide the levels. Notes client users are usually pretty happy with the standard navigation provided in the client, but neither categories nor folders translate particularly well to the browser UI, so building your own breadcrubmbs for back-navigation can be pretty useful.
-rich
I use breadcrumbs for a complex site where the user has to drill down through views with 5 or 6 levels of categorisation. Take the following view structure:
Operating Unit\Country\Company\Category\SubCategory
The default breadcrumb is Home. When the user clicks a specific Operating Unit, then only see the collapsed categories relating to that OU, with a breadcrumb link then added i.e. Home > OU1
If the user then selects a country the view is further refined to only show those docs and the breadcrumb trail becomes Home > OU1 > Country1. And so it goes on. The benefit of this approach is that the user can return to a relevant subset of collapsed categories or documents easily. This means that even when they are reading a specific document, the breadcrumb trail allows them to go right back to the Country1 level and start again. For web users this is intuitive, and for Notes client users it works like a Notes view, not like a standard web view.
I use a single view to build the breadcrumbs, using the first column using code something like this:
sep:="~";
key:=OU;
key1:=OU + sep + Country;
key2:=OU + sep + Country + sep + Company;
key3:=OU + sep + Country + sep + Company +sep+Category;
"*":key:key1:key2:key3
key4:=OU + sep + Country + sep + Company +sep+Category+sep+SubCategory;
The subsequent columns build the key for that column then use a javascript function to change the &RestrictToCategory parameter. I am not sure how effective this is but in a large database with hundreds of thousands of documents and at least 5 levels of categorisation it seems to work.
-> William, how do you build your breadcrumbs if the user can access to the document from different path ? It has always been a problem for me.
How do you build the breadcrumbs for a document that can be in multiple categories ?
For most of the site I worked on, there was a navigationnal menu on top or on the left of the page, the current path was highlighted in the menu. That was our breadcrumbs.
Gaston
I should have added that in the above code the default view parameter is ViewName?OpenView&RestrictToCategory=* to return all the first level categories
Gaston
If a document is in multiple categories then the user will see the breadcrumbs relevant to the path they took to get to that document. If they are directed to the document directly via a url link, a default set of breadcrumbs is shown.
www.weert.nl
OK, I've been to bed since I wrote this and, whilst I didn't sleep on it, I have woke up with mixed opinions.
So breadcrumbs can be a good thing in Domino. But only in Domino sites where the whole view/document paradigm has been turned on its head and manipulated in to a "pretend" website. Domino has no effective way of managing multi-level document hierarchies! Don't tell me about categorised views. They're a pain.
Again, this isn't a rant. Depsite what I say about Domino, I do really like it. But I think it's best left to do what it does best. As soon as you start trying to mimic other systems it quickly gets messy.
I think the problem is that people actually implement breadcrumbs incorrectly. Surely breadcrumbs are a path of where the user has been... not where the document lies. We were tempted to put breadcrumbs on our domino site simply because of the scale. And to be honest if there was a way to do them easily we would have.
Our site has over 150 separate notes databases containing in total well over 6000 documents. These documents can be linked from other documents, A-Z, life events sections etc. etc.
Now if we placed a breadcrumb trail showing the user where the document lays, what good would that be? So we'd need to record how the user got to each page, using session variables.. Or cookies in dominos case. But then where do you call an end to it? Theoretically it should be a list of all the documents they have been to from when they hit your site... but this list may become huge.
Breadcrumbs are a good idea, but often on large sites aren't implemented correctly.
On a small site such as this, they’re pointless.
{Link} Is this site worthy of breadcrumbs? It's a mix of Domino and non-Domino content and it's been poorly maintained of late. On our intranet we have a debate going on about whether our workflow applications (which are being converted from the notes client to Domino) should be launched in a new window or not. Some people like to be able to alt-tab between them, but it drives me batty having all of those new windows pop up. Maybe tabbed browsing is the answer to that one (oh wait, that would be too much like the Notes client).
Actually, by their definition, breadcrumbs are not a path of where the user has been. Rather, they show the user where the current page is in relation to the site hierarchy. Therefore, the analogy to Hansel and Gretel (and thus the term 'breadcrumbs') is slightly misleading).
We have many Domino websites and internal sites that are very deep and breadcrumbs can be quite useful, especially in the context of searching.
Here is a quote from a posting by Jakob Nielsen regarding breadcrumb navigation:
"Do not link to all sections of the site from all pages. What is the probability that a user will go from looking at hairdryers to looking at grunge music? More to the point: what is the probability that the user will need the link on the one day in human history when he or she wants to make this transition. Why not just go back to the home page (one click to a page that is already cached and thus displays in half a second if coded correctly).
Instead, provide links to all levels of the hierarchy above the current location. Breadcrumb trails serve two purposes:
-the context of the current page (how it is nested) allows users to interpret the page better (you don't just know that you are looking at product 354, you also know that it belongs to the widget product family)
-the links allow users to go directly to a higher level of the site in case the current page is not what they wanted, but they do want something similar
True, users will often ignore the structural links, but sometimes they will notice them, especially when they are interested in understanding a page better. Without structural links, pages become orphans that are not contextualized. And since users often arrive at pages through search or other means that bypass the higher-level navigation pages, it is necessary to provide a path back to these higher levels. In particular, it is useful to link to a page that provides an overview of the current subsite or region. "
Some good things to think about...
By the way - there is an old THE VIEW article with an example database called
A Custom View Interface for the Web - Featuring Fast Loading, Easy Drill-Down, Breadcrumb Links, and "Jump-to" Functionality (THE VIEW, January/February 2001)
{Link}
Hope this helps, Thanks for the great site
Ingo
I've actually written an article about this - it's a two parter where I was going to explain how I do this with multi-levels (ie. article / response, etc)
Basically, it's a combination of using the @ViewTitle, the "article" url, and the "response" url and store that information at the document level. Then, just make your breadcrumb trail lookup the document field value - simple enough.
The article (if I ever have time to finish it) will explain it in greater detail - I hope!
-Chris
By definition - as in breadcrumbs in a maze - it is where you have been.
Doh
This doesn't relate to Domino but it does relate to breadcrumbs. It's a really cool article on breadcrumb usability. It did studies on efficiency and breadcrumb placement.
{Link}
What about using the database category? What we have done is use the multivalue capabilities in the database category, and then use those values in each of the pages. For example, we have our Intranet (our Extranet uses ColdFusion). Every database used in our Intranet has "Connect" as the first value, then anything associated with certain areas. When we're in our Programming Standards database, the database category is "Connect:Software Development:Programming Standards", then we tack on the view or page title.
This also helps us with Domain Search - we can say search all of our Intranet, or just certain parts, or just certain databases. Hope I made sense.
I don't entirely disagree with you Jake, but when you say "Depsite what I say about Domino, I do really like it. But I think it's best left to do what it does best." my reaction is simply that we don't always get to choose what we're going to with Domino. Sometimes we are required to make an application work in both the Notes client and the web browser, and sometimes the natural way to make it work in the Notes client is with either folder and subfolders or categories, because the data does naturally fall into some sort of hierarchy. Users of the Notes client are used to navigating hierarchies of folders and categories, and (for the most part) they like them just fine. When you say that categorized views are a pain, I'm not sure if you're saying that just for web interfaces, or also for the Notes client. In the former case, I totally agree. In the latter, I only agree somewhat. Personally, I tend to prefer nested folder structures, but like it or not, categories are a widely-used feature of many Notes client applications, users do tend to be familiar with them, and even when building entirely new applications for an existing user base it's often best to stick with what they are used to. But now take that application as-is, and put it in a browser... and the vast majority of users are going to tell you that the navigation is unfamilar at best, and that it sucks at worst. One of the things that Domino definitely does not do best is automatically translate the navigation UI into HTML that looks good and functions well. This is where, as developers, we have to delve into our bag of tricks and overlay something that is functional and familiar for browser users. The prevalence of breadcrumb navigation on popular web sites pretty much assures that that it will be familiar to browser-based users of our applications, so that leaves it to us to make sure that our bag of tricks is good enough to make the breadcrumbs funcctional.
-rich
Dictionary... ;-)
Sorry...I should have said: "By their definition in the web realm". Yes, in other contexts breadcrumbs mean "where you've been", but in almost all cases on the web, they are used to show hierarchical relationships among pages. Here is the definition as defined by whatis.com:
"On a Web site, a breadcrumb trail is a navigation tool that allows a user to see where the current page is in relation to the Web site's hierarchy. The term breadcrumb trail comes from the story of Hansel and Gretel, who left a trail of breadcrumbs as they walked through the forest so they could trace their way back home."
From Domino Bible 6 :
catlist := @Explode(@ReplaceSubstring(Categories; " - "; "~");"~");
@For(z:= 1; z <= @Elements(catlist);z:= z + 1;lname:= @Trim(lname + @If(z=1; ""; " - ") + catlist[z]);
breadcrumb := breadcrumb + @If(z=1; "";" - ") +
@If(z < @Elements(catlist); "<a href=\"" + @URLEncode("Domino";lname) + "?Opendocument\">" + catlist[z] + "</a>";catlist[@Elements(catlist)]));
"<a href =\"?openview\">Top</a> - " + breadcrumb
Even in Codestore breadcrumbs can be handy. e.g. {Link} This blog entry offers users to navigate from the blog entry with comments to:
- home
- a list of all blogs by title
This list gives users a fast overview of all blog entries. The list is sortable by Title, Date, etc. You could also add a sort by subject category.
Some hints:
1. http_refferer
2. Query_String
3. Some Formula Or JS or both
4. Index of views and their titles (usually different from @ViewTitle)
Every site has a different structure so there is no trick that will always work.
Good breadcrumbs will show the user where he came from and not where in the site he is so if a document can be accessed from more then one place - user should get different breadcrumbs for each way.
I agree with Richard re. folders vs categorisation. My CMS holds the content pages in a nested folder structure. There are two reasons for this:-
1. it is an organisational/storage metaphor that users find intuitive (and which is readily converted into breadcrumbs), and
2. it allows the system to generate REST-compliant URLs for its content pages.
Mike Golding has blogged on REST and SOAP/web services before - see {Link}
REST, however, can also be applied to web sites. If you want to improve the accessibility of your site, you should use REST-compliant URLs. This is one area where Domino-generated URLs are useless. Domino is a great tool for building such systems, however, so (as Richard says) we just "have to delve into our bag of tricks ...".
What on earth does REST have to do with accessibility? REST describes a web service GET request style that uses logical URLs rather than RPC/SOAP (or GET with a query string). Even within that narrow context, REST is only useful for returning a data set -- it cannot, by its very nature, allow any complex action upon the data (relationships, computation), except by addressing a single-parameter "stored procedure".
Getting a document by its UNID is valid in a REST context, by the way, should you ever wish to do direct-key addressing when GETting XML pages. It's only the query string that's a problem, and you never need to use it when merely opening a Domino element.
Let me put my point another way.
Given the following URLs, which would you find easier to understand
...://mysite/site.nsf/products/productA
or
...://mysite/site.nsf/0/ACDCBC95B136D48580256ECB003E531F
??
Nothing to do with REST, I'm afraid, and it breaks if you have more than one document that could be keyed as "ProductA" unless you add an artificial unique identifier tab or -- worse -- send the user to an "ambiguous key" page. Anything sufficiently long to be used as a unique identifier in anything but a trivial web site will be "inaccessible" due to the need for URL-encoding. It ain't the hrefs that need to be accessible -- it's the link text and title.
My contention is that the URL does need to be "accessible".
It's easy to discern from the URL
(1) ...://mysite/site.nsf/products/productA
that it contains information about productA from the products section of my site.
Now we can't say that about
(2) ...://mysite/site.nsf/0/ACDCBC95B136D48580256ECB003E531F
It doesn't make any sense for URL (1) above to point to more than one document. If there is more than one page associated with productA, we might want to break it down as follows:-
...://mysite/site.nsf/products/productA/overview
...://mysite/site.nsf/products/productA/whitepaper
and so forth.
Similarly, if I knew URL (1) and wanted general information about products, then
...://mysite/site.nsf/products
might be a good guess (and therefore one the site should cater for).
What would you try given URL (2)?
You are going to contend that users should just try URLs until they find something? Nonsense. And yes, it does make sense that URL(1) can point to more than one thing (it is, after all, only one layer beneath the top of the site, so the specificity is minimal unless you have a VERY small product list). URLs are not meant to be accessible, and if they are at all specific in a non-trivial site schema, they will be inaccessible due either to length
.../mysite.nsf/products/fasteners/MILSPEC/threaded/hex/UNC/SWIRE/3%2F8/1-3%2F4/...etc
or to obscurity
.../mysite.nsf/products/fasteners/AN180976-17A/1-3%2F4
(not unlike a Domino unid) or to encoding
.../mysite.nsf/products/fasteners/threaded/3%2F8UNC%20x%201-3%2F4%20Hex%20safety%20wire%20drilled
Specificity breeds inaccessibility, and merely reading someone's monograph does not change that -- a forty-foot URL is no more "accessible" than a 32-character UNID. That which shows in the address bar (beyond the site root) is for the machine -- links, searches and other user tools is what brings the human to the data.
"Friendly" URLs may look pretty, but they mean bloated view indexes, extra views (by the score, in this case), and reduced performance. And it still doesn't add to usability or accessibility. Decent, usable navigation will get you to the same place without making the application unworkable.
(And yes, I also pooh-pooh REST as a web service access method, since it can do so little compared to POST/SOAP and parametered GETs unless the URL is so contrived as to be meaningless again. Not to mention that everything's passed in the clear, which is also a problem with GET.)
Stan, Actually Arka is 100% correct and your reading of REST is very limited.
REST is more than just GET. It's basis is making use of standard HTTP calls of all varieties, including GET, POST, HEAD, PUT and DELETE to perform various actions on data resources.
Regarding linking: "REST accomplishes this by defining a resource to be the semantics of what the author intends to identify, rather than the value corresponding to those semantics at the time the reference is created."
or more simply "a URI identifies a concept rather than a document". So Arka's URI example of 'domain/products/productA' is spot on. URIs that link via the domino standard of 'db/view/unid' is way wrong because it's extremely likely to change over time. Whereas 'domain/products/productA' should be consistant and never change no matter where the actual resource lies on a server.
In this way URIs like this are actually FAR more usable and worth the trouble to create.
If you want to learn about REST go here: {Link}
Thanks, Andrew.
It's a constant source of disappointment to me how products like Domino.Doc, WS Portal and others (from vendors other than IBM) render these un-RESTful URIs.
These URIs may well achieve what the programmer wanted in terms of the application but, outside of that, it's tough to assign much meaning to them (which is a shame for us 'users').
Did you really think I posted blind? Man, I hate it when people glom onto a concept without actually examining its implications....
Again, URIs are not a usability matter -- users should never interact directly with a URI value (no matter what anyone says in a paper). There is a mechanism in place for "permanent resources" (see the namespace spec). REST is a solution looking for a problem -- and the problem isn't there. As I pointed out, the simple matter of getting, say, a usage sheet (loads, torques, etc.) on a milspec 1 3/4 by 3/8-20 UNC bolt with a one-inch unthreaded shank, cross-drilled for safety wiring (trust me, this is a common-enough occurence in the real world) is going to result in an unfriendly URL, no matter what the ideals of something like REST are. It is an incredibly limited and short-sighted concept. Oh, but it does look good in an address bar, eh? That's not usability or accessibility -- that's contrived nonsense.
Stan, you're thinking with blinkers on man!
REST is not about URIs! REST is one solution to the SAME problem as SOAP or XML-RPC. It's the general problem of a network based application architecture, there all just different approaches.
My understanding of REST, as far as URIs go, is that a URI should not be composed of elements relating to a resources location on a server, time, or user session info, but to an unchanging unique identifier that is recognisable to humans. This does not mean REST promotes good looking URIs. What it means is that in a network based application other entities will want to gain access to that resource for various purposes (one is to GET it). Now all of the entities are written by human beings and in the REST view of the world (a resource centric view) a human being should be able to write a process to GET a resource and be assured that the URI to it will not change.
Compare this to the SOAP/XML-RPC view of the world which is process centric where the human would write a program to request from a central point access to a method (passing optional args) to GET the resource for them.
So, for example:
a SOAP/XML-RPC style app might have a URL to send a HTTP POST containing a XML envelope with the name of the method: "getBolt" and send it the manufacturers catalog ID for the bolt: "12345C".
A REST application would instead have you make a HTTP GET request to a URI for the bolt: manufacturer.com/bolts/12345C
The point about REST URIs is that they make sense to humans. In the example a catalogue ID is perfectly sound.
However, a Lotus Notes document UNID is completely contrived and does not help anyone in a REST style network application.
SOAP/XML-RPC style architectures are more familiar to programmers because using them is akin to making API calls, and so it's easier to understand. REST uses standard HTTP requests but its capabilities are no less. If I wanted to update the bolt's info I'd POST to it, if I wanted to delete it I'd send a HTTP DELETE request.
Regarding the contruction of URIs in any web application your example of a long one is completely rediculous and no one here is advocating that.
You say users never interact with URIs?
- Try authoring a webpage/web app where you need the URIs to resources: readable/understandable URIs reduce errors and make it easier to work with them
- When you email a link to a friend (Try emailing a URI from a websphere portal page).
- Those email banking scams which trick people to click a link - they work because people read and trust what is in the address bar!
- Try reading this discussion board and make sense when people post something like: "Hey I read this great article here: someblog.com/articles/x34gr5t", now you might get a sense of its relevance from the discussion context but otherwise you wouldn't know if it's worthwhile to visit. If it said "someblog.com/articles/all_about_cheese" you'd have a much better idea. This = usability. Actually this is a totally redundant example because Jake turns all links into '{link}', shame on you Jake! But you get the idea.
- I use URIs all the time and it drives me nuts when they are unreadable.
- The address bar is like a backup command line interface : when no other option is available it's great when you know you can type in 'company.com/bolts/bolt catalog #' and get what you want.
No, I'm not (thinking with blinders on, that is). Your call (equivalent to getBolt(partNo)) is simplistic in the utmost -- utterly unrealistic from a real-world standpoint, since you still need to go through the long, involved procedure of getting the part number in the first place. That's where something like REST breaks down -- in order to make the URI (and it IS all about URIs) look nice and human, I need to progress through several levels of query to get to the magic part number that's all warm and cuddly. How's that better than POSTing all of the specs in one go, especially if I know the specs but haven't a clue which part numbers (and there will be several, given that the bolts under discussion here will come in at least five alloys with three possible coatings) correspond? In the final analysis, is a part number more usable than an ugly URL? For that matter, how permanent are your part numbers? (In my experience, they are superceded at least as often as, say, a Domino UNID.)
It's great if you can simply name a resource (say a product name or part number), but if there's anything more complex involved, then REST addressing is far, far more complex and roundabout than either a proper POST or a query-structured GET. Even your simple cheese discussion gets more and more involved the more people talk about cheese.
REST is great in theory, but like so many other concepts in fashion, it's never actually been extended by its proponents into a complex real-world situation. Dammit, its nothing more than a vogue look at the world as we geeks know it. And like every other buzzword manure pile, it will genearte a lot of unnecessary work with absolutely nothing to be shown at the end of the day except full buzzword-compliance.
Breadcrumbs on AIDS Committee of Toronto site (Domino site)
example page: {Link}
home page: {Link}
All I can say Stan, is you should do some more reading, I still think you've got a very limited idea about what REST is.
2 Articles I've read that really explain it well are at the Oreilly webservices.xml.com site:
'Second Generation Web Services' : {Link}
'REST and the Real World' : {Link}
Look, I'm learning about it myself, I've never used SOAP/XML-RPC or have made a design choice in favour of one architecture over another. BUT when doing web apps one is using REST more often than not.
But looking at your response, a good example of a search to find an entity then making a reservation for that entity is here, an example from a REST wiki site for a Library Management System {Link}
Which leads me to examples of real-world REST apps:
#1 is of course the World Wide Web!
also; RSS syndication, Orielly Meerkat, Yahoo groups, Google & Amazon both offer REST style web services, WebDAV, a product called sqlREST {Link}
I'm sure there are others but I'm just a beginner.
I have done such system for my web site. I have used the same method as Chris Toohey with response document hierarchy in order to build a tree. Each level contains it's url. But I don't use any dblookup in order to cache the page and to boost performance, I use a javascript method based on a matrix generated by a view in pure html. You can see it on my site by looking at the html code.
I just have to call a javascript methode and passing it the current level id, the level separator (> for example) and the starting level.
Let me know if you want a sample database
Sylvain
This is cool:
"But also, the coolest aspect of the PHP web site is its search-by-url feature. It looks up a function or language reference page, finds a set of likely matches, or just googles the site for you. Try it: php.net/array - {Link} php.net/sprintf - {Link} php.net/error - {Link}