Talk:Main Page

Editorial Consistency

see Wording

Page Families

OK. So we'd like to be consistent in page formatting. We have:

• Family of pages for Preferences: I'd like to propose that we use headings for naming the static boxes, e.g. ==Recording== for the static box named 'Recording' and then bullet points for the items within the static box, i.e. we follow the design of Audio IO Preferences. I've been using two layers of bullets in some of the other preferences pages.

Update: after discussion on devel-list about accessibility issues, I think we should settle for James' plan which means ==name of static box or panel section== then a bulleted list for items within the static box or panel section. The first text in each list item should be the name of the item within the box or section, in bold. Using ===item within static box=== is another accessible solution, but it takes twice as much space and if we have a contents box, will make that so long as to be very intrusive for sighted users. Possibly this solution should be adopted for Menu pages as well (i.e. second order header then bulleted list of menu items within each section). However I'll gauge opinion on the list first - Gale

Reply by Gale: James, thanks for comments. I don't especially like headings on the Preferences pages (in fact on one such page - will have to check which - they got so much in the way that I got rid of them). They also looked very odd as there was not much text, so that the "Contents" was one-third or so of the height of the page. In those circumstances, I think headers are questionable, and pragmatism is better, but do screen reader issues mean we have to have headings irrespective? Can/should Contents sections be suppressed in the printed version only, or must it be forced with __NOTOC__ on the page?

Another thing about headings is the size. We normally seem to use == (h2) for the first order and down from there but this is not always consistent and sometimes even authors that use it forget and use = (h1) for first order in the same page. I tend to prefer h1 then h3 for second order ignoring h2. This is because with h3 being bold it kind of looks more important than h2, given h2 is not very much larger than h3... but I don't have strong views. Some people like h1 then h2, but that means second order is underlined as well as first. I think the objection to h1 is the size relative to main text?

• Family of pages for Menus: I like the three column table layout used in Track Pop-Down Menu, with the image of the menu on the left, the names of the items in the middle column and descriptions in the right column. However, it may not work well for pages which need long descriptions for each menu item. Perhaps we should do 'the same thing' as for preferences and give:
  • The image, and then
  • Headings for each section within the menu, and then
  • Bullet points for menu items within each section?

I quite like the three column style too (actually four columns because columns two and three must be space-separated for it to look decent). On that page, "Set Rate" actually has two paragraphs and it still doesn't look bad. Another problem with "image, then headings underneath" is that it looks pretty odd because the image will be tall in relation to width (and it wastes space). But again if we must have headings for screen readers we may have to rethink...

• Family of pages for Toolbars: Should we use Control Toolbar as the prototype? What I like here is the use of just the button icon without the button background. It makes the section describing each button take little space. It encourages us to keep it brief.

Yes I like this too and not the old headered text underneath if we "can" get rid of headers. This is another page where (for sighted users) a Contents section seems redundant to me. Are these images of buttons without background in the source (i.e. not lovingly hand-cropped?).

Gale, these are just suggestions, so that we can fix on something. I think it's more important that we are consistent than what those choices of consistency are. JamesCrook 04:45, 9 December 2007 (PST)

Structure

Audacity Selection and Selecting are similar pages both linked to from the Main page. Is this overlap what we want? (probably yes, but just checking). JamesCrook 15:23, 24 November 2007 (PST)

Looks a bit odd to me. I'd say either make two paragraphs saying that Audacity depends on selections of audio and that it works on the basis of Tracks and Clips, or (better) delete Audacity Selection and Audacity Tracks and Clips altogether and use the Selecting and Tracks and Clips articles in the "Using Audacity" section. In either case the article to do with selection probably needs a quick note of the select all on none feature that is on by default.

On the Tools Toolbar page I've linked the individual tools to the comprehensive articles on the topic - e.g. for envelopes and for selecting. Should we do the same for the links on the main page rather than create new short pages for these tools? JamesCrook 15:23, 24 November 2007 (PST)

I can certainly see the top of Playing and Recording is a duplication of Control Toolbar. We certainly don't want that duplication.

There's at least three styles of writing in this manual.

• There's the remnants of the old reference manual- not linked to directly from the main page, but still visible via the FAQ.
• There's the detailed tutorial style of the main help.
• There's some newer reference help that is brief.

I'm thinking the reference section needs to stay brief, so that anyone can quickly see what the features are by reading the reference section. To understand how to use the features they'll either start in the tutorial sections, or get to the tutorials from links from the reference section. The old reference material is gradually deprecated as we replace it with newer stuff. Sound OK? JamesCrook 16:31, 24 November 2007 (PST)

Reference section looks quite verbose to me in places e.g. the Effects section in the Reference is longer than Applying Effects in "Using Audacity" and there is quite a bit of duplication. Splitting Stereo Tracks has no corresponding section for the Track Popdown Menu in Reference? Editing: Cut, Paste, and More in "Using Audacity" looks like a duplication of Edit in the Reference. I think this needs a serious rethink and I don't think the Reference section in many cases can even be useful unless it describes all the menus and Preferences properly (and non-geekishly). I'm beginning to wonder if we need more (or longer?) "Tutorials" - something along the lines of the sections of "Using Audacity" but integrated into a real life scenario. For example there might be "my first session editing an audio file" and so this includes importing, editing and export/save (but split sufficiently that sections can be accessed individually or returned to). Then instead of "Using Audacity", a proper "How do I ..." index (links only, no descriptions) that people can go to for how to do an exact thing. Examples of this would be "recording..//choose mono or stereo recording" (goes to Reference: Audio I/O tab of Preferences) "create a new track" (goes to Reference:Tracks Menu).... "recording..// adjust input levels" (goes to Tutorial:My first recording).

Gale