This section lists some best practices for designing presentation applications. These best practices are based on developer experience and on formal user testing conducted in Yahoo! usability labs.
Today's search users have become experts at skimming through search results and discarding anything that looks irrelevant. For any given search result, there is roughly a 250 millisecond window where the user is subconsciously perceiving and processing the result. During this 250ms window, if the search result appears to be not relevant — or worse, an advertisement — the user moves on without ever consciously examining the entry. This leads to the fundamental principle of SearchMonkey presentation application design:
Search results should never look like advertisements.
This is one of the fundamental reasons why Enhanced Results have a standard template. Even with the help of the template, it is still possible to make bad design decisions within those constraints. Since you have at most only a quarter of a second to "prove" to the user that your result is relevant, deadweight text or elements that look too commercial will cause users to skip right over your search results.
![[Note]](images/docbook/note.png) |
Note |
|---|---|
The 250ms window does not necessarily apply to Infobar applications. Clicking to expand an Infobar indicates a conscious action, and implies that the user has already determined that the search result might be relevant. |
![[Tip]](images/docbook/tip.png) |
Tip |
|---|---|
Beyond the actual presentation of the search result, take care when trying to do anything computationally intensive with your code. Most applications rely on simple assignment and string manipulation, and should be fairly fast. If your code takes too long to execute, Yahoo! Search will fall back and display your Enhanced Results as Infobars, at least until the results are cached on the server side. |
The following sections contain specific guidelines for designing optimal enhanced search results, component by component.
Make sure titles are meaningful. Users scan titles for important
keywords, and this is one of the most important factors for
determining whether to examine a search result consciously. If a site
has useful information, but the page's default titles are unhelpful,
use the ['title'] key
to rewrite the title into something more appropriate. For
example:
Titles often have text at the beginning that specifies the name of the site, the author of the page, the date, or other metadata about the page. However, the left-most text in the title is your most valuable real estate, and users care about what is on the page, not your site. Rewrite the title so that the first part describes what is on the page, and move all other information to the right (or eliminate it entirely). For example,
JanesSportsSite.com ~ by Jane Smith, Copyright 2008 ~ San Francisco 49ers Team Roster
would be far better as:
San Francisco 49ers Team Roster ~ JanesSportsSite.com
Titles sometimes include additional words inserted by a
content management system or blog system, such as "Blog
Archives" and other cruft. Remove these words entirely, as
they can only hurt relevance.
Some sites don't provide titles at all, or have a huge number of titles that are all the same. You can use SearchMonkey to provide more meaningful titles.
Of course, the best place to fix a title is at the source, in the page itself. However, if you are writing an application for a site that you don't control, or if it would be extremely challenging to rewrite all of your site templates, as a stopgap measure you can fix up search result titles with SearchMonkey.
Summaries must be short and to the point. Like titles, users scan summaries for keywords, and a bad summary can be worse than none at all.
If an summary is long, rambling, or too flowing and polished, it starts to appear less relevant. Ideally, a summary should consist of one or two terse sentences that use neutral, factual language. To shorten an summary, truncate it with ellipses at the end. Do not use ellipses at the beginning. Note that SearchMonkey automatically truncates long summaries for you, and it truncates them even further if you add one or two key/value pairs.
For Infobars, the rules change. Longer summaries are fine, because when a user clicks to expand an Infobar, they are already "on task" and willing to learn more.
Images do make search results more visually appealing, but this is less important than helping users complete their task. Images are worth adding only if they help users determine the relevance of a result without forcing them to read the accompanying text. If used unwisely, images can actually increase the risk that the search result resembles an advertisement.
Images are valuable for specific products, because they help users determine whether your result applies to their query. However, this only applies only the picture is actually of the product. For example, a search result for a 24" Apple iMac should display a picture of that specific iMac model — not a picture of a MacBook Pro, or worse, a picture of a cartoony computer icon, or worst of all, a generic company logo.
With that in mind, do not use an image to display a company logo or generic product image. If you don't have a specific image available for the product, then omit the image entirely. Company logos are only appropriate for pages about the company itself, such as the homepage.
Images of people are valuable, but only if the page is fundamentally about that person.
Images of places are valuable, particularly for restaurant reviews and the like. Again, use an actual picture of the place; a picture that is obvious stock photography makes your result appear less relevant, not more.
For applications in the Gallery, the image src
URL must belong to the host of the search result. For example, if you
design an application to work on wikipedia.org, any images
must reside on wikipedia.org. However, you may request
non-host links during the approval process. For applications outside
the Gallery, the image src URL may have any host.
Links can be very helpful for searchers who are still "sniffing" along the information trail, trying to find the page they want. For example, a user might get a result for a book listing, but what they're really looking for is a page with reviews about the book. If you can anticipate other things the user might be looking for, links provide valuable shortcuts that take users deep into your site.
Deep links should never appear as if they were paid for. Avoid having overly commercial-looking links such as "Buy it NOW!" or "Add to Shopping Cart!!!" It is better to provide useful product information that convinces the user to click through, rather than trying to sell to the user directly.
If you must have a sales link, put it at the bottom rather than the top.
Avoid using currency signs or numbers in link text.
Link text should make it clear that the link is about the subject of the page. Do not link to your homepage, partner sites, or unrelated topics.
Deep links increase the apparent complexity of the search result. If your audience is not very tech-savvy, you might want to avoid links.
Each deep link should point to a different URL, and the title of the deep link should correspond to the referenced URL.
Key/value pairs are useful for businesses, product specifications, and contact information. They are good for very small items of information that the page already contains.
As with deep links, avoid making key/value pairs appear too commercial. Key/value pairs should report neutral, factual information.
For ratings and reviews, consider using the Data::getStars() and Data::getStarsFromNum()
functions.
Submitting your SearchMonkey app into the Search Gallery is a great way to showcase your app to the rest of the world. For developers who want to get their apps into the gallery, below is a list of things we consider when reviewing your submissions.
Is the app abusive? Inappropriate text, images and links are not allowed.
Is the app properly described? Make sure that your app title and description are properly entered as these fields are displayed in the gallery. The title/description should actually correspond to what the app does. And don’t call it “Test App” (we get a lot of these!).
Does the app contain sufficient examples? We look at each of the 10 Test URLs that you input from the dev tool. Make sure you fill up all 10 with working examples so that we can better assess the app’s output. Also, the first test URL is used as a preview in the gallery.
Are the image domains listed? If the images you display in the app are hosted in different domains than the underlying URL, then these images must be listed through the dev tool.
Does the app contain proper logos/icons? A logo must be uploaded as each app will be shown in the gallery with the logo prominently displayed next to it. The images must be relevant and appropriate to the app you designed. Finally, make sure you have the permissions for the logo you use. You can write an app for any site, but please use your own logo!
Is the app useful? The simple litmus test is that the app presents more value to the end user than when the app did not exist. Often times we see an app that looks nice but it actually makes the experience worse by taking away the default abstract and replacing it with meaningless text and a somewhat useless (but possibly cool!) image. Also, apps whose primary objective is to simply advertise/spam will not be allowed.
Is the app differentiated? If we already have several apps in the gallery that do almost the same thing, then we do not have a need to accept another one.
Are the deep links relevant and useful? The title of the deep links must be informative, and once clicked on, the destination should match the user’s original expectations of where the links should take them. Further, the links need to be relevant to the underlying result. We’ve seen many apps that show the same set of deep links regardless of what the actual result is, making the app not very useful.
Are the deep links relevant and useful? The title of the deep links must be informative, and once clicked on, the destination should match the user’s original expectations of where the links should take them. Further, the links need to be relevant to the underlying result. We’ve seen many apps that show the same set of deep links regardless of what the actual result is, making the app not very useful.
When using a custom data service, please make sure that you are submitting an Infobar app. A Results app using custom data services is not allowed in the gallery.
When we render an Infobar app that doesn't return any extra data for a URL that it was triggered for, we show a 'No data' message. This is not the best user experience - so it would be good idea to default to a generic display, instead of not showing anything at all.
With a Result app, however, it's the opposite - you shouldn't present a generic display if you don't have anything interesting to add to the existing search result - in this case return an empty array in your getOutput() method, so we default to the simple search result.
Make sure you have the right developer name set for your app. When an app gets displayed in the gallery, the name on the profile associated with the developer's Yahoo! ID will be used to display the developer name. If your profile says you are "John Doe," your app will show the text "developed by John Doe" in the gallery. You can change this anytime by editing the profile name associated with your Yahoo! ID.
And finally, the app should follow the rest of the best practices guideline we outlined above in this section.