Re: How might I filter documentation being searched?
Re: How might I filter documentation being searched?
- Subject: Re: How might I filter documentation being searched?
- From: Andy Lee <email@hidden>
- Date: Fri, 03 Aug 2012 22:17:20 -0400
On Aug 3, 2012, at 8:20 PM, Erik Stainsby <email@hidden> wrote:
> Hi Andy,
>
> Thanks for the thought. I find Dash childishly ugly,
I didn't like the original look, with non-standard windows. Have you seen the "normal"-looking window that Dash currently uses? I was greatly relieved when Bogdan made that change. If that *is* the look you were saying is ugly, then obviously never mind.
By the way, today I noticed something smart that Dash and Xcode do. If you search for "setJitteringEnabled", they find the property "jitteringEnabled". I made a note to myself to emulate that.
> and I have to say that AppKido seems inside-out as a new user aide: it presents the hierarchies as the primary model for the new user.
The intention isn't for the hierarchy browser to be "primary", but what I'm hearing is that it *seems* that way because of its prominence within the window.
The hierarchy browser is for two things -- neither of which, I admit, is the main way people use AppKiDo:
(1) General exploration. I'm not aware of any other doc browser that lets you wander the class hierarchy so easily. I feel this is a useful thing for new Cocoa developers, and experienced ones too.
(2) Showing where a class is in the hierarchy when you've navigated to it by some other means such as Search, or by clicking a link in the documentation. One isn't always interested in this, but sometimes it's useful to see ancestor, sibling, and/or descendant classes at a glance.
> This seems strange because the naiive new user of Objective-C doesn't know where in the hierarchies to start looking for any given object.
I agree the hierarchy browser is an inefficient way to find a specific class. Not to mention, it might not be a class you're looking for but a method or a constant.
I suspect the vast majority of the time people use the Search field to find what they want. Certainly I do.
> Too much space is required also by the out-dated drawer.
Yeah, NSDrawer has been out of fashion for quite a while. It's convenient in that you can adjust its width independently of the main window. But an NSDrawer is not the only way to accomplish this.
There's another sense in which the Quicklist drawer may be outdated. One reason for the quicklists is that back in the day, people were often confused by things like delegates and data sources. Or they weren't aware of all the collection classes that were available.
These days I hardly ever see questions that fundamental any more, at least on cocoa-dev. I personally like having the quicklists there; they're useful sometimes to get to frequently-used classes, and I especially like the "Classes in [FrameworkX]" quicklist. But maybe a case could be made that they aren't worth the space.
> I think it may be time for you to remodel the app.
You aren't the first to say so. Any suggestions? If so, maybe we should take them off-list, but that's up to you.
> $0.02
And appreciated as such. When people try an app and don't like it, they usually don't bother to tell the developer (I know I don't). So it's a real luxury to get concrete negative feedback, rather than wonder what people don't like. Doesn't mean I promise to change anything, but still, it's good to have the feedback.
Getting back to your original question, I see you got a bunch of answers, which is a good thing.
--Andy
>
> ~ Erik
>
>
> On 2012-08-03, at 3:39 PM, Andy Lee <email@hidden> wrote:
>
>> Dash, a doc browser by kapeli.com, addresses this issue elegantly. You can specify a prefix that you type before your search term that indicates which SDK you want to search. Thereafter it assumes you want to keep searching that SDK and supplies the prefix for you. You can always manually delete the prefix or switch it to a different SDK. I use "m:" for Mac stuff and "i:" to mean iOS stuff.
>>
>> You can also try my two apps: AppKiDo (which is for Cocoa, and only shows one SDK of your choice) and AppKiDo-for-iPhone (which only shows iOS docs) -- they're at appkido.com.
>>
>> I've blogged a few times about both apps at notesfromandy.com.
>>
>> Both apps support searching from anywhere via a system service, which you'll want to map to a hotkey using System Preferences.
>>
>> --Andy
>>
>> On Aug 3, 2012, at 5:14 PM, Erik Stainsby <email@hidden> wrote:
>>
>>>
>>>> From: Erik Stainsby <email@hidden>
>>>> Date: 3 August, 2012 1:54:50 PM PDT
>>>> To: XCode <email@hidden>
>>>> Subject: How might I filter documentation being searched?
>>>>
>>>> Hi all,
>>>>
>>>> I'm finding it increasingly frustrating that I am getting four responses to keyword searches in the Documentation browser for every search. I am only developing for OS X at the moment, and all the iOS docs are irrelevant to my needs. I'm still getting duplicate hits for 10.7 and 10.8 but I can live with those I guess.
>>>>
>>>> Is there any way to make the documentation browser search on only one or two of the available docsets? Perhaps even make the document search aware of the build target version? Now that would be a nifty feature.
>>>>
>>>> ~ Erik
>>>>
>>>>
>>>> Sent from my iPad
>>> _______________________________________________
>>> 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