What’s an alternative you’d be satisfied with? While it’s not possible to add custom toolbar icons, buttons, etc. most functionality can be “promoted” to be more conveniently accessible with keyboard shortcuts, although it may require more effort (e.g. script writing) and third-party support than desirable.
You happened to pick an example that’s irrelevant for my current DTPO usage.
What about functionality we could agree is already up front and obvious that many customers never use? Surely I ignore more of DTPO’s functionality than I use; same with most apps of any reasonable size.
Earlier, you mentioned:
I’d say it’s harder to satisfy (your) mouse-centric interface usage than (my) keyboard-centric usage. Most mouse-centric interface components/priorities will be static while most keyboard-centric ones can be more flexible.
I’m questioning more than answering here, e.g. what does “up front and obvious” functionality mean and how might the DTPO office interface better accommodate it?
And wouldn’t it be nice if there was some way to change and assign keyboard shortcuts like in BBEdit and Mailsmith, so that you can do it from within the application (ie no need to type the menu name in the preferences panel), be warned of conflicts, and be able to change default shortcuts? eg I never use “Highlight”, and I’d like to rebind command-shift-L. But I can’t (or at least I don’t know how to).
But I guess providing this functionality would take too much work.
Ideally it could also warn of conflicts with any shortcuts that override app-specific ones. I’ve been more careful about using Control- as a modifier for some of my shortcuts since DTP(O) started using it with more of its shortcuts, though it won’t always matter if my shortcut takes precedence. I’ve previously suggested that DTech be less aggressive about assigning default shortcuts in its apps and leave it up to users to do it if they choose to, which ties into to:
The app is at a scale where it seems to need its own shortcut management system, like BBEdit, et.al., to cope with the increasing shortcut overload.
IMO, certain commands likely to be infrequently used by most users (e.g. Tools > Verify & Repair) really don’t need default shortcuts. But I suspect it’s one of those interface decisions that’s unlikely to change.
That should be possible using Keyboard Shortcuts in System Preferences, and for any other commands under the app main menus.
Yes, DT is one of the applications that could really use such a system.
Perhaps at some point in the future Apple will provide such functionality for keybindings (apparently there’s a “haxie” that lets you do easily redefine shortcuts, but I’ve never tried these things and don’t feel like putting more stuff onto my system).
Sometimes I wish everything was built atop emacs: “easily” extensible, self-documenting, definitions of most functions within a few keystrokes… It’s fair to say that, in some respects, we’re going backwards. Shame the thing takes almost as much regular practice to remain current on as a musical instrument.
You’re right, it can. For some reason I was convinced that this does not work if the key is already bound, but I was wrong. Excellent. The prefpane isn’t so bad after all!
Unsanity’s Menu Master Haxie™ is the only one I’m aware of. Never tried it, even before Apple added Keyboard Shortcuts functionality.
Ha! I’ve long wanted a layer for the OS with those Emacs-like capabilities, too. You’ve probably heard the jokes about Emacs being an OS.
Glad that’s working for you now. One issue I’ve had here is certain shortcuts (re)assignments will disappear from the KS UI even though they’re actually still in effect, and can mysteriously reappear again later. I save screen captures to have a record of the assignments in case they need to be redone for any reason.
I think that some commonly used and useful functions are a little too hidden in the app as it stands at the moment. I therefore wonder whether it might be useful to take a step back and look at the application afresh and consider if some of this functionality might be usefully brought more to front of the application e.g. possibly via the toolbar. DTP is a mature app and sometimes I think developers can get blinded to how users actually currently use their application or what is important to a users daily workflow with the app.
Judging by your post count you’ve either used the app a long time or are very keen on it - making you more expert at the nuances of it. I’m coming to it fairly fresh and still have a lot to learn about it. But because of this I think it’s useful to consider what I as a new user find confusing about the interface or commands because that may add insight into improving the app’s usability.
Well that’s exactly my point - could some of the stuff thats up there on the toolbar but not commonly used be potentially replaced by other items that are commonly needed. A well tuned app will be optimised to ensure that the most commonly needed functions are the most available.
I’m wondering are there many users wanting to do tasks that are not easily accessed and is some of the valuable screen real estate on the toolbar being used for items that are not being commonly used? If a toolbar item is used by 1% of users but 90% of users have to utilise a 4 component keystroke, contextual menu or find an arcane script to undertake something then it might be time to rejig the interface a little. I exaggerate here to illustrate obviously but the point is a valid one if you want a fine-tuned app.
Yes of course there are many possible usage scenarios but, for example, on this thread you’re in the minority in not commonly needing to OCR and retitle documents.
I thinks it’s self evidently easier to accomodate a keyboard focussed user than a mouse focussed user because the reality is there’s only so much you can access quickly from the mouse and there’s limited screen estate on the toolbar. As I get more familiar with the app I’ll undoubtedly make more use of some of the keyboard commands, I already do now with the “Set Title As” command, but there’s still a place to accommodate those who do not commonly use keyboard commands as the Mac is GUI focussed.
I would say that it might be a useful exercise for the DTP guys to look at the most common usage scenarios and run through how the users workflow would go. If for the most common usage scenarios the majority of the functionality can be easily accessed then this is ideal. But if it turns out that certain tasks that users need to undertake often are not easily accessible perhaps the interface can be tweaked. This results in an easier to use app for the majority of people which makes it a better and easier to use app.
Here’s a script I wrote, based on the “Append to Title” script, that prepends the selected text to the document title, then allows you to edit the new name before applying it. I like maintaining the auto-generated date stamp in the title because it tells me when the document was scanned, and helps avoid duplicate file names.
Note: by naming this file “Title Prepend___Cmd-Ctrl-Opt-p.scpt” I can trigger it with the keyboard combination specified in the file name, which also appears in the AppleScript menu. I also like the idea of this in a new folder (I use “Custom”) in the Devon scripts folder.
-- Prepend To Title
-- Created by Neil Johnson on March 11, 2015.
-- Based on "Append to Title" script
-- Created by Christian Grunenberg on Aug 10 2009.
-- Copyright (c) 2015. All rights reserved.
tell application id "DNtp"
try
-- Check for selected text
if not (exists think window 1) then error "No window is open."
if not (exists content record) then error "Please open a document."
set theText to selected text of think window 1 as string
if theText is missing value or theText is "" then error "No text is selected."
-- Display proposed new file name for edits and confirmation
set oldName to name of content record
set newName to theText & " " & oldName
set userCanceled to false
try
set dialogResult to display dialog ¬
"New Name:" buttons {"Cancel", "OK"} ¬
default button "OK" cancel button ¬
"Cancel" with title ¬
"Update File Name" default answer newName
on error number -128
set userCanceled to true
end try
-- handle input
if userCanceled then
-- statements to execute when user cancels
display dialog "Name change cancelled."
else if newName is "" then
display dialog "Please specify a file name."
else if button returned of dialogResult is "OK" then
set newName to text returned of dialogResult
set name of content record to newName
end if
on error error_message number error_number
if the error_number is not -128 then display alert "DEVONthink Pro" message error_message as warning
end try
end tell
