[uf-new] A search form microformat?

[Mr. Meitar Moscovitz]

Hello everyone,

I'm writing to continue a discussion that spawned from Aleksander  
Kmetec's work on Mosembro[0], a microformats-enabled mobile web  
browser, that originally started on the -discuss list. In the thread  
on the -discuss list[1], Aleksander and I began discussing the  
possible uses of (what might be) a microformat for determining which  
forms on web pages provide particular functionality. In the case of  
Mosembro's implementation, this makes it possible for the browser to  
display a consistent UI for a web site's site-wide search form, a  
feature present on the vast majority of web sites of all scales.

One of the reasons we both feel this is a useful thing is because  
search form placement and visual appearance is not consistent across  
many sites, but its presence is. Furthermore, site search  
functionality is frequently used in many contexts in an effort to "get  
results faster," notably from handheld devices. Providing consistent  
interfaces to access a site's search form is therefore helpful from a  
usability perspective.

In the same thread listed above, Brian Suda pointed me towards a  
discussion in 2006 about OpenSearch and microformats[2]. (Thanks,  
Brian!) From briefly reading the thread, it seems like there was a  
larger scope to the OpenSearch and microformats effort than what  
Aleksander has implemented in Mosembro and what I'm proposing here.  
Specifically, the search *results* of search forms were included.

In the spirit of "solving only the simplest problems first," when I  
say "search form microformat" I specifically exclude consideration of  
the results of a search form. It seems logical to me for any page,  
including a SERP, to return microformat content based on the type of  
content it is. I.e., a search on Google Product Search (formerly known  
as Froogle) would ideally return a page marked up with hProduct (and  
even hReview). Many blogs that implement hAtom have search  
functionality and they return search results marked up in hAtom by  
providing lists of hentry results.

However, to date, I'm unaware of a simple solution like this that  
allows one to discover where to *aim* a search request. WordPress  
blogs, as an example, use the 's' variable in a GET request's  
querystring to indicate a search:

http://example.com/wordpress/?s=search+terms

However, Google uses the 'q' variable:

http://google.com/search?q=search+term

In all typical cases, an HTML form element exists on the home pages of  
these sites that provides search functionality. However, in a typical  
web page, there are many forms, including email subscription forms,  
comment forms, and so forth. It would therefore be beneficial if these  
forms used standardized semantics such as a microformat that indicated  
what kind of functionality they provide. This way, user agents of  
various types, e.g., mobile web browsers, can provide simple yet  
consistent UI's for such specific functionality.

So…the above (and more) are my preliminary thoughts on this topic.  
What are yours?

I should state that I've used microformats in the past, but never  
participated in a microformat's development process. The first thing I  
did was go to the Wiki, read the Introduction and Process pages, and  
as they directed me to mail this list first, that's what I'm doing. :)  
There seems to be a well-developed framework for exploring the  
viability of additional microformats, and I am learning about that as  
I go. I'd appreciate pointers or constructive meta-feedback as well as  
feedback on the search form microformat idea specifically.

Cheers,
-Meitar Moscovitz
Personal: http://maymay.net
Professional: http://MeitarMoscovitz.com

EXTERNAL REFERENCES

[0] http://lexandera.com/mosembro/
[1] http://microformats.org/discuss/mail/microformats-discuss/2009-January/012765.html
[2] http://microformats.org/discuss/mail/microformats-discuss/2006-August/005298.html