<?xml version="1.0" encoding="utf-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Grant.gov&#8217;s Aluminum Bullet</title>
	<atom:link href="http://www.robfay.com/2006/09/13/grantgovs-aluminum-bullet/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.robfay.com/2006/09/13/grantgovs-aluminum-bullet/</link>
	<description>UX Architect @ Blackboard. UX / IA / IxD / Usability junkie. NY Yankee Fan. UConn Husky fan.</description>
	<lastBuildDate>Mon, 10 May 2010 18:46:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Rob Fay</title>
		<link>http://www.robfay.com/2006/09/13/grantgovs-aluminum-bullet/comment-page-1/#comment-5523</link>
		<dc:creator>Rob Fay</dc:creator>
		<pubDate>Thu, 14 Sep 2006 16:51:06 +0000</pubDate>
		<guid isPermaLink="false">http://robfay.com/2006/09/13/grantgovs-aluminum-bullet/#comment-5523</guid>
		<description>Sure, Java isn&#039;t without its problems, but I assumed that it might be easier to rollout than a separate client for each OS.

The government does, in fact, hold onto people&#039;s grant application data - aren&#039;t there rules for retention?  However, I understand if grants.gov doesn&#039;t have the resources to support it and must, instead, just feed the data off to the granting agency.

But that perhaps answers my question that grants.gov could never handle cradle-to-grave grants needs if it&#039;s simply the broker of such information.</description>
		<content:encoded><![CDATA[<p>Sure, Java isn&#8217;t without its problems, but I assumed that it might be easier to rollout than a separate client for each OS.</p>
<p>The government does, in fact, hold onto people&#8217;s grant application data &#8211; aren&#8217;t there rules for retention?  However, I understand if grants.gov doesn&#8217;t have the resources to support it and must, instead, just feed the data off to the granting agency.</p>
<p>But that perhaps answers my question that grants.gov could never handle cradle-to-grave grants needs if it&#8217;s simply the broker of such information.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave Cassidy</title>
		<link>http://www.robfay.com/2006/09/13/grantgovs-aluminum-bullet/comment-page-1/#comment-5521</link>
		<dc:creator>Dave Cassidy</dc:creator>
		<pubDate>Thu, 14 Sep 2006 15:35:10 +0000</pubDate>
		<guid isPermaLink="false">http://robfay.com/2006/09/13/grantgovs-aluminum-bullet/#comment-5521</guid>
		<description>As long as an offline client is needed, the system will use e-forms. While it would indeed be more open-standards focused, using Java Swing (or anything similar) has several problems of its own -- browser and OS compatibility, performance issues, and more -- that would create new issues.

Personally, I&#039;m in favor of the e-forms solution playing second fiddle to an online application mechanism, much like FastLane. When Grants.gov started up, most grantees were not familiar with either e-forms or web-forms. Nowadays, though, most people are much more comfortable with web-based forms and it&#039;s e-forms that present a learning curve.

In addition, with contemporary technologies such as AJAX, a rich web interface experience is possible (Google Maps, GMail, Basecamp, Salesforce.com and many other apps demonstrate this) so there&#039;s no argument against the feasibility of this approach.
But the government doesn&#039;t want to host people&#039;s grant application data -- either in draft or submitted form -- wherever possible. (NSF is okay with it; other agencies are more skittish.) So we&#039;ll need to see a change in thinking there before this option becomes truly feasible.</description>
		<content:encoded><![CDATA[<p>As long as an offline client is needed, the system will use e-forms. While it would indeed be more open-standards focused, using Java Swing (or anything similar) has several problems of its own &#8212; browser and OS compatibility, performance issues, and more &#8212; that would create new issues.</p>
<p>Personally, I&#8217;m in favor of the e-forms solution playing second fiddle to an online application mechanism, much like FastLane. When Grants.gov started up, most grantees were not familiar with either e-forms or web-forms. Nowadays, though, most people are much more comfortable with web-based forms and it&#8217;s e-forms that present a learning curve.</p>
<p>In addition, with contemporary technologies such as AJAX, a rich web interface experience is possible (Google Maps, GMail, Basecamp, Salesforce.com and many other apps demonstrate this) so there&#8217;s no argument against the feasibility of this approach.<br />
But the government doesn&#8217;t want to host people&#8217;s grant application data &#8212; either in draft or submitted form &#8212; wherever possible. (NSF is okay with it; other agencies are more skittish.) So we&#8217;ll need to see a change in thinking there before this option becomes truly feasible.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

