Hi, just upgraded to 2.0 and am really missing a feature. In my earlier version, I could select a word, and control click (or right click) on it and I’d get the option of looking up the word in the OS X dictionary. That is now missing. How can I get it back???
Thanks!
It’s still there, just under “Writing Tools” toward the bottom. 
…or press Ctrl-Cmd-D
Regular readers may think there is a certain single-minded repetition in my posts, but I do use other shortcuts. Honest. Sometimes I even use my mouse. But when you combine the 2, ooh what fun! Try holding Ctrl-Cmd-D and then moving the mouse across your text - little definitions appearing one after the other, chasing each other across the screen. Whole moments of entertainment…
And once again, if you hate the little small-font hover mode that Ctrl-Cmd-D presents, customise Scrivener so that the full dictionary lookup is bound to this shortcut instead!
On the contrary, I’m glad you chimed in. I was thinking of you but I never use the Dictionary shortcut. (Honestly I never use the look up context menu either, I always take the roundabout route of typing the word in Spotlight if I have to look something up, and I have a NaNoWriMo specific rule of just highlighting a word I know or believe to be wrong and fussing with details like definitions later.) I tried very lazily to look up what was the right shortcut so I could include it in my post, but after 45 seconds of searching hadn’t found it, I just posted without it. So good, now other options are presented!
Ah, didn’t see it hidden under Writing Tools. The Control-Command-D trick is AWE…SOME. Thanks everyone!
Big thumbs down on this change (2.0 not presenting “Lookup in Dictionary” on a right-click over a word, which I use very very often during development).
Lots of nice improvements in 2.0 but this is a big usability backstep IMO.
Please revert this to the 1.0 approach in your next revision.
Really, having to navigate to a single submenu is such a massive effort? Pages does exactly the same, and it’s in a submenu in Word, too, so it’s not like this is uncommon. Moreover, it’s in a submenu because it belongs with “Look Up on Google” and “Look Up on Wikipedia”, which combined take up a fair whack of room and there are plenty of other commands that belong in the ctrl-click menu. Do you really spend all day looking up the words that you are writing? I can’t understand why you’d want to use this command so frequently that those extra few millimetres of mouse movement make any genuine impact on your working day.
That was a “no”, by the way.
(I’m not trying to be facetious, incidentally - I’m genuinely bewildered that anyone would need this menu item so frequently that its movement would be such a cause for complaint.)
And once again, if you hate the little small-font hover mode that Ctrl-Cmd-D presents, customise Scrivener so that the full dictionary lookup is bound to this shortcut instead!
Would you stop solving the problem already! How is a person supposed to complain when you keep fixing the issue?
Bah!
I have to chime in here since this change from 1.x slows down my writing as well.
It is not a MASSIVE effort when done once, or maybe twice; but I’m the kind of writer who use the full dictionary and thesaurus all the time, searching for precision in my writing, looking up definitions even of words I think I know well, and constantly using the thesaurus. And those extra steps, right-click, visually scan for “writing tools,” then carefully pulling the cursor arrow along the highlighted menu item so you don’t loose it’s highlight, and then visually scanning again before targeting the Lookup in Dictionary and Thesaurus submenu. Adding the submenu is significantly slower when you want words to flow seamlessly - unimpeded by thoughts or distractions - onto the computer screen.
I think the brilliance of Scrivener is that it is NOT Pages or God forbid Word. Scrivener is the best writing tool in the world because you have designed the best interface specifically for how writers think and work. Pages and Word have not done that. Comply with some kind of normative standard when it doesn’t matter, but Scrivener should be unique when it matters (the others will follow along, or not, to the detriment of their interfaces).
“Lookup in Dictionary and Thesaurus” is a whole lot more important to the writer who is writing than I believe “Look Up on Google” and “Look Up on Wikipedia” are, which are more research tools and therefore may belong on a submenu.
The full-screen dictionary and thesaurus is vastly superior to the small little boxes with a few measly words in them.
And lastly, during spell checking, a right-click brings up alternate spelling choices top and center, therefore there just seems something right about having “Lookup in Dictionary and Thesaurus” immediately under those words, or in place of those words when one is not spell checking.
I notice you didn’t once reference the usage of a keyboard method for doing this. If you are typing and you want to look up a word, why are you even messing with the mouse in the first place, no matter where the menu item is, or how many pixels you have to traverse in the orthogonal mode to get there? You are already slowing yourself down by the sheer amount of mental and nervous system activity that is required to move your right arm through vast amounts of space, delicately find the apparatus, and position it over the word on the screen in the first place. I’m already alt-tabbed back to Scrivener by the time you’ve right-clicked in the right spot. The situation is only marginally better on a laptop with a trackpad.
Whatever points you make seem to be beside the point. A menu should be designed to be the best menu it possibly can be. Alternate modes of navigation / entry should be the very best they can be. And then the writer should decide what works best for them, even if they appear illogical to others, no?
I’ll bite.
No.
You’re argument was about efficiency. Ioa points out the fundamental flaw in your argument; using the mouse over keyboard short cut is fundamentally in efficient. Your suggestion that user preference trumps UI design spec is also flawed as you are a user of the most tightly control UI in existence, Mac OS. Scriv now uses the OSX standard placement of this contextual menu.
What am I missing?
I’m being dense, Ioa. 
How do I do that precisely? I’m still setting up my new MBA. On the MBP i have over-ridden the Ctrl-Cmd-D so that does a “Convert Formatting to Default Text Style” as I use that the whole time. However I do use the dictionary all the time (when I have Chinese-English and English-Chinese dictionaries installed) so I have changed the “Convert …” shortcut on the MBA so that I can use the dictionary shortcut for its original purpose as well. On the other hand, the little pop-up is not enough for me, but I don’t want to have to click the “More …” button in the bottom corner all the time in order to access the full works.
I don’t find the submenu access problematical, since when I’m accessing the dictionaries I need a lot of thinking, as opposed to typing time anyway, but the shortcut option would be nice to have too.
Mark
I’ll bite even harder: if the argument is one of efficiency, and that is all the argument is about, then there no conceivable advantage to using the menu unless there is no other option (and there are many cases where that is the appropriate answer, to be clear, but this response is why this particular case isn’t one of them). If this argument is about things not being the way they used to, or user preference as you suggest, well then that is another matter entirely, but in efficiency, there are two scenarios:
Now note that I didn’t describe how you get to the menu function in both Method A answers. This is a variable quantity and involves a different amount of effort based on a number of difficult to predict factors. It is not a set procedure.
So quantifying the tail action, “access a menu function”, is difficult to do because it is highly variable, and a highly variable landscape that must be parsed and adjusted to using cognitive thought is by definition inefficient because of the introduction of semi-unpredictable multiple stimuli that you must react to in order to process a decision action and convert it into physical motion. Whether the item is in a sub-menu or the top-level menu is almost moot, given everything else. I say almost because in an isolated closed-box scenario where all you have is Method A, then any added complexity to the “access a menu function” stage is indeed a liability.
My point, and it is entirely relevant and not “beside the point”, is that there is more than just Method A, so attempting to construct an argument based solely on the neglect of external methods is not an accurate picture of the situation (there is also a Method C: and that is the “Dictionary” toolbar icon, which I would consider to be a compromise between A and B. It lack’s B’s precision, but at the same time it also lacks A’s unpredictability, though suffering a slight drop using Fitt’ Law in that the most optimal placement for something is where you already are—not that a contextual menu item usually is—but the menu at least is).
Method B, on the other hand, has no variables. The final action in the list is precisely the same no matter if the word is at the top or bottom of the screen, or if you are in a table cell, or clicking on a word with 35 suggestions—it simply doesn’t matter—it’s always the same purely mechanical reaction, requiring no extra cognitive functioning to perform: it is, by definition, efficient.
Circling back around to an earlier argument: it requires two hands. Yes, and presumably you have two. If you do not, then I apologise in advance for the faux pas. In fact, in most UI scenarios, unless the application is solely keyboard based or mouse based, a combination of the two comes out the winner. Classic example: Photoshop. There is another program that is extensively wired up for keyboard usage. Even though on the surface you might think it a mouse intensive application—it’s actually not. If you’ve ever been in the same room as a professional graphic designer you’ll know this. They almost use the keyboard more than the mouse in Photoshop. In most cases, the most efficient way to use Photoshop is with two hands: one to point and one to enact. Expert Photoshop users hardly touch menus (but even when they do, a menu use does not require displacement of the left hand).
I would submit that editing and proofing is, mechanically speaking, very similar to professional graphic work. It is a two-handed affair: one to point and one to enact. Now since editing does require periodic typing, there is going to be more back and forth than in Photoshop, no analogy is flawless and this truth cannot be avoided, unless you are particularly efficient at one-handed typing—most touch typists are not—or very good at navigating text without a mouse (again, Vi users).
So setting that outlier aside, most editing actions are point and enact. Point and fix a letter; point and highlight; point and delete; point and cut and paste; point and look up in dictionary. These are two handed actions by nature. They can be done all entirely with the mouse or all entirely with the keyboard, but neither is going to be as efficient, 90% of the time, as a two-handed approach.
I’m speaking purely of raw efficiency here. This isn’t about individual preference, or aesthetic beauty, or anything like that: this is purely about the reduction of cognitive UI management time (giving your brain more cycles to focus on the work and not the program) and the maximisation of mechanical protocols to accomplish frequently enacted tasks. The more predictable your pathing is, the less you have to look at the interface and “think” about it, giving you more time to do what your job is.
And how critical is all of this? Barely (no offence intended). The calculated differences between (a) item dynamic at top-level, (b) item dynamic at second-level static, and © item at static mechanical is—in the grand scheme of things: nothing to worry about. We are talking about fractions of a second and minuscule load time on the brain between the first two, compared with a fairly substantial reduction in the third. Or to put it another way: quibbling about variances in the pathing between a & b are like fussing over whether its faster to use the iPad glass keyboard in portrait or landscape orientation when you have a Bluetooth mechanical keyboard sitting right beside it.
You might need to check your Dictionary preferences and make sure they are set to “Opens Dictionary application” instead of “Opens Dictionary Panel”. I had to change this to the first option, and once I did that, the keyboard shortcut that I set up (as well as the toolbar icon), were rerouted to the full Dictionary.app, rather than the panel.
Hmm … it was already set to that, but it only worked on the contextual menu, not with the standard shortcut. This is on 10.6.5, by the way.
But I then thought the best way to do it was to set up the shortcut in the system preferences for Scrivener to open the full dictionary app. That works.
Thanks
Mark
Oh, yes! Sorry, I thought that is what you meant initially. That is precisely what I’m advocating. Add a custom shortcut for “Look Up in Dictionary and Thesaurus” to system preferences.
Preference I understand (I like sweet, my wife likes savoury - neither is better, just different). But when we return to a discussion on efficiency, I find it hard to see how reliance on a mouse and menus can be more efficient than a keyboard. I won’t rehash AmberV’s detailed response, but I will say that to check the definition of a word my fingers barely move from their home key positions (I just tested this on the word “positions” - little finger moved down from A to CTRL, thumb moved from space to CMD and middle finger stayed over D).
Two hands? It never occurred to me to use 2 hands to press Ctrl-Cmd-D as I’ve only ever used one hand to type it. It’s just part of my workflow, my hands never leave the keyboard and my eyes stay in place. If I then really need to use the full dictionary, well then I use the mouse to select “More…”. After reading AmberV’s responses, I’ve now set up a separate shortcut to open the full Dictionary app and display the definition of the highlighted word, but I do wonder if I’ll ever actually use it (especially since it requires highlighting, while the standard Ctrl-Cmd-D does not).