User talk:Galeandrews

From Audacity Wiki
Revision as of 17:23, 21 November 2007 by Suf (talk | contribs) (Several little notes and replies...: Replies to Gale)
Jump to: navigation, search

Templates limitation, no recursion

Hi Gale,

I just realised another limitation of the templates mechanism: You can not invoke a template from the string you send to another template. Specifically, I tried to format an external link in an intro, like this:

{{intro|...{{external|...}}...|...}}

That fails, as the interpreter is not recursive on this level, and thus is not able to nest template invocations like this. (That is also expressly stated on the Wiki template editing help page , section FAQ.)

The implication is that intros (and of course any use of a template) can only contain "plain text", or text formatted with other wiki or html functions. Pity. Suf 12:34, 16 November 2007 (PST)

Hi Suf

I came across this last night when trying to include an external link in the Vocal Removal inroduction but had not had time to figure whether 1= etc. would work. I'm sure <nowiki> won't work as it will stop the nested temploate running. But it looks from USB turntables that you cracked it with n=.

Use n= according to the string of the template where you invoke the nested template e.g.

{{intro|1=This {{external|[http://www.numark.com/ Numark]}} page is great.
|2=Several manufacturers {{external|[http://ion-audio.com/index.php Ion Audio]}},
{{external|[http://www.numark.com/ Numark]}}, use the current version of Audacity.}} 

produces:

This Numark  page is great.
Several manufacturers Ion Audio , Numark , use the current version of Audacity.


and

{{intro|1=This {{external|[http://www.numark.com/ Numark]}} page is great.|2=}}


produces:

This Numark  page is great.


that is, you need to supply "2=" after the second pipe even though it contains no text. Assuming this has general applicability to nesting templates inside each other I will write it up on the Templates page and on the Template:Intro page which has a second string.


Hi again Gale,
Pretty strange - never mind, if it works it is ok! Suf 21:51, 16 November 2007 (PST)


Missing page?

Hi Gale,

I may have missed it (I am known to occasionally miss things...), but I can not find a page on basic installation of Audacity. Suf 12:34, 16 November 2007 (PST)

The Wiki doesn't have this because generally installing Audacity (getting to the point where you are ready to launch Audacity for the first time) isn't much of a problem as long as your download manager has not corrupted the installer. Mac users have problems sometimes as they try to run Audacity from inside the .dmg image which will create problems, so I will add that to Mac Bugs. Though it would be nice, I'm not sure there is a burning need for (what amounts to) a guide to installing Audacity on Windows.


Hi again Gale,
I agree, there may be no burning need for it. I just thought that on the main page I would (if I were a prospective user looking for information) expect a link to a page "Where to get it" or something similar. Or perhaps just an additional sentence on the top of the main page like: "Audacity is very simple to install. Download from http://audacity.sourceforge.net/download/ ." or similar. Suf 21:51, 16 November 2007 (PST)


Latest musings

Hi Gale,


1) "menu" vs "shortcut"

On the Splitting recordings into separate tracks page I pondered whether to use {{menu|...}} or {{shortcut|...}} for the Play and Pause buttons. I chose the former, as I see it more similar to clicking a dropdown menu. Thus, to me {{menu|...}} means click something, while {{shortcut|...}} means type on the keyboard. Also, there are true shortcuts: to start recording, you either click Record button icon or type R on the keyboard!

Now, mind you, I don't say this is the only view, or the "correct" view, it's just how I came to visualise it.


Hi Suf - indeed there is that way of looking at it, I just felt it confusing to imply there is a path for a button when there isn't. Fact is that strictly, neither {{Path or {{Shortcut is probably correct and probably an image should be used wherever possible (though if you state you can use P instead of the Pause button that is perfectly OK). An image may be best as after all the user may not be familiar with the buttons (and the page in question already assumes the user knows that he uses the Record button to begin with..). Even if you can't use an image, probably just boldening the name of the button in the text is least confusing?

Yes, using an image and then putting the function in bold (Pause), or perhaps bold italics (Pause) may be the reasonable solution. /SUF


2) Style for Hints

It appears you are experimenting with further styles for hints:

HINT: Is this a new style to be used?

Should we try to make a template for "hints" too? Now that we (possibly) solved the nesting problem it could be worth it.


Yes I had it written down to make a new {{Template:Hint}}

HINT:


and a new {{Template:Instruction}} or some similar name:

Please make sure you do:
  1. this
  2. this and
  3. this

for something that is not a "warning" (you must not) but an advice or instruction set (e.g. the instructions on Feature Requests). A lot of instructions have the blue colour we have now settled on for intros. but we should not use the same colour for advice and instructions.

I'd like to use these background colours for the templates but am not necessarily certain about the text colours e.g. should the hint text be black or should the advice text be some other dark colour?

If you have time, please do draft out a new page for each template.

Thanks

Gale

Right, I can probably give it a try tomorrow. /SUF

Template:Hint

Hi Gale,

Now there is a working, preliminary version of a Template:Hint. You can see it used on Test:Suf.

Still playing with it as you can, see especially as to text colour.

Addendum:

Should perhaps the {{Template:Intro}} also be furnished with a 1px border?

Thanks for this suggestion. I think bordering the intro takes away the additional emphasis from any instructions or hints which may be elsewhere on the page, so I'm minded to leave it without a border. What do you think from looking at these?

I slotted in 100%/88% font and indented/non-indented "Related pages". My vote is for indented (this makes it clearer it's tied more to the intro than the actual page content), 100% (arguable either way, but generally the related pages are quite important) with a list style, as I suppose we should. Also, should it be related "pages" or "articles" (we seem to have used "articles" to begin with, and this may be better, as sometimes we link to a category directly, and Category pages refer to "articles").


Audacity is fully supported under Mac OS X. However, there are a number of quirks, and because of subtle differences between Mac OS X and other platforms, you may discover bugs or issues that are specific to Mac OS X. This page is solely for recording such OS X-specific problems, in other words those that are specific to the Apple Mac OS X operating system and thus do not occur with Audacity on Microsoft Windows or Unix/Linux systems.
If you are looking to request a new feature for Audacity, please go to our Feature Requests page.


Template:Related


This page is intended as a reference point only. It is not constantly monitored by the Audacity team and is thus not meant as a direct method for obtaining technical support.

Before adding a report here, please:

  • Check the existing reports below thoroughly, plus our extensive online help resources as listed on our Reporting Bugs page, to see if your issue is already known.
  • Only add an issue on this page if you're sure it is something specific to Macs only, you're sure of your facts, and that there is not some other explanation for the problem. In all other cases, please follow the instructions on Reporting Bugs to get help and/or give us a useful bug report that we can follow up.




Audacity is fully supported under Mac OS X. However, there are a number of quirks, and because of subtle differences between Mac OS X and other platforms, you may discover bugs or issues that are specific to Mac OS X. This page is solely for recording such OS X-specific problems, in other words those that are specific to the Apple Mac OS X operating system and thus do not occur with Audacity on Microsoft Windows or Unix/Linux systems.
If you are looking to request a new feature for Audacity, please go to our Feature Requests page.


Related Pages:


This page is intended as a reference point only. It is not constantly monitored by the Audacity team and is thus not meant as a direct method for obtaining technical support.

Before adding a report here, please:

  • Check the existing reports below thoroughly, plus our extensive online help resources as listed on our Reporting Bugs page, to see if your issue is already known.
  • Only add an issue on this page if you're sure it is something specific to Macs only, you're sure of your facts, and that there is not some other explanation for the problem. In all other cases, please follow the instructions on Reporting Bugs to get help and/or give us a useful bug report that we can follow up.

Template:Related

Hi yet again Gale,

I am proposing a template for the "Related pages" section appearing on top of yet more articles. In short, I thought that the formatting could be:

  • Smaller font (88%, same as in Template:Hint)
  • No other special formatting
  • The header text "Related pages:" is built-in (which would of course necessitate parallel templates for other languages)
  • I personally prefer using list style (not part of template, must be typed in parameter string)

Have a look at Test:Suf where I have shown the different uses.

Also, a strange thing: I wanted to try setting line-height to a smaller number, but that proved impossible as the change was caught by the spam filter!!

Several little notes and replies...

Hi Gale,

Much discussions!


See Template:Related and Template:Hint for my views on those matters. Mind you, they are just that, my personal views. Now I think you should make the choice (I see myself more as a helping hand here, but expressing my opinion when I think it may be valid!)

Hi Suf

Thanks for your efforts.

Re Template:Related, I'm afraid I am turning very strongly against the smaller font and smaller line-height. To me it really begins to look silly on plain white once you go below medium browser font sizes. I see the smaller font as used for an "aside" or something of "secondary importance" that gives the message the user can skip it if not relevant. I don't see "Related articles" as secondary at all, hence why initially we were emboldening the links. For the same reason I don't like the practice of some Wiki authors of burying "related articles" in a footnote or as the last item in a long list of section headings. I didn't like to say so but I was a bit sceptical of the need for a template for this, and if I don't really like small font/line-spacing, then there isn't a lot for this template to do unless we let it indent. Taken as a whole I prefer indenting anyway, since most of the important pages are going to have intros. As it's indented it appears as part of the intro, which lets the user decide if they want to be on this page at all or should go instead to one of the "related articles".

Hi Gale. I leave the final decision to you. As I understand it, the variant indented with a table in the template, header included, standard font size, is the one you prefer. If you wish me to finalise it, I will (drop me a note), or feel free to do it yourself. Should you, rather, prefer to skip this template altogether that's fine too, it was after all no more no less than an idea to be tested.


Re Template:Hint somehow I find a bit of eye strain with the original colour scheme where there is a lot of text. I "think" I will go with the second one where the slightly different colour for the text is easier for me and yet doesn't look so different to "HINT" to be disruptive:

HINT: You must enable all the recording switches if you want to listen while you are recording. Note you cannot do this with "stereo mix"

Alternatively, we could make "HINT" this same colour (#254117) or even drop the word "HINT", which I am beginning to think is best. My reasoning is that including it is a bit "in your face" or "presumptuous" which would tend to discourage using it more than once or twice in a page whereas this is in fact a useful way to break the text up and get a secondary point across. Also in our Manual for 1.4 where we have a similar "Div class" for the purpose, we don't have any word which states what the purpose is.

The published "hint" template is fine!


Re formatting in-line code (or whatever it should be called) I can't make up my mind yet. I am, however, a little afraid we are starting to mix too many formatting styles. I do think, though, we should leave out color formatting... In that case standard bold and/or italics remain, or (possibly) using the <tt></tt> style - which I seem to remember you weren't to happy about.

I think at least, Template:Menu and Template:Shortcut were good moves and really make it easy to look away from the text at another app. or at the keyboard, look back and see what you need to see. My vote on balance is don't add any more colour formatting of text for now, but don't use Template:Shortcut for text emphasis unless it really is a shortcut, just embolden it. As I said the trouble with <TT> is that advanced browser options can always force all text to one font family/style, but incrementing the size or emboldening will always create a difference.

That's fine with me. Restricting (myself) to using "menu" and "shortcut" narrowly, and using bold and/or italics for any other emphasis.


Re {{Template:Instruction}} I think it can be done as soon as we have settled the Template:Hint.

OK. I don't think there is anything controversial here is there? I am assuming it will always be 90% width and centred to align with the intro. It looks as if in usage, an optional first and third string would be good, both of which are italicised, left-aligned and indented to align with the text of the instructions (after the bullets or step numbers). The Feature Requests instructions are a good example.

Now that "hint" is published I can make a copy of it, just changing the background color. Will do later today, unless you beat me to it!


I am also going to press again for the Edit toolbar to have a table button (other Wikis have this). If not, for those who find tables difficult, I have been wondering about a "cut and paste" area where you could grab some common table layouts e.g it gives you "text of first row here, text of first column here" and you just overtype what you want.

Thanks

Gale