User:Billw58/Templates and Spans

From Audacity Development Manual
< User:Billw58
Revision as of 14:34, 26 April 2012 by Billw58 (talk | contribs) (add alternative intro and note div colours; re-arrange page; more notes)
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 and Note Colours

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

Intro

Manual:

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 + ,).

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

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.

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.

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=17285"