User:Billw58/Templates and Spans

From Audacity Development Manual
< User:Billw58
Revision as of 23:32, 27 April 2012 by Billw58 (talk | contribs) (comments, and a grey box with icon)
Jump to: navigation, search
  • Bill: Summary as of 10Apr12
    • I think we have consensus to change the advice div and template to pale orange (#FFEECC - same as current editornote), and change the editornote div to pale mauve (#EEDDFF - last example in that section).
    • I'm OK with #FFEEAA for the menu span and template (#2 in the examples below) so I think we have consensus there as well.
      • On April 12 or 13 I'll change the css for these if there are no objections here or on the -manual thread.
    • On April 12 or 13 I'll trim the key and button template examples down to those that have received positive votes and we can have another round of voting on those.
    • Worst case - if people don't like them I can just revert the css.
    • I think it will be useful to see them in use throughout the manual and continue to tweak as needed.
  • Bill 12Apr12: Trimmed page for easier comparison of outstanding choices: key, button, keyboard and path spans
  • Bill 13Apr12: Templates and CSS classes now created for button, keyboard and path. We can now try those out "in the wild".
    As we continue to refine our choices here I can edit the CSS to reflect those changes throughout the manual.
    I have not changed the "key" (shortcut) CSS since that one is widely used throughout the manual and I think we need more consensus here before we change it.
  • Bill 17Apr12: Today changed the CSS for the key span and template per editornote below those examples.
    New deadline of April 20 for the various button templates and the keyboard template.
    BTW, I am putting off editing the Consistency page, and changing the CSS in the wiki to match the manual, until all changes are accepted. So for a week or two they may be out of sync.
  • Bill 20Apr12: Today changed the keyboard span/template to white text on dark grey background; created templates for the rest of the buttons.
  • Bill 26Apr12: Today changed the keyboard span/template back to bold italic text on white background; change button border to "outset" (makes it look 3D).
    Re-arranged page with "decided" items at bottom.
    Added section for comparison of alternative Intro and Note div colours.

Changing the Intro, Note and Advice Box Colours

Gale, in a -manual thread, has suggested changing the presentation of these notes to match the wiki. Here is a comparison.

  • Gale 26Apr12: To me, green is a better colour for the "note" or "hint" than blue. A blue or grey is better for the "intro". Even simply switching the "intro" and "note" divs" in the Manual would afford IMO a significant improvement (examples added).

    I also added a comparison of the Manual and Wiki "advice" div where we have a problem with the "menu" span or template not being visible enough. Apart from that, the more yellow colour on WIki seems preferable; this is the next stage up in importance from hint/note, and the current Manual colour looks like an "aside".

    If a yellowish colour is right for "advice", what to do with the "menu" span? I am still not convinced by the current "menu" colour, nor frankly with the "key" colour - this IMO does not work well inside the Wiki "hint" div and even less inside the Manual "note" or "intro" colour. Would a lightish purple/red background work for "key" like our editornote? I think we can be more garish with the "menu" colour than the "key" colour. I see "menu" as like emphasising the text with a highlight pen. This is something like we do for "key" now, but it seems like overemphasis, just like the overemphasis with "keyboard" as white-on-black. Note on the Wiki, we permitted a different colour for menu strings in divs (menugrey) - is that something we want to do here?

    Generally, I think it could be good for note/hint and advice div colours on Manual and Wiki to be the same, otherwise there is confusion of meaning when switching between them. There could be a case for Manual and Wiki intro divs to be different blues or greys, making it clearer "which" you are on. I suggest deciding the div oolours first then going into detail about the span/template colours that fit.

    I also mentioned icons such as "light-bulb" for "hint", maybe "i/info" for "advice" and "exclamation" for "alert". I think this would assist interpretation of these divs.

  • Bill 26Apr12: Round and round we go :)
    • The advice div was changed to pale orange since the yellow was thought too garish.
    • The menu span was changed to pale orange since the yellow was thought not visible enough (and did weird visual things when the bold blue link text was on top of it).
    • It seems we forgot to consider all possible combinations of text highlights and div colours.
    • Is it possible to put icons in divs? I know how templates do it, but I can't see how to do it with a div. If we were to add icons to the note/advice/warning boxes, would we not have to change all occurrences of those divs to templates?
    • If we do add icons to the boxes, perhaps advice could go to light grey with the blue-circled "i"?
    • I can see a case for returning the key span to grey if we keep a blue box.
    • I agree that Wiki and Manual should have consistent spans, divs and/or templates, especially now that we are sprucing up the Wiki.
    • Yes, let's get the boxes right, then work out text highlights that work with them.
      • In general, paler colours are probably better for the boxes - less obtrusive and allow text highlights to stand out better.
      • Added some paler examples for the hint/note and advice divs.
    • The TOC table background is #EAEDFF, and the Wiki intro background is #EEEEFF. Very close. Would it make sense for them to be the same?
    • The editornote can be any colour, so grey is probably an option there.
    • We've kind of got a traffic-light thing happening here:
      • Green = go -> Note/Hint
      • Amber = beware -> Advice
      • Red = stop -> Warning
    • ATM I'd go for Intro #3, Note #5 and Advice #5.
  • Peter 27Apr12: My primary concern is that I would like to see the same formatting styles and the same coloring in the Manual and in the Wiki. The HTML is hard enough to grapple with anyway so having two different sets makes it more than doubly complicated. We have moved somewhat in this direction recently, I would like to see us complete this journey. It would produce a visual consistency, a "house style", across our user documentation.
    • I don't think I like the ide of icons like light bulbs. I don't like the icon in the warnings in the Wiki - the red color is scary enough anyway. For me the use of icons like that is a bit twee and passé - and they take up valuable real-estate on the screen.
    • I like Bill's traffic-light model, makes sense to me.
  • Bill 27Apr12:
    • -1 for icons in the boxes
    • See -manual thread for discussion of Manual <-> Wiki consistency
    • Peter, what do you think about the various colour choices for the boxes?
      • Peter 27Apr12: my head's spinning too much to think about colours today Bill. I'll try to take a look over the weekend, I may be able to cajole a newbie (Mrs. waxcylinder) to have a look too.
  • Gale 27Apr12: I never agreed to changing Manual advice div away from yellow as far as I recall. If the previous yellow was too garish, the current colour is meaningless, as is the very pale green #5 for the "note" which hurts my eyes. Experience seeing the "key" and "menu" colours in practice tells me we got it wrong (someone actually complained about the "aggressive" "key" colour).

    Wiki IMO had most of this right in the first place. I would like a more "defined" border colour and a slightly different background colour for the Wiki intro div, but that is all I would have changed. In particular, the misnamed "key" span/template here is a pain - I can never remember which is which versus keyboard, it should IMO have been called "shortcut" as in Wiki. I wish I had been more involved when Dominic made these changes.

    Of course you can have icons in divs, see the first "intro" div below. If you want the text to line up to right of the icon then you will probably have to use a table (which you can template easily). I'm not wedded to the idea of icons if others are opposed, though I do think they give us more flexibility in background colour choice than if we don't have them. +1 to Wiki/Manual intro div colour and TOC background being the same, though I find the colours we currently have for both a bit too "purple" and jarring. I suspect there may be a better shade.

  • Bill 27Apr12: Although I'm not keen on icons I can see a case for them, if the advice, note and warning divs were grey and their purpose was indicated by the icon, much like a printed manual. I'd want the icons to be somewhat low-key; the warning icon in the Wiki is too much IMO. See added example #6 under Notes.
    I'm open to exploring shades of purple for the intro div and TOC.
    Of course one can put an icon in a div by writing it in explicitly. My point was that a template puts it in for you and can include a table construct to place the icon where you want. If we were to switch to icons for the note, advice and warning boxes we'd have to either change all occurrences of those divs to templates or explicitly edit the icons into the existing divs. That's probably as much work as changing all the key spans to mixed case.

Intro

1) Manual:

FrenchFlagSmall.png Preferences let you change most of the default behaviors of Audacity. The Preferences dialog can be accessed using the Edit Menu (or by using the shortcut CTRL + P). On a Mac, Preferences is under the Audacity Menu (shortcut CMND + ,).

2) or could take the current "note" colour:

Preferences let you change most of the default behaviors of Audacity. The Preferences dialog can be accessed using the Edit Menu (or by using the shortcut CTRL + P). On a Mac, Preferences is under the Audacity Menu (shortcut CMND + ,).

3) Wiki:

Preferences let you change most of the default behaviors of Audacity. The Preferences dialog can be accessed using the Edit Menu (or by using the shortcut CTRL + P). On a Mac, Preferences is under the Audacity Menu (shortcut CMND + ,).


Note

1) Manual:

These two values also control the Cursor Long Jump and Cursor Short Jump commands when playback is stopped. The shortcuts , (comma) or . (period) jump the cursor backwards or forwards respectively by the Short Period interval; SHIFT + , or SHIFT + . jump the cursor backwards or forwards by the Long Period interval.
  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)

2) or could take the current "intro" colour:

These two values also control the Cursor Long Jump and Cursor Short Jump commands when playback is stopped. The shortcuts , (comma) or . (period) jump the cursor backwards or forwards respectively by the Short Period interval; SHIFT + , or SHIFT + . jump the cursor backwards or forwards by the Long Period interval.
  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)

3) Wiki:

These two values also control the Cursor Long Jump and Cursor Short Jump commands when playback is stopped. The shortcuts , (comma) or . (period) jump the cursor backwards or forwards respectively by the Short Period interval; SHIFT + , or SHIFT + . jump the cursor backwards or forwards by the Long Period interval.
  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)

4) Paler still

These two values also control the Cursor Long Jump and Cursor Short Jump commands when playback is stopped. The shortcuts , (comma) or . (period) jump the cursor backwards or forwards respectively by the Short Period interval; SHIFT + , or SHIFT + . jump the cursor backwards or forwards by the Long Period interval.
  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)

5) Very pale

These two values also control the Cursor Long Jump and Cursor Short Jump commands when playback is stopped. The shortcuts , (comma) or . (period) jump the cursor backwards or forwards respectively by the Short Period interval; SHIFT + , or SHIFT + . jump the cursor backwards or forwards by the Long Period interval.
  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)

6) Grey with icon

Note These two values also control the Cursor Long Jump and Cursor Short Jump commands when playback is stopped. The shortcuts , (comma) or . (period) jump the cursor backwards or forwards respectively by the Short Period interval; SHIFT + , or SHIFT + . jump the cursor backwards or forwards by the Long Period interval.
  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)

Advice

1) Manual

  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)
  • The exact operating system you are using (for example, Windows 7 Service Pack 1, Mac OS X 10.6.8, Linux Ubuntu 11.10)
  • Any other information about your computer and its audio connections that you think might be relevant (for example, 2 GB RAM, 2.2 GHz, M-Audio Fast Track USB interface).

2) Wiki

  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)
  • The exact operating system you are using (for example, Windows 7 Service Pack 1, Mac OS X 10.6.8, Linux Ubuntu 11.10)
  • Any other information about your computer and its audio connections that you think might be relevant (for example, 2 GB RAM, 2.2 GHz, M-Audio Fast Track USB interface).

3) Paler orange

  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)
  • The exact operating system you are using (for example, Windows 7 Service Pack 1, Mac OS X 10.6.8, Linux Ubuntu 11.10)
  • Any other information about your computer and its audio connections that you think might be relevant (for example, 2 GB RAM, 2.2 GHz, M-Audio Fast Track USB interface).

4) And even paler orange

  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)
  • The exact operating system you are using (for example, Windows 7 Service Pack 1, Mac OS X 10.6.8, Linux Ubuntu 11.10)
  • Any other information about your computer and its audio connections that you think might be relevant (for example, 2 GB RAM, 2.2 GHz, M-Audio Fast Track USB interface).

5) So pale it's almost grey

  • Your exact three-section version number of Audacity (for example, 2.0.0) - you can check this at Help > About Audacity or Audacity > About Audacity on a Mac computer (or the new shortcut ALT + H)
  • The exact operating system you are using (for example, Windows 7 Service Pack 1, Mac OS X 10.6.8, Linux Ubuntu 11.10)
  • Any other information about your computer and its audio connections that you think might be relevant (for example, 2 GB RAM, 2.2 GHz, M-Audio Fast Track USB interface).

Non-shortcut keys - the "Keyboard" span

Advice April 22 2012: Debate continues on white-on-black versus black-on-white.

26Apr12: Changed keyboard span to bold italic black text on white background.

  • Bill 13Apr12: The "keyboard" class and template have been created. You can try them out "in the wild" as you see fit.
    Syntax is:
<span class="keyboard">Return</span>

or 

{{keyboard|return}}

Both produce: Template:Keyboard

  • Gale: +1 for white background as this improves presentation inside a note.+1 for bold text inside the button as in "Return". Did you try white text on black? I guess it would look bad, but so many keyboards are white on black now.
  • Bill 12Apr12: -1 for bold text - I think there's enough emphasis with the border.
    • Gale 12Apr12: I'll drop to +0.5 for bold text, but I really don't think the current keyboard span is strong enough when amongst normal text without background. You could make a slightly darker border or slightly darker text with styling.
  • Steve: +1 for white background.
  • Ed 13Apr12: I would like to see white on black. I prefer the bold text. Hmmm, white on black works and sets it off from a button. Overall, I prefer the bold non-italic white on black.
  • Bill 13Apr12: I'm not convinced of the white on black. It may be too distracting. I could live with bold text in the white box.
  • Gale 14Apr12: I tried some lighter greyish backgrounds and used #4 "Progressively darker borders, bold text" in the "white on black keyboard span in context". Although a little distracting, the meaning is very considerably clearer to me. I do not have to read the text to know what those "buttons" are supposed to be.
  • Bill 14Apr12: I'm still -0.5 for the white on black, although the dark grey is a minor improvement. Since Ed and Gale prefer white on black I'm prepared to go with it unless Steve weighs in heavily against it.
  • Bill 20Apr 12: Changed the CSS for the keyboard template to plain white text on dark grey.
    • Peter 21Apr12: Bill, I'm finding this format far too obtrusive to the eye. On this page that you edited recently for example Metadata Editor I find my eye drawn to the strong buttons as a focus, making it difficult to concentrate on the text and thus hindering readability. Can we try the lighter grey that I originally voted for #6 (though I suspect that may prove to be too strong in real use).
    • Bill 21Apr12: Peter, I agree. I've changed the CSS to the slightly lighter grey but I still think it's too strong. I always preferred the plain text with a white background and medium grey border - it emphasized that it was a key press without smashing you in the face.
      Added #4 which is lighter grey still (#666666 versus #504A4B in #3) but that just looks "faded".
    • Peter 22Apr12: that's an improvement Bill, but I still think its too oppressive on the page, the Metadata Editor page is a good test case. I am switching my vote to the #2 that Gale voted for as one of his 0.75s - and I do prefer the transparent background so that they take the note color when in a note div (similarly for other divs).
    • Bill 22Apr12: Adding my vote to to 'black on white bold italic #2'. Since the button template keeps its grey fill inside a note I think the keyboard template should keep its white fill. The bold italic of the keyboard template makes it sufficiently different from the button template, and is consistent with the bold italic of the key template - see 'Mixing button and keyboard template in the same note..." below.
      Putting off changing the CSS until others can weight in.
    • Gale 26Apr12: The lighter grey background (#666666) didn't look too faded to me on Metadata Editor when I tried it, but I think if {{keyboard as now is mixed with {{button it gives too much prominence to the key press. OTOH #2 in "Black on white, bold italic, progressively darker borders" barely has enough difference with {{button to my eyes. I don't like transparency as a solution. In the above "Example: (from Splitting a recording into separate tracks)", in the CD burning line, I've used "outset" border style to mimic a button. I don't think that's over the top and actually gives a less muddy impression where buttons are close together in the text. "Outset" or some other border styling would make me happier with reverting to black on white for {{keyboard.
    • Bill 25Apr12: I like the outset border - it does look more like an on-screen button.

Black on white, plain italic, progressively darker borders

  1. Use keyboard Home, End or arrow keys to navigate to individual characters.
  2. Use keyboard Home, End or arrow keys to navigate to individual characters.
  3. Use keyboard Home, End or arrow keys to navigate to individual characters.

Black on white, bold italic, progressively darker borders

  1. Use keyboard Home, End or arrow keys to navigate to individual characters.
  2. Use keyboard Home, End or arrow keys to navigate to individual characters. Gale +0.75, Peter +1, Bill +1
  3. Use keyboard Home, End or arrow keys to navigate to individual characters.

White on black, plain bold text, progressively lighter backgrounds

  1. Use keyboard Home, End or arrow keys to navigate to individual characters. (no border, not italic) Gale +0.75
  2. Use keyboard Home, End or arrow keys to navigate to individual characters. (no border, not italic)
  3. Use keyboard Home, End or arrow keys to navigate to individual characters. (no border, not italic) Gale +1; Ed +1
  4. Use keyboard Home, End or arrow keys to navigate to individual characters. (no border, not italic)

The white on black keyboard span in context

  • Tag Value: Type in the data you want for each Tag, or accept the data already present from an imported file. You don't have to fill in every value. When exporting multiple files, the "Track Title" and "Track Number" tags are pre-filled automatically from the names and ordering of the tracks or labels.

    Single-clicking on a value field (or navigating into it with the keyboard arrow keys) selects that field - typing will replace the contents. Tab can be used too, and also permits navigation into the buttons below the Tag and Value fields.

  • Double-clicking a field (or selecting it, then using keyboard F2) highlights the text in the field. This allows the text to be edited rather than merely replaced, and permits cut, copy or paste using standard system shortcuts or a right-click context menu. Use keyboard Home, End or arrow keys to navigate to individual characters. Once a value field has been replaced or edited, press the Return key to select the next value field, or click in any other one to select it.

The black on white span in context:

  • Tag Value: Type in the data you want for each Tag, or accept the data already present from an imported file. You don't have to fill in every value. When exporting multiple files, the "Track Title" and "Track Number" tags are pre-filled automatically from the names and ordering of the tracks or labels.

    Single-clicking on a value field (or navigating into it with the keyboard arrow keys) selects that field - typing will replace the contents. Tab can be used too, and also permits navigation into the buttons below the Tag and Value fields.

  • Double-clicking a field (or selecting it, then using keyboard F2) highlights the text in the field. This allows the text to be edited rather than merely replaced, and permits cut, copy or paste using standard system shortcuts or a right-click context menu. Use keyboard Home, End or arrow keys to navigate to individual characters. Once a value field has been replaced or edited, press the Return key to select the next value field, or click in any other one to select it.


Black on white inside a note

Double-clicking a field (or selecting it, then using keyboard F2) highlights the text in the field. This allows the text to be edited rather than merely replaced, and permits cut, copy or paste using standard system shortcuts or a right-click context menu. Use keyboard Home, End or arrow keys to navigate to individual characters. Once a value field has been replaced or edited, press the Return key to select the next value field, or click in any other one to select it.

Black on white inside a note, with a white background

Double-clicking a field (or selecting it, then using keyboard F2) highlights the text in the field. This allows the text to be edited rather than merely replaced, and permits cut, copy or paste using standard system shortcuts or a right-click context menu. Use keyboard Home, End or arrow keys to navigate to individual characters. Once a value field has been replaced or edited, press the Return key to select the next value field, or click in any other one to select it.

Mixing button and keyboard templates in the same note - is there sufficient difference?

  • By default, Metadata Editor appears for each exported file after choosing the file format in the Export File or Export Multiple dialogs.
  • When using Export Multiple, it's often easier to uncheck "Show Metadata Editor before export step" in Import / Export Preferences, then enter any tags common to all tracks at File > Open Metadata Editor... before exporting. Audacity will then add the automatically generated Track Title and Track Number tags for each exported file without the Editor appearing.
  • Metadata Editor shows data for the most recently imported track in the project, not the selected track. If you need the editor to show separate data for each track, import the files into separate projects.
  • Use the OK button in Metadata Editor to complete the Export. The Save... button only saves an optional template of Tag names and values.

Double-clicking a field (or selecting it, then using keyboard F2) highlights the text in the field. This allows the text to be edited rather than merely replaced, and permits cut, copy or paste using standard system shortcuts or a right-click context menu. Use keyboard Home, End or arrow keys to navigate to individual characters. Once a value field has been replaced or edited, press the Return key to select the next value field, or click in any other one to select it.

  • By default, Metadata Editor appears for each exported file after choosing the file format in the Export File or Export Multiple dialogs.
  • When using Export Multiple, it's often easier to uncheck "Show Metadata Editor before export step" in Import / Export Preferences, then enter any tags common to all tracks at File > Open Metadata Editor... before exporting. Audacity will then add the automatically generated Track Title and Track Number tags for each exported file without the Editor appearing.
  • Metadata Editor shows data for the most recently imported track in the project, not the selected track. If you need the editor to show separate data for each track, import the files into separate projects.
  • Use the OK button in Metadata Editor to complete the Export. The Save... button only saves an optional template of Tag names and values.

Double-clicking a field (or selecting it, then using keyboard F2) highlights the text in the field. This allows the text to be edited rather than merely replaced, and permits cut, copy or paste using standard system shortcuts or a right-click context menu. Use keyboard Home, End or arrow keys to navigate to individual characters. Once a value field has been replaced or edited, press the Return key to select the next value field, or click in any other one to select it.

Button span

Advice 26Arp12 Changed button class to use outset border per discussion.
Other button-type templates use the same background and border colours.

Keeping this here for reference.

  1. click the Select All button.
  2. click the Select All button.
  3. click the Select All button.
  4. click the Select All button.
  5. click the Select All button.
  6. click the Select All button.
  7. click the Select All button.
  8. click the Select All button.
  9. click the Select All button.Gale +0.5
  10. click the Select All button.Gale +1, Peter +1
  11. click the Select All button. Ed +1; Bill +1; Gale +0.5
  • Gale 14Apr12: I like these but feel the border is a little too strong.
  • Bill 14Apr12: These are all based on the button class. See MediaWiki:Common.css for the current definition.
    I think all the "buttons" should have a consistent background and border. Added a "plain" button to the list below for comparison.
    At this point I think it makes sense to edit the CSS to see how all the buttons look.
  • Bill 14Apr12: Edited button class in the CSS to make #9 in the above list.
  • Bill 17Apr12: Is it possible to reach consensus on the look of the various buttons by April 20?
  • Gale 19Apr12: In the buttons above I can see the sense of the lighter background so I have moved by votes to the lower three. I prefer #10 but don't really care. I assume the same colours will be used for the templates below yet to be created.

    -1 on the alternative re-write of point 4 as posted because VI users possibly may not "hear" the unchecked state of the box even if you add it in image hover text (which you should). However I think you could do something similar and just say "Unchecked" or "Checked" to right of the template.

  • Bill 20Apr12: Additional templates created, examples below. Rewrite of "point 4" in example text.

Export {{button|Export}}

selected radio button Ask User {{RadioSelected|Ask User}}

unselected radio button Do not copy any audio {{RadioNotSelected|Do not copy any audio}}

checked checkbox Ergonomic order of transport toolbar buttons {{CheckboxChecked|Ergonomic order of transport toolbar buttons}}

unchecked checkbox Show 'How to Get Help' dialog box at program startup {{CheckboxNotChecked|Show 'How to Get Help' dialog box at program startup}}

Export Format  menu dropdown {{DropdownMenu|Export Format}}

Advice The last five of these are available as templates only, not as spans.

Example: (from Splitting a recording into separate tracks)

  1. Click on File > Export Multiple....
  2. Choose the Export Format from the pop-up menu:
    • for CD burning choose AIFF (Apple) signed 16-bit PCM if you're using a PPC Mac, or on Intel Mac use AIFF (Apple) signed 16-bit PCM or on Windows or Linux use WAV (Microsoft) signed 16-bit PCM
    • for loading into an MP3 player, choose MP3 files  menu dropdown
    • for loading into iTunes/iPod you can export as AIFF or WAV and use iTunes to convert the WAVs to AAC or MP3.
  3. Click the Choose... button and pick the place where your exported tracks will be saved.
  4. Under Split Files Based On:
    • checked checkbox Labels should be checked
    • unchecked checkbox Include audio before first label should be unchecked, as there is no audio before the first label
    • Under Name Files, checked checkbox Using Label/Track Name should be checked.
  5. Click the Export button.
  6. Metadata Editor will appear for the first song. The Track Title and Track Number will be pre-filled from the labels, but you can enter any additional information for that song that you wish (for example, Artist Name and Album Title).
  7. Click the OK button in the Metatdata Editor (not the "Save" button).
  8. Metadata Editor will appear for the next and the subsequent songs; as before, enter any additional information and click "OK" for each window. When you click "OK" on the window for the last song, all the files will export.

4. Make the following selections:

  • Under Split Files Based On:
    • checked checkbox Labels is checked.
    • unchecked checkbox Include audio before first label is not checked.
  • Under Name Files:
    • checked checkbox Using Label/Track Name is checked.

A "Path" span

Advice April 23 2012: Some debate over font size and readability remains.
  • Bill 13Apr12: The "path" class and template have been created. You can try them out "in the wild" as you see fit.
    Syntax is:
<span class="path"><yourhome>/Library/Application Support/audacity</span>

or 

{{path|<yourhome>/Library/Application Support/audacity}}

Both produce: <yourhome>/Library/Application Support/audacity

  • Ed 18Apr12: There is a disparity in perceived font size when we use the monospace default. Just to see the difference, I added "big" to the green sample Gale (and I) prefer below--IMVHO it is better though maybe a tiny bit too much.

The wiki has a "path" template. Do we want one? How about ...

  1. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity
  2. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity
  3. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity
  4. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity
  5. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity
  6. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity Gale +1; Bill +1
  7. The audacity.cfg file can be found in gTTheCFg <yourhome>/Library/Application Support/audacity ...testing font-size:1.1em
  8. The audacity.cfg file can be found in gTTheCFg <yourhome>/Library/Application Support/audacity ...testing font-size:1.15em
  9. The audacity.cfg file can be found in gTTheCFg <yourhome>/Library/Application Support/audacity ...testing font-size:1.2em
  10. The audacity.cfg file can be found in gTTheCFg <yourhome>/Library/Application Support/audacity ...testing font-size:1.3em Ed +1
  11. The audacity.cfg file can be found in gTTheCFg <yourhome>/Library/Application Support/audacity ...testing font-size:1.5em
  12. The audacity.cfg file can be found in gTTheCFg <yourhome>/Library/Application Support/audacity ...testing font-size:1.55em this gives vertical parity
  13. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity no span for comparing mono with plain
  14. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity
  15. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity
  16. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity
  17. The audacity.cfg file can be found in <yourhome>/Library/Application Support/audacity


  • Gale 12Apr12: -1 for red text which looks like a broken link. +1 for the idea of having a template. Some kind of purple?
  • Bill 12Apr12: agreed -1 for red. Added some greens. I'm not serious about that last one! I couldn't resist trying a little retro "glowing green text on a black screen" :-)
  • Gale 14Apr12: I'm OK as is, or the green one I voted for. I marginally prefer the green to what we have now. I think there is only a marginal improvement over black in either case.
  • Bill 14Apr12: Agreed, I think it's the monospace font that really sets it off. I'm OK with 4, 5 or 6.
  • Gale 19Apr12: Don't like the "big" font much. Another reason against purple is that it is very close to the "visited" colour for URL's that some browsers use.
    • Ed 19Apr12: At zero magnification on my 1920x1080 27" monitor I cannot read the "default mono" font--can barely tell it is text; look at the following line of "normal" text--the default mono is much smaller than the surrounding text would be. Added some better sizing the "TheCFg " leader is just to measure ascenders & descenders.
  • Gale 19Apr12: Another decision; if we are dropping ~ for the Linux/Mac user's home directory, can we say "Your Home" and not "yourhome"?
    • Bill 23Apr12: '<yourhome>' is how I've been in the habit of writing it on the forum since I don't need the OP coming back and asking "what does ~ mean?". I'm fine with writing it as '<Your Home>' (the angle brackets hopefully emphasize to the Mac user to substitute their home directory). If we want to keep using '~' that's also fine with me.
  • Peter 19Apr12: -1 for red text, black text and the horrid green-on-black, otherwise agnostic

Decided

Alternative "Menu" span/template colours:

Decision: #2 below is the new menu highlight colour.

(keeping this here for reference)

  1. Click on Effect >Amplify #FFFFCC previous colour
  2. Click on Effect >Amplify #FFEEAA Steve +0.5; Gale +1; Peter +1
  3. Click on Effect >Amplify #FFEECC Bill +1
  4. Click on Effect >Amplify #FFDDAA Steve +1
  • Bill: I think 2, 3 and 4 look OK.
  • Steve: Changed my vote to 2 as a good compromise.
  • Gale: Changed my vote to 2 as a good compromise between 3 and 4.
  • Ed 12Apr12: one thing to keep in mind for spans which could be a hypertext link is that the link color (generally a modestly dark blue) must contrast well with the span color--the lighter the saturation of the span color the more likely the link will be obvious; there is probably some color wheel rule for picking contrasting colors. My vote--lighter is better.
  • Bill 12Apr12: To my eyes (and others I've asked), the old yellow menu highlight almost disappears when it is behind bold blue link text. I think this is some kind of colour trick the eye/brain system does. So, yes, there is probably some colour-wheel rule that would at least say which colour is "bad" to have behind the blue text. As for "lighter is better" - there is a middle ground between "too light to easily see" and "so dark it is distracting".

The "Key" span

Decision: #1 below is the new 'key' (shortcut) highlight colour.

Keeping this discussion here for reference.

  1. Press CTRL + A. Gale +1; Steve +1; Bill -0.5, Peter +1
  2. Press CTRL + A. Gale -1, Peter -1
  3. Press CTRL + A. Steve +1; Bill +0.5; Gale -1, Peter -1
  4. Press CTRL + A. Gale +1
  5. Press CTRL + A. Bill +1 (changing my vote)
  6. Press CTRL + A. Or Gale +1 for this key span also
  • Gale: Having looked at the green key spans, I think the darker ones are too far from other colours we use in the Manual, and the "intro div" colour is too light for the small surface area of a span. I think any not too prominent colour with a light blue/green hue (more blue than green) would work for me.
    I think the button span benefits from a border but most of the buttons are too prominent in strength of border and background colour. I voted for a couple of them.
    • Bill 10Apr12: +1 for "more blue than green" in the key spans
      I've added a selection of button spans (above) and transferred votes to them. There's now a selection of lighter fill colours.
  • Bill 14Apr12: Peter? Ed? Any comments? If there's no other votes or changes before April 17 then #1 it is.

Shift-modified clicks and arrow key presses

Decisions:

Proper usage is:

  1. Hold the SHIFT key while clicking in the waveform.
  2. Hold SHIFT while pressing LEFT
  3. Press SHIFT + K

Why do we highlight the Shift key as a shortcut? Is it just to highlight it since before we have no consistent way of doing so?

What makes more sense here:

1. It's possible to change the selected time range and which tracks are selected independently. To change the selected time range, you have several options:

  • Move the mouse pointer to one of the edges of the selection until it changes to the "finger with pointing hand". Click and drag to change that edge of the selection.
  • Hold Shift while clicking near one of the edges of the selection to extend or contract the selection to the time point you clicked on.
  • Hold Shift while using Template:Keyboard or Template:Keyboard to extend the selection from the left or right edge respectively.
  • Hold Ctrl + Shift while using Template:Keyboard or Template:Keyboard to contract the selection from the right or left edge respectively.

2. It's possible to change the selected time range and which tracks are selected independently. To change the selected time range, you have several options:

3. It's possible to change the selected time range and which tracks are selected independently. To change the selected time range, you have several options:

  • Move the mouse pointer to one of the edges of the selection until it changes to the "finger with pointing hand". Click and drag to change that edge of the selection.
  • Hold Shift while clicking near one of the edges of the selection to extend or contract the selection to the time point you clicked on.
  • Press Shift + Left or Shift + Right to extend the selection from the left or right edge respectively.
  • Press Ctrl + Shift + Left or Ctrl + Shift + Right to contract the selection from the right or left edge respectively.
  • Bill 19Apr12: I have not strong preference for any of these, although I feel 2 and 3 are more "consistent".
  • Ed 19Apr12: my pref would be to consolidate both "key" and "keyboard" using only "keyboard" maybe conjoining any combo; use the white-on-black, no italics, bold OK but no pref here. Now that I look more closely, I think my problem with the leading/trailing space around the + is due to the kerning of italicized text--if it is not italicized I have much less problem with the space.
  • Bill 19Apr12: Thanks, Ed, for the further examples.
    I'm -1 on using the same span for shortcuts and non-shortcut key presses.
    I'm also -1 on "conjoining" key presses when they are not a shortcut. My thought was that the span simulates a key on the keyboard, and there is no key labelled "Shift+Ctrl+A". While there is no key labelled "← Left Arrow" we probably can't use the ← on its own since it won't be read properly by screen readers. We do what we can.
    I prefer "Hold Template:Keyboard while pressing Template:Keyboard" over "Press Shift + Left Arrow" since it emphasizes that the user can hold the Shift key while repeatedly pressing the arrow key.
  • Gale 20Apr12: I only mildly agree with Bill about the need for separate "key" and "keyboard" spans/templates. If we used just the "keyboard" span/template it would actually avoid a lot of the fine decisions we're making here.

    I strongly prefer "Hold Shift while pressing Template:Keyboard" over "Hold Template:Keyboard while pressing Template:Keyboard" because SHIFT can never be used other than with a shortcut. And since these are shortcuts, just a repeated iteration of them, I feel "Hold SHIFT while pressing LEFT" is purer. If user does not know LEFT means "Left arrow" then they are not going to be able to use single iteration shortcuts anyway. If we use Template:Keyboard with an arrow, let's have the arrow on the right as in Template:Keyboard.

  • Bill 20Apr12: I have no strong objection to "Hold Shift while pressing Template:Keyboard" nor to "Hold SHIFT while pressing LEFT". The latter is more consistent, as SHIFT + LEFT is a shortcut.
    When I started this business of the keyboard template I was thinking of those instances where we now write <Key> as in Metadata Editor.
    I was just playing with the arrow symbols. I'm not suggesting we need to adopt them, I just wondered how they'd look. I'm not convinced they're an improvement. I do think if we are going to use them we need a space or non-breaking space between the symbol and the word.
  • Gale 21Apr12: Unless someone weighs in strongly against, let's go with "Hold SHIFT while pressing LEFT". If you feel we need to say on Keyboard Shortcut Reference that LEFT, RIGHT, UP and DOWN mean the arrow keys, add that to the text for each.

    If people understand left/right/up/down then we don't necessarily need "arrow" in Template:Keyboard. The choice should be between Template:Keyboard and Template:Keyboard. But where does it end? Do we then want SHIFT ⇑ ?

  • Bill 21Apr12: OK, can the arrow symbols. I can't imagine anyone who doesn't know what Template:Keyboard means.
    +1 for "Hold SHIFT while pressing LEFT".
Retrieved from "http://alphamanual.audacityteam.org/m/index.php?title=User:Billw58/Templates_and_Spans&oldid=17359"