Re: suggestions for documentation integration
Re: suggestions for documentation integration
- Subject: Re: suggestions for documentation integration
- From: Ronald Hayden <email@hidden>
- Date: Thu, 8 Nov 2007 14:45:45 -0800
I'd like to see a
much slicker, keyboard driven browser that takes you from the search
to the
desired doc more directly (rather like AppKiDo does it, perhaps).
We will consider this factor for our next UI upgrade. Please feel
free to file a bug as a prompt also.
Some of the challenge we've had in this area is that people tend to
want the browser to get the focus so that their next action (such as
using scroll gestures) impacts the doc that just got loaded, rather
than the search field or results table. Moving the focus to the
browser, however, makes it harder to allow for easy keyboard
navigation of the search results. So far we've erred in favor of
browser focus because people find it really annoying when scrolling
doesn't behave as they expect and they start filing bugs. However, we
can take another look at Appkido and other solutions to see what works
there.
What
I was expecting by now is that every method listing would have a
little
"paste" button next to it (or even some less clicky device) that would
transfer the template for this method right to the selection point
in the
frontmost code window.
This is an existing request, which we didn't spend time on for Leopard
because we felt that the code sense functionality was better optimized
for this sort of thing than anything we could probably provide in the
documentation, and so it was better for us to focus on other aspects
of the major doc viewing overhaul we did for Leopard.
Also, we get requests to add various doohickeys to the doc, such as
buttons to jump from each section to the top of the document, and I'm
way of adding a bunch of UI to documentation. For me, it tends to be
distracting, and just something I might accidentally click while
scrolling around.
That said, especially since this has been requested multiple times,
we're certainly open to considering it.
-- Ron
On Nov 8, 2007, at 12:14 PM, Matt Neuburg wrote:
What I was hoping for hasn't come to pass in Xcode 3, so let me try to
describe what it would be like. I haven't actually got an exact spec
in
mind, but here's the problem for me: the documentation is (1) too
darned
clicky / scrolly, and (2) not integrated with the code you're actually
working on. The talk of a "research assistant" had raised my hopes,
but my
experience so far is that working with the documentation is no
better than
before.
As an example of (1): Let's say you want to look up something about
NSString. So you type NSString in the Find field. Good, NSString
shows up in
the list below. But to display the documentation for it, you've got
to take
your hands off the keyboard and click on it in the list; there's no
way (as
far as I can work out) to do it with just the keyboard. I'd like to
see a
much slicker, keyboard driven browser that takes you from the search
to the
desired doc more directly (rather like AppKiDo does it, perhaps).
As an example of (2): Why are you here (in the documentation)? It's
usually
because you're looking for some method that you're thinking of using
in your
code. Okay, so you've found it. Now how do you get it *into* your
code? What
I was expecting by now is that every method listing would have a
little
"paste" button next to it (or even some less clicky device) that would
transfer the template for this method right to the selection point
in the
frontmost code window.
Basically what I'm suggesting is that the designers of the
documentation
window should be studying actual use cases among developers.
Watching me
struggle with Xcode for five minutes would certainly provide a clue!
m.
--
matt neuburg, phd = email@hidden, <http://www.tidbits.com/matt/>
A fool + a tool + an autorelease pool = cool!
One of the 2007 MacTech Top 25: <http://tinyurl.com/2rh4pf>
AppleScript: the Definitive Guide - Second Edition!
<http://www.amazon.com/gp/product/0596102119>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden