Hrm, it's a good point from a valid problem with using sheets. Novice
users probably won't get the middle-click. But I think making a
separate mode for editing vs. browsing could add a big layer of
complexity -- how exactly would we switch to and from editing mode? I
can't think of any way of doing this that wouldn't make it much harder
to edit code now -- which is probably more important to users than
browsing through code. I think editing code is the main feature of any
IDE and browsing through the code is the secondary, supplementary, feature.
I definitely think the idea of adding tooltips for the underlined links
with a middle-click reminder and other useful information would be good
-- and perhaps then making the links always be underlined and/or blue.
How about another brainstorm to be complained about: when you
left-click on a link, it does nothing out of the normal, but somewhere
on the screen, either immediately below the text (like a tooltip or the
new Office XP floating buttons) or in the context completion area, a
button shows up saying "Browse to java.awt.Vector()". This doesn't get
in the way, is more obvious than any of the other alternatives, etc.
BTW, I do think the Office XP floating buttons (or whatever they call
them) are a nice out-of-the-way feature... (Reminiscent of something I
developed back when I tried to build a vector graphics GUI editor for
Sheets and stuff).
- Aaron
Stephen Chin wrote:
> I've been thinking about making some UI changes to sheets again, and
> wanted to run it past some people.
>
> Here are some of the problems I have been thinking about:
> 1. Middle-clicking is cool, but an awkward gesture for new users
> 2. Rolling over the text to see what gets highlighted so you can click
> on it is annoying
> 3. When you are "navigating" code, sometimes it is easier to use the
> keyboard than the mouse
>
> So here is my proposal (feel free to complain loudly):
> 1. Make editing explicit. You can't type into a fragment until you
> have turned editing on.
> 2. Use the left mouse button for navigating codelinks in non-editing
> mode. Control-left click while editing (with a tooltip to remind users)
> 3. Underline all codelinks upon display (rather than waiting for a
> mouseover)
> 4. In non-editing mode, typing letters on the keyboard navigates to
> the link by that name and pressing return follows the highlighted
> link (sort of like the link navigation feature in mozilla firebird)
>
> Alternative proposal:
> 1. Don't muck with the editing mode because it is fine like it is now.
> 2. Add tooltips on codelinks that reminds users to middle click, and
> possibly has some useful information about the link.
> 3. Underline all links upon display (and don't bother turning things
> blue, just underline).
> 4. Add a special link navigation mode that you enter by pressing some
> key combination, which temporarily turns on the keypress navigates
> links mode.
>
> Anyway, just shooting off some ideas. No promises about actually
> changing the behavior yet. :)
>
> --Steve
|
