<div class="gmail_quote"><div>I take two points from this exchange:</div><div><br></div><div>#1 User interaction changes are always subjective.  Patches, requests, suggestions, etc. should not be submitted with &quot;duh&quot; as a rationale.  They should be backed up with a clear rationale; better yet, hard data.  </div>

<div><br></div><div>#2 The Sugar UI is not sacred.  There needs to be a process to collect and evaluate data, and to design and implement improvements.  </div><div><br></div><div>With changes to the user experience, writing the code is expected to be the simplest part of the process so the patch may be trivial, but acceptance may not.  I could submit a patch changing the Home background color to a lovely blue; it would be trivial to apply and motivating for me, but not necessarily a good idea!</div>

<div><br></div><div><br></div><div>The correct way to submit this patch is to file an enhancement bug, post the patch to the bug, and create a wiki page under <a href="http://wiki.sugarlabs.org/go/Features">http://wiki.sugarlabs.org/go/Features</a> using the provided template.</div>

<div><br></div><div>An improvement to this patch that would increase its likelihood of acceptance would be to make it a toggle.  Even better would be to report delayed menu item clicks to a usability log server.  Work with a deployment to distribute both versions randomly, analyze the results, and include that in the feature request.</div>

<div><div><br></div><div><br></div><div>I&#39;d like to put my designer hat on for a minute and offer an alternative to Bernie/Michael&#39;s patch and the current behavior:  Any time the mouse hovers over a part of the screen with a delayed action, that part must immediately highlight itself.  With the frame, that would be a 1px rectangle around the screen.  With icons, this could be a border rectangle.</div>

<div><br></div><div><br></div><div>Best,</div><div>Wade</div></div></div>