Keep LaunchBar from changing abbreviations I assign?

General discussions about LaunchBar
Post Reply
theorist
Posts: 8
Joined: Sun May 13, 2012 3:31 am

Keep LaunchBar from changing abbreviations I assign?

Post by theorist » Sun May 13, 2012 3:57 am

I've used command-option-A to assign one-letter abbreviations to my favorite applications. For instance, Entourage is "E." But suppose I want to open a different program that begins with E a couple of times, and I do so by typing E, and then clicking down to that program. According to the LaunchBar (LB) documentation (and I've confirmed this is the case), the "E" I've assigned to Entourage will be (without my consent!) reassigned to that new program, forcing me to repeat the command-option-A process for Entourage. Is there any way to keep LB from doing this? It seems there should be because, generally speaking, if a user has taken the trouble to assign a specific shortcut to an application, he'd like that shortcut to stay that way until he (not LB) decides it should be otherwise.

theorist
Posts: 8
Joined: Sun May 13, 2012 3:31 am

Re: Keep LaunchBar from changing abbreviations I assign?

Post by theorist » Mon Apr 06, 2015 7:24 am

Bump.....

kaidoh
Posts: 2
Joined: Sun Jan 13, 2013 7:23 pm

Re: Keep LaunchBar from changing abbreviations I assign?

Post by kaidoh » Tue Apr 28, 2015 10:03 pm

I'm not aware of the actual rule behind this, but I guess that you have to use the same abbreviation twice to make Launchbar remember it as "new favorite". I don't think, you can change this "learn rate" user-wise. One simple solution for your use case: type more than one character for occasional other apps. If you want to save "E" for Entourage, use "EY" if you want to launch EyeTV from time to time. Typing two characters does not take that more time - on the contrary: With only one character the list to choose from will be significantly longer.

I have single numbers assigned to my most wanted apps and single characters for often used folders (D for Desktop, A for Dropbox, S (think "stuff") for my documents folder etc.). Everything with a medium usage profile gets 2 or 3 characters. The key is consistency; if you stick to it for a while, your muscle memory will hard code it and you won't recognize speed bumps.

ratty
Rank 1
Rank 1
Posts: 36
Joined: Wed Apr 22, 2015 5:35 pm

Re: Keep LaunchBar from changing abbreviations I assign?

Post by ratty » Wed May 06, 2015 2:21 pm

That's the whole idea of Launch Bar learning from your habits. I think this is a bad idea. You should assign abbreviations to the app you use the most, else it's pointless as you workflow won't be as efficient. If you still want to assign abbreviation to an app you don't use as often simply type one more letter when accessing other apps, it's not that difficult. Don't assign abbreviations unless it's very difficult to find an object. In your case, I'm sure it'll find Entourage with ENT, or ETR, or ERG, even perhaps EG.

You are correct key is consistency and making abbreviations permanent would be counter intuitive and against that idea. Let the Launch Bar learn on it's own, you rarely have to assign abbreviations. It'll learn what apps or objects you use the most, without having to assign abbreviations. You are trying to do that job it's best at, that is learn the usage of objects. Also one letter abbreviations aren't that clever because there can only be so many; what if you want to use Desktop, and Documents, then both of them start with D. You could also have apps which start with D like Disk Utility, so instead it would be better to use DSK for Desktop, and DOC for Documents, and DUT for Disk Utility. You won't have to assign any of these abbreviations, it already knows those unless you overrode them. Use three letter abbreviations, or at least two. As for muscle memory that's the point to use Launch Bar, it's supposed to be intuitive so you don't have remember any thing at all. With your approach you'll have to reassign the abbreviations to new items each time you want them to change and that's just tedious to do and your "muscle memory" might remember the previous ones.

Read more about LB's adaptive abbreviations search here. If you are new, I would highly recommend you reading the whole manual, I also though about assigning abbreviations to every thing when I started using it, but give it time. Don't expect perfect behaviour at the start, you and it will both learn to love and understand each other in time.

theorist
Posts: 8
Joined: Sun May 13, 2012 3:31 am

Re: Keep LaunchBar from changing abbreviations I assign?

Post by theorist » Sat Jun 06, 2015 6:05 am

Hi guys,

Thanks for taking the time to offer your thoughts, and sorry for not replying more quickly,

Ratty, you wrote: "I also though about assigning abbreviations to every thing when I started using it, but give it time. Don't expect perfect behaviour at the start, you and it will both learn to love and understand each other in time."

First, I think you misunderstand me. I'm not advocating giving abbreviations to everything. Instead, I'm advocating maximizing efficiency (for me) by using a hybrid approach in which permanent abbreviations (typically one letter) are given to the most frequently-used apps and documents, and where its adaptive algorithm is used for everything else.

Second, I appreciate that LB works fine for you as currently configured. The problem is I use my computer differently from you and, given this difference, the inability to make some abbreviations permanent makes my workflow less efficient. Here's a specific example that illustrates why the non-permanence makes things more difficult for me:

As already mentioned, I've set Entourage to open with an "E." But suppose I'm working on a project that, for the next week, requires intermittent use of an app called "Exstacy." To avoid losing my Entourage abbreviation, the way LB would have me open this is to type in "Ex" rather than "E". But the problem is I may not remember if it's spelled "Ecstasy" or "Ekstacy" or "Exstacy" etc. So instead of typing in "Ec", looking around,not finding it, then typing in "Ek", and so on, it's far easier for me to just type in an "E", arrow down to find it, and open it. And maybe the next day (since I really haven't bothered to pay attention to the spelling), I do that again and -- poof -- my super-convenient Entourage abbreviation is gone! I.e, when I'm looking for some infrequently-used app that begins with some letter, I'd really rather not be burdened with having to think about being careful to operate LB in a a way that protects my favorite abbreviations, since that requires more work and more personal attention from me. And the point of LB is to reduce this, not increase it. I'd prefer to just lock them in and then not worry about them further.

I also don't like the uncertainty of not knowing whether my favorites will work or not. It's really nice to just do command-space and then E and know that Entourage will reliably appear (and the same for all the others), without even having to look at the LB panel to confirm it. This certainty creates an efficiency that is lost when you have to check it. More broadly, what's most efficient for frequently-used apps is different from what's most efficient for infrequently-used ones. For the former, you want speed and certainty. For the latter, you want adaptability and fluidity. By having permanence for the former, and an adaptive algorithm for the latter, you have a system that is optimized for each category. This hybrid approach is superior to trying to shoehorn two very different categories of apps into the same launch approach. It's the difference between living in Alaska and using snow tires in the winter and all-seasons the rest of the year, versus trying to get by on all-seasons year round.

Indeed, one could say my way of doing things is consistent with LB's own documentation, since it says "you should insist on your own abbreviations." Well, what could be a more strong way of insisting on my own abbreviations than by configuring the program to make them permanent?! Steve Jobs (who I think knew a thing or two about designing efficient user interfaces) once said that 'computers should adjust to people, not the other way around.' By not allowing me to configure LB as it's most efficient for me, LB is violating Job's dictum by forcing me to adjust to it, instead of it adjusting to me. And if you don't find that argument compelling, let me put it in terms that you might relate to better: you believe in the idea of an adaptive interface. Well, if LB were truly adaptive to me, it would notice me continuing to reset certain abbreviations when they are lost, and thus leave them permanent, so I would not have to keep resetting them! Alas, LB does not have quite that level of adaptive capability, so the only way to make it truly adaptive to me is to allow me to configure these to be fixed until I tell it otherwise.

You may be tempted to dismiss this post as representing someone that is not sophisticated in adaptive algorithms. On the contrary, a truly sophisticated understanding of adaptive algorithms covers not only their powers, but also their limitations. And it's a limitation, and a work-around for such, that I'm bringing to light here. Until LB is like Samantha from Her :D, such work-arounds (or, if you prefer, customizations) will be necessary to ensure it is optimized for all users.

I hope this makes my insistence on this more compelling.

Post Reply