Talk:File Menu

Bill 27Apr11: Proposed changes in support of the new "Importing Audio" page. Discussing here rather than going live as we may want to tweak this page and the Importing Audio page substantially before we go live. Basically I think we can simplify the description of the Open command by pointing users to the Importing Audio page, and do the same for the Import > Audio command rather than pointing users back to the Open command for details in importing audio.

Gale 28Apr11: I don't think we can over-rely on links being read. I think we have to say (at least):
 * The first time we mention "import" (i.e. in File > Open), state that by "import" we mean bring file content other than an .aup file into a project (by any menu or any other means).
 * In Open, make clear that if there is no content in the project, a new window will only open for each file after the first. We didn't say that before, but I missed it until now. Text also changed to reflect that you can open one or more projects too. Also here (to get away with the terminology confusion about "import"), mention that if you want to bring content into a project which already has existing content, use File > Import.
 * Probably the text linking to the Importing Audio page should mention the role that the file selection filters play in choosing the importer (but not in any detail).

Gale (later on 28Apr11): Thanks, Bill. I've tweaked "Open" further. Please comment. Should the new "Importing Audio" page be limited to importing audio, or also cover MIDI, label tracks and Raw Data? I think "audio" is sufficient at present, as long as the below and your page make clear you can import more than just audio files.
 * Bill: Your version of "Open" is more succinct and hits all the points
 * Opening or importing a LOF file that references multiple audio files behaves differently from opening or importing multiple audio files. Your description is correct if "imported file" can mean one LOF file. But when opening or importing multiple audio files by use of a LOF file, all the referenced files are imported into one project window.
 * AFAICT the discussion on File menu reorganization is still open, so some of this may become moot.
 * Tweaked paragraph starting "If you want to add..." to say "one or more audio tracks" instead of "an imported file" since the user may wish to add an imported file to a live recording.
 * Agree "Importing audio" should be about audio and not include labels or midi. I can see mentioning "raw data" as a special case of importing audio (in a note div?), but I don't think it's essential.

Open ...
Launches a file selection window where you can: If an empty project window exists, that window will be used for the first project or imported file. Any subsequent projects or imported files will create new project windows.
 * Open one or more Audacity Project files (.aup) or
 * Import one or more audio files or lists of files (.LOF).

If you want to add the content of an audio file into a project that already contains one or more audio tracks (for example, to mix two audio files together), use File > Import > Audio... instead. Import means bringing new content into an Audacity project by any means, such as File > Open, File > Import or dragging files into the project window. The content would typically be an audio file like WAV or  MP3, but (using File > Import) could also be a label track, a MIDI file or Raw Data. For audio files, the importer used depends on the currently selected file type in File > Open or File > Import > Audio... and on settings in Extended Import Preferences. See Importing Audio for more information.

Audio
Launches a file selection window where you can choose to import one or more audio files into the current Audacity project. The file(s) will always be added as a new track to the project. This lets you mix two or more files together. See Importing Audio for more information.

'''EVERYTHING BELOW THIS LINE IS REALLY OLD STUFF DISCUSSING 'QUICK TEXT' Experimenting with an alternative to existing quick text. Existing quick text would move out to be with the text under the detailed heading. Not sure I like it, just experimenting.--James

It's a good attempt, done by concatenating some commands which then gives (relatively) more importance to say "Print" than it deserves. Dunno either. At the fonts I use the description still goes way down below the menu, so I feel the need to go back up to look at it because of the grouping of commands. This Quick Text has wasted a lot of time really, apart from identifying mistakes and gaps in what we want to say (somewhere) on these pages. The more I see it, the more I want to get rid of it because if it's done well enough to mean anything, it's then a duplication. I'm not sure if links in tables (which we need more of to save space) are an accessibility problem - links in headers may already be. Whether getting rid of item by item quick text (if we do) means we get rid of the image and restore TOC for menu pages with the shortcut given in the header, I don't know yet. -


 * PS. Any merit (at cost of a lot of capturing) of having separate images for each section  of menus, above each section of text (assuming quick text but not necessarily a summary introduction is dispensed with)? Gives a way for users to skim by image and allows us to show cascades where there are any, which we now don't. Length of image would not matter.  - Gale

Below is some thrown together text for another approach... Obviously needs more work, if it is to work, but gives the general idea--James

I've been reading the discussion about what to do with the menu images and the quick text. I think that I agree that the quick text is there mostly to fill the white space. It has many problems which others have identified. It may have been said before but you'll never get the quick text to line up with the menu items (without breaking the menu image into a separate image for each item - yuk!), forcing you to repeat the menu item name(s) in the quick text.

From a style point of view, I don't think we need menu images just because we have dialog box images. For the special GUI elements in Audacity - toolbars, tracks, timeline, waveforms, etc. - we certainly need images to explain a lot of them. The editing examples would be next to useless without the images - they explain so much better than words. But I would hope that every user knows what a menu looks like and doesn't need a picture of one to follow what we're saying.

The simple table format provides at least two advantages. It preserves the quick text for those users who are happy with that level of information; and it provides a sort of table of contents with hyperlinks to the full text.

So, here's what it could look like if we scrapped the menu image and used a 3-column table. Each menu item name would be hyperlinked to the full text. Note that the Overview text is just there as a placeholder -Bill W

I might like this better if we could create a "menutable" class that:
 * Has the menu items column fixed width (so menu items names can never be wrapped)
 * Has the shortcuts column fixed width (so there's guaranteed to be some whitespace)

I know, the problem with this is that we have to define the class with the longest menu item name and longest shortcut in mind, and if users change their browser text size it will break anyway. But I hate it when I resize the browser window and the table resizes and shrinks the first column and the menu item name wraps - it destroys the "simulation" of a menu.

Anyway I can live with the prettytable or the wikitable for now, for the sake of moving forward with the descriptions of what the menu items do.

Quick text experiments copied from article. Just saving them here in case we want to use them. - Bill

//////////////////////

I wrote my text so it's fairly easy to trim it. This is the minimum I regard as helpful if we are to have sectioned or itemised quick text. Increasingly, I don't see the point, even with this cut down version, which isn't necessarily an improvement if people assume "that's it" and don't scroll down for the details. I'd certainly want to use the quick text as the start of the full text rather than rewrite the full text for the sake of it. If I don't rewrite it, the duplication is obvious. - Gale

//////////////

Don't like the way this is going. The quick text is easily twice the length it once was, and is increasingly making the main text redundant. Your mistake I think is that you're trying to summarise what the commands can do. That's not the purpose. In my view quick text is not trying to tell you exactly what each command does. It's only to tell you enough so that if you are scanning the list rapidly you know whether to look into the feature more. We must convey that metadata is about tags, that dependencies are about being self contained, that chains are an automation feature, because otherwise people might not know. Quick text really does need to be quick.

Text like: "This safely renames a project (letting you then delete the original files), or lets you archive the project in its current state while continuing to modify the original project, such as margins and paper size, if this is the last window open, Audacity exits, if preferred, Audacity can open a new, empty project on closing the last window, go to the Interface tab of Preferences to enable this, the last step of the chain is normally to export the result to an audio file." belongs in the main help. If on reviewing you still don't agree, then by all means experiment with longer quick-text wherever you feel it is needed. For me the main thing is that getting help written is no longer the major roadblock to release that it once was. It doesn't have to be exactly the way I would prefer it.--James I didn't feel the revised quick text was final, and did feel (at any rate in this case) it was getting too long, but I wanted to drop in all I thought we might possibly want to say and think about shortening it again later (agreed I could have div noted that but had to rush). All the things I'm saying are important (unfortunately this menu has more than its fair share of issues which confuse users) and some are currently not said anywhere on the page. That said, I have become disenchanted with this quick text idea. The text we had before (IMO) was wooly, written in non-reference style, and seemed to just give an example of what the command might do (e.g. "export multiple exports to MP3" or whatever it was). Supposing people don't read beyond the quick text, and then think Export Multiple does not work with WAV? Yes I too was beginning to feel the quick text was replacing the detailed text. Perhaps it should do so, because however you phrase that quick text, if you do it item by item then you are creating a duplication and risking people don't even go to the main text. I could not live with the quick text we had before. It looks like the "half-saying things to save space" problem that we are rightly criticised for in the old manual. We may be able to do something like you have on the discussion page for this article (even that is much better than before IMO), and I would not rule out doing the same for the other quick text if you think we need it. But I'm no longer sure this is the right approach. If you want quick text to be solely what you state, I doubt it can be done non-confusingly item by item with the length you want. I think perhaps we like quick text because it looks nice to fill the space to right of a menu image, and we're confusing its purpose because of this. Might it be better just to (yes, summarise) not each command, but what the range of commands in that particular menu does? So, it's like the summary div'd introductions (I think) we're already agreed are a good idea on many pages. Gale

''That said, I have become disenchanted with this quick text idea.... I think perhaps we like quick text because it looks nice to fill the space to right of a menu image, and we're confusing its purpose because of this.'' I think you're right here. '''If you're not happy with it, because you feel it says too little, or if you think the same approach won't work on other menu pages.... then:''' These problems have been entirely caused by the presence of the image. If it had not have been there, we could have got on developing the detailed text. And the old manual does not have menu images - it's two tables of text side by side. The images seem to have appeared in Dominic's early work on the current manual. It's a shame not to have the image but it's at the root of the problem and without it, I doubt we'd even have considered more than a repetition of the text in Menu Reference as an intro div. However as we have images for other items of the GUI I'm assuming we persist with the image.... A side by side image of the menu (at the top) split into two halves would be a solution. I don't think I like that idea a great deal, as it's nice to have the image in one piece so you can see where the various parts are. What do you think? Otherwise, I'm happy with the content/depth of the current Quick Text as far as it goes (except for Edit Menu) and can review the other Quick Text in case I can cut something out that's not essential. I think the content of the Quick Text is now good: it's precise, informative enough if the user does not read further and does not (AFIK) have holes so that something it says isn't true in a particular case. I still think it's a duplication of the main text. The alternative you tried of writing an overview at the right level is very difficult to do, as you found, and will be time-consuming. It may be useful if we use if to address confusions (e.g. in this case the export/save and dependencies problem) but may not be appropriate for all the menus. If it goes down below the level of the image on a medium fonts browser, it's probably too long again. Note that where it does so, it creates its own white space to left. Obviously one of us has got to make a decision on this, including the easy option of just having white space to right of the image. However I think to save this roadblocking work on the rest of the manual as it has been doing, we can probably finish the detailed menu text now. Decide then based on what all the menu pages look like with TOCs removed if it's best the user just goes into the main text, or needs quick text or summary to save them having to wade into the whole page if they don't want to. We can always if needs be add a hint/link in the first relevant menu item to a page dealing with confusions e.g. whatever page we have to talk about Audacity Projects. PS. There is another alternative to an image, which is to make the menu a hyperlinked table instead, as we do here. It's more work, doesn't avoid the problem of having to fill space to right of the menu with something, but works better with larger fonts as the text in the menu will be the same size as the rest of the page text. And it would probably have to be done with CSS to avoid loads of markup in the page.- Gale
 * I think we have been using it to fill the space to the right of the menu image, and being confused about its purpose (the idea of menu with explanation beside it was also a carry over from the old manual).
 * Your new version is fine, not too long, and the hint in the title is helpful. If we can do this for any menu page that becomes over long, that's great.
 * We migrate any useful quick-text into the subheads.
 * If we can come up with summary/introduction/overview text then that's a good solution for 1.4.0 timescale. My worry there is that we then try to say too much in the summary text, e.g. still try to say something about every command in the menu...  I had a go on the talk page, and found myself doing just that.
 * If summary/introduction/overview text is going to be a lot of hard work, or if it will work for some menus and not others, then best just to leave a white space??? What do you think?
 * Post 1.4.0 we can look at extending the menu images to the right by showing the opened sub-menus (only 'Import' in this case, but we have four on the edit menu). It's what I call a 'spider diagram'.  The submenus are linked by black lines to the parent menu items.  We should be able to improve the screen capture code to automate the process of producing image captures, including spider diagrams.
 * I think breaking up the menus into smaller chunks will look messy. I don't want to spend time experimenting with it and then probably reverting it until/unless we have tools that automate the process.