The use of a ">" to get a command box does not appear to be in the online manual anywhere.
At least I could not find it by searching "command", "command line" and reading the articles, nor by looking at keyboard documentation, panel documentation. I also searched the forum using similar terms. I finally got the answer by out-and-out asking on the forum when a support person suggested a command line for a task and put the ">" at the front of the command, but did not at first explain the special function of the ">" -- so I kept looking for a command box or something in the menus, say under tools.
Maybe it is there in the docs and I missed it, but if it's not in "obvious" places, it's just as bad as not being there at all. It really needs to be prominent, since it's the gateway to using commands. It's a rather odd, hidden user-interface technique, and is not in the menus, so it can be very frustrating -- no way to discover it.
Yup, I see it now. But unfortunately, It's pretty well buried -- you'd have to know the answer (the FAYT field) in order to find the answer (the FAYT field).
I suggest you put this and the other functions of the FAYT field -- DOS command, Range, Search, etc -- also in the documentation under each of those functions.
But also consider adding these to a "misc function" menu item under "Tools" as an alternate to the FAYT hotkeys. That way, a user can discover the functionality by searching the menus -- it won't remain "hidden" behind a quirky hotkey/popup mechanism.
BTW, I think I spent a frustrating hour or more looking for this. Yeah, I could have asked earlier, but it seemed so elementary that I thought I was missing something obvious and did not want to pester folks for it. I am a bit gratified to find that it isn't at all obvious, in itself or in the docs.
Adding more documentation won't help when the problem is you can't find what you're looking for because there's too much documentation.
You say you wouldn't know where to look without already knowing the answer, but how did you even know there was something to look for? From the forum, if I remember correctly. So just ask on the forum if someone talks about something and hasn't been clear about how to get to it.
There are some things in a program of Opus's size & complexity that you won't find without going through all the menu items and Preferences pages (Preferences / File Displays / Find-As-You-Type would also show you how to open the command field, in this case), or reading through all of the manual, or being told about it on the forum (or asking on the forum, if you think something is there but can't find it). That's normal, and there's no magic solution to it.
Besides which, the command field is not needed by many people, and is only really useful to advanced users who have already grasped the internal commands and can type them and their arguments from memory. It's not front & center in the documentation or menus because putting it there would actually get in the way of finding more essential things.
Simple questions posted to the forum are often answered in minutes or hours, so just ask if you need something.
There's a ton of documentation about commands in the online help/manual -- that's how I knew there were commands. In fact, my first search was "junction", which brought up 8 results, the first of which was clipboard: "The Clipboard internal command can be used to" -- so hey, there are internal commands! Copy was third on that result list, so I knew within about a minute exactly what command I needed -- copy makelink=junction). Finding how to issue that command in a simple way is what took an hour -- actually, I never succeeded via the online manual.
At the very least, when I search "command" or "command line" the information about how to execute commands ought to appear near the top in clearly recognizable form. That's in addition to all the material about how to construct and edit commands.
What I suggest is a section listing the various ways that you can execute commands -- command line (what we are discussing), via buttons, via scripts (which I still don't understand how to construct and execute), via menus, other ways? -- with pointers to each section.
Anyway, that's how I would do it -- and I've written a ton of software documentation in my day (not to mention a lot of software). Documentation can have "bugs" just as easily as the software itself. DO is a fabulous product -- far and away the best file manager in the Windows market. I do think the documentation suffers a bit from an engineering orientation as opposed to a user orientation, and that can lead to "bugs" such as this one. But it's not big deal -- just fix it, as you would fix any bug and thank the one who found it -- some free QA.
But yes -- I should have asked earlier on the forum. It was kind of a progressive thing -- search a bit; find nothing; feel stupid; take a break; get determined and search a bit more; fail again; feel even stupider; etc etc.
Valid Response and a valid suggestion.
I just don't understand why responses on this forum are at times so defensive.
Surely customer experience can help make a better product that is more accessible to uses of all experiences and backgrounds.
Is it defensive to explain our point of view? Maybe we'd be better off acting like most other software companies, avoiding any conversation, and just say "thanks for the suggestion".
Indeed, as someone who constantly gets frustrated by the manual, and how to find things, I have great sympathy with the original suggestion.
The size of the manual is not the problem, it is how you find your way around it. As no two people will have the same approach it makes sense to have a help system that covers as many bases, and approaches, as possible.
At one stage I used a PDF version of the manual and used index and search software to locate things.
I have recently been using software that has migrated it help file to an on-line "wiki". This is good for random searches of the "now where was that? variety, which is especially important for something as complex as Opus. But then I find myself frustrated by the absence of a local help file. So the software writers can't win.
It's impossible to custom-write the manual for each user which is effectively what you are asking for.
Look at it this way; the information is all in there - if you read it from cover-to-cover then you'd know everything there is to know about the program. Presumably you're not prepared to do that, so what you really want is a shortcut to point to you the particular information you are looking for.
Since we don't know in advance what information people are looking for it's not really possible to include these shortcuts in the manual. That's what the forum is for.
Think of the forum as a personalised index for the manual
It is the ability to find stuff that matters, which was, after all, the initial quest.
To do that the information has to have the right words and concepts.
Like djlewis, I am often in search of the terms "command" and "command line" albeit it not in Opus. In that case, the phrase will, and should, turn up all over the place.
It is down to users to work out how to refine such a search. They will do this using concepts that are familiar to them. These will not always be terms that programmers use.
If users have an opportunity to help to refine the manual to reflect how they use it, the thing could be an improvement over a manual written from a programmer's perspective. That is where the wiki approach can help.
Oh, and I might read the whole manual if it had a gripping plot.
The normal way to use commands in Opus is to create buttons (or menu items, hotkeys, context menu items, etc.) which run them. How to do that is well documented and easy to find both (in long form) in the manual and (in summary form) in the FAQs here at the forum.
In this case, the OP wanted to avoid creating a button and to run the command ad-hoc.
As it turns out, there is indeed a way to do that, and the forum provided the answer very quickly. But it's an advanced, esoteric feature which isn't essential to using Opus and it wasn't needed to get the job done; it just provided an alternative way to do it. (If the command field didn't exist or if you didn't know about it, it's still very quick & easy to create a button, use it, then delete the button. Even knowing about the command field, that's usually what I do myself, because the button editor makes building commands a lot easier than typing them from memory into the command field.)
Esoteric features aren't always going to be easy to find, and won't always have How-To tutorial style explanations of how to use them (like there is for mainstream features like button editing). Making esoteric things easier to find often means making the more important mainstream things harder to find, because people will only look through so much in the manual, FAQs and search results before they give up. It's a call we have to make. People often assume everyone else will look for the same things they were looking for, but we get to see all the questions people ask, which gives us a good overview of what people are having problems finding as a group.
[quote="Renaldostheold"]I just don't understand why responses on this forum are at times so defensive.
Surely customer experience can help make a better product that is more accessible to uses of all experiences and backgrounds.[/quote]
Indeed.
Fundamentally, yes. The complaint "It was too hard to find X in the manual" translates to a request to rewrite the manual so that X is easier to find. The problem is that X is different for every person and every situation.
Yes we could add a page at the start with 40 point type saying "HOW TO RUN COMMANDS" and that would help in this instance, but it wouldn't help the next person who needs to know how to do something completely different.
We don't realistically expect everyone to read the whole manual, but the information actually is all there.
Interesting discussion -- I appear to have touched a bit of a nerve. I do understand the challenge of building and maintaining a complex piece of software and keeping the documentation in sync and in good shape. As I said, the recipe for that, IMHO, is to treat the documentation like software from a process standpoint -- including acknowledge "bugs" non-defensively when they are reported, put them on a list and fix them in some priority order.
But software these days is largely "self-documenting" in the sense that most functionality is accessible via menu items, buttons, links, etc. And that's the solution I would like to emphasize here -- make a new "tools" menu item to perform the functions of the various FAYT hotkeys.
Do you take every feature or UI suggestion as a request for personal customization? If so, then you are not exactly listening to your users in an effective and respectful way, and I think your product will suffer. I know you are just stating your position, but --- again listening to your users -- it's being perceived as defensive, and that's not a good place for a support team to be.
Anyway, it's not for me. I have what I sought -- I now know how to invoke all those juicy but somewhat hidden (not in the standard UI) DO features, including and especially one-shot internal commands!
